How To Run A UI Design Critique

Principles For Running A Great UI Critique

From my own experience, I’ve found that design critiques for user interfaces (UIs) need to be performed throughout the entire product design and development process, at least weekly, and possibly even daily at certain times. They keep the product design on track, and they become even more critical in an interactive agile or lean UX product environment, where designs go through multiple iterations before deployment. Running a UI design critique is a challenge, requiring you not only to explain decisions, but also to listen carefully to other ideas.

Establishing clear principles — not “rules” — at the beginning of every critique is imperative. Unlike rules, which are dogmatic and feel restrictive, principles help everyone understand the expectations but still allow for the freeform discussion that is needed.

Chief among these expectations is for everybody to agree on why you are actually critiquing what you are looking at. Jason Ulaszek recommends:

Start by asking about the purpose or intention behind the design you’re critiquing. Why are we asking for this piece of information? What expectations have been set that allow us to ask for it? What will we do with it? If we can answer those questions, then we move on to discussing various options of interpreting the need for the element and respective advantages and disadvantages with each option.

To help you keep to this guideline, I recommend following the standard principles you might apply to any design critique, whether it involves UI design or not:

• Show respect.. It might sound cliched, but if everyone in the critique is not respectful of the opinions and skills of the others at the table, then the critique will quickly degrade into hostility.
• Designate roles.. Before starting, clarify who will be taking on which role(s) during the critique. It’s best to mix these up from critique to critique so that no one feels left out, and it’s optimal if the three lead roles are different people (but that is not always practical).
  • Presenter. This is the person responsible for presenting the design and the thinking behind it. This person answers all questions or directs them to other people in the critique who can answer them.
  • Moderator. If possible, it is best if this role is performed by someone not directly responsible for the design, often the project or product manager. The moderator ensures that everyone stays on topic and that everyone is heard.
  • Note-taker. This person focuses on recording what is discussed and is especially vital for making sure that the takeaways (another principle, listed below) are clearly defined at the end of the critique. The note-taker should not be left out of the discussion, although their role might lean towards getting other members of the team to clarify what they have said.
• State the goals for the project and for the critique up front.. Quickly remind everyone of the goals of the project and what this specific critique will cover. Keep the critique focused on the task at hand, rather than allowing the scope to creep to other considerations that would derail the primary purpose of the discussion.
• Review the audience(s).. To reinforce that the people in the critique are not the target audience for the product, remind everyone about who is.
• Avoid coming up with “the answers.” Participants will feel a strong desire to solve problems and come up with the “answer” in a critique. However, the best solutions rarely arise in the actual meeting. The point of a critique is to probe for issues and discuss multiple potential solutions for the designer to take away and consider.
• Agree on takeaways.. After everything has been said in the critique, the note-taker needs to review the takeaway tasks for everyone who participated to ensure that everyone is on the same page for the next critique.

Unfortunately, all too often, UI design critiques focus heavily on the visual and not enough on the interactive, much less temporal, nature of the design. For a UI design critique, add the following elements:

• Identify the presentation media.. Along with identifying the audience, review the platform and technologies being used to create the product. Is this an iPhone app? A website? Are you using AngularJS? C#? Make sure these are all considered so that you avoid proposing solutions that wouldn’t work.
• Outline the process flow.. You need to know the road map. For UI design, that would be the process flow for the user’s experience. This might come in the form of storyboards, journey maps or other ways of describing the process, but everyone should be familiar with it before considering the UI.
• Demo the product, but show more than tell.. I cannot stress this one enough: A great user experience has a lot more showing than telling. The end user will need to know exactly how the product works with minimal explanation. Your demo should also require as little explanation as possible. As the saying goes, a good UI is like a joke: If you have to explain it, it’s not very good.

Asking The Right Questions

Plenty of questions and statements work against strong cooperation in a design critique. Here are a few questions that I have found open dialogue for exploring designs in a collaborative, rather than combative, way, which you can suggest to your team.

“How Did You Come Up With That Solution?”

A great place to start any critique or conversation is to ask the designer how — not why — they did something. Asking why immediately puts them on the defensive, while asking how invites exploration of the concept’s origin without the need for justification.

“Why” questions push us towards trying to prove something is “true,” rather than explaining it as one possibility. According to Aaron Morton:

“Why” elicits a story, explanations of why something is true. If you ask why nothing is working out the way you want it to, you are likely to create a story, which may or may not be true. This is dangerous territory in making you feel bad.

Instead of asking “why,” consider asking “how” questions to elicit a story about the process of creation, rather than a defence of its existence. From there, you can then ask what possibilities the designer considered before, and only then explore alternatives they may not have considered. But listen carefully to what the designer has already tried before offering suggestions. They may have overlooked something, but don’t go into the conversation assuming so.

“Where Did You Get the Idea To Do It That Way?”

Thomas Edison famously said, “Genius is one percent inspiration and ninety-nine percent perspiration.” But he largely stole his one percent from Nikola Tesla. Then again, Picasso said, “Good artists borrow, great artists steal” (but he probably stole that line).

A central idea of Pixar Animation president Ed Catmull’s book Creativity, Inc is that having a great team is more important than having a great idea:

Getting the right people and the right chemistry is more important than getting the right idea.

We rarely conceive ideas in a vacuum, and thinking about where we got our inspiration from can push our own innovation. Even better, bringing our inspirations together in a team setting can spawn new ideas.

A word of caution: Be careful not to sound accusatory or condescending — i.e. implying they stole the idea. Though, you do want the designer to push their own understanding of the motivations for their ideas and where they came from, without squishing the innovation.

“When Does That Need to Happen?”

Just like in comedy, timing is everything in temporal design, and events need to happen at the right time and in the right order. When we are designing, though, that order is not always obvious until we have to sit down and explain it.

A great UI is like a great story, and that means you have to carefully pace it. How much information is just enough to get started with a form? Are you displaying data in the right context for the user to understand? Is this the right moment to reveal the conclusion?

Jason Kunesh, CEO of Public Good, a startup that helps nonprofits connect with people through the news, tells me:

For our customers, a great interaction at the right moment is the difference between a happy fan of the product or service and a lost opportunity to connect. Turning a casual interaction into a lasting relationship depends on a series of tiny, positive interactions and messages arriving when people are ready for them.

Part of the critique process should be to iron out the wrinkles in the timing of the interface by asking at every opportunity whether this is the right moment to perform an action, ask a question or present data.

“Can We Use Motion to Add Visual Cues?”

This question will surprise a lot of designers who are used to the static nature that has dominated UI design for years. However, movement, animation and transitions are becoming the norm in experience design. Motion will soon be as important to consider in a design as color.

According to UI animation expert Rachel Neighbors:

With the rise of flat design and the UX stumbles that have come with it, we’ve seen just how dangerous it can be to strip visual cues from a site’s components. Animation can be used to the opposite effect.

Movement or change could be as simple as a change in opacity or color, or a monkey’s arm stretching across the page, or a sun rising as the user completes a task. Asking about adding moment-to-moment movement in a UI design will often push the designer to change their perspective in good ways. Push the designer to think beyond the discrete moment and to discuss the design in time, not just in space.

“How Could We Make It Simpler?”

Simplicity is hard. It seems like adding is always easier than taking away, and many UIs suffer from what I like to call the “snowflake in a blizzard” syndrome: Sure, every snowflake is unique, but you’ll never notice that in a blizzard. In UI design, we all too often see interfaces chockablock full of links, buttons, controls and images. Clients will often think they need to include everything the audience might ever need, to the point that you can’t find anything you actually need.

I put the simplicity question to Steve Krug, author of Don’t Make Me Think:

I think it’s a very useful question. I would have thought it’s a lesson everyone’s absorbed by now, but I know they haven’t. I always like to say that anything on the page or screen that’s not part of the solution — for the user’s real goals — is noise and a candidate for being thrown overboard.

At every step in a design, we need to ask ourselves, How can we create something that requires less thought yet keeps the same power? In a critique, this is best expressed by asking how to make something simpler. It’s important to maintain clarity in the design, but to do so with fewer clicks, less text and not as many form fields. Get down to the bare minimum needed to get the job done, and your users will thank you.

“What Happens Next?”

A great design critique shares a lot in common with a great interview: They are both about exploration. One of the greatest interviewers, Studs Terkel, said:

[Interviewing] isn’t an inquisition; it’s an exploration, usually an exploration into the past. So I think the gentlest question is the best one, and the gentlest is, “And what happened then?”

Applying this to a UI design, we always need to ask the designer to think about what happens next. This question invites them to think beyond what they considered to be the end. Users must always have somewhere to go next.

One of the greatest challenges to envisioning any UI is to consider all of the possible paths, not just the “happy path” we want the user to take. What happens after they click a button? What happens if there is an error? What happens after they submit a form? Ask what happens next until you’ve considered every possible scenario, otherwise you run the risk of leaving the user hanging, which is always a bad experience.

Don’t Just Ask Questions to Answer Them

When asking these questions — or any others for that matter — don’t ask simply so that you can answer yourself. It is annoying when someone asks you a question not to hear your answer or to understand your thinking but simply to hear their own voice.

If you are one of those people, cut it out immediately. Ask all of your questions with your mind wide open to the answers given. Then, craft your responses based on those answers, not the answers you wanted to hear.

What A Good UI Critique Looks Like

Critiques will vary greatly depending on the skills, goals and responsibilities of the participants. However, a good critique always focuses on specific aspects of the product and thoroughly explores the presented solution.

A UI critique focuses not just on what the product looks like at the moment, but on how it works over time and whether this best suits the user’s needs. Rather than considering the user’s needs, participants will often wonder why something wasn’t done the way they expected. Jason Ulaszek of UX for Good agrees, telling me about his own critiques:

Staying objective in our discussion and considering the mental model of the individual tasked with using the design [i.e. the user] is critical in how we discuss the solution.

Always keep in mind that — like cell-based animation, where a second’s worth of the final film could take weeks or months to produce — while we might spend hours agonizing over a minute detail in the interface, it will probably be just a blip on the user’s radar.

Steve Krug had this to say when I asked him about this:

We’re thinking, “great literature” (or at least “product brochure”), while the user’s reality is much closer to “billboard going by at 60 miles an hour.” It’s incredibly hard for UI designers to realize just how quickly people are zooming through — or past — the interface they’ve worked so hard to develop, and how little of it they actually take in.

A good UI critique slows down to consider every element, but recognizes that this is not how the user will be seeing the design. If the participants in your critique do not have formal training to speak directly to color, typography or experience design, they can still consider these important factors in all UI designs:

• Consistency. Are the design and its implementation consistent throughout the product? This includes color, typography, controls, imagery and any design element (static or interactive) that is used more than once in the interface.
• Context. Have you consistently respected the context of the user as they are using the product? Constantly asking this question is key because you are likely not in that context, but merely simulating it, while designing or testing.
• Voice. Do the brand and design have a clear, consistent and recognizable voice?
• Transitions. Are you using transitions from state to state for any significant changes in the UI? Modern designs are about far more than the visual. Consider how all interface elements move and change during the user’s interaction.
• Simplicity. Is the design as simple as it can be to get the job done?

Avoiding Hostile Critiques

Critiques can be — and often are — done in a pugnacious way, where members of the team, for whatever reason, are inclined to criticize the work without listening to the thought process that went into its creation. They bring their own biases to the design, rather than consider the user, and they often just try to show how clever they are.

You can always tell when a critique becomes overly aggressive: The designer tends to become prickly about their decisions, rather than explain how they arrived at them and discuss alternatives. The key to avoiding aggressive critiques is to set out clear principles and ask open-ended, constructive questions. Remember that the idea is to strengthen the design collaboratively, not to win a design battle.

I find aggressive critiques to be unhelpful and usually harmful. Antagonistic critiques force the designer into a defensive posture, entrenching them in what they have done, rather than empowering them to expand it. Design is — to a very large extent — intuitive and not always easily qualifiable, much less quantifiable.

However, that does not mean the critique is purely about the designer’s opinion; it is about the designer’s well-informed opinion gained through years of study. Web producer Phillip Djwa of Agentic feels that the key is to…

… speak from my experience, and not try to generalize. For example, I would ask, “I wonder whether the opening banner is communicating enough of the brand?” instead of, “Wow, people will never understand what brand value we have.”

Final Word: A Critique Is Not Usability Testing

It’s easy to trick yourself into thinking that you speak for the audience, either through the use of personas or your own biases. No matter how many personas you create or critiques you run through, you are not your audience. Steve Krug tells me:

This is one reason why I think every designer should spend time watching people try to use what they’ve built (aka usability tests).

Just like a laser level versus a bubble level, usability testing is more precise and accurate than internal critiques, but also generally more time-consuming and expensive. Regular design critiques are invaluable for keeping a project on target but can never replace getting out in the field and testing with real-life users. Otherwise, all you are doing is talking to yourself.