Log In
Back to Methods page

Table of Contents

Resources

No resources available for this entry.

Additional tags

No tags are assigned to this entry.

Design review and critique

Matt Carrano avatar

Author: Matt Carrano | Last edit: March 18, 2025

What are design reviews?

Design review and critique is an essential part of a mature, highly performing, design culture. Design reviews are structured discussions that give designers an opportunity to receive feedback about their work from their peers. While reviews can be used as a means of sign-off and approval of work, they are also employed during the design process to enable iteration and refinement of work. They operate on the premise that even experienced designers can have blind spots, and that feedback from peers is the best way to integrate multiple perspectives to ensure the best outcome.

Why perform a design review?

Designs are not ready to hand off until they have had at least one review. Engaging in a process of regular design reviews will have multiple benefits. 

  • First and foremost, design reviews raise the quality of resulting designs by identifying problems or defects in those designs and driving the need for iteration. 
  • They also provide a vehicle for information sharing among team members so that they are better informed about work being performed by others on the team and have an opportunity to exchange ideas. This should ultimately lead to more consistency and reuse of established conventions among designers. 
     
  • Lastly, reviews provide an opportunity for learning. Designers can only improve their craft by subjecting their work to periodic feedback from their peers. 


In short, instituting a process of regular review and critique will sharpen designer skills and elevate the quality and consistency of design output.

What to look for when doing a review

We want to apply a consistent standard of quality to our design work across teams to ensure consistency and excellence.  Designers should demonstrate that they have thoroughly understood the user problem at hand and based their designs on data collected through either direct user research or by leveraging existing insights available in our teamwide knowledge base. A problem statement summarizing this understanding should either appear directly within the artifact under review or should be referenced if this information is documented elsewhere (in a Jira ticket, for example) Designers should also provide evidence that they have explored multiple approaches before settling on the recommended design solution. 

In addition, it is helpful for reviewers to keep in mind a set of common heuristics when considering a design. The following is adapted from Nielsen’s 10 Usability Heuristics and are intended to guide reviewers in what to look for and how to think about reviewing a design:

1. Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. For enterprise applications, examples include the use of clear status indication to reflect the progress of tasks running in the background and appropriate use of notifications. Graphical visualizations (charts and graphs) should be readable and clearly convey information to users without extraneous decoration.

2. Match between system and the real world

The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. We should make sure that on-screen language is consistent with Red Hat conventions and usage standards as well as providing clear instruction to users.

3. User control and freedom

The design should provide users with clear affordances for executing required actions and appropriate options to accommodate both novice and experienced users.

4. Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing as they move between Red Hat products. Designs should be reviewed for conformance with PatternFly guidelines and UXD design conventions. We should minimize the use of custom components, where possible.

5. Error prevention

Careful design should prevent a problem from occurring in the first place. We should use disabled states and confirmation options where appropriate to prevent users from performing destructive actions.

6. Recognition rather than recall

Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the interface to another. It is especially important that the system provides a consistent and clear navigation model to allow users to confidently move around in an application.

7. Flexibility and efficiency of use

In enterprise applications it is important to include features to help speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. These features should be made easily discoverable and allow users to automate or customize frequent actions.

8. Aesthetic design and brand

The user interface should be aesthetically pleasing, use appropriate color palettes, and represent the Red Hat brand in a positive light. Screen layouts should facilitate interaction and honor the Gestalt principles of visual design.

9. Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language, precisely indicate the problem, and constructively suggest a solution.

10. Help and documentation

Help and learning content should be easy to access, search, focus on the user's task, list concrete steps to be carried out.

11. Accessibility

The product needs to be usable by everyone, including those with a variety of visual impairments. Consider issues of color and contrast, content readability, and how easy the design will be to use by people with low vision. Also consider the sequencing of controls and how a user might tab through the content on the page using a keyboard and/or a screen reader. See PatternFly's accessibility guidelines for guidance.

How to perform a design review

Design reviews can be performed as either synchronous or asynchronous activities. Asynchronous reviews will allow for getting quick and timely feedback on design work. They can be initiated at any time and will allow for critique to be provided remotely using any tool that supports robust commenting and threaded discussion. Synchronous reviews are regularly scheduled and facilitated. They provide the opportunity for real-time discussion. In either case, presenters will be responsible for explaining the problem they are trying to solve and questions they might have at the start of a review. The following provides an outline of the parameters for each type of review.

Asynchronous reviews

For an asynchronous review, it is important to provide reviewers with sufficient context up-front so they have enough information to perform a meaningful review. As a designer who is requesting review of your work, you should start by offering the following information:

  • A description of the user problem you are trying to solve.
  • A description of what will be subject to review and at what stage in the process is the design with a link to the design artifacts subject to review.
  • A video walk-through or demonstration of your design (optional). A video walk-through is recommended for designs that entail significant complexity or whenever more explanation is needed to orient reviewers.
  • A list of concerns or questions that you wish to be addressed by reviewers.

Identify appropriate reviewers and reach out to them on Slack or Jira requesting feedback and setting a date by which feedback is needed or expected. Reviewers can provide feedback by leaving comments. We recommend that comments are left directly on the design file where possible (e.g. in a Figma file).  The presenter should always close the loop by indicating what, if any, changes will be made as a result of a specific comment.

Synchronous reviews

Synchronous reviews take place during a live meeting that can be either in-person or remote. A minimum of 30 minutes should be allowed for reviewing a single design in order to give the presenter sufficient time to present their work and to allow for adequate comment and discussion. A link to design artifacts should be sent out to members of the cohort one day before the review to give reviewers a chance to familiarize themselves with the design prior to the meeting. Consider including a description of the problem you are trying to solve along with any questions you have or areas you would like reviewers to focus on for context. 
 

Optimally, review meetings should include no more than 4-6 invitees. This will allow for diversity of feedback while giving everyone ample space to contribute. There should always be one presenter, a facilitator, and 3-4 reviewers. The facilitator can be a team member that is designated for each meeting on a rotating basis. Once the participants have gathered, meetings should follow this format:
 

  1. At the start of each review session, the presenter should provide an overview of their design. This overview will include:
    • A description of the user problem you are trying to solve.
    • A list of concerns or questions that you wish to be addressed by reviewers.
       
  2. The facilitator will ask for comments from the reviewers making sure that all reviewers receive an equal opportunity to comment on the design. The facilitator should focus on keeping the discussion moving in a positive direction and taking notes. They may or may not also act as a reviewer, but if they do provide feedback, it should only be after allowing others a chance to provide their input.
     
  3. All comments will be recorded for future follow-up. The goal of the meeting should not be to ideate and agree on design changes on the spot. Suggestions may be recorded as part of the notes, but it will be up to the presenter to decide what feedback to accept and how to follow-up on problems that were raised.
     
  4. Once the facilitator is satisfied that all reviewers have had an opportunity to provide feedback and that the presenters initial questions have been answered, the review is done.

Guidance for presenters

As a presenter, you are offering up your design for critique and feedback. It is important that you clearly explain the problem you are trying to solve and provide enough information so that reviewers can provide reasonable feedback. During the review, you should answer questions to clarify you design intent, as necessary. Presenters should:

  • Reiterate goals of the design and the user problem that you are trying to solve. 
  • Let everyone know what you are looking for feedback about (and what you are not).
  • Tell a story. Walk through your design from a user’s perspective. How do you expect people to interact with your design?
  • Don’t feel like you need to defend or over explain every design decision that was made. Be concise and to the point.

Guidance for reviewers

The reviewer's responsibility is to provide the presenter with meaningful feedback that will help improve the design under review. As a reviewer, you should familiarize yourselve with the design and the user problem it solves ahead of time and come prepared with questions. While giving honest feedback, you should also keep the exchange friendly and constructive such that the presenter does not feel personally judged or attacked. Reviewers should apply the UXD standards of quality (see above) when reviewing a design. This will both help to ensure completeness and make sure that everyone is working with the same definition of what a quality design is.

Here are some general guidelines for reviewers (Adapted from GV Guide to Design Critiques):

  • Be candid and honest about your opinions and doubts while being respectful. 
  • Be as detailed as possible about what’s working and what’s not. If you say a whole design is not working, it’s not helpful. Be prepared to back it up with a lot of specifics.
  • Tie everything to goals. Good feedback is about how the design is meeting (or missing) the customer and business goals. Stay analytical. If you have an emotional reaction (this sucks!) dig for why you’re feeling that way.
  • Along with identifying faults, also call out what’s working well. This will both bolster the presenter’s confidence and preserve great ideas.
  • Don't argue about solutions. Start by taking a step back and first discussing problems with the current design. The review session is not intended to be design by committee. Any new ideas should be given as suggestions, not mandates. Trust the designer to explore a new design direction and make their own call.

Guidance for facilitators

The facilitator plays an important role in ensuring that the design review meeting is productive. Facilitation is the conscious, balanced management of conversations towards a conclusion. [Connor, A., & Irizarry, A. 2015. Discussing Design. O’Reilly Media.] We recommend that the facilitator role be rotated between members of the team. Duties and responsibilities of the facilitator are:

  • Make everyone aware of the scope and goals for this review.
  • Record notes publicly and collaboratively.
  • Ensure everyone has an opportunity to speak while bringing endless discussions to a conclusion. As the facilitator, you should feel empowered to cut off discussion when you perceive that the conversation is going off track.
  • Encourage input from everyone. Using a “round robin” approach to ask everyone for their comments is one option.
  • Support the presenter to ensure they don’t feel attacked or need to be defensive. Keep the discussion constructive.

Additional resources

The following are helpful articles about the benefits of performing regular design reviews along with guidance on best practices.

methods process

Get in Touch!

Spotted a typo? Any feedback you want to share? Do you want to collaborate? Get in touch with the UXD Methods working group using one of the links below!

Drop us a message on the #uxd-hub Slack channel

Submit Feedback