Design reviews take place throughout the UX design process. When design work begins, so do the reviews. Likewise, reviews should continue as long as design work continues on the project. 

Depending on the timeline structure of the project (e.g., waterfall, agile, hybrid), design work, including reviews, should be completed ahead of or overlapping with implementation.

At the beginning of the project, communicate to the full project team and leadership in which phases design reviews will take place.

There are two main types of design reviews, each with a different purpose and attendees. Projects need to include both review types. The reviews take place sequentially and build on one another.

First is the design team review. These reviews include the designers working on the project, the UX lead, the technical lead, and a front-end development representative. 

The goal of the design team review is to make sure that UX and technical team members have the opportunity to work through questions, discuss complications and build alignment before the work is presented to the larger stakeholder group.

Second is the larger review with the design stakeholders which includes everyone from the design team review plus additional stakeholders and subject matter experts (SMEs). 

The design stakeholder review provides an opportunity for other key roles to ask questions, impart insights from their expertise, and supply feedback. This enables designers to refine designs quickly with more information and ultimately get approval so the designs can be packaged for development. 

The design stakeholder review quorum includes:

• Relevant SMEs (e.g., marketing, content owners, business process owners, etc.)
• Project or digital property leadership (final decision-makers)
• Project technical lead
• Representatives from the project’s development team, especially front-end developers
• Project designers
• Project design lead

Decisions require a majority of the quorum to agree, with project leadership having over-arching decision-making power.

Optionally, other key stakeholders can be included in these larger group reviews as needed to provide additional insight. These include:

• A DesignOps design system representative
• Others with relevant business or technical expertise
• Design representatives from other related digital properties at the organization

Optional stakeholders are not part of the decision-making quorum and should only be asked to attend the larger group reviews where gathering their input makes sense.

There are many deliverables throughout the design process that require feedback. These include but are not limited to:

• Information architecture (IA) diagrams (e.g., site maps, etc.)
• Interaction models
• Mood boards or style tiles
• Navigation designs
• Task or workflow diagrams
• Wireframes
• Concept/direction setting mockups
• High fidelity mockups
• Prototypes

It is important to present design deliverables for review in the order of the design process as activities build on one another. It is also key to break up deliverables into consumable portions that provide enough context but can still be realistically reviewed within the meeting time. 

Each presented deliverable should be given two rounds of review per review group (two rounds of review with the design team and two rounds of review with the design stakeholders). The first round is to gather the bulk of the feedback on the work presented so that refined versions can be presented in the second round, ideally receiving approval at that time or minimal additional feedback.

As mentioned, design team reviews take place prior to design stakeholder reviews. The cadence of each is based on the size of the project, the number of review participants, the project timeline, the workload of the designers, and the amount of design intended to be covered per session. 

A good rule is to schedule reviews with the design stakeholders once or twice a week, with sessions lasting one to two hours. Within that cadence, design team reviews can also take place once or twice a week, depending on what needs to be worked through prior to the design stakeholder review. It could be that your design stakeholders can only meet once a week, or every 2 weeks, and the design team can build up a backlog of items for review. If the availability of your design stakeholder decision-makers is slowing down the design work, work with them to define strategies to keep the work moving.

All review participants are expected to ask questions and provide feedback and approvals of UX deliverables in a timely manner to keep the work on track.

Depending on their role, participants have other responsibilities in reviews as well. Please see the associated presentation for more details.

Review participants are expected to follow proper feedback etiquette and can use the feedback framework detailed in the associated presentation.

These norms need to be set by the UX lead at the beginning of the design review process. Review the presentation with review participants at the beginning of the first design reviews of a project and again as needed depending on the length of the design process for that project and any design review participation issues along the way. 

It is the responsibility of the UX lead and project leadership to set these expectations, exemplify these norms, and create a safe environment conducive to strong, open collaboration. It is also their responsibility to address any participants who are not abiding by review norms, meeting responsibilities, or following etiquette.

Download the Limina design review presentation to get started.

In the design reviews: 

1. The UX lead (or the role performing UX lead duties) kicks off by outlining the focus and goals for that review session. Be clear and specific to ensure participants are working from the same set of assumptions. If possible, outline three to four questions the participants should aim to answer in the review (e.g., which local navigation pattern best meets our product goals, whether we should follow Apple and Google’s button order pattern or Microsofts, etc.)
2. Designers present a portion of the design for the project, articulating important considerations (e.g., meets a requirement, addresses a pain point from user research, follows UI best practices, follows the design system guidance, etc.).
3. Review participants ask questions and provide feedback (using the feedback framework), especially from the unique perspective their role provides them on the project. The feedback can be given incrementally as the review takes place or within a specified time section of the meeting.
4. For larger reviews that involve stakeholders and decision makers (e.g., design stakeholder reviews) participants are given a few business days (e.g. 1-3 days) following the review to provide additional questions or feedback asynchronously. This is ideally done through commenting within the design tool.