Skip to content Skip to sidebar Skip to footer

Effective and Efficient: Conducting UX and Design Reviews

We have all been there—the umpteenth design review on a feedback loop that just will not end. The team is exhausted and creativity has been squeezed like water out of a dishrag. The stakeholders keep giving new feedback, often derailing previous feedback. The team wonders if it will ever be done. There is no clear path forward and the team has lost sight of the original goals, instead spending time on copy for one link or a particular shade of blue.

Endless rounds of feedback and wayward comments are crippling to team morale. Without a clear path forward, repeated reviews can ultimately make attempts at innovative UX suffer and leave stakeholders questioning the approach.

There is hope; this does not have to happen. With the three-step process of reviews introduced in this article, creativity can be restored and your team can help clients and stakeholders achieve their goals. This process will ultimately lead to better UX and designs because it starts with defining a clear UX strategy and limits the design project to three rounds of review.

Why does this happen?

There are common themes that seem to surface on fatigued, review-challenged projects:

  • Ambiguity in project definition resulting in a lack of continuity in the direction of the design and ultimately, the design reviews.
  • Focus on all the wrong things at the wrong times in the review cycles, resulting in wayward designs that appear as a jumble of elements instead of design elegance that meets a strategic vision.
  • Lack of clear review expectations and boundaries, resulting in late nights to meet a deadline and nagging errors in the final delivery.

All this results in burnout, sadly with a loss of the passion that brought the team together in the first place. And while the team can boost its egos with the next project, the downstream development teams and users suffer.

What can be done?

With clear definition at the beginning of a project, specific goals for each phase of the review cycle, and communication and expectation setting throughout, you and your team can design and run UX deliverables to the project finish line with satisfied stakeholders.

Definition of Users and Business Goals as a Foundation

UX deliverables are the blueprints for a site or app, but what about blueprints for the UX? Great UX starts with a full understanding of the users and strategic direction for the project. I show this as a clear articulation of the user and business goals, any marketing plans, available content or content strategy, design considerations, and technical requirements.

However, it is rare for teams to ask about these design criteria or bring them together at the beginning of the project. For agencies, there is a creative brief that serves as a foundation for messaging and art direction, but rarely does it touch upon what users need from the design. For in-house projects, there are user stories and functional requirements, but these separate parts are rarely seen as needing to support a higher business or user purpose.

However you arrive here—through user research, full discovery, strategy presentations, or an audit/heuristic review—the definition document must have two key pieces to serve its purpose:

  1. User personas and scenarios. Who are you designing for and what tasks do they need to achieve? How do you define success for them and what information and/or functionality do they need to achieve it? What pain points do they currently have?
  2. Business goals. What revenue or cost savings goals must this design facilitate and how will it be measured? What does the company get out of this design?

During discovery, capture all these elements to define the foundation of the project. I’m an advocate for user-centered design with clear ROI, so I believe that if these points are well defined, the team is 90% of the way toward seeing what their design must achieve. However, there are many pieces of an app or website that need to work together. I don’t believe the following elements take priority over the previous user and business goals, but capturing them during definition will ensure their consideration and often result in more efficient reviews with relevant stakeholders.

  • Marketing or access considerations
  • Technical considerations and functional requirements
  • Content strategy
  • Visual design and brand guidelines
  • Legal mandatories

It helps to review this document with the project team and stakeholders at the beginning. Communicate that it is the foundational document upon which the design will be completed and that you will be using it at every review to ensure the alignment of the design meetings, the user needs, and the business goals. It is unlikely a client or stakeholder will disagree with that intention.

Only Three Rounds of Review

Good things come in threes, including efficient review cycles. This method focuses on making sure the design direction meets the project goals in the first round. Then, a second review ensures all screens are accounted for to set scope. Finally, a third review refines for detailed interactions and technical feasibility. This process is like an inverted triangle; there are a lot of ideas and concepts at the beginning of the design process. Each design review serves to move the project from many ideas to one quality UX by refining along the way.

The secret to this method is focus. Each review cycle serves a purpose; if the team clearly communicates the purpose and goal of each review, the reviewers will have the guidance they need and the process will go much smoother. (This process also works for agile on a smaller scale instead of full site reviews; it can be used for specific sections of a site or app as they relate to user stories. For each sprint, a team member can state the intention of the design and review-round in the related task and present on such.)

Three key goals for each round of review listed here. First Review to make sure design direction meets the business and user goals. Second, Review or scope and make sure all screens are represented. Third, Review for all details and integrations.
Figure 1. Goals for each of the three rounds of review.

First round: review for direction

In the first round, the stakeholders need to know two things: did the designers “get it” and is the design going in the right direction?

This is not a time to review specific details. It is a time for presenting and reviewing several different ideas, discussing in broad strokes the validity of each one, and getting agreement on which idea moves the project in the right direction. It is a time for deliverables that illustrate the user experience conceptually and reflect the specific business and user goals. The first review should include designs for the main screens of the major user flows. The team needs agreement from the stakeholders on one direction to follow. After the review of concepts, the team can move forward to further design refinement and flushing out all the screens.

In the first round, the deliverables and the level of fidelity needed are as follows:

  • User flows – For each persona, identify primary user scenarios and show the user flow for each.
  • Information Architecture (IA)/Site Map – Major categories and labels, subcategories, and detailed screens should be represented
  • Wireframes – Include the major navigation model, page headlines and sections described, and major fields and buttons shown. Lorem Ipsum is okay for copy, but for headlines you need to indicate the page or screen title and content sections.

Second round: review for scope and scale

The goal of the second review is to ensure that all screens are accounted for in an IA and wireframes. The direction agreed upon in the first review should carry throughout the designs. The team should be able to communicate the purpose of each screen and how screens link together for the user.

  • User flows – For each persona, primary, and secondary user scenarios shown.
  • IA/Site Map – All screens should be accounted for and labeled in the IA and sitemap. The navigation model is represented on all pages.
  • Wireframes – All major and minor screens should be accounted for in the wireframes and numbered per the IA. The global, secondary, and tertiary navigation is accounted for and thought through. The copy decks or functional requirements should be able to be started from these designs.

This review will take longer for the stakeholders. The goal of this review meeting should only be to introduce and go over deliverables, answer any questions, and gather some initial feedback. Technical teams can start to estimate and plan for architectural requirements, content strategists can plan their copy delivery, business analysts can write the functional requirements and user stories, and project managers can start to plan iterations and sprints from this review.

Third round: finalize the details

The third round is the final stretch, when all the deliverables come together to show a robust app or website, the time where broad strokes have morphed into clear details. At this point, a team member should be able to look at the flows, IA, and wireframes and have two clear ideas: how the app or site will function for different users, and how the users will be successful in accomplishing their tasks. This deliverable may take the form of a clickable prototype instead of flat wireframes. In this deliverable, the annotations are clear on the different interaction states:

  • User Flows – All scenarios for each persona are accurate. In the flows the screens are represented and those screens are present in the IA and wireframes.
  • IA/Sitemap – All screens are present, linking, and navigation is clear and understandable. One can look at it and understand what page goes where in the structure, any linking and site relationships, and where each screen maps to in the wireframe.
  • Wireframes – The details are all filled in. There is no Lorem Ipsum on major screens; copy may be grabbed from the copy decks at this point to fill in the blanks.

Clear Communication and Expectations at Every Review Meeting

You may be at the point in this article where you are asking, “This all sounds great, but I work with some interesting people. How do I get them to go along with this?”

I have learned that the UX or design leader sets the expectations for each review. If no one does this, the stakeholders do not have the necessary guidance they need to provide feedback. At the design review meetings, try these tactics to set the tone and prevent wayward comments:

  • Review business goals and user needs and scenarios from the brief as an overarching theme of what the design is supposed to achieve.
  • State what type of feedback you require. For example, in the first round tell the audience that you will present several design concepts and directions and at the end of the review you’d like agreement on one.
  • Establishing when and how you’d like feedback creates boundaries and expectations among your stakeholders. For the first round of review, I recommend taking the time to go through all the designs, recommending one as a way of showing thoughtful analysis and a point of view, and then asking for feedback and questions. In rounds two or three where details are important, break at each natural stopping point like a category, flow, or screen, and ask for feedback.
  • Ask stakeholders what they like about each design and what could be improved upon.
  • At the end of each meeting, review the comments and feedback and agree on next steps. Your project manager should ask if anyone else needs to review and set the date to consolidate feedback.
  • Get consolidated feedback from the project manager to act on. Do not act on ad-hoc review comments outside of review cycles.
  • At each meeting, keep the introduction short, especially if this is a remote meeting (where no doubt there’s more multitasking than listening.) Move quickly to introducing the deliverables. Your task is to give two sentences that introduce each deliverable, its purpose, and how it meets the business and user goals. Trust that once you ground the team in the basics of how the design meets business and user goals, the team will meet you halfway and give feedback accordingly.
  • Listen and be quiet. Often reviews are the only time the stakeholders are together discussing the project. They may be using this review to hash out their own answers to the same questions your designs are trying to solve. Be patient and ask for feedback or if they need more time to discuss to keep the review moving forward.

Overall, it is my hope that this advice saves the sanity of design and stakeholder team members. I practice this review process continually and have found it to work. In my experience, guiding teams with a clear vision, and leading design and reviews from big ideas to detailed design, will result in passion returning and user success.