Platform User Research and Journey Mapping

The data platform team’s dashboard showed four hours of active service-desk handling for an initial dataset access request. The clock excluded time waiting for approval and identity synchronization. Then the new product manager asked eight analysts to walk her through the last time each had needed a dataset they did not already have. The shortest account took six calendar days; the representative case below took nine. It began with a search that returned three similarly named tables, followed by questions in chat, a ticket requiring an unfamiliar access group name, and three days waiting for approval. After the grant, the query failed because the warehouse role did not include the table’s schema. A second request and another wait followed. The four hours described work within this journey, but left much of the analyst’s elapsed time unmeasured.

The product manager then read three months of the chat channel. Two fifths of the questions concerned five recurring problems, all visible in the walkthroughs. The company, timings, and dialogue are fictional. They illustrate why a platform team needs to examine user needs, the journey across systems and teams, and the work behind each touchpoint. Support messages provide evidence about reported difficulties; interviews and observation are needed to find experiences that never reach the channel.

Three levels of experience

Nielsen Norman Group distinguishes three scopes of experience: an individual interaction, a journey toward a goal, and the relationship built over time. These scopes help clarify what a design or measurement covers. A usable request form can belong to a journey that fails at approval, and a successful journey does not settle how someone experiences the platform over years of use.

Level	On an internal platform	What is designed	What is measured
Interaction	One screen, one command, one form: the access request page, the CLI that creates a service	The interface, its errors, its defaults	Task completion on that screen; time in it; errors
Journey	Getting from I need this dataset to a query that returns rows, across catalog, ticket tool, approver, warehouse, and chat	The sequence, the handoffs, what each step tells the user about the next	End-to-end time; steps; touchpoints outside the platform; how often support was needed
Relationship	A team’s years with the platform: every capability adopted or avoided, every ticket, every migration	Consistency across capabilities, what the platform promises and keeps	Retention, breadth of use, whether the team checks the platform first

The team’s dashboard covered service-desk handling within the journey. It missed the analyst’s wait for an approver and the work needed after the first grant failed to enable the query. Repeated experiences can influence whether a team considers the platform for another task, but a single incident does not determine that relationship. Developer experience examines developers’ lived work through feedback loops, cognitive load, and flow state. Those dimensions can be investigated within an interaction, across a journey, or over time; they are not another name for the relationship level.

Start with what people are trying to do

GOV.UK’s guidance on learning about users starts with the people who need the service and the outcomes they are trying to reach. A user need describes the intended action and its purpose, without prescribing an interface or technology. For the analyst, the need was to query an authorized dataset within the day she found it. A faster ticket tool was one possible response, to be evaluated against the rest of that journey.

Research should include intended users who struggle, abandon the route, or build an alternative, as well as those who complete the task. GOV.UK also includes people who provide support: on a platform, these include support engineers, access approvers, and administrators. They provide operational evidence alongside users’ accounts. Sponsors’ and architects’ suggestions about user needs remain assumptions to investigate; established policy requirements are a separate input. Asking only those who participate creates a risk of selection bias. The result may be unusually favorable or unfavorable depending on who responds and who is missing.

GOV.UK recommends combining existing evidence, interviews, and observation. The CNCF platforms white paper describes similar ways to learn, including issue trackers, surveys, interactive sessions, and usage observations. Discovery research gives the interview a concrete starting point: follow a recent task through its searches, waits, failures, and workarounds. Record whose tasks were examined and what remains unknown about other users. The resulting account of current journeys, user groups, and needs supports an investment decision, as discussed in Four of Sixty Teams Used It.

Map the journey, not the screen

A user journey map depicts a person’s progress toward a goal. Nielsen Norman Group identifies an actor, a scenario and expectations, phases, actions with thoughts and emotions, and opportunities for improvement. One viewpoint makes a map easier to follow; it does not make the account representative of everyone with that role. For a current-state map, connect steps and reported feelings to research evidence. A map of an anticipated journey can instead record design assumptions. Label those assumptions and what still needs validation. Actual user statements help explain a finding, but quoting them alone does not establish its frequency or cause.

GOV.UK’s whole-problem guidance asks teams to look beyond the transaction they own. A user can encounter a dead end between systems or be unable to choose among apparently equivalent routes, such as the three tables in the catalog. Mapping the wider journey may require coordination across teams or at program level. DORA likewise recommends investigating critical platform journeys, including starting a service and diagnosing a production problem. Choose journeys relevant to the users and decisions under investigation, rather than trying to document every possible path at once.

The representative nine-day case is mapped below in sequential phases. Durations are illustrative calendar time, including waits between actions; they sum to nine days. The first grant’s active handling is contained within these elapsed intervals, not added to them. The final row marks completion at the end of the second request phase.

Phase	Actions	What the analyst said (fictional verbatims)	Touchpoint and owner	Elapsed
Find	Search the catalog; open three candidates; ask in chat which is current	Which one of these is the real one?	Catalog (platform); chat channel (platform)	One and a half days, including waiting for clarification
Request	Open a ticket; look up the access group name; ask in chat again	I don’t know what group I’m supposed to ask for.	Ticket tool (IT service desk); chat (platform)	Half a day
Wait	Nothing; check the ticket twice a day	Who approves this? Should I chase someone?	Approval email (data owner)	Three days
Get access	Receive the grant; run the query; get a permission error	It says I have access. It says I don’t have access.	Warehouse (warehouse admins)	One day, mostly overnight sync
Request again	Ask in chat; open a second ticket for the schema role; wait	Why didn’t the first request include this?	Chat; ticket tool; approval email	Three days
Use	Query returns rows	Next time I’ll just ask someone to export it.	Warehouse	—

The analyst’s last comment suggests a possible workaround to investigate, rather than proving that she will abandon the platform. The map’s opportunities column, omitted here, assigned improvement work across the catalog, approval, and warehouse teams. GOV.UK’s whole-problem guidance emphasizes finding the other teams involved. Keeping their touchpoints visible helps the platform team coordinate changes even where it cannot authorize them.

The blueprint: what happens below the line of visibility

A service blueprint adds the organizational view of a journey: the people, systems, evidence, and processes supporting its touchpoints. Nielsen Norman Group organizes this view with three boundaries. The line of interaction marks customer interactions with the organization. The line of visibility separates visible frontstage activities from backstage work. The line of internal interaction separates customer-contact work from supporting internal processes. The drawing helps locate dependencies to investigate; evidence about what happened is still needed to explain a delay.

In the fictional access case, the investigation found two stale mappings and a scheduled handoff. Approval emails used a dataset-owner spreadsheet that still named a departed employee. A second spreadsheet mapped identity groups to warehouse roles but omitted needed schema roles. These were local maintenance defects as well as parts of a wider coordination problem. The identity grant also synchronized to the warehouse once a night. With a midnight run, approval at 10 a.m. leaves 14 hours to wait, while approval at 5 p.m. leaves seven. Both grants appear after the same run, but their waits differ. Ticket and identity records are needed to separate approval, handling, and synchronization time. Green measures for handling speed, approval rate, or sync reliability would not by themselves expose every defect.

Service design examines how people and processes deliver the experience, including work the user cannot see. Nielsen Norman Group distinguishes this organizational work from designing the visible touchpoints. GOV.UK pairs the user-side experience map with a service landscape covering systems, processes, participants, and required evidence. For a platform team, this makes approval routing and role maintenance choices that have owners and can be changed. The Load Has to Land Somewhere develops the operating responsibility boundary. Value stream mapping helps examine processing and waiting time. Use the blueprint to identify dependencies, then compare observations and records to test explanations for delays.

Touchpoints and support as research evidence

A touchpoint is where the user encounters the service. It can communicate expectations as well as enable a task: an error message may give the user a recovery route, while a status page may leave them unsure whether anyone has accepted the request. The table applies that investigation to the fictional service. Its designer assignments and gaps describe this case; the interpretations are questions to test with users, rather than assumptions about every platform.

Touchpoint	What the user is doing there	What to investigate with users	Design responsibility in this fictional case
Portal and catalog	Finding whether the platform has what they need, and who owns it	Whether the platform knows its own inventory	Platform team
CLI, API, templates	Doing the work	Whether the platform expects them to be competent	Platform team
Documentation and the getting-started guide	Learning; recovering from an error	Whether anyone has walked this path recently	Platform team, often nobody
Error messages and job output	Finding out what went wrong	Whether they can fix it themselves	Whoever wrote the code, usually without a user in mind
Ticket tool	Asking for something the platform does not self-serve	How long things take, and whether anyone is there	IT service desk
Chat channel	Asking a person	Whether the platform team is approachable, and how the last person was treated	Nobody, explicitly
Office hours, onboarding sessions	Learning with a person present	What the platform team thinks is hard	Platform team
Incident communication	Finding out why their job failed at 3 a.m.	Whether the platform tells the truth quickly	On-call engineer, under pressure
Approvals and other teams’ systems	Waiting	That the platform is one of several gates	Other teams

Support belongs in the service design. GOV.UK’s assisted digital guidance identifies trust, confidence, skills, and motivation as reasons someone may need help. Similar questions arise when an analyst encounters an unfamiliar platform. Observe task performance to understand difficulties, and ask about confidence to understand the person’s perception; one does not replace the other. Decide where people ask, expected response times, how an answer becomes reusable guidance, and how users hear what happened to their feedback. A Mandate Is a Measurement covers operating this support as a capability.

The support channel is a useful research source because it contains unsolicited accounts of difficulty in the user’s own words. In this case it helped locate recurring problems across the walkthroughs. Sort contacts by journey phase and problem, distinguish repeated contacts from distinct affected journeys, and compare them with task volume. Silence can reflect a fix, abandonment, another support channel, or fewer attempts. Follow up with people who stopped asking and sample users who never contacted support. A short question at a failed touchpoint can add evidence, but it has its own response gaps. Measure the Friction, Not the People explains how to combine such feedback with behavioral observations.

Repeated problems

The five recurring problems in the fictional channel were choosing the current table, choosing an access group, finding the approver, receiving a grant that did not enable the query, and interpreting an error that named an unfamiliar internal component. GOV.UK’s research-analysis guidance separates observations from interpretations and proposed actions. Record what happened, group related observations, then write findings and decide what to investigate or change. A question about three tables does not yet establish whether the cause is documentation, naming, duplicated data, or distinct versions that the catalog fails to explain.

Responses can change the path, the information, the support, or the accepted operating arrangement. For this case, the team could include the necessary schema role in the authorized request, explain the missing role in an error, publish a reusable answer, or staff a recurring need while recording its cost. These responses can be combined. Mark genuinely superseded tables as deprecated, while preserving distinct supported versions. After a change, examine whether comparable users can complete the task with fewer failures or delays. Track recurring questions alongside distinct attempts, new users, repeat contacts, channel changes, and abandonment. A question’s disappearance is a reason to check the outcome, not proof that the problem was solved.

Measuring the experience

Signals before metrics

The four-hour measure answered a local handling question. It did not measure the goal of helping an analyst reach a usable query within a day. Rodden, Hutchinson, and Fu’s HEART framework connects goals to signals and then metrics. Its categories are Happiness, Engagement, Adoption, Retention, and Task success. Their PULSE examples—page views, uptime, latency, seven-day active users, and earnings—remain useful but often give indirect evidence about user experience. HEART adds attitudes and behavior: Happiness includes satisfaction, and Task success includes effectiveness and efficiency. The authors treat it as complementary to business and technical measures; local handling time can remain useful alongside the user’s elapsed time. For this journey, define an attempt by the first recorded search for a needed dataset and completion by a successful query that the user confirms meets the task. Report the population, observation window, and gaps such as searches outside the instrumented catalog.

For each entry cohort, report completion by an agreed deadline, failures, abandonment, and still-open attempts at the reporting cutoff. Show elapsed-time distributions for completed attempts and the age of open ones separately. Faster successful cases can coexist with more unfinished work. If measuring completion without support, use all eligible attempts in the cohort as the denominator and count only those confirmed complete by the deadline without help through the specified channels; keep unknown support status visible. Assistance through a designed support route can be a successful outcome too. HEART complements qualitative research, while a perceptual measure adds evidence about how users experienced the work. Measure the Friction, Not the People develops this combination of measures.

What a reviewer should ask

• When did someone on the platform team last follow a real user through a whole journey, from the moment they needed something to the moment they had it?
• Which user needs are written down in the user’s words, and which are feature requests wearing that format?
• Who was researched: the teams that adopted, the teams that left, and the people who support users?
• For the most important journey, how many touchpoints does it cross, how many are owned by other teams, and does the map show them?
• What is below the line of visibility on that journey, and does anyone own each item there?
• Is the metric on the dashboard the user’s elapsed time or the platform’s?
• Which problems recur most often in the support channel, and what response or combination has each received?
• Which questions stopped being asked, and why?
• Does the person who asked a question find out when it changed something?

The changes in the fictional case were mostly outside the platform’s code. The catalog began using maintained ownership records from the product registry; for this workflow, the designated data product owner also held delegated approval authority. Who Is This Table For? explains product ownership and consumer needs. The portal selected the access group from the dataset and included the authorized schema roles. The warehouse team replaced the nightly sync with event-driven propagation, removing the scheduled wait on that path; the time saved depended on when approval arrived and the new propagation delay. Two superseded tables were marked deprecated.

Completed journeys in the follow-up sample typically took a day. The team still needed to compare similar tasks and include incomplete attempts before attributing an overall improvement to these changes. Two recurring questions disappeared within a month, prompting checks for reduced failures, channel changes, and abandonment. For the initial monthly cohort of instrumented access attempts, 31% were confirmed complete within one calendar day without troubleshooting or guidance through chat, tickets, or direct staff contact. Routine approval work was not counted as support assistance. This illustrative rate used every eligible attempt as its denominator, with incomplete attempts and unknown support status reported separately. The dashboard retained local handling time and added completion, elapsed time, and support measures. Together they made the service easier to investigate than the four-hour figure alone.

References

• GOV.UK Service Manual: Learning about users and their needs (Open Government Licence v3.0).
• GOV.UK Service Manual: User research in discovery (Open Government Licence v3.0).
• GOV.UK Service Manual: Map and understand a user’s whole problem (Open Government Licence v3.0).
• GOV.UK Service Manual: Analyse a research session (Open Government Licence v3.0).
• GOV.UK Service Manual: Assisted digital support: an introduction (Open Government Licence v3.0).
• GOV.UK Service Manual: Understanding users who do not use digital services (Open Government Licence v3.0).
• Nielsen Norman Group: Sarah Gibbons, Journey Mapping 101 (2018, reviewed 15 July 2026).
• Nielsen Norman Group: Sarah Gibbons, Service Blueprints: Definition (2017, reviewed 15 July 2026).
• Nielsen Norman Group: Sarah Gibbons, Service Design 101 (2017).
• Nielsen Norman Group: Kim Flaherty, User Experience vs. Customer Experience: What’s the Difference? (2023).
• Kerry Rodden, Hilary Hutchinson, and Xin Fu, Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications, CHI 2010, author’s version.
• CNCF TAG App Delivery, Platforms White Paper (Creative Commons Attribution 4.0).
• DORA, Capabilities: Platform engineering (Creative Commons Attribution 4.0).