How to: Do a design review as a product manager
Win over your designers and avoid becoming that PM...
Where PMs fail when reviewing designs
Many PMs will approach reviews with a creator mindset and quickly spit out many potential UX or UI updates, in some cases even feature ideas, without acknowledging the thinking and approach laid out by the designer. In contrast, some PMs do not go deep enough during design reviews leading to designs that can often lack the alignment and depth to be effective when built.
It is key to acknowledge that the designer is the driver of the design and it is through their understanding of the business case, customer, and context that the team will succeed in finding the right experience. Collaboration is necessary, of course, but the designer is ultimately running point on the design. The PM, however, is running point on ensuring the design drives value and delivers on the intended use case by ensuring a use case and value-focused mindset during the process. Through this combination of roles, the discovery and design process finds the necessary pressure, trust, and collaboration to deliver effective design solutions.
The PM’s role in a design review:
The PM’s job is to ensure that the conditions are in place for the designer to succeed. Simply put, the goal is to sharpen design thinking by challenging, clarifying, and contextualizing where applicable. The PM should bring a clear and in-depth understanding of the customer, use case, market, and business implications as well as an open mind and understanding of basic design concepts. As a reviewer, the PM is seeking, throughout the review, to:
Clearly understand the laid-out approach
Assess the design approach in its ability to solve the use case
Correct any misconceptions about the business context
Challenge the approach and identify risk areas/complexity that need to be mitigated
Ensure that the design approach is aligned with the business case, the philosophical direction of the product, and the end user.
Help refine the key follow-up questions/areas to be investigated by the designer.
By doing the above things you’ll become a more effective partner for the designer because you’ll be helping the designer find the path and enriching their mental model for the solution. The designer is the driver, only they can get you to the outcome the team needs, but that doesn’t mean they won’t get lost - this is where the PM can provide the most value, ensuring that we can find the way.
When do things enter the PM domain?
I think there are a few places where one can draw the line for where the PM can, and should, jump in:
The investment cost line:
When a path’s cost exceeds the acceptable investment level for the problem it’s partly the PM’s job to help the team understand a threshold has been reached and the solution needs to be downscaled.
It’s important with this type of intervention, to try to understand why the designer ended up where they are. Are they seeing something you’re not, or is there a misalignment in how certain variables are weighed?
This is most effectively done with team input and understanding, which requires nailing the exact reasoning for why it would be over-investing.
The business requirement line:
When a path is solving alternative business requirements or business requirements that don’t exist, or not solving the core business requirements at all, then a PM can step in and pull back.
The PM is responsible for the outcome being driven and (ideally, always) has the most use case knowledge. This makes them the most capable actor to re-direct focus.
Again, here it’s important to try to understand why the designer ended up where they are.
The decision needs to be made line:
When an area of the project becomes blocked there’s no agreed-upon solution, and one can’t be arrived at through research/testing/validation, it’s the PM’s job to make the decision and take accountability for its outcomes.
In many projects, this won’t be required, but when it is required, it can be one of the more important things the PM can do as it ensures the project continues moving forward.
The work is not good enough line:
If you’ve spent the time to fully understand the laid-out approach and at the end feel like it’s not good enough and is missing elements that have to be there for launch, it is in your domain to course correct and push the designer to dig deeper.
This can be the hardest intervention to make, but when it happens it’s the most important intervention because it ensures that you don’t put something out there that fails to deliver value.
How to approach a design review:
Ask yourself if you’re at the beginning or finishing phase.
Discovery tends to be in either the beginning or the finishing phase. During the beginning phase, you’re trying to nail down the philosophy and requirements for your solution. The beginning is open and benefits from gathering information, talking to customers, experimenting, and having long philosophical conversations. It’s the going broad stage of the work.
During the finishing phase, you’re trying to move the work towards a buildable place. The finishing stage is focused on closing out open questions, focusing on the core value to be delivered, editing down to the essentials, and ensuring what we end up building nails the problem/philosophy/value we set out to achieve.
It’s important to always have a strong sense of if you’re beginning or finishing and adjust your approach accordingly. If you don’t know where you are in the design process, you might end up investing in processes that aren’t necessary and the process will lose momentum and focus.
During the review, start by understanding the state of the design.
It’s very easy to get lost in a misunderstanding about the level of definition something has. Understand the progress level of the work so that you don’t spend time on the things that they haven’t thought much about. Focus on the things they spent the most time on in the review, or if they’re going the wrong way, focus on clarifying the focus/understanding the misunderstanding.
Ask the designer things like
“What things should I pay attention to and which ones aren’t ready?”,
“Is the work still very conceptual, or more evolved”,
“Should I pay any attention to the UI or just the experience?”
Then dive deep into understanding the design. Hold your thoughts until the review is finished.
Spend as much time understanding the approach as possible before making any pronouncements. Try to understand why the designer made each choice and how each choice works together to create a mental model for the solution. This should be 1/2 of the review with the second half being a discussion.
During the review emphasize that you’re trying to understand the approach fully and that you’ll be asking many questions, that these will not be judgmental, just information gathering. For understanding, oftentimes intense questioning is necessary, this can make designers feel challenged. You want to mitigate this going in.
In terms of questioning, focus on understanding the designer’s decision-making process at great depth, look at each frame and each experience step, and ask the designer things like:
“Walk me through how you got to this implementation, what considerations did you have, and why this felt like the best decision?”
“What led you to place this step here specifically? How does this placement affect the rest of the experience?”
“What do you think are the most important factors to mitigate? Why those factors, and how do you think the approach mitigates those?”
“How do you see the intended user using the feature? Walk me through the flow for x use case ?”
“What do you think will work and what are you worried will not? What did you deliberate the most on with this approach?”
“What led you to this specific UI (dig into specific affordances, placement, components, and how they affect the user’s experience and interpretation of the experience?”
“How do you expect the user to feel throughout this experience?”
“Do you feel that the user will clearly understand at each stage why this is being asked of them or what their options are?”
“What are the principles that you feel are really important in this experience?”
Once the design approach is fully understood, hone in on the key questions worth discussing.
Once you fully understand what’s being presented, focus on highlighting the areas that work and the areas you’re worried about. Discuss each of these to the depth applicable. Mostly focus on what’s missing or what’s going the wrong way over what everyone likes. Discussions around these areas are where the majority of the progress will be made.
Look for problems at a few different levels:
Path: will users effectively get from point A to point B or is there danger they’ll get lost or stuck?
Comprehension: will users understand the affordances in place, is there enough context building, is there an overwhelming amount of information, do users understand the possible actions and their outcomes?
Requirements: are we solving for the requirements or are we off track, are there new requirements that may have surfaced, will this thing deliver the value we expect?
Complexity: is the solution being presented overly complex from any lens, is it overly complex to build, hard to maintain, hard to support, has redundant parts, has unnecessary parts, is it overkill, or should it be simpler?
Placement: Why is this feature in one part of the product and not the other? Why does this path take us here? Why does it exist at the 1st layer of interaction and not the second?
Sentiment: is there a specific feeling or notion that is key to the user’s success with this experience? Does the laid-out experience keep that in mind/achieve it?
Principles: are there essential principles to this experience that must permeate the experience (for example, the experience should always feel non-intimidating, or users should feel rewarded at each step)? Does the design factor these principles in?
Finally, focus on the clear next steps to move the project forward.
Always end with clear next steps or areas of questioning, and align with the designer on what these are and why they’re valuable. Be very conscious about what the process needs, in particular:
Do we just need to keep exploring the use case further and go more in-depth into certain areas?
Do we need to validate certain notions so that we can safely move forward?
Do we need to be more focused on a very specific use case/customer journey and run the design through that use case/customer journey?
Do we have a lot of unknown unknowns, should we go talk to customers to find these?
Do we need technical input to ensure that what we’re coming up with is buildable?
Design reviews will very often end with new questions. It’s important to highlight the progress made in closing older questions and pinpoint the new areas of investigation. If both the PM and designer are aligned on these, you’ll often make quick progress on the problem to be solved.
Note: Over-invest in philosophical conversations when there isn’t a strong internal sense of what you’re trying to do, don’t over-invest in philosophical conversations when the truth can easily be arrived at with exposure to the customer. Remember that sometimes, you might need to ship the thing and see what happens with the scale.