A Product Designer Perspective

Design reviews are a cornerstone of an effective design team. They offer opportunities for design peers to have visibility into each other's work and are most commonly used to give structured space for critique of proposed UX or the application of a design system.

Within a product team, reviewing designs early and often with your product managers and engineering partners is equally important. Design reviews ensure that the whole team is aligned, customer and business goals are met, and any potential issues are addressed throughout the project lifecycle.

During my time at One Medical, I was the strategic design leader in a product team focusing on improving our app experience for pediatric patients and parents (Kids and Family). As part of a triad with product and engineering managers, we defined our team’s goals and were able to prioritize areas of high impact for our target customers. We also had the autonomy to create ways of working together that made our product development process more efficient. One of my contributions included how we come together as a team to review designs throughout the project lifecycle.

Below is the comprehensive design review plan I created to keep my product teams and project stakeholders aligned through the lifecycle of our projects. This is not intended as a one-size-fits-all plan for every product team and organizational structure, rather, an overview of a successful structure which you can take what you need from and leave the rest.

Kickoff Meeting

The design review process begins with a kickoff meeting. This sets the stage for the entire project and serves as an opportunity to start discussions among relevant stakeholders. The primary goals of a kickoff meeting are to create project awareness and transparency by aligning objectives and project scope, surfacing risks, identifying cross-team dependencies, coordinating project timelines, and outlining the next steps.

Attendees for a kickoff meeting will typically include the core product team; which in my case included a product manager, an engineering manager, myself as the design lead, and all engineers assigned to the project. Other important attendees can include Quality Engineering (QE), Customer Support (CS), and Cross-departmental stakeholders like product leadership or other product domain teams. Basically, any teams or individuals that may be impacted by, or have information for, your project.

The meeting is typically led by the Product Manager (PM), with contributions from design and engineering. While it’s easy for design to jump straight to creating solutions, it’s best to bring information to this meeting. I will use the kick off meeting to speak on behalf of the customer and highlight relevant pain points we’ve received from research or feedback submitted to our customer service team. This information will help define a clear customer problem that aligns with the business objectives and will inform designs once starting to explore possible solutions. When available, I will bring customer persona’s, exploratory diagrams, or maybe even low-fidelity wireframes as visuals to anchor the discussion to our customer’s needs.

There are also occasions where a project is assigned to a team and there is less information available. When this happens I like to bring the following questions to kick off meetings to ensure I have what I need to being explorations:

What is the customer problem that we’re trying to solve?
Where did the request come from? (e.g. a senior leader, or from customer feedback)
Are there any documents or research that’s already been created to reference?
How does this fir within our priorities?
How will we know we’re successful?

Initial Design Sync

Following the kickoff meeting I typically start exploratory design concepts to offer multiple solutions to solve our customer’s problem. These early designs should aim balance both the business objectives and scope constraints defined in the kickoff meeting, and provide a solution to solve the customer problem. Once I reach a point where engineering input is blocking ideation, I’ll organize and schedule our team's initial design sync.

It’s best for the initial design sync to happen early in the design process when designs are low fidelity and a solution hasn’t been decided. The goal of this meeting is to review proposed design explorations with engineering and product to gather their feedback on feasibility and ensure the design direction is aligned with project objectives and scope. For engineering, the initial sync is an opportunity to get a sense of the potential design solutions and roughly estimate the level of effort (LOE) it would take to build, discuss potential technical risks, and identify dependencies for each potential solution.

For this meeting to be effective, the core team (PM, EM, Design lead, and supporting engineers) should prioritize attending this meeting to ensure their perspective is included in the direction of the designs. Other participation from CS, and dependent teams are optional since a solution isn’t completely defined. Design typically leads this meeting, with contributions from the PM and engineering as needed. Design deliverables for this stage can include flow diagrams and/or grayscale wireframes that explore multiple solutions for the identified customer problem.

Design Refinement Reviews

At this point in the design process the team is pretty aligned on a direction for the project. Many early explorations have been explored and wild ideas have been moved to a parking lot or archived. Now is the time to capture all possible use cases, edge and corner cases and really get into the weeds with the solution. For me, this is when I like to connect with my product team more often, maybe even twice a week, depending on how fast the project is moving.

Because this part of the project lifecycle can have many touch points with the team, I’ve broken up the reviews into three rounds, each with specific goals and deliverables. You can add more rounds as needed of course, but this is what I strive for.

Round 1

Depending on how quickly your design team jumps to high-fidelity designs, this may be the first time the core product team sees full-color UXmocks. You may also still be in grayscale wireframes, which is fine. Fidelity doesn’t matter as long as you get what you need to move the designs forward.

The goals of this round of refinement are to present your proposed solution and capture feedback from engineering and any new dependencies now that the designs are more developed. This is also a good time to ensure all use cases are covered and that your solution is still within the project's scope and agreed timeline. It’s important to document any necessary edits for the designs and bring those changes to round 2.

Attendees should include the core product team and optionally dependent stakeholders when their input is needed to unblock design progress. Design leads the meeting, with contributions from engineering and optionally the PM. Design deliverables can include grayscale wireframes or a mix of higher fidelity mocks that start to consider the use of established design system components.

Round 2

The refinement process continues as designs get closer to engineering handoff. The goals for this refinement review are similar to round 1 but may only require a quick walk-through with engineering to cover any design changes. However, if major changes were applied to the designs I recommend a full walk-through to get the team aligned on the new approach and prevent surprises closer to the engineering kick-off.

The attendees and roles are the same as in Round 1, the design deliverables should be in higher fidelity and start to consider final components and page details. If the team is aligned with the design direction, now is a great time to begin working with a copywriter (if available) to start removing placeholder copy.

Round 3 (or, the last review before the final review)

As I said above, three rounds of reviews is not a firm number and it’s very likely that more will be needed to get the designs where they need to be. Regardless of what round it is, the purpose of this review is for the core product team to come together one last time to pick nits, ensure all platform best practices and components are correct, and make sure you’ve removed all the filler copy.

It’s important for all attendees to be in agreement with the solutions and have a good sense of any risks and dependencies before moving on to the final review where wider groups of stakeholders are brought back into the discussion to provide their feedback.

Final Review

Now it’s time to present your final designs to a room full of stakeholders. For me, this meeting brought back cross-departmental leaders, dependent product owners from other domains, QE, and CS. This meeting may look different for you, the point is you are bringing together everyone whose input may alter what engineering will ultimately build.

Similar to the refinement reviews, design is responsible for leading the meeting, sharing designs and prototypes, and capturing any comments or feedback from the audience. The goal of this meeting is to ensure all stakeholders are aligned on the final designs so that product managers and engineering teams can develop project plans and deliver timelines. There is always a chance to get new feedback requiring additional rounds of refinement and product team reviews, but hopefully, the previous rounds of reviews and meetings will minimize or prevent this.

Design Quality Assurance (QA)

Not every product team does design QA, but a designer needs to review the work of the engineers before it’s pushed to production. This is especially important for teams without a mature design system as things can get lost in translation between Figma and what is coded. For a deeper dive on design QA, check out this article Design QA: A Very Scrappy, practical guide by Shannon Bain; it’s definitely worth a read if you’re new to this step in design.

Ultimately the goal for design QA is to compare what was coded with what you handed off in prior review cycles. If inconsistencies are found, it’s important to document the necessary changes in a way that can be assigned to engineering. For our team, this would be a Jira ticket created by myself, a product manager, or the engineer working on this project.

Research Share Out

Research can happen before or after any of the above reviews, it depends on the type of research you’ve completed. If research produced customer insights and can inform the strategic direction of a project, it should likely be shared before the kickoff. If usability studies were completed during exploration to confirm a design proposal, sharing those results can influence discussions during the refinement reviews.

Overall, the goal of sharing research with your product team during the project lifecycle is to bring the customer's voice to the discussion and build awareness of what works, what doesn’t, and why. In my experience, research insights from customers can influence discussions with various stakeholders and engineers that may need convincing of your solution and how it meets the needs of the customer.

Conclusion

By following this structured approach to design reviews, your product team can move forward with designs that are meticulously reviewed, feedback that is effectively incorporated, and a final product that meets both the customer’s needs and business goals. This plan ensures that all team members are aligned, design goals are met, and potential issues are addressed early in the process.

Happy reviewing!

Design reviews for product teams