UX Design Roadmap
Begin
14 pages · ~28 min
Interactive digital-human course

UX Design Roadmap

This training helps aspiring and current UX designers build a practical roadmap to develop core skills, grow their careers, and advance toward senior roles.

A digital instructor presents all 14 pages. Hold “Ask” at any point and ask out loud — the answer comes from this course. No sign-up needed.

28 minFree to watchDownloads

What you’ll learn

  1. 01Building a UX Design Roadmap: From Research Priorities to Shipped ExperienceWelcome. Over the next several slides, we're building a UX roadmap that connects evidence, design intent, and delivery commitments. This is the version of the roadmap that survives contact with senior stakeholders. Start by naming what they actually expect: a sequenced set of priorities, the dependencies between them, and a rationale they can defend in a room you're not in. That framing changes how you write every line. We'll use three horizons: discovery, design, and post-release iteration. Now, next, and later are confidence horizons, not a queue of features marching toward a date. Pressure-test this against the failure modes you've all seen. A feature list. An unprioritized backlog. No measurement plan. Any one of those turns the roadmap into a wish list. One scope note. We stop at delivery and engineering planning. The point is to hand off cleanly, not to own the sprint. What a UX Roadmap Is, and What It Is Not.Building a UX Design Roadmap: From Research Priorities to Shipped Experiencejordanmeyerowitz.comprodpad.comtenagile.com+22 min
  2. 02What a UX Roadmap Is — and What It Is NotLet's get precise about what a UX roadmap actually is, because the term gets overloaded fast. Start by drawing the boundary: it is not a product roadmap, and it is not an engineering delivery plan. A product roadmap answers what ships and when. Your UX roadmap asks what users need, what's broken, and what we still have to validate. Pressure-test this with your team: the product roadmap says launch the new onboarding flow. Your roadmap says validate the onboarding blockers, run one-on-one testing, and recommend progressive disclosure. Different question, different artifact. There are three common shapes. Field roadmaps span all of UX, specialty roadmaps focus on one area like research, and hybrid roadmaps blend UX work with product commitments. Most of you will run a field or hybrid. Organize yours by outcome and confidence, not feature and date. Now, next, later works well here, because it keeps you honest about uncertainty. And remember who you owe clarity to: executives, product, engineering, and design. Each needs a different altitude, not a different roadmap. The Evidence Layer: Making Inputs Credible.What a UX Roadmap Is — and What It Is Notnewsletter.uxuniversity.ioheymarvin.comnngroup.com+22 min
  3. 03The Evidence Layer: Making Inputs CredibleLet's talk about the evidence layer. This is what makes our inputs credible enough to defend. Start by harvesting every source you already have: generative research, usability findings, analytics, support themes, competitive signals. Then, for every opportunity, record the source count and the dates. Here's the rule I want you to pressure-test in your own backlog: five or more distinct sources means established. Two to four is thin. Exactly one is a quote, not an opportunity. And none at all is a solution somebody wanted, drawn as a need. That last one is the trap. Most written opportunities are solutions in disguise, so read each one and ask whether a customer would say it in those words. If not, rewrite it. Build an evidence register your partners can challenge, contribute to, and trace back. Then align with your team on the threshold: when existing evidence is sufficient to commit, and when new research has to run first. Pressure-test this, because the count is the verdict. Now let's map these opportunities with the Opportunity Solution Tree.The Evidence Layer: Making Inputs Crediblegetperspective.aiideaplan.ioescutaproduto.com+22 min
  4. 04Mapping Opportunities with the Opportunity Solution TreeNow let's map the opportunities themselves using the Opportunity Solution Tree. Four layers: the outcome at the root, the opportunities that could move it, the solutions that address those opportunities, and the assumption tests beneath each solution. Start by keeping the tree small. Three to five opportunities at a time, two to three solutions per opportunity, and prune the rest. A tree with three to five opportunities is something a team can hold in its head and revisit weekly; a sprawling tree becomes a wall poster nobody acts on. Pressure-test your evidence before you trust a branch. Five or more distinct sources is established. Two to four is thin. A single source is a quote, not an opportunity. And no sources at all is usually a solution someone wrote upward and drew as a need. Be explicit about one thing with your team: the tree generates candidates. It does not rank them. Prioritization comes later, through scoring or capacity planning. What the tree gives you is traceability. Every roadmap item traces to an opportunity, and every opportunity traces to the outcome. That trace is what turns a feature list into a defensible bet. Next, we look at Prioritizing Experience Work Against Business Constraints.Mapping Opportunities with the Opportunity Solution Treegetperspective.aiideaplan.ioescutaproduto.com+22 min
  5. 05Prioritizing Experience Work Against Business ConstraintsLet's talk about prioritizing experience work when business constraints are real and the roadmap is already full. Start with a familiar frame: impact over effort, with RICE as one option: reach times impact times confidence, divided by effort. Kano and weighted scoring also work well for experience initiatives, but pressure-test the criteria itself. If effort is the only heavy penalty in your model, usability debt is structurally disadvantaged, because debt rarely looks like a big new feature. So score debt explicitly by user severity, breadth, business impact, and fix difficulty. Then add cost of delay and cost of inaction. What do we lose every sprint this unresolved problem stays open? That reframes debt as a cost, not a cleanup task. The real unlock is shared, visible criteria. When the scoring is on the wall, trade-offs become negotiable instead of personal. Log those trade-off decisions so they are revisited, not relitigated. Align with your team on who owns each call, and what evidence would change it. Next, we will look at giving UX debt and accessibility a seat at the table.Prioritizing Experience Work Against Business Constraintsnngroup.comtestparty.aiweb-accessibility-a11y.com+22 min
  6. 06Giving UX Debt and Accessibility a Seat at the TableLet's talk about giving UX debt and accessibility a real seat at the table. UX debt hides everywhere. User interface, interaction, copy, information architecture, accessibility, journey consistency. Start by inventorying all of it in one place, not scattered across team trackers. When you score, use user severity, breadth, business impact, and fix difficulty. Pressure-test this: WCAG level alone will misrank your queue. A Level A issue buried in an obscure prop can outrank a Level AA defect that blocks screen reader users on every dashboard. Severity means user impact, so rate it with real assistive technology, not by reading criteria. Then use blast radius as leverage. One design system component fix can clear dozens of findings. Group by component and rule, and the math works in your favor. A component with thirty-four instances should beat the same defect patched on one page. For paydown, choose your model. A percentage per sprint, dedicated remediation sprints, or a hybrid. Align with your team on which one you can actually sustain. Finally, report three numbers per release. Open blockers, open majors, and the trend. That keeps debt visible next to performance and reliability, and it buys you room for the slower work. Now let's look at sequencing across discovery, design, delivery, and learning.Giving UX Debt and Accessibility a Seat at the Tablenngroup.comtestparty.aiweb-accessibility-a11y.com+22 min
  7. 07Sequencing Across Discovery, Design, Delivery, and LearningNow let's talk about sequencing across discovery, design, delivery, and learning. The key move here is to structure cycles around real decision points, not calendar blocks. A decision point is a moment when evidence should change what we do next. So run continuous discovery in parallel with committed delivery work. Your product trio keeps a weekly customer touchpoint going, even while the team ships. Then use Now, Next, and Later as confidence horizons. Pressure-test this: the moment you attach a quarter label to Next, it becomes a calendar, not a roadmap. Show partners your options, bets, and unknowns. Don't hide them. And map dependencies across research questions, design decisions, and engineering readiness, so you can see which work is actually blocked and why. Start by reviewing your current cycles with your team. Ask what decision each one is meant to inform. That single question will sharpen your sequencing fast. Next, we will look at reserving roadmap capacity for learning.Sequencing Across Discovery, Design, Delivery, and Learningjordanmeyerowitz.comprodpad.comtenagile.com+21 min
  8. 08Reserving Roadmap Capacity for LearningLet's talk about reserving roadmap capacity for learning. This is where discovery stops being a side activity and becomes a line item. Start by making weekly customer touchpoints a standing event on the calendar, never a phase. A phase ends. A standing event keeps the evidence flowing every week. Next, keep a hypothesis log right beside the increment backlog, and give every hypothesis a verdict: validated, killed, or inconclusive. Killed hypotheses are institutional memory, so log them, don't delete them. Then, pressure-test how you fund the work. The prototype is the discovery track's unit of work, the same way the increment is delivery's. If prototypes aren't in the plan, the plan is wrong. Make learning milestones visible roadmap artifacts. Something like three onboarding experiments per cycle, stated plainly. And replace deadlines with decision gates: scale, iterate, or kill. Agree on the decision rules in advance, not when the results land. Align with your team on which gates you'll honor, then hold them. Next, we'll get concrete about defining outcomes, metrics, and success signals.Reserving Roadmap Capacity for Learningjordanmeyerowitz.comprodpad.comtenagile.com+22 min
  9. 09Defining Outcomes, Metrics, and Success SignalsNext, let us define outcomes, metrics, and success signals. Start with outcome statements the team can act on and stakeholders can verify. That means naming the behavior change you expect, not just a number you hope to move. Pair experience metrics with business metrics, and never substitute one for the other. Task success tells you the interface worked. Conversion tells you it mattered commercially. You need both. When you apply HEART, adoption and task success usually carry activation, with retention as your downstream proof. Before any work starts, set baselines and thresholds. No retrospective metric fitting. Run one A divided by B check on your measurement plan. If your sample is too small, or the window is too short, your threshold is not evidence. Finally, guardrail metrics need scope, tolerance, and consequence. Write down what degradation you will not accept, and what happens if it occurs. A guardrail without a consequence is decoration. So pressure-test this before you commit the roadmap. Can every outcome statement be verified by someone outside the design team? If not, tighten it. That keeps our priorities honest and our stakeholder conversations grounded. Stakeholder Alignment and the Roadmap Narrative.Defining Outcomes, Metrics, and Success Signals2 min
  10. 10Stakeholder Alignment and the Roadmap NarrativeLet's talk about turning research into a roadmap narrative your stakeholders will actually act on. Start by reframing findings as recommendations, using a simple structure: observation, evidence, inference, recommendation, and confidence. For example, instead of saying users are confused by navigation, say: users abandoned step three, based on five of eight participants, we believe it's the payment options, we recommend testing clearer labels, confidence medium. That gives your PM something to decide, not just something to interpret. Next, tailor the depth. Give executives a five-minute version focused on decisions and risk. Save the deep dive for product partners who need methodology and tradeoffs. Pressure-test this by pre-empting the three objections you'll always hear: scope, speed, and perceived design delay. Then tie every recommendation to a metric your PM is measured on, whether that's activation, retention, or support volume. That's when research stops being a UX concern and becomes their problem too. Finally, set governance. Agree on a review cadence, keep a change log, and be explicit about who can change what. That keeps the roadmap credible when priorities shift. Next, we'll look at operating the roadmap: reviews, reprioritization, and change control.Stakeholder Alignment and the Roadmap Narrativenewsletter.uxuniversity.ioheymarvin.comnngroup.com+22 min
  11. 11Operating the Roadmap: Reviews, Reprioritization, and Change ControlLet's talk about operating the roadmap, because a roadmap that only gets edited at planning time is already stale. The cadence follows confidence. Review Now weekly, Next monthly, Later quarterly. Match that rhythm to how volatile the work actually is. Before you need them, write your reprioritization triggers down. Decide now what evidence justifies a reversal, so when you change course it reads as judgment, not as a reaction to the loudest voice in the room. Keep a visible decision log: what changed, who decided, and why. Pressure-test this with your team. If someone asks why an item vanished, the log should answer in seconds. Retire stale items out loud. Silent decay is what erodes roadmap credibility, and it happens one forgotten initiative at a time. Reserve interrupt capacity for incidents and escalations, so unplanned work doesn't quietly consume your Now column. And give the roadmap an explicit slot for shipped work that missed its outcome, with a continue, iterate, or stop decision attached. That slot is how we stop building second increments on foundations that never delivered a first. Align with your team on those triggers and that log this week. Next, we'll look at artifacts and tooling, and how to keep one source of truth.Operating the Roadmap: Reviews, Reprioritization, and Change Controljordanmeyerowitz.comprodpad.comtenagile.com+22 min
  12. 12Artifacts and Tooling: One Source of TruthLet's talk about artifacts and tooling, and the principle that matters most here: one source of truth. Start by matching the artifact to the audience. Executives get a one-pager or a board visual. Working teams need the living document. Same roadmap, different readouts. Next, pressure-test what actually lives in the tool versus the story around it. A dedicated roadmap tool answers what we're building, in what order, and why. Figma or FigJam answer how it works and what it looks like. The friction comes when a feedback-led tool, a strategy-led tool, and a delivery-led tool each try to own the narrative. Pick one home for priorities, then let the others link to it. So when you align with your team, decide the hierarchy explicitly: docs for context, boards for decisions, tickets for execution. Make the roadmap readable for varied stakeholders without exposing internal backlog complexity. And keep it current. A roadmap is only as good as the last time someone updated it. That sets up what happens when this breaks down. Next, we'll walk through pitfalls, anti-patterns, and stress tests.Artifacts and Tooling: One Source of Truthnewsletter.uxuniversity.ioheymarvin.comnngroup.com+22 min
  13. 13Pitfalls, Anti-Patterns, and Stress TestsLet's talk about where roadmaps go wrong, and how to stress-test yours before it does. Three anti-patterns to watch: infinite redesign, where nothing ever ships because the work never feels finished; the research theater roadmap, where discovery happens but never changes a decision; and the unowned experience debt list, which nobody prioritizes because nobody owns it. The moment your roadmap becomes a compliance document, you've lost the plot. It should be a planning tool. Pressure-test it against funding cuts, leadership change, and platform shifts. And be honest about capacity. Capacity optimism triggers quality collapse, so plan for real throughput, not the throughput you wish you had. If you do hit trouble, recovery has a shape: shrink scope, log your decisions, and rebuild credibility with evidence. Start by auditing your current roadmap against those three failure modes. Then pressure-test it against one realistic constraint and one leadership change scenario. Finally, make sure every item has a named owner. Before we go, connect this back to your own context. Workshop: Drafting Your Next Two Quarters.Pitfalls, Anti-Patterns, and Stress Testsjordanmeyerowitz.comprodpad.comtenagile.com+22 min
  14. 14Workshop: Drafting Your Next Two QuartersSo let's put all of it to work. This is your workshop, and here's the shape of it. Start by picking one real product area, and apply everything we've covered: your evidence, your prioritization, and your metrics. Pressure-test it against the goal-signals-metrics mapping and your guardrails, not just the easy numbers. Then draft a one-page now, next, later roadmap. Now holds what's validated and in flight. Next holds the problems you're actively shaping. Later stays loose, at the level of strategic bets. Label your assumptions explicitly. That's the whole point of the format. It separates what you know from what you're betting on. Once it's drafted, pair up and critique against the anti-patterns and the stress test checklist. Be direct with each other; that's what makes this useful. Before you leave, commit to one stakeholder conversation and the artifact you'll bring to it. Then close with your personal action list: what actually changes in your next planning cycle. Take a moment and write it down. Here's the through line from today. Roadmaps are systems for reducing uncertainty, not delivery schedules. Evidence earns confidence, confidence earns commitment, and commitment lives in your objectives, not in dates. Thank you for the work you put in today. Go draft the roadmap, book the conversation, and let the evidence drive what comes next. You've got this.Workshop: Drafting Your Next Two Quartersjordanmeyerowitz.comprodpad.comtenagile.com+22 min

Take the deck with you

Download this course as a file — free, no sign-up needed.

Free to use in your own training — please keep the PersonWise credit page at the end.

Have your own deck? Turn it into a course

Sources consulted

Web sources consulted while building this course.