What UX roadmapping is and why it matters NN/g
A UX roadmap is a strategic, living artifact that aligns, prioritizes, and communicates a UX team's future work and problems to solve. It is not a project plan, not a feature list, and not a design backlog. It answers the question: "What UX problems are we solving, in what order, and why?"
UX teams need their own roadmaps because the product roadmap — even a good one — typically doesn't represent UX work at the right level of detail. A product roadmap might say "Improve onboarding." The UX roadmap says: "Conduct onboarding usability study (research), redesign first-run experience (design), test new onboarding flow with 5 users (validation)." Without a UX roadmap, design and research work becomes reactive — driven by whatever the product team asks for this sprint rather than by a strategic view of the biggest UX opportunities.
The benefits of a well-maintained UX roadmap follow the PROSPER framework: it Puts plans in strategic context, Reorients effort around top priorities, Orchestrates future action toward purposeful outcomes, acts as a Single source of truth, Prompts excitement about future direction, Embraces learning as part of the process, and Rallies the team around a shared vision.
Why this matters for your projects
Without a UX roadmap, the design team is a service bureau — responding to requests, not shaping direction. With one, UX becomes a strategic partner that proactively identifies the highest-impact experience improvements and sequences them thoughtfully. The roadmap is also the single best tool for communicating UX value to non-UX stakeholders: it shows what the team is doing, why, and what outcomes to expect.
Three scopes of UX roadmaps
UX roadmaps exist at three levels of scope, and understanding which one you're building prevents confusion:
Product roadmap (UX-inclusive): Represents all future problems to be solved across the entire product — including development, marketing, content, design, research, and operations. UX themes sit alongside engineering and business themes. This is the broadest scope and typically lives with the product manager.
Field roadmap: Represents all future problems to be solved by UX — design, research, and content — but excludes non-UX work. This is the most common type of UX roadmap. It gives the UX team strategic direction while staying focused on the discipline's scope of influence.
Specialty roadmap: A subset of the field roadmap focused on a single UX discipline or team — for example, a UX research roadmap or a design system roadmap. Useful for large UX organizations where individual teams need their own strategic planning.
Common mistake
Building a UX roadmap that duplicates the product roadmap with a "design" label. If your UX roadmap themes are identical to the product roadmap themes, you've just added a layer of bureaucracy. The UX roadmap should surface problems, research needs, and design opportunities that the product roadmap doesn't capture — especially exploratory research, design system investments, and cross-product experience improvements.
Roadmapping vs. the roadmap
The distinction between the process and the artifact matters even more for UX teams. Roadmapping is the process — stakeholder interviews, input gathering, theme workshops, prioritization exercises, and regular revision. The roadmap is the output artifact that communicates the results. Many UX teams skip the process and jump straight to making a pretty roadmap, which produces an artifact that looks strategic but isn't grounded in real inputs.
The roadmapping process involves three types of participants. The creator (typically the UX lead or design manager) owns the roadmap and drives its creation. Contributors (designers, researchers, content strategists) provide input and will execute the work. Consumers (product managers, engineering leads, executives) read and react to the roadmap but don't author it. The most effective roadmapping processes gather input from all three groups before the creator synthesizes and prioritizes.
UX-specific roadmapping challenges
Practitioner research reveals three challenges that hit UX roadmaps harder than product roadmaps:
Roadmaps make promises teams aren't confident in. UX work is inherently uncertain — a research study might reveal that the planned design direction is wrong. If the roadmap treats every theme as a commitment, the team loses the ability to follow the evidence. Solution: make confidence levels visible on every theme and use "Now/Next/Future" instead of fixed dates.
Roadmaps become too detailed and merge with project plans. UX teams — trained to think in flows, screens, and interactions — tend to add too much detail to roadmap themes. The result is a task list masquerading as a strategy. Solution: themes should describe problems to solve, not solutions to build. "Understand why checkout abandonment spikes on mobile" is a theme; "Redesign the cart page to use a single-column layout" is a task.
Roadmaps lack buy-in and support. If the UX roadmap was created in isolation, stakeholders treat it as a wish list. If it was co-created with product and engineering input, it becomes a shared commitment. Solution: involve consumers (product, engineering) in the input-gathering and prioritization steps — not just the final presentation.
UX roadmap structure NN/g
The context dimension
Every UX roadmap needs a context frame that lets anyone understand it without explanation:
Scope: Title (which product or team), owner (who created it), date (when created or last updated), version number, and the high-level goal the roadmap serves. Example: "UX Roadmap: Customer Portal — NN/g Design Team, Owner: Sarah Gibbons, V1 | June 2024."
Time: Organize themes into time horizons rather than specific dates. The most effective framework uses three buckets: Now (work in progress, well-defined, high confidence), Next (near-future work, 1–2 quarters out, moderate confidence), and Future (6+ months away, deliberately vague, low confidence). The further out you look, the less specific the themes should be — this communicates appropriate uncertainty rather than false precision.
Primary components: what every theme needs
Theme Core Element
A bundle of future UX work representing an area of focus, initiative, or problem to be solved. Themes are not features or tasks — they're strategic containers. Good themes are framed as problems or opportunities: "Attendee Conference Access," "Readers' Favorite Content," "Program Participants Exam-Taking." Each theme should be understandable to someone outside the UX team.
Beneficiary Core Element
Who receives the value — an end user, customer segment, or internal team. Naming the beneficiary explicitly prevents the roadmap from becoming an abstract list of initiatives. "Conference attendees," "first-time buyers," "support agents" — each beneficiary frames the theme's purpose.
Need Core Element
The problem that will be solved — the purpose of the UX work. Frame needs from the user's perspective: "Provide seamless access to our virtual conference and decrease need for help and support" or "Establish a way for readers to save articles and videos to increase engagement."
Business Objective Core Element
The expected outcomes from a business perspective that will be achieved upon completion. Categories include: new market insight, user growth, increased engagement, ease of discovery, and revenue impact. Connecting UX work to business objectives is what gives the roadmap credibility with non-UX stakeholders.
Ownership Core Element
Two dimensions: who (the team that will do the work — Digital Team, Research Team, Certification Team) and what (the type of work at a high level — Research & Test, Design, Development, Define, Prototype, Competitive Analysis, Report). This makes resource implications visible without turning the roadmap into a project plan.
Secondary components: add depth where needed
Product or experience area: which part of the product the UX work touches — Virtual Conferences, Articles & Videos, Online Seminars, Reports. Useful when one UX team works across multiple product areas.
Subthemes: specifics nested under a theme — multiple sub-goals, specific user segments or personas, predetermined solutions from past work, or discrete features already tested and validated.
Confidence: an informal assessment of likely impact and demonstrated need. High confidence means the theme is backed by strong evidence (user research, analytics data). Low confidence means it's exploratory. Making confidence visible helps stakeholders understand which themes are near-commitments versus bets.
Disclaimers: requirements, dependencies, or risks associated with a theme. "Requires API work from platform team" or "Pending legal review for accessibility compliance." These prevent downstream surprises.
Practical tip
Start with just the primary components. Add secondary components only when they solve a real communication problem — for example, add confidence when stakeholders keep asking "how sure are you?" or add disclaimers when dependencies keep causing delays. Over-engineering the roadmap template is a common trap for UX teams.
The roadmap creation workshop NN/g
The most effective UX roadmaps are created collaboratively in workshops, not by one person in isolation. Here are two approaches — choose based on your team's maturity and available time.
Approach 1: Single workshop (3 hours) Fast Track
Use when: You have existing inputs (research, analytics, strategy docs) and need to move fast. Best for teams with some roadmapping experience.
Pre-workshop: Establish the roadmap's primary goal and gather inputs — existing research artifacts, analytics data, stakeholder interview notes, competitive analysis.
Introduction (25 min): Icebreaker, then a "roadmap hopes and fears" activity where participants silently write what they hope the roadmap will achieve and what they fear might go wrong. This surfaces expectations and concerns early.
Read-out (15 min): Share the context — what inputs were collected, what methods were used, what the roadmap's goal is.
Distill themes (45 min): Assign small groups to review specific inputs. Each group individually identifies potential problems to solve (silent post-up), then converges on named themes, then presents back to the group.
Break (20 min)
Affinity diagramming (30 min): The full group clusters small-group themes into patterns. Name and expand each cluster into roadmap themes.
Prioritization (45 min): Collaboratively identify prioritization criteria, then rank themes. Play back the result to the group for final adjustments.
Post-workshop: The roadmap creator visualizes the output, sends a recap, and determines the sharing strategy.
Approach 2: Two workshops (1 hour + 2 hours) Thorough
Use when: Inputs are thin and you need to gather strategic context from stakeholders before creating themes. Best for teams new to roadmapping or working in complex organizations.
Workshop 1 — Establish Goals & Gather Input (1 hour): Introduction and roadmap definition (5 min). Roadmap hopes and fears activity (15 min). Strategy collection — embed stakeholders or knowledge workers in small groups for interviews, identify potential insights, cluster into early themes (30 min). Identify open questions that need additional research (10 min).
Between workshops: Conduct research to fill the gaps identified in Workshop 1 — competitive analysis, user research, secondary stakeholder interviews.
Workshop 2 — Create Themes & Prioritize (2 hours): Recap share (15 min). Distill themes from all inputs — silent generation, small group convergence, playback (30 min). Break (15 min). Affinity diagramming across all groups (30 min). Prioritization with identified criteria (30 min).
Post-workshop: Visualize, share recap, determine distribution strategy.
The six-step process
Both approaches follow the same underlying process: (1) Establish goals, (2) Gather inputs, (3) Create themes, (4) Prioritize, (5) Visualize and share, (6) Revisit. The difference is in pacing and depth — the single-workshop approach compresses steps 1–2 into pre-work, while the two-workshop approach dedicates an entire session to them.
Visualizing and sharing your UX roadmap NN/g
Choosing the right format
The distribution formula has three variables: who is the audience, what level of detail do they need, and how will they consume it (live presentation, async document, tool they check periodically).
For internal UX team alignment: a collaborative board (Miro, MURAL) or spreadsheet with full component detail — all primary and relevant secondary components. Updated every sprint or cycle.
For product and engineering partners: a cleaner view emphasizing themes, needs, ownership, and time horizons. Strip out UX-internal details like research methodology or design-specific sub-tasks. A slide deck or wiki page works well.
For executive stakeholders: the highest-level view — themes, business objectives, and time horizons only. Remove specific dates where possible. Include confidence levels. A one-page visual or short presentation deck. The pivot report approach (removing dates entirely, showing only Current / Near-term / Future buckets) works particularly well for executive audiences who might otherwise treat the roadmap as a delivery commitment.
Presentation strategies
When presenting a UX roadmap, lead with context: why this roadmap exists, what inputs shaped it, and what the high-level goals are. Then walk through themes by time bucket — not by team or product area. This keeps the narrative strategic rather than operational. End with what you need from the audience: feedback, resources, alignment, or decision-making on specific themes.
Practical tip
Create multiple views of the same roadmap, not multiple roadmaps. The underlying data is the same; the visualization changes per audience. A common mistake is maintaining separate roadmaps for different stakeholders, which inevitably drift out of sync. One source of truth, multiple presentation layers.
Roadmap assessment
Periodically evaluate whether your roadmap is actually working. Key questions: Is it being used? Has it changed in the last quarter? Can team members explain the themes and their prioritization? Are stakeholders referencing it in conversations? A roadmap that lives in a drawer isn't a communication tool — it's documentation theater.
UX roadmapping tools NN/g
Choose your tool based on where your team already works and what your primary need is:
For collaborative creation workshops: Miro and MURAL both offer roadmap templates (25+ each) and are built for real-time group work. The output won't be polished enough for executive presentations, but the collaboration is unmatched. Start with the template and expand it to include your primary components.
For polished, stakeholder-facing roadmaps: ProductPlan offers a specific UX/UI roadmap template with timeline views, color-coding, and the ability to combine UX, UI, and research work in one view. ProdPad is excellent for theme-based (Now/Next/Later) roadmaps with built-in idea collection from team members.
For integration with engineering tools: Jira's built-in roadmap feature works well if your team already uses Jira. Use initiatives as themes, and consider naming them with their time horizon (e.g., "Payments (Now)") to keep the strategic level visible. Avoid getting pulled into discrete dates for future items — use the 1-year filter.
For getting started with zero overhead: A spreadsheet (Google Sheets, Excel) with columns for Theme, Beneficiary, Need, Business Objective, Ownership, and Confidence across Now/Next/Future time buckets. This is a perfectly valid roadmap format. Graduate to a dedicated tool only when the spreadsheet becomes the bottleneck.
Real-world examples NN/g
Case study
NN/g Customer Portal: Field roadmap with full anatomy
The NN/g Digital Team created a UX roadmap for their Customer Portal using Now/Next/Future columns. Each theme includes a product area label (Virtual Conferences, Articles & Videos, UX Certification, Reports, Online Seminars), a clear need statement, the responsible team, and the type of work involved (Research & Test, Design, Development). The roadmap explicitly names two themes per time bucket with different product areas, making cross-initiative trade-offs visible.
What makes this exemplary: every theme connects a product area to a user need to a team, giving anyone reading it a complete picture without needing additional context. The owner, date, and version are visible in the header, making it clear when it was last updated.
Case study
Greetings & Gifts: E-commerce UX roadmap anchored in user problems
This e-commerce roadmap structures each quarter around primary and secondary user problems rather than features. Q1's primary problem: "I need to find what I'm looking for on g&g.com." Q2: "I need to buy online with ease and confidence." Each quarter also lists secondary problems to keep in mind, plus measurable business goals (revenue targets, conversion rates, CSAT/NPS scores). The vision and mission statement sits alongside the roadmap, anchoring every quarterly priority in the company's strategic direction.
The standout element: separating primary problems (what will move fastest) from secondary problems (what's important but not the current priority) prevents the roadmap from becoming an everything-at-once wishlist.
Case study
ASU Online: Multi-disciplinary UX roadmap with quarterly swimlanes
Arizona State University's UX team built a roadmap organized by quarter (Q1–Q4) with three swimlanes: Technical & Data, Research/Testing, and User Experience. Each swimlane contains specific initiatives — from "PHAT API Created" and "Optimization for load time" in Technical, to "Degree page user testing" and "AB Test: GDPR consent" in Research, to "RDS Homepage launch" and "Cost calculator redesign" in User Experience. A persistent technical initiative spans the entire year across the top.
This format works well for teams that blend UX work with technical infrastructure and research — it shows how the three workstreams interconnect and where they have dependencies across quarters.
Case study
Atlassian: UX Research specialty roadmap
Atlassian's UX Research Manager maintains a specialty roadmap — a subset of the broader UX field roadmap focused only on research. Each row is a research theme (Activity Feed, Benchmarking, Mobile UX, Confluence-JSW crossflow) with columns for subject type (Exploration, Evaluation), dates, priority level, status updates, assigned researcher, and linked Jira tickets. The "Status update" column is particularly useful — it shows real-time progress and notes like "In the 'Wonder' phase, working with both Conf. and Growth teams."
This demonstrates how specialty roadmaps go deeper than field roadmaps: they include operational detail (who's assigned, what Jira tickets track the work) that would be too granular for a team-level or stakeholder-facing roadmap.
Common pitfalls NN/g
Building the roadmap alone
A UX roadmap created by one person in isolation reflects one person's perspective. It misses stakeholder priorities, engineering constraints, and research insights from the team. Even if the final artifact is authored by the UX lead, the inputs and prioritization should be collaborative. The workshop approach exists precisely to prevent this.
Confusing themes with tasks
UX teams, trained in detail-oriented work, tend to populate roadmaps with tasks: "Create wireframes for checkout," "Run 5 usability tests," "Update component library." These belong in a sprint plan, not a roadmap. Themes should be problems or opportunities: "Reduce checkout abandonment on mobile," "Understand enterprise user onboarding needs," "Establish design system governance." If a theme can be completed by one person in one sprint, it's a task, not a theme.
Duplicating the product roadmap
If your UX roadmap themes are identical to the product roadmap themes, you've created a redundant artifact. The UX roadmap should surface work that the product roadmap doesn't capture: exploratory research, design system investments, cross-product experience audits, accessibility improvements, and proactive UX initiatives that aren't tied to a specific feature launch.
Never updating
UX roadmaps should be revisited at a regular cadence. Practitioner survey data shows the most common update frequencies are quarterly and monthly. The "Now" column should refresh every sprint or cycle. The "Future" column should be revisited when new research invalidates assumptions or when strategic priorities shift. A stale roadmap is worse than no roadmap — it communicates that the UX team has stopped thinking strategically.