Thoughts on Improving Design Reviews (Part 1)

I was in a discussion with some design leaders the other day, and we talked a little bit about some of the challenges with design reviews. For example, sometimes stakeholders just complain about photos or colors rather than the interaction design; or sometimes the discussion is all about the late project status; or, sometimes we just have arguments about what looks better.

I don't pretend to have all of the answers ... but these are some thoughts and ideas from my years of running and participating in design reviews, and they could help with some of these common issues in design reviews.

This is Part 1, and it is mostly focused on preparing for the design review. Part 2, which I wrote separately, is about how we might present the design review.

(By the way -- I have in mind design reviews with stakeholders in mind ... and not so much the internal design team reviews).

Invest in the Design Review

The big point, that I will come back to over and over again in some of the individual ideas, is that we should plan and run the design review like we do our design project:

• Use empathy -- We should think about the participants. What do they want? What are their legitimate concerns?

• Define the Objectives -- Why are we doing a design review? What do we want to get out of it?

• Ideate -- Don't just assume there's there's one way to do a design review. How could we run the design review to please our stakeholders. How can we meet our objectives?

• Prototype -- We should try out a couple of different structures. Try different screen flows? Try different sequencing of designs.

• Test -- We should get feedback from people and iterate.

These are all just the phases of standard Design Thinking process -- all of us know this. And if you're thinking that this sounds like a lot of work -- you're right. It is. But a design review is expensive to begin with. Just the meeting itself is an hour of your time plus an hour for everyone in the meeting. Just count the number of people in that meeting and multiply by the blended rate of your team. Add to that all of the time you iterate on the design in response to the design review. (Not to mention any escalations, explanations, or other backroom politicking if things don't go well.) It's already a lot of time and it's already lot of money. Let's invest a couple of hours to do it better so those thousands of dollars of time are useful rather than perfunctory.

Before the Design Review

Stakeholders

Let's think about our stakeholders and what they want. What would delight them? What do they fear? What are their priorities? What words, phrases, or terms have we heard them use to describe this project?

We all know how to do empathy maps. Maybe it might be worth it to do a quick one for some of our key stakeholders. What would they say? What would they think? What might they do? How might they feel?

Make sure we know which pages or features each of the stakeholders is most interested in. We should think about how we might engage them during the design review. And if there are specific tough questions we can anticipate people will ask, we should decide how we are going to answer them in advance.

Finally, figure out who everyone is. What are their titles? Who reports to whom? While I hate the HiPPO principle, let's admit it -- it is operative to some extent in all companies. But that's not all. We can listen for their concerns better. If the person is an IT project manager, we can listen for concerns about impact to schedule. If the person is a director in a line of business, we can listen to hear if she is looking for a better way to describe the design improvements to her boss. If the person is a VP, perhaps she is listening for things beyond just the scope of this single project such as impact to budget or technical debt or the company brand.

Logistics

If at all possible, we should separate out the functions of the facilitator, the presenter, and the project leader. I see all too often the presenter also trying to facilitate the meeting and also trying to answer questions about the project status. These are separate and distinct functions, and confusing them sometimes creates half of the friction in the design review.

• The facilitator calls on people to speak, moves the meeting along, reminds people that we still have 5 more pages to look at, and calls out the next steps or follow up items. The presenter can't do this while also trying to respond to all of the questions of the stakeholders. The facilitator can close a discussion that is taking way too much time and going sideways in a way that the presenter can't.

• The presenter drives the prototype and provides the basic description of the designs. This is usually the designer who did the majority of the designing. This should be someone who understands the project goals and not just the hexcolors. The presenter needs to be aware of the other people on the call who can answer questions and defer to them. Far too often I see a presenter trying to field all questions about the project.

• The project leader is the person who has background of the project and enough standing among all of the stakeholders to have meta-discussions about the project status, the schedule, the project charter or purpose, business goals, etc. Ideally, this should be someone like the product manager or project manager. The designer should know some of this, but is usually not the authority on these topics, and should defer all such questions to the project leader.

The Framing Deck

Unless this is just a tiny project with a minimal number of stakeholders and only minor changes to existing pages ... I always want to frame the design review before getting into the designs.

• Business Goals -- This project has a business purpose. Let's show our stakeholders that we heard them. Let's assure them that we know why this project is important. This will also help to guide us in our responses during discussions. If there isn't a lot of nodding and agreement during this part, there could be a problem. If we are really misaligned, we might suspend the design review and nail this down first. Otherwise we might end up having a contentious discussion that has nothing at all to do with design choices but that everyone will blame on the bad design.

• User Needs -- Let's establish that we understand the user as well. Sometimes business leaders are focused on their business goals that they forget about the user needs. Often times the user needs are similar to our business goals. But it is important to remind everyone that the design must work for the end user or we might not meet the business goals. We are going to want nice memorable phrases for these user needs to help us in our responses to questions about the designs. Again, disagreements here could suggest that we're not really ready for the design review -- and maybe that we weren't really ready to begin design in the first place. This sounds awful, but it's better to catch it here than later.

• Project schedule -- Let's remind everyone where we are in the project, which phase we're in, what's coming next, how much time is left, etc. This will help us frame our responses to certain types of questions that might come up during the discussions, such as reminding people that we will do user testing next week, or that photo selection will not be finalized until next month, etc.

The Prototype

Let's get the pages ready for the design review and the page flow sequenced in advance.

• Show the pages/features that we want feedback on and show them early in the presentation. Obviously, if the project is an internal page, you have to start at a logical place and get there -- but get there quickly. Sign post early to tell stakeholders that we are not discussing the first 3 pages -- that's just a user path we are providing for context. We know people are going to jump in with comments, so we should show the pages we want to discuss as early as possible, because there will likely be less time for the pages at the end.

• Focus on the happy path (unless the unhappy path is the point of the project). We need to stay focused on the use cases, states, and flows that the stakeholders are most interested in. I have sometimes seen designers go into a bunch of the unhappy paths and edge cases in an effort to demonstrate the robustness of the thinking. I prefer to stay with the business priorities. A design review is not the place to admire the complexity of the solution or acknowledge the hours of labor. We can mention that other work by saying as an aside, "And there is much more detail we can show at a different time for those of you who would like to see them."

• Let's de-emphasize or don't show things we don't want feedback on. For example, if the content isn't finalized yet, and this is a point of contention with stakeholders, then we show Lorum Ipsum rather than draft content that we know is going to stir up emotions unnecessarily. Also, we should use FPO liberally for images. Don't get trapped into unnecessary discussions by showing photos, icons, or designs that appear to be more finalized than they are.

Aligning on Language

I was going to mention this in the stakeholder section, but I decided it merits its own section. It's that important. In some discussions I've been in 50% of the conflict and 99% of the emotion all boiled down to language.

• Be consistent. Don't call it a wireframe in one sentence, a low-fidelity comp. in another sentence, and then the Sketch file in another. Some of our stakeholders find the design process complicated and nebulous enough to begin with. Let's not make it harder. Let's all use the same words or phrases all of the time.

• Use the company lingo. For a health insurance company I worked for the "customer" is not a person but a company. The "customer" is, say, Disney. The "patient" is the human being who works for Disney who is getting care and using the website. If the designer doing the presentation comes from a retail background, she needs to be very aware that the "user" should not be referred to as the "customer." That's just one quick example. There are probably dozens in any organization.

• Understand people's peeves. All of us have them. Listen carefully to your stakeholders. Use their language.

These seem like trivial things, but sometimes people take careless use of language as a sign that we are not listening to them, that we don't understand the business, and that we are out of touch.

Our brand as designers is that we are empathetic, that we understand user expectations, and that we can design to delight people. But if we can't even use language consistently and in the way that our stakeholders do, how are we demonstrating our brand? Do we have any credibility saying that we can empathize with millions of people on the internet when we can't even empathize with our coworkers? How can we say that we understand user expectations of faceless people around the world when we can't even understand the expectations of people we are talking to?

We need to be our brand during these design reviews. That's how we will be credible, trustworthy, and persuasive to our stakeholders.

* * * *

... Stay tuned!

Part 2 is about the Design Review itself ... what we do, what we say, and how we respond to questions ...