A UX roadmap is a strategic, living artifact that aligns, prioritizes, and communicates a UX team’s future work and problems to solve. In this article, we answer the most frequently asked questions we receive about roadmaps in our full-day course, UX Roadmaps

1. How Do Roadmaps and Project Plans Differ? 

Roadmaps should be the bridge between a company’s UX vision and project-tracking artifacts. Thus, roadmaps are strategic, vision-oriented documents, while project-management plans focus on execution and output tracking. 

Needs or problems to solve are represented on a roadmap, whereas solutions to those needs are represented on a project plan
Roadmaps capture the work that the organization needs to do, in order to fulfill its vision, but do not explain how that work should be done. Project plans are specific and include the steps or tasks that must be accomplished to address a need. 

Roadmaps are used to communicate future work at a high level. They lack formal, discrete task definition and capture a range of potential problems to solve, which have yet to be solved. Each of these problems can be broken down into tasks, captured in a project plan or task tracker. In these, items are specific, low-granularity, less likely to change. They often include discrete, measurable tasks that are carried out by individual members of the team. 

2. How Does a UX Roadmap Relate to Other Roadmap Scopes? 

Teams can create 3 types of roadmaps that vary in goals, context, and intended audience: 

  1. Product roadmaps represent all future problems that need to be solved, including ones related to UX, marketing, content, design, research, development, support, or operations. 
  2. Field roadmaps represent all future problems to be solved by UX (for example, related to design, research, or content), but do not include problems outside of UX (for example, in marketing, development, and support — these fields might obviously have their own, separate, field roadmaps).
  3. Specialty roadmaps are a subset of field roadmaps and focus only on problems within one UX area (for example, in user research). 

Field roadmaps are the most used roadmaps in UX. They include problems to be solved by any UX area: user research, UX design, content, information architecture. Unlike product roadmaps, field roadmaps can cover multiple products (or product areas). They provide a way to align across UX areas and educate stakeholders on the user-centered–design process.

While field roadmaps are the most common across UX, specialty roadmaps are the most common roadmap type used in UX research. They outline the research efforts taking place over time and the research question addressed by each effort. 

Unlike product roadmaps, both field roadmaps and specialty roadmaps can capture problems to solve from across projects. For example, one research team may conduct research for multiple product-design teams. A specialty roadmap for this research team would thus include activities targeting a variety of products and teams. 

3. What Are the Benefits of UX Roadmaps? 

All mapping methods have benefits from both the process of creating the map and from the artifact itself. The process of collaborating with others to make a roadmap helps practitioners: 

  • Align and prioritize diverse work. Often UX practitioners get a range of requests thrown at them — “add this feature,” “expand this capability,” “do this research,’’ or “satisfy this customer request.”  Ideally, to maximize efficiency, they should identify similar problems to solve across these requests and prioritize them. The roadmapping process [SG9] helps practitioners reveal themes and patterns from a wide variety of potential work activities, then prioritize them based on a mix of business- and user-oriented criteria.  
  • Create common ground. A highly functioning team shares a common vocabulary and understanding of the work at hand. However, this is easier said than done. Collaboration throughout the roadmapping process, especially as themes are identified and prioritized, helps surface any misunderstandings before the work gets underway and minimizes conflicts later in the process. 
  • Build buy-in across the team. Participation and ownership increase the likelihood of buy-in and support later in the process. By collaboratively prioritizing activities as a team before the actual work begins, team members are more likely to buy into the high-level strategy and sequence of work. 

The artifact that results from the roadmapping process then can be shared and distributed. This artifact can be used within and outside of a team to: 

  • Bridge UX disciplines and teams. A field roadmap interweaves objectives from all UX areas. Each UX area can see what other areas are working on. For example, the design team can see what research is tackling concurrently. A roadmap acts as a single source of truth, enabling general awareness and fostering crosspollination.
  • Communicate the UX-design process. Many teams, especially those with a low UX maturity , must still educate their stakeholders on what it means to be user-centered. A field roadmap communicates the UX-design process, from early discovery research to content creation and to wireframing and clearly articulates future UX work. It gives a high-level view into the problems that the UX team must solve and frames needs from the beneficiary’s point of view.

4. When Should a UX Roadmap Be Created? 

Roadmaps are not meant to be created every week. They are a strategic tool, best used at key moments when communication and alignment is needed. There are 4 primary instances when roadmaps are created: 

  1. New initiative. Roadmaps establish a shared vision and prioritize the first problems to solve. They are a visual representation of a strategy for the new project and where you plan on starting. 
  2. Something’s gone awry. Every now and then, teams reach a breaking point as a result of too many competing priorities and no one knowing what’s going on. In these moments, roadmaps can help recalibrate goals and orient around a single set of vetted priorities.  
  3. Leadership change. Whether it be the result of a reorg or simply a new leader joining the team, there’s a level of education that must occur. Roadmaps can communicate existing initiatives and current direction to new leaders. 
  4. Annual planning. This is the most common instance when roadmaps are created. Roadmaps help align focus as teams head into a new year (or quarter). Creating roadmaps for the coming year or quarter rallies excitement and helps advocate for future resources. 

5. Who Should Be Responsible for Creating a UX Roadmap? 

The responsibility of creating a roadmap depends on the type of roadmap and the makeup of a team. As a general rule of thumb: 

  • Product roadmaps are most often created by product managers. In many cases, UX directors or leads will step into the role of product managers and create the product roadmap (or cocreate  it alongside their product peers). In teams with high UX maturity, product roadmaps are collaboratively built by leaders of product, design, and development. In teams with low UX maturity, design leads are often fighting to have a say in the high-level product roadmap. 
  • Field roadmaps are usually led by UX directors or leads. These leaders (or managers) oversee multiple UX areas within a product and are responsible for the team(s) who deliver on the UX vision. They are often the same individuals who participate in the creation of the higher-level product roadmap and thus understand the driving strategy and vision. UX program managers may also be creators of field roadmaps. They are the people tasked with program- or organization-level design operations.
  • Specialty roadmaps are most often created by team leads (e.g., design, research, content teams) or by individual practitioners. Team leads will create specialty roadmaps that outline the work that their specific team is tackling. In smaller organizations or startups, specialty roadmaps are created by individual practitioners to communicate their planned work to their manager and peers.

6. How Long Does It Take to Create a UX Roadmap?

The amount of time depends on the type and scope of the roadmap you are creating. Your roadmap scope will largely impact various other factors, including the people involved, the number of inputs needed, and the stakeholder engagement.

In our survey with 104 practitioners on how roadmapping is used in organizations,  the majority of participants reported that, on average, they spend less than 1 day creating a roadmap.

Roadmaps don't take too long to create. Most practitioners create them in less than a week.
Only a relatively small segment of participants (34%) reported spending more than 1 week to create a roadmap.

This breakdown makes sense, as most roadmaps are created in a roadmapping workshop that can take from a few hours, if working on a smaller scoped roadmap (like a specialty or field roadmap) and up to a few days for a largely scoped roadmap (like a portfolio-wide field roadmap or product roadmap). 

When roadmap creation takes weeks or months, this time will often include conducting discovery research, creating a high-level vision, identifying prioritization criteria, and aligning stakeholders. These tasks, though not directly tied to the creation of a roadmap, are required for a successful roadmapping initiative. 

7. How Often Should a UX Roadmap Be Updated?  

A successful roadmap isn’t intended for one-time use. A roadmap creator should revisit and update a roadmap to keep it current. Updating a roadmap includes: 

  • Moving themes that have been completed to a Completed time-horizon 
  • Shifting next-in-line themes to the Now column (or the column most current)
  • Updating themes with new insights (often as a subtheme) 
  • Reprioritizing items based on new learnings 
  • Adding new themes to a Future++ or Ideas column

The majority of participants in our roadmapping research reported that they update their roadmaps between once a week and once a month. 

Most practitioners up
The majority of practitioners reported updating their roadmaps once a week to once a month. 

We recommend scheduling a monthly recurring meeting to revisit your roadmap (for example, a standing meeting the first Friday of every month). This cadence is fairly comfortable and ensures that the artifact stays current. As you make changes each month, save previous versions. They are valuable communication tools for interfacing with new stakeholders or onboarding members to the team because they depict previous efforts.  

As you continuously revisit your roadmap, pull others into the process. In the long term, this approach creates a community of practice. As your team builds roadmapping expertise, team members can take on the responsibility to create the small-scope roadmaps like specialty roadmaps. 

8. How Should a UX Roadmap Be Presented and Shared? 

How a practitioner presents and shares a roadmap is just as important as the quality of the roadmap. Most practitioners create a roadmap, then copy and paste it into a slide deck or drop a link into an email. While this approach may seem efficient, it opens the door for unhelpful or off-topic feedback and questions; it also makes it easy for stakeholders to ignore it.  

Instead, schedule a meeting and tell a story as you are presenting the roadmap to others. Use  progressive disclosure to avoid overwhelming your audience and to keep it focused on the activities that are most relevant in the moment. Use the below outline to construct an efficient, effective roadmap presentation: 

  • Set context to help stakeholders understand the roadmap and where it came from. Without it, you run the risk of inaccurate assumptions or a lack of buy-in. This part should be brief — no more than 5–10 minutes. 
  1. Who: Give background on the team that created the roadmap and the high-level vision that the roadmap maps back to.
  2. Why: Describe how the roadmap will be used and the criteria used to prioritize the work represented in the roadmap. 
  3. Recent Progress: Briefly share a high-level overview of recent work completed. For example, you might share a previous roadmap, framed as a reminder of where you’ve been and what you’ve recently accomplished.  
  4. Research: Outline any recent data that supports the success of recent activities or that directly drove new additions to the roadmap. 
  • Show now and near-term time horizons.
  1. Now: Show the immediate work underway (the Now column). This part warms stakeholders up with what they are likely already aware of and comfortable with, while priming them to better understand the roadmap structure and format. 
  2. Next: Once you’ve shared the Now column, display the next time horizon (usually the Next column). This slide focuses the discussion and lets you frame the work you’ll soon begin, appropriately limiting discussion to it. 
  • Share the long-term vision (or in other words, reveal the roadmap in its entirety). 
  1. Future: Now that you’ve shared the Now and Next columns, reveal the Future column. Work in the future is naturally the most abstract and ambiguous and showing this column first would have prompted many questions. However, now that you’ve primed stakeholders with the previous two columns, there’s more context and perspective. Frame the discussion to be exploratory — nothing in this column is final and each theme will evolve as you learn more from your current work.
  2. Full Roadmap: Display the roadmap in its entirety. At this point, share any open questions or decisions you have for your stakeholders. Clearly identify next steps and what they can expect in the next month or two. 
When presenting roadmaps, don't show everything at once. Give context and show each time horizon one at a time.
Tell a story around your roadmap by setting context, showing Now and Near term columns, then showing the longer-term vision.

Conclusion

Roadmaps act as single source of truth as to how you plan to execute a strategy. They should be a bridge between your vision and task management. The type and scope of your roadmap directly impact the time it takes to create a roadmap, as well as whose responsibility it is to create it. 

Reference

C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors. 2017. Product Roadmaps Relauched. O’Reilly Media. Sebastopol, CA.

Written by Sarah Gibbons.