Context before action
Definitions, ownership and taxonomy let people judge relevance before a request enters review.
Work / Data Market Point
Enterprise dataUX/UI leadershipInformation architectureDesign system
Data Market Point
From finding a dataset to requesting access and following the request to delivery, in one place.
01
Data discovery only works when it leads to a clear next step
The challenge was not just finding a dataset. It was deciding whether it was right, who owned it and what happens after access is requested.
Data, reports and terminology were scattered across domains with different owners. People knew what they needed and still couldn’t tell whether an asset was relevant, or whether they could request it.
Data Market Point puts discovery, meaning and access in one experience. The official catalog and taxonomy stay where they belong.
It borrows the familiar marketplace pattern, but it never pretends that controlled data is an instant purchase.
02
Discover, understand, request, govern, track
At every step of the access journey you can see the decision and where it stands.
Discover
Search across asset classes and narrow the catalog with filters that use enterprise language.
Understand
Inspect the definition, owner, status, taxonomy and related assets before deciding what to request.
Request
Collect the assets you need in a basket and give one business reason for the whole request.
Govern and track
Keep review, delivery, rejection and hold states explicit instead of hiding the work after submission.
03
The marketplace metaphor needed firm boundaries
Three decisions kept useful discovery from turning into a shopping flow that misleads.
Governance stays authoritative
The marketplace shows people a clear way forward. The enterprise catalog stays the source of taxonomy and control.
Status stays with the user
Access remains an experience after the basket: people can follow delivery, rejection, hold and follow-up.
04
The access journey in five screens
The views below show the interface, built on fictional content. They show the whole interaction model without exposing anything confidential.
Discoverstart with a searchable marketplace
A home that gives distributed information a shared entry point
Search, asset classes and discovery shortcuts establish one way into a large enterprise catalog. The headline carries a single serif accent word, and live catalog numbers sit in a quiet strip below.
The interface is shown on fictional content. Names, values and identifiers are invented, while the interaction anatomy follows the designed product.
Comparedifferent assets need one readable language
Search results that make asset classes comparable
Filters and consistent result anatomy help a person narrow a broad catalog without learning a new interaction pattern for each domain.
Master and detail share one view: the first result opens in a preview pane, so comparing assets never means leaving the list.
Understandmeaning and ownership come before access
An asset detail view that makes a request an informed action
Definitions, ownership, status, taxonomy and related assets give a requester the context to assess an asset before adding it to a basket.
Status, owner, location and refresh date sit above the fold, with ratings and comments one section away. Governance shows up as useful information, not as an obstacle after the decision.
Requestone justification in the right place
A basket that turns a selection into a proper request
Relevant assets can be grouped before the requester explains the business need. This preserves the marketplace mental model while making the review boundary explicit.
Validation appears in place and is summarised on top, so nothing is lost while the user fixes it. The primary action stays quiet until the request is complete.
Tracksubmission is not the end of the product
Requests and status that keep governance work accountable
The requester can return to a history of ordered items and see delivery, rejection, hold and follow-up states without leaving the product.
Each asset keeps its own four-step timeline, red where progress stopped, and a side sheet shows the owner’s feedback with a one-tap resubmit. Controlled access stays legible after the first action.
05
The design starts from variables, not from screens
Every colour, space, radius and type size is a variable, and every screen is assembled from components. Dark mode is a mode, not a second set of drawings.
Systemone palette, defined as tokens
A blue and navy palette, built as a token system
The portal blue, the deep navy and the green, amber, red and pink used for status sit at the centre of colour ramps. They feed a Semantic layer with Light and Dark modes, so a component never holds a hex value.
Type pairs Inter with one italic serif accent and Geist Mono for data labels.
Themesone set of screens
Dark mode without redrawing a single screen
Frames switch the Semantic collection to Dark and every component follows. Surfaces, borders and status colours were chosen for contrast in both modes.
Status never relies on colour alone: every badge carries a label, and every step marker carries an icon.
Foundations
Five variable collections, 22 text styles bound to variables and five effect styles.
Icons
95 stroke icons, each one component, coloured by a single Tone variable.
Components
67 components and sets built from atoms to templates, with slots for page content.
Screens
51 screens and states assembled only from those components, then reused in the flow boards.
06
Eight flows, every state drawn
Each flow board lays its screens out at full size, with modals, popups, error paths and variants, joined by labelled arrows. A map shows how the boards connect.
Mapeight boards, one main journey
From discovery to a tracked request, with the rest branching off
The main journey runs discover, evaluate, request, track. Favourites and templates, account and assistant, system states and the returning-user dashboard branch from it.
The boards hold 11, 9, 12, 7, 9, 7, 7 and 5 screens, 67 placements in all.
Requestthe core task, step by step
The request flow shows the happy path and every way it can break
From add to basket through validation, confirmation and the success page. Branches show the empty basket, losing the connection and an expired session.
Every arrow names the user action, and error paths are red so they can be found at a glance.
Loading
Skeletons hold the layout while data arrives, so nothing jumps.
Empty and no results
Empty states explain themselves and offer one next step; a fuzzy match says what it searched for instead.
Validation
Errors appear in place and are summarised on top.
System
Offline, expired session, 404, server down and planned maintenance each have their own screen.
07
A focused MVP became a globally used product
From concept to MVP in three months, then 2.5 years of development.
Concept
Framed a single, complete discovery-to-access experience
The interaction model connected search, evaluation, request and status from the start.
governed marketplace model
MVP
Moved from concept to MVP in three months
Business analysis, engineering, testing and UX/UI worked from one shared product language.
3 months
System
Implemented an early internal design system in the product
I applied a reusable system in Data Market Point after contributing to the wider internal design system for approximately six months.
reusable product foundations
Rollout
Developed the product over 2.5 years and rolled it out globally
General anonymized feedback informed continued development and additional capabilities.
worldwide employee usepositive feedback
“A data marketplace is useful only when it turns a search result into an understandable, governable next step.”
Data Market Point product principle
08
I owned UX and UI end to end, working closely with the whole delivery team
I owned the experience, put the design system into the product and stayed in constant contact with the people responsible for requirements, delivery and quality.
UX and UI
I was responsible for the whole experience and interface: interaction model, information architecture, down to the detailed UI.
Design system
I implemented an early internal design system in the product, building on approximately six months of contribution to that wider system.
Business analysis
The Business Analyst owned requirements and product definition. I worked closely with them to keep decisions clear in the experience.
Engineering and quality
Two backend developers, two frontend developers and one tester each owned their part, and we stayed aligned on delivery all the way.
09
The outcome was one experience for governed discovery and access
What was delivered, and how it was used.
Enterprise UX here is information architecture plus operational clarity. Search gets more useful when people understand a result, make a justified request and see what happens next.
The product went live globally and was used by employees worldwide. This case keeps client names and source data out of the text and the images.