A research finding can lose its meaning surprisingly quickly. A participant struggles to understand who owns the next step. The research report describes unclear responsibility. A planning workshop turns that into a notification feature. A delivery ticket asks for a bell icon and a badge. By release, the original problem is difficult to find.

The feature may still help, but the team can no longer explain the chain from evidence to investment. If the notification is technically blocked, the problem may disappear from the roadmap along with it. If it ships, success may be measured by clicks rather than whether users understand what must happen next.

The method I would use keeps the problem stable while allowing the solution to change. It connects observations, interpreted findings, desired outcomes, candidate interventions and delivery work without treating them as the same thing. The examples are hypothetical; this is a practical approach, not a claim about results from a named client.

The aim is a roadmap that supports decisions rather than a permanent record of the first feature ideas generated in a workshop. A useful roadmap can change direction without losing the evidence that justified the work.

A delivery board makes work visible; the user problem still needs to travel with every item. Credit: Paymo / Unsplash.

Begin by separating observation, finding and recommendation

An observation describes what happened. A finding explains a pattern or mechanism supported by the observations. A recommendation proposes a response. Keeping these layers separate is essential because they have different degrees of certainty and different roles in planning.

Imagine a hypothetical B2B platform for reviewing account changes. In a task session, a reviewer opens the activity history several times before asking a colleague whether another approval is needed. That is an observation. “The current status does not communicate who must act next” is an interpretation that needs support across the relevant evidence.

“Add a notification” is one possible recommendation. Other responses might clarify status language, display responsibility in the task view or change an ambiguous approval policy. The observation does not select the notification by itself.

The GOV.UK research-analysis guidance is a useful reference for moving from observed material to findings. The additional planning discipline is to preserve those layers when the team starts choosing what to build.

Give each consequential problem a stable identity

I would assign a short identifier to every problem that enters planning. The identifier links the problem statement to supporting evidence, affected roles and later delivery work. It should remain stable even if the solution is replaced.

A problem record might say: “Reviewers cannot determine the responsible actor from the current approval status.” Include the relevant task, context, consequence, evidence references and scope. Add what remains unknown, such as exposure across customer configurations.

Avoid naming the record after a solution. “Notification center” becomes awkward when the team decides to improve inline status instead. A problem identifier allows both interventions to belong to the same investment question while making their differences visible.

Keep the evidence in an approved repository and link to it rather than copying sensitive research into every planning ticket. The summary should be readable without access to raw recordings, while someone evaluating the claim should be able to find the authorized supporting detail.

Linear’s historical timeline example, published in 2021, makes time and project overlap visible. It is not presented as today’s interface. Credit: Linear.

Cluster by mechanism, not by screen

Research workshops often group findings under navigation, forms and dashboard. Those categories are easy to understand but can obscure a problem that spans the whole task. Unclear responsibility may appear in a list, a detail view, an email and an approval dialog.

Cluster findings around the mechanism affecting the user: inability to identify ownership, difficulty comparing evidence, uncertainty about completion or loss of work during interruption. This creates themes that can support coherent interventions rather than unrelated local fixes.

Do not erase important differences to make a clean theme. Two users may encounter the same label with different permissions and consequences. Preserve subproblems and scope boundaries where needed. A shared theme is a way to coordinate work, not evidence that every instance has the same cause.

For the review platform, “Understand the next actor and task state” could connect several findings. A separate theme might address evidence identification. Both involve information clarity, but their interventions, owners and verification methods may differ enough to justify distinct roadmap entries.

Write outcomes before features

An outcome states what should improve in the user’s work. “Ship a notification center” is a delivery milestone. “Reviewers can identify whether they need to act and what is blocking completion” is a user outcome. The second supports several possible implementations.

Make the outcome concrete enough to investigate. “Improve trust” is too broad unless the team identifies the behavior or understanding behind it. For approval work, relevant questions might concern recognizing pending steps, identifying the responsible role or avoiding repeated submission because confirmation is unclear.

Connect the outcome to the organization’s goal without overstating causality. Clearer responsibility may support smoother operations. It does not guarantee a particular revenue increase. If the business wants a numerical target, establish a baseline, data definition and plausible relationship before attaching a percentage to the design work.

Also state guardrails. A change that accelerates completion by concealing exceptions may undermine the task. A reduction in support contacts may be undesirable if users stop reporting failures. The outcome needs the context that distinguishes real improvement from a misleading metric.

Preserve the obstacle and intended outcome even when the delivery proposal changes. This trace is hypothetical. Credit: Original editorial visual prepared for Andrea Mabellini.

Generate interventions that address different causes

Once the outcome is clear, ask the team to generate plausible interventions. For unclear approval responsibility, options could include better status content, a visible ownership field, targeted notifications or a policy change defining reassignment. These are not merely visual variations.

For each option, state the mechanism of improvement and the assumptions. A notification assumes people need an interruption outside the task view. Inline ownership assumes they already visit the relevant page. A policy change assumes ambiguity originates in the operating process. Evidence should help discriminate between these explanations.

Include reuse and removal. An existing component may support the required information. A redundant approval step might be unnecessary if the domain owner confirms its purpose is already covered elsewhere. These options prevent the workshop from treating new interface production as the only acceptable outcome.

Do not select solely by effort. A cheap intervention that does not address the cause may consume capacity and create false confidence. Equally, do not insist on the most comprehensive solution when a smaller change can responsibly improve the task and provide learning.

Prioritize the problem and the proposed action separately

A consequential problem can deserve attention even when the best solution is uncertain. Its next roadmap action may be investigation rather than implementation. This is why confidence should affect the type of work, not automatically demote the problem.

Consider two findings. One is a reproduced false-success state after a failed save. Another suggests that occasional reviewers misunderstand approval responsibility. The first may justify a direct correction and verification. The second may justify targeted research before committing to a new notification system.

Use consequence, exposure, recoverability and strategic relevance to discuss problem priority. Use evidence strength, feasibility and dependencies to decide the next action. Record unknowns instead of assigning convenient scores. A framework can structure judgment without pretending it removes judgment.

Make trade-offs explicit when delivery sequence differs from importance. A high-consequence issue may require a dependency change; an interim control can come first. The roadmap should retain the original problem and explain the staged response rather than silently replacing it with an easier ticket.

Dates help coordinate delivery. They are a different commitment from verifying that the user problem has improved. Credit: Eric Rothermel / Unsplash.

Put learning work on the roadmap when it changes a commitment

Roadmaps often show research as a preparatory activity with no decision attached. That makes it easy to remove when delivery pressure increases. A stronger entry states what uncertainty the learning addresses and which commitment depends on the answer.

For example: “Determine whether unclear responsibility comes from status presentation or approval policy before selecting the intervention.” The output is a decision with evidence, not a research deck. The team should be able to choose implementation, another investigation or stopping the proposed feature.

The GOV.UK planning guidance provides a reference for aligning questions and research activities. The roadmap makes that alignment visible at the investment level. It protects learning that can change the direction, rather than scheduling research only after the direction is fixed.

Be realistic about access and timing. Specialist recruitment, policy review and data availability can affect the schedule. A learning entry should expose those dependencies so the organization can arrange them. It should not imply certainty about a completion date before the necessary access exists.

Use time horizons without disguising uncertainty

Near-term work can be specific because the team understands the problem and prerequisites. Later work should remain at the level justified by evidence. A theme with an unresolved intervention should not look like a fully estimated feature simply because the roadmap template has a date column.

Now, next and later can be useful labels if their meanings are explained. They do not eliminate uncertainty by themselves. State which entries are committed, which depend on learning and which represent potential investment areas.

Nielsen Norman Group’s UX roadmap guidance describes roadmaps as high-level communication artifacts around future UX work. My recommendation is to connect each entry to a stable problem record so that changes in timing or implementation do not sever its evidence.

Avoid implying that a theme is guaranteed to ship unchanged. A roadmap should be able to incorporate a finding that invalidates a feature. Otherwise it becomes a commitment mechanism that research is expected to justify rather than a plan that research can improve.

Translate into delivery without shrinking the problem

When an intervention moves into delivery, retain the problem identifier and outcome in the epic or equivalent parent record. Individual tickets can be specific, but the team should still be able to trace them to the task improvement they support.

For an ownership improvement, tickets may cover status content, role data, presentation, permissions and verification. A badge implementation is one part of the work. If the role data is unavailable, the team cannot claim the user outcome is complete merely because the badge looks correct.

Write acceptance criteria against relevant states. “When a request is awaiting approval, the reviewer can identify the authorized next actor; when that actor is unavailable, the permitted reassignment path is explained.” Include cases where information is restricted or changes during the workflow.

Engineering should review what the system can observe and enforce. Design should review whether the resulting experience communicates the intended meaning. Product should preserve the outcome and trade-off. Shared ownership prevents a cross-functional problem from being reduced to a visual task assigned to one person.

Productboard’s documentation links an idea to source insights. The fictional organization names belong to the published demonstration. Credit: Productboard.

Keep deferred problems visible without creating an endless backlog

Maintain a decision history when priorities change. If the organization pauses the responsibility theme to address a critical integration issue, record the reason and its effect on the intended outcome. Do not rewrite the problem as unimportant merely because another commitment now comes first. Later teams should be able to distinguish a valid problem awaiting capacity from a finding that was disproved.

Likewise, record when one intervention addresses several problems. A shared status model may improve responsibility, confirmation and support diagnostics. Link those problem records to the same initiative without claiming they all have equal evidence or will all be resolved by the first release. Verification can then assess each outcome separately instead of declaring the entire theme complete when the shared infrastructure ships.

Not every valid finding belongs in the active roadmap. Some affect a narrow context, have limited consequence or depend on work the organization cannot currently undertake. Defer them explicitly with a reason and a review trigger.

Avoid keeping every finding in a permanent undifferentiated list. Distinguish active, monitored, deferred and retired problems. Retirement may mean the product changed, the issue no longer applies or later evidence contradicted the initial interpretation. Preserve the reason so future teams do not rediscover it as if nothing was known.

For a deferred approval issue, a trigger might be expansion to a new user role or evidence of repeated operational failures. This is more useful than an arbitrary promise to review everything every quarter. The trigger connects the problem to a change that could alter its priority.

Verify the outcome after release

Shipping the intervention closes delivery work. It does not automatically close the user problem. Plan verification around the original outcome and the evidence gap the team intended to address.

Observe whether reviewers can identify who acts next without avoidable assistance. Check implementation states and permissions. Examine operational signals with appropriate context. An increase in notification engagement can show that people interact with the feature; it does not establish that approval responsibility is now clear.

If the outcome remains unresolved, revisit the mechanism. Perhaps the interface improved but the policy still conflicts across departments. Perhaps the change works for frequent reviewers but not occasional ones. The stable problem record makes this follow-up possible without framing every revision as a failure of the original designer.

Update both the roadmap and the evidence record. Explain what improved, what remains and what the next action will be. This closes the loop from research to investment to delivery to learning, rather than ending at the release announcement.

Verification should test the intended outcome. This loop distinguishes completing a change from resolving the user obstacle. Credit: Original editorial visual prepared for Andrea Mabellini.

A practical planning workshop

Start with a small set of consequential findings and their evidence. Ask each participant to restate the user problem without naming a feature. Agree the scope and confidence, then define the task outcome and at least two plausible interventions.

Decide whether the next step is implementation, investigation or temporary acceptance. Assign an owner and identify the dependency that could change the plan. Write the entry in language someone outside the workshop can understand. Keep the evidence links and unresolved questions attached.

For interaction patterns that recur across products, connect the entry to the design-system team. The technical context discussed in my design-to-code guide can support consistent implementation. The roadmap still needs to explain which shared user problem that implementation serves.

The most useful roadmap is not the one with the most detail. It is the one that lets the organization change a solution while preserving why the work matters. When observations, outcomes and commitments remain connected, research has a practical route into the product rather than a brief appearance before the feature list takes over.