This is the second article in a four-part series. To start at the beginning, read the article Guide to UX Planning — How to Create a Roadmap.
Good UX takes time and planning. Lots of it. That’s why your team needs a UX roadmap.
Getting on the same page with your teammates about what UX design project types will be included on the roadmap is an essential first step. UXers pull from a range of skills and methodologies to do their work depending on the needs of the project and team. That often means that the terminology we use, the timelines and processes we follow, and deliverables our partners can expect will differ significantly from project to project. Before we even get to planning, it’s critical that we start from a place of shared language and expectations.
Follow along as I share a framework for setting clear expectations with your partners on timeline and deliverables by design project type.
Choose design projects to help you meet your unique goals
It all starts with defining your terms. Most design work falls into one of the following categories, each with its own unique expectations for deliverables and timeline:
UX project type 1: launch projects
A launch project is a resourced initiative intended to provide lasting customer benefit. Most UX design projects fall into this category. They can be any size (XS through XXL), and large ones may be subdivided into smaller initiatives.
Critical criteria for launch projects:
- They must include a clear understanding of the user problem and success metrics.
- Design solutions are thorough, thought through well, and intended to last.
UX deliverables for a launch project generally include some or all of the following:
- Mockups of the complete designed experience, including final copy, edge cases, and error states
- Redlines or other development documentation for your engineers to follow when building, including any additional interaction specifications that may be needed.
- Insights and learnings from any relevant tests, experiments, or user research.
UX project type 2: experiments
Have you ever had a partner balk at the timeline you’ve given for a project and ask, “Can’t we just be scrappy and get a quick test out to learn?” My response is to propose an experiment: a lightweight (sometimes scrappy) test to prove (or disprove) a specific hypothesis over a limited period of time.
In this case, we agree to temporarily try a less thorough, faster-turnaround solution in exchange for a few agreed-upon guardrails:
- By definition, each experiment must include a clear hypothesis, testing criteria, success criteria, and thresholds, as well as clear next steps based on the outcomes.
- This experience will only stay live for as long as it takes to answer the hypothesis. Most often, it’s just a few weeks—not a long-term solution.
- The live experience must still meet team standards for public use, even if it’s just for a short period of time.
In most cases, experiments offer the quick answers needed to determine the direction for a launch project that will be a more lasting solution.
UX deliverables for an experiment generally include some or all of the following (in addition to the experiment criteria listed above):
- Mockups or wireframes, including final test copy.
- Development documentation, ad-hoc conversations, or collaborative working sessions with engineering partners to ensure the production test meets your standards for UX quality.
UX project type 3: vision work
Vision work is forward-looking, user-focused exploration. It results in a shared north-star vision or strategy that teams align around, even if that vision isn’t yet achievable. This tends to be cyclical work that informs annual or three-year planning. It can also happen at key points when teams are in need of renewed clarity or alignment on the future of their product.
The deliverables here are quite different from those for a launch project or experiment. Instead of outlining details and specifics, design deliverables for vision work are just high fidelity enough to communicate the high-level concept. Typically, the end result is a shared vision, recommendations for achieving it, and the outline of a phased approach for how to get there.
UX deliverables for vision or strategy work generally include some or all of the following:
- High-level concept visualizations of future ideas or direction
- Tip: Stay just high fidelity enough to communicate your idea and get partners excited about the direction. Avoid including any details that distract from your high-level concept.
- A clear explanation of how this vision solves for the user problems, including evidence from research and experiments that support the proposed direction.
- A proposal for additional research or experiments to validate the direction or answer critical open questions, if needed.
- Recommendations for achieving this vision, including a high-level proposal for a phased approach to getting there made in partnership with your product management and engineering peers.
- Remember: These recommendations will likely include dependencies on other teams.
- Ask: What could we start doing in our first quarter of work to move us in this direction? What could be done the quarter after? What about the following year?
- Consider: Because there are frequently unforeseen delays between phases, make sure each phase will be a solid standalone experience that meets your standards for quality.
I often find that vision work done one quarter informs my team’s roadmaps for the following several quarters or years. A healthy product team should plan to conduct some form of vision work at least once a year, especially ahead of annual planning.
UX project type 4: consultation and development support
Sometimes, our partners just need a consultation: some lightweight input rather than solutions or deliverables. We can help with that. Lightweight support takes less time but should still be marked on roadmaps.
We also need to keep in mind that projects that are actively in development take time and attention from UX practitioners, too. You’ll be pinged with questions, asked to review experiences in pre-production, and need to help troubleshoot late-breaking issues. I recommend designers mark upcoming periods of development support on their roadmaps as a reminder that their time and velocity for other project work will likely be reduced.
- Tip: If you find you’re getting interrupted and randomized by constant pings and questions, consider setting up a regular meeting series or office hours for the duration of the support period.
UX deliverables for development support or consulting time:
- Generally none other than your real-time input and feedback!
Get the right mix of UX project types on your roadmap
The types of UX projects on a quarterly roadmap depend on a few things:
- The overall maturity of your product.
- Where you are in your annual product planning cycle.
- What you’ve done in the last quarter or two.
When a product or problem space is nascent, you’ll need to schedule a lot of time for vision work. But established projects also need vision work (or vision refreshes). Any time there isn’t a clear strategy for what’s next — or the strategy you had feels dated or irrelevant — earmark time to define a new vision to take you through the next few years.
Finally, keep the future in mind by making sure your work can inform the next year’s direction. Carve out dedicated time for vision work and generative research on big questions at least once a year, ahead of your product team’s annual planning cycle.
Once your team has aligned on a strategy, the roadmap for your next few quarters may look very different. It will primarily be comprised of launch projects and experiments that help move you toward your vision.
After each project has been designed, plan on a slower velocity sprint as you support your development team as they build your designs.
In general, from concept to execution, your roadmaps will likely end up following these paths:
- Vision > launch projects > development support for those projects
- Vision > experiments > launch projects > development support
- Consulting > experiments > launch projects
A shared understanding is only the start
Aligning with all your partners to find shared definitions for project types, their timelines, and deliverables is a great first step to building your UX roadmap. But it’s not the end.
Now you’re ready to talk as a team about choosing specific projects, and competing priorities will likely be at play on any team. In the next phases of planning, stay focused on having effective conversations with your cross-functional partners ahead of each planning cycle. This will help you carry on the hard work you’ve done in this phase to lay a solid foundation of shared understanding for your roadmap.
Read more in the next article in my UX roadmapping series: How to Lead Effective Roadmap Planning Discussions
Go back to the series hub: Guide to UX Planning — How to Create a Roadmap
