A framework for better UX capacity planning
Many companies struggle with aligning on level of UX Effort a project needs. This framework can help.
If there’s one pain point I’ve seen designers and researchers at every company I’ve ever worked at, consulted with, or advised struggle with, it’s lack of alignment on the capacity & priority of UX Design & Research work.
Some of the struggles come from designers who expect to do the “full UX process” (whatever that means) on every project. Other designers have anxiety letting developers implement anything they’ve designed without first usability testing their work.
Even more common is a lack of alignment with Product Management on the level of research & design effort a particular project should justify. Often, this is because no actual capacity planning for UX work takes place. Effort, Estimates, Roadmaps, and Capacity are all terms most commonly assigned to engineering work. Commitments are made, and planning is done for the delivery phase only.
To be fair, I’ve also observed that it’s not so much that teams don’t want to include UX in their estimates. They often just don’t know how. There’s no standard framework for level setting across the board around Design & Research Effort. Until now.
Problems to solve
There were 4 main problems I set out to solve:
- Improve UX Capacity planning and improve alignment between UX, Product, & Engineering on level of UX effort needed in varied circumstances.
- Set realistic expectations on the kind of UX activities that can realistically be expected in the timeframe
- Help UX team determine level of discovery, iteration, and execution
- Empower UX team to spend more time on projects where they can add the most value.
Pendo Research Effort Framework
Others have taken a stab at similar problems. In August of 2021, Jeanette Fuccella published a research prioritization framework on the Pendo blog attempting to solve the problem of determining how much research to do.
She created a quadrant across two dimensions: Problem Clarity & Risk.
- Problem Clarity: High and Risk: Low was “Ship it and Measure”.
- Problem Clarity: High and Risk: High was “Design Heavy”.
- Problem Clarity: Low and Risk: Low was “Research Light”.
- Problem Clarity: Low and Risk: High was “Research: Heavy”.
While very useful at a conceptual level, there were some practical obstacles to overcome:
- It provided little context on what Research Light vs Research Heavy meant. It illustrated when to do which level of research, but not what that research entailed.
- Most companies don’t have the luxury of having a big enough research team to do all the project-level research. So the question came up of when should a designer do the research and when should it be left to a full time researcher?
- Attempting to combine both research and design into 1 matrix was overly simplistic. It helped some with determining research effort, but I saw a big opportunity to do a similar thing for Design effort.
UX Effort Framework 2.0
My new framework splits out research effort from design effort, included t-shirt level effort guides, a description on what each level of effort is (and when to use it), as well as common activities or attributes per level.
For Research Effort, I stayed with Problem Clarity vs Risk. Risk also makes sense for Design work, but I replaced “Problem Clarity” with “Complexity” (as complexity is often what determines how much iteration we need for design work).
PROBLEM CLARITY: HIGH
This is a problem we’ve worked on before, have extensive existing qualitative & quantitative research we can leverage, and/or shared understanding of across the team.
PROBLEM CLARITY: LOW
This is a largely new or unknown problem. Lots of assumptions exist. The problem is not well defined and significant alignment needs to happen. This work is likely at the strategic / initiative level.
RISK: HIGH
Work that is not easily “undoable”, affects a large % of users’ key workflows, and/or has a large amount of risk to the business or user experience.
RISK: LOW
Work that is easily undoable, affects a small % of users, does not affect mission-critical workflows, and where “getting it wrong” would have only a small impact to the business or user experience.
COMPLEXITY: HIGH
Involves many systems/APIs, external dependencies, stakeholders across multiple teams, or is technically complex (in ways that affect design decisions).
This is a problem space with many questions or in which the designer has little existing knowledge.
COMPLEXITY: LOW
Is mostly self-contained in terms of systems and stakeholders, has few if any dependencies, and is straight-forward.
Often these are simple usability improvements or additional use cases in well-understood workflows.
Research Effort Quadrants
To help understand each effort level better, let’s take a closer look at each of the Research Effort levels.
SHIP & MEASURE
Sometimes we need to prioritize speed over research rigor. This is best done when the problem clarity is high and risk is low. Often this step entails partnering on a post-release strategy and can be done by a designer.
RESEARCH LIGHT
Even when risk is low, if we have low clarity around the problem we’re trying to solve it is wise to do some research. Yet, we don’t need to spend weeks starting from scratch. Research Light also usually focuses on follow up discovery research. Since the risk is low, usability testing is not usually needed at this level.
Research Light is most often appropriate when we have prior quantitative or qualitative research we can leverage but still have unanswered questions. This research is typically done by the design team. Freeing dedicated research teams up from doing Research Light projects is a key element of improving the value created by research teams.
RESEARCH MEDIUM
When risk is high, even if problem clarity is high it is important to invest in research. The key difference between Research Medium and Research Light is that since the risk is high we do need to invest in evaluative testing since it’s not easily undoable or the cost to the business if we get it wrong is high.
It is also worth noting that this is the most common level of research that a designer will conduct if a dedicated research team is established.
RESEARCH HEAVY
For larger projects spanning multiple projects, teams, or journeys, more rigorous research is needed. Often these projects will require multiple research methods spanning generative & evaluative, qualitative & quantitative, and attitudinal & behavioral.
This kind of research typically is more strategic in nature and should be completed by a trained and experienced researcher. It often requires more time than a designer often has to run on their own.
Design Effort Levels
The level of design effort needed between quadrants detemines:
- Level of fidelity needed
- Leveraging existing patterns vs creating new patterns
- Amount of iteration required
- What stages of UX work are needed (modeling/mapping, wireframes, mockups, prototypes, etc)
The intention here isn’t to restrict the designer to a particular deliverable, but instead to communicate to partners the type and amount of work needed depending on risk vs complexity.
CONSULT ONLY
Not every project needs direct UX “hands-on” work. When the risk and complexity are low, it is 100% acceptable for UX to be consulted rather than assigned work (mockups) to do. This will enable the design team to spend their time on work where they can have the most impact.
Doing more consultations when risk is low, complexity is low, and we are leveraging existing design patterns is a key to unlocking UX’s potential to contribute more strategically to building the business. Too many designers spend far too much time being mockup monkeys for pre-determined solutions.
In those cases, it is extremely helpful to set the expectation with your product team that you’d love to just have a quick connect to align on the right component to use, flow, etc but that then the engineeering team should be empowered to do that work. This is one of the biggest benefits of having a design system in place.
I’ve even worked places where a front end engineer would spin something up quickly with a mocked up back end and then just show it to me. We’d discuss a minor tweak or two and then it would be ready to connect to the real back end and be released.
Letting go of needing to do a mockup on every little UI change is a key tactic in being able to spend more of your time on the more complex and risky (and impactful) work for which you are uniquely suited.
DESIGN LIGHT
Even if the complexity is high, if the change you’re contemplating would be easy to undue if it went awry, there’s often no need for a high level of iteration, low fidelity pre-work, etc. Just get it out there and test in the wild.
This is work where due to the complexity, we’re not comfortable just consulting, but we also don’t need a month of design work. Another key component here is where the cost to the business or user experience would be low if you’re wrong.
HINT: work related to personal info, financial transactions, government regulations, or mission critical systems should never fall within “Design Light”.
One of the biggest mistakes I see teams make is wanting designers to do UX Light work on every project. One of the big value-adds of using a framework like this is to help illustrate that we absolutely can do UX Light work, but only when Risk is low.
DESIGN MEDIUM
When Risk is high, it’s important to do more iteration and start problem solving at a lower fidelity. If the complexity is low not as much of this is needed, but it still makes sense to spend some time iterating to avoid costly rework and negative business impact.
Another common reason for Design Medium rather than Design Light has to do with situations where a new pattern / component needs to be introduced. Extra validation and testing are needed and it’s important to allow capacity for that.
DESIGN HEAVY
Finally, we arrive at Design Heavy. These are complex, risky projects where getting it right is essential. Often Design Heavy is paired with Research Medium or Heavy as well unless extensive prior research has been done.
This level is what many designers think of when they talk about the “Full UX Process”. Modeling, Information Architecture work, Low Fidelity, Mockups, etc. Although deep functional prototyping is not always needed, it is important here.
The work needs to be more thorough because the cost of getting it wrong would be significant to the customer and/or business.
How to use this framework
“This sounds great, Jeremy”, you say, “but how do I actually use this?” That’s a great question. Let me share an example.
1. PROJECT PLANNING
When a project get’s prioritized (and often before), we populate the Project description with the following:
- Background Info (any context needed to understand the problem)
- Problem to Solve (and why this is worth prioritizing now)
- Business Impact (or “value”)
- User Outcome (how will someone’s life improve)
- Success Criteria (what do we need to observe to know we were successful)
Usually these are populated by the Product Manager, but it definitely can and often is a joint effort.
Then, the assigned UX Designer on the team will take a stab at populating:
6. Design Effort level (based on the framework criteria)
7. Research Effort level (based on the framework criteria)
2. PROJECT KICKOFF
We then hold a kickoff with the balanced team and any key stakeholders (such as UX, Product, and Engineering leaders). We align on on the Project Description (including UX effort) before designers start work. Tweaks or additions are often made.
3. DESIGNER ADDS UX STORIES TO JIRA
One thing that I’ve found invaluable is to ensure UX tracks their work in a project management tool such as Jira. This helps provide clarity & transparency to partners, and allows us to hold ourselves accountable.
Once we’re all aligned on all the above, the designer will break up the project into individual work items (stories, tasks, product backlog items whatever flavor the org prefers). Guideline for level of fidelity is that each backlog item should be tied to some sort of deliverable (research plan, wireframes, mockups v1, research readout, etc). The Effort Framework operates as a guide on what backlog items should be done.
Each backlog item gets a specific estimate and is prioritized according to PM’s direction on which project should be worked on first, etc. Backlog items then get dragged into Sprints based on the designers capacity.
4. PLANNING
At this point, UX stories are reviewed with Product & Engineering and adjustments are made according to priority, business needs, etc. Our goal is to do this for all projects on the roadmap for a particular quarter. We recognize changes will happen but having something written up and prioritized for all projects in a given quarter enables UX Capacity to be taken into account when doing Quarterly Planning which results in more realistic expectations being communicated to executive leaders.
NOTE: I’m a firm believer in prioritizing problems & outcomes rather than features. That’s an ideal state I always work towards. I have found, however, that isn’t the way most teams realistically work. So ensuring a problem and outcome is defined for projects being prioritized and letting UX Effort and capacity guide release schedules (instead of the other way around) has been a useful & realistic compromise.
I’m Jeremy. I help orgs build better design teams and designers build better careers. Need help? Just ask.
Works Cited / Further Reading:
