This is the final article in a four-part series. To start at the beginning, read the article Guide to UX Planning — How to Create a Roadmap.
A lot of work goes into building a UX roadmap. In previous articles, I’ve shared how to make sure you and your cross-functional partners are speaking the same language when it comes to project types and expectations, and how to lead effective project planning and prioritization conversations.
But how do you actually take that information and make it into a clear quarterly roadmap document that accurately represents everyone’s capacity? Here’s a peek into my process for creating a UX roadmap that teams and partners can actually use, as well as some tips to keep in mind when you’re building your document.
1. Create a roadmap document
Start by creating a roadmap document using whatever platform works best for you and your team. Some teams use a spreadsheet, a Miro or FigJam board, or software like Asana. The easiest path forward is to use a simple shared document like a Google spreadsheet like this sample roadmap, which you can use as a template.
First, map the dates on your spreadsheet to the upcoming quarter. Try to use the same sprint schedule and cadence as your engineering teams, and mark out any holidays or upcoming vacations so you remember to limit your workload during those sprints.
If there are multiple UXers on your immediate team, I find it helpful to give everyone a section in the same spreadsheet, including UX researchers and UX content designers.
Then, refer to your project list for the quarter and enter each project into your roadmap document in order of timing and priority. In addition to vacation time, call out anything that might take up some of your velocity, like annual reviews, personal goals you have deadlines for, trainings, or team on-sites.
2. Scope your design work
Next, you’ll need to estimate how long each project or task will take you and add that to your spreadsheet. There are tons of methodologies for scoping design work. Some teams use t-shirt sizing, story points, or sprint percentages. Use whatever model works best for you and your team.
If you don’t already have a scoping model that’s working for you, here’s one of my favorites: The “Perfect Day” points system.
- Start by being realistic about how much time a designer actually has to work on a project. Sure, there are 30 days in a month, but how much of that is really heads-down design time? Imagine about a third of our time is taken up by meetings and weekends. Another third is evenings and responding to emails. That leaves about ten uninterrupted heads-down days’ worth of work time each month.
- Don’t ask how much time you’ll need to get something done. Instead, imagine you had an entire workday with no meetings to attend or emails to respond to; all you had to do was work on this project. How many of those imaginary days would you want to get this project done?
- Use that ideal day as a base unit for scoping work. These 7.5-hour, heads-down days may not happen often, but it’s an easy mental model to use.
- Review your list of projects and decide how many perfect days each project would need. Half a day? Give it half a point. Two days? Give it a 2. Would you like to dedicate a whole two week sprint? That’s 5 points. How about an entire month devoted just to that project? Give it 10 points. If you’re not sure, round up. It’s always better to deliver early than promise early and be late.
The nice thing about the Perfect Day points system is that you can split the math across sprints to fit in smaller requests without giving less time to a project than it needs.
3. Plan out your work
In your roadmap document, start assigning blocks of sprint time to work on each line item. Decide ahead of time how much work is realistic for you within a sprint. If you’re using the points and days method mentioned above, cap each designer at four or five points per two-week sprint.
So if you have a five-point project, you may decide to put all five points towards that project in the one sprint. But if you have urgent competing priorities or vacation time that sprint, you might decide instead to spread the five points for that project over two sprints, putting three points on one and two on the other.
It’s normal for large or ongoing projects to get split across multiple sprints, but if you have the option, I recommend designers stay focused on one project per sprint so they can go deep and not lose time context switching between projects.
Rearrange projects as needed to get your sprint totals below your maximum workload, and try to meet the scheduling requests from your team where you can. It won’t be perfect, and that’s OK.
4. Be realistic about your time
Often, demands on your time will exceed the actual time you have in the quarter. You’ll be asked to do more and to do it faster. When this happens, you may feel tempted or pressured to work extra hours to fit in every request. Stay strong and avoid that impulse. The point of this exercise is to improve the quality of your design work by ensuring you have enough time to do it well.
Here’s what to do instead: Map out all the projects on your roadmap, assigning each the amount of time they need to be done properly. They’ll overflow into the next quarter (or beyond). Show your cross-functional partners where things net out, and have a healthy conversation about which projects should be prioritized for this quarter over others and what the tradeoffs will be. Maybe project scope can be cut back or divided into phases. If there are other designers on your team, maybe you can look into sharing the load.
It’s important to take care of yourself; after all, you’re not a UX robot, and UX is not a bottomless resource.
5. Socialize your plan
Share your roadmap, even in draft form, with your product and engineering leads, and get their agreement. You’ll move things around quite a bit before you find a plan that works for everyone, but you can use this roadmap as a shared visualization to illustrate your capacity and that of your team.
When an urgent new project comes in and disrupts your plans, look at the roadmap together to visualize how subsequent projects will get pushed out and displaced. This makes it easier for your partners to understand the effects of adding something new.
And of course, expect that your plans will change over time. Decide with your cross-functional team early on how frequently you want to check in and revisit timelines and priorities.
Best practices to keep your UX roadmap working for you
Now that you’ve built your roadmap, here’s how to keep it in good working order:
Keep your roadmap accessible and up-to-date
Maintain your roadmap in a shared space so it’s accessible to your partners and always up-to-date. Get your partner teams and manager used to looking at this as the ultimate source of truth.
Review and revise as needed
Periodically review and update the roadmap with your product team as priorities shift.
Things change! And they often have a ripple effect: emergency projects coming up mean other work needs to get pushed out or deprioritized. When this happens, use your roadmap to help your partners to visualize the cascading effects of a change. This forces healthy discussions about prioritization and reminds your partners that, just like engineering, you are not a bottomless resource.
Ask for advance notice
Ask your partners to let you know as far in advance as possible about any upcoming work or demands on your time. It’s easier to commit resources when you have the lead time to plan adequately. This way, you can slip the project into next quarter’s roadmap when you’re planning it, instead of trying to cram it in (and move everything else around) after the roadmap’s been set.
Scoping will differ from designer to designer
I generally assume that scoping will vary by designer, experience, and product space, so a project that’s scoped at 30 points for an intern might be a 10 or 15 for a more experienced designer.
The goal isn’t to set a deadline. It’s to accurately predict how long it will take a specific designer to do a project well.
Round up on scoping if there’s any uncertainty, which there will be any time you try a new scoping method, work with a new team, or get familiar with a new product space.
Keep your roadmap easy to read
If you’re using a spreadsheet, hide rows and columns after the dates or projects have passed, so they’re not distracting. You want any partner to be able to see at a glance what’s happening now and what’s upcoming.
Use your roadmap to anticipate resourcing spikes
Most of us find there’s more work planned or requested than we can reasonably do in a quarter. The roadmapping process will help you and your manager understand exactly when additional resources are needed and what work will be below the line if additional resources are unavailable.
We rule the roadmap, not the other way around
Stress to your partners that the roadmap is a planning and prioritization tool, not dates set in stone, especially as you onboard your team to the process. Dates and projects can be adjusted as priorities shift, but those shifts require healthy cross-functional conversations about tradeoffs.
In short, the roadmap helps us visually understand the impact of these tradeoffs. It helps keep workloads manageable, makes it easier to identify gaps in resources, and ensures our shared understanding of the downstream impact.
Share your learnings
As with everything in UX, the methodologies outlined in these articles should be iterated and improved upon. As you embark on your roadmapping journey, feel free to find Indeed Design on LinkedIn and Twitter to share your learnings, your success stories, new tips, or great improvements you’ve made to this process. Happy roadmapping!
Go back to the series hub: Guide to UX Planning — How to Create a Roadmap
