Improving Design Reviews (Part 2)

This is the second part of my thoughts on how to improve design reviews. If you haven't read the first part, which is mostly about preparing before the actual design review, you can read that here.

(Again, I have in mind design reviews with stakeholder, and not so much internal design team reviews).

Now we're in the design review. We have a script for our prototype and we've done some preliminary planning, including reviewing the business goals, the user needs, and the stakeholders.

And we want to make this as productive a design review as possible. While we're open for any constructive criticism, we're most interested in getting feedback on questions about the design concept, the interactions, and overall design strategy for this business need. We'd prefer to avoid quibbling about photo selection, color choices, minute content editing, and such.

How do we manage the presentation and the discussion to do this?

Meeting Timing

Some of this isn't strictly just about design reviews but about meetings in general. (I'll write something more focused about meetings later.) But I'm including some suggestions here that have to do with design reviews.

Does anyone plan a design review like this? "I have 4 major screens to show in 1 hour. So I'll present for about 15 minutes per screen. And if there are a few minutes left at the end, we can have questions."

I don't think anyone explicitly plans to do this ... but I've seen many design reviews executed like this. As a presenter, let's run the meeting like a meeting we'd like to be a participant in.

Here's my recommendation:

• Spend the first 10 minutes at the beginning (or so -- depending on the complexity of the project) to review business goals and user needs.

• Reserve 10 minutes at the end of the meeting to review agreements, next steps, action items, etc.

• Divvy up the pages/screens/flows/sections and assume a 2:1 ratio for discussion to presentation. So, for example, present for 5 minutes and allow 10 minutes for discussion.

• Don't drone on for more than 5 minutes without a pause or asking questions.

What this means is that we will have 40 minutes for, say 2 sections. According the the 2:1 ratio, that's about 5 minutes for presentation and 10 minutes for discussion, with some padding in case something goes long.

If we are doing most of the talking in a design review, we're doing something wrong. As creative people, we like to explain what we did. We want people the appreciate the beauty and elegance of the solution. But, really, if the design requires a lot of explanation -- we did something wrong.

• Talk less about the different design elements and what each does -- anyone can see a checkbox allows users to select from some options.

• Talk more about how the design meets the business objectives.

Also, if we need more time, we won't squeeze the business goals or discussion time. We'll either limit the scope of the design review (and do the design review over several sessions) or we'll schedule a longer meeting.

Review the Goals

Before clicking into the prototype, we should review the business goals. What are the overall goals of the project? What phase are we in? What's the MVP for this release? If the project leader (e.g. product manager or project manager) is in the meeting, it might be best to allow that person to provide some brief context.

Then, when we get to the first screen of the prototype that we want to demonstrate, we should set up the design objective of this screen. This should align with the overall project goal. So for example if the goal of the project is to make a set of paper forms available online, the purpose of this one page might be to allow the user to make certain selections on a particular form and digitally sign it.

We want to be as specific as possible with the user experience goals to help guide our discussion. So let's refine the general goal to more specific ones. So we should have talked to the product manager and established specific targets for this goal, say, 50% of forms submitted online within 1 year and no more than 10% abandonment.

Let's do a good job of clarifying the different kinds of goals:

• Project Goal: Make paper forms available online

• Form Interaction Goal: Less than 10% abandonment on this one form

The better job we do of setting up these specific goals, the better our discussion will be.

Discuss the Design in Terms of the Goals

Now that we have established both the project/product goals as well as the goals for this specific page, feature, or interaction, we should present the design in those terms.

We want to discuss our thinking of the designs in terms of how they best meet these business needs. We might say, for example, "Since limiting abandonment is one of the major goals of this interaction, we designed ..."

And there is no need to discuss or even mention every single design element on the page. When a designer points out that there is a "submit" button and also a "cancel" button, what I hear is, "I have nothing interesting to say about the design."

If at all possible, we should provide information about why this particular design might be more effective than alternatives for meeting this business objective. If we considered other interaction patterns, we should mention them and then briefly explain why we made the choices we did.

Add in Our Expertise with User Behaviors and User Expectations

We want to establish the basis for some of the design decisions that we made. Some of those reasons could be:

• Analytics from other part of the experience or other properties

• User testing results

• Our design system and consistency

• Design best practices and user expectations

• Google (or Amazon, or pick your favorite) does it ...

I often find that some designers use those fourth and fifth bullets first -- and use them too often or use them exclusively. When a stakeholder asks, "Why did you use a checkbox pattern there," I think the weakest, not strongest, of these answers is to say, "It's design best practice" or "Amazon does it."

Why do I consider these the weakest answers?

• In many cases there is no such thing as a "best practice" -- there are "good practices"

• Who decides what a "best practice" is? There isn't a UX version of ISO 9000

• Many interactions depend on context -- so while a checkbox might be good in one context, a radio button might be better in a different context

• For everything we can find on Google, one of our stakeholders might find something else on Facebook

And perhaps the most important reason I think they are not good answers: Good answers for UX design decisions are USER CENTERED.

If you think about it, the bottom two are not user-centered -- they are EGO-centered. They say that I know the best practice because I'm me and I know.

That's not how we designers want to show up. That's not empathetic. And that's not user-centered.

Pause and Ask a Question

I find this happens much more often than I would expect. The presenter talks for 20 minutes straight before allowing anyone to say anything. That's way too much. I don't have a firm number ... but I aim for about 3-5 minutes. After talking for 5 minutes or less, we should pause and ask the audience a question. Let's keep this interactive and collaborative. It's not about us just declaring what's best.

And the question should NOT be: "So what do you think?" or "Any questions?"

If we ask for what they think, we will get what they think. So people will tell us what they think: about the colors, about the photos, or about the comma in the third paragraph.

If we ask, "any questions?" we will literally get ANY question, including: what's the project status, why aren't we launching first with Android?, or why haven't you validated that content with legal yet?

If we ask for it. They'll give it to us!

So instead of that, let's ask the kind of question that will get us into the kind of discussion we want to have. For example:

• Are there any insights from current analytics or current performance that we should take into account here?

• Are there parts of this design you would like us to probe on during user testing?

I offer these two because I think they emphasize how we would prefer to make decisions about designs. We should make decisions based on users and based on data -- not based on the HiPPO principle or who can quickly find the best examples on Amazon or Google.

Finally, if we think we might be working with a group of stakeholders who are not used to doing design reviews, we might prepare some good questions in advance (good, legitimate, smart, probing questions -- not obvious self-flattering ones) and ask someone on the team to ask them -- this might help provide a model to the other stakeholders on the types of questions or comments that are part of good design reviews.

Timebox Discussions

I do not feel that we should be having extended discussions about competing design concepts during design reviews. It's not that we shouldn't ever have such discussions -- just that I don't think we should have them during design reviews. We can have them, for example, in brainstorming sessions, where we are using the tools and processes that will make this more effective for everyone involved.

In my view, we should have a clear idea of what we are trying to accomplish in the design review, depending on where we are in the design phase. There might be different kinds of design reviews we have for different kinds of purposes. Here are the typical ones I see:

• Conceptual design reviews can be used to draw out many different options. This is a very early stage design. In fact, we should probably have a few alternatives. And we want to capture more ideas. Let's capture that input and go on. There's no need to assess each of the suggestions exhaustively or start the selection process. This is about expanding options.

• Iterative design reviews can be used to draw out questions about design to test against alternatives. This is more in the middle of the design phase, and we are no longer expanding but, rather, narrowing our options. Let's capture the potential strengths/weaknesses of the designs and also the questions to pose to users and go on. A design review is not the forum to argue points exhaustively and establish "best practices."

• Validation design reviews can be used as a preliminary step toward stakeholder sign off on the whole project. This is very late in the design phase. We want to line up the specific business goals, discuss user testing results, and show how we expect to meet business objectives.

Whenever the discussion gets more involved, the facilitator should step in and offer to provide a forum to continue the discussion at a later time -- whether online or offline.

Close on Time and Thank Everyone

So while the presenter was demonstrating the design and discussing it with the stakeholders, the facilitator should have been managing the meeting and taking notes, including follow ups and action items.

Let's make sure to thank everyone for their participation, and let's make sure we really do follow up on all of the items that we noted.

Anyway ... these are my thoughts ... thank you for reading. Are there any points that we should reconsider? I'd love to hear from you.