Design Critiques: Setting Some Ground Rules

Rule #1: Communicate the Ground Rules

To set the right tone at the very outset of a feedback session, diplomatically, but authoritatively communicate the ground rules before delving into your presentation. Dedicate the first slide of your presentation to spelling out the ground rules. They should be succinct, scannable, and easy to understand at a glance. You can be creative, visual, or even witty in presenting them. As shown in Figure 1, the first slide could potentially include

• the four R’s of critique
• ground rules for providing feedback

If any stakeholders are new to the team, the project is just kicking off, or this is a preliminary design-review session, you might want to quickly explain the ground rules. Otherwise, it should be okay to just pause for a few seconds to let everyone skim the ground rules before moving on.

Rule #2: Set Expectations Early

Before jumping into presenting wireframes or prototypes, set some expectations, as follows:

• Let people know when and how you want to receive feedback—for example, at the end of the session or as you go along. Let them know whether it would be alright for them to interrupt you at any time to ask questions or seek clarifications or that you’ll be pausing at specific intervals to allow that.
• Describe clearly the stage of the design—for example, initial, intermediate, or final. Provide the iteration or version number. This is important because stakeholders might refrain from providing strong feedback if they feel that you’ve already finalized elements of the design—or they might complain that you should have sought their input earlier. Alternatively, they might assume that the design is early and fluid, so suggest big changes late in the game.
• If you’re presenting a revised version of the design, list any changes you’ve already made in a revision history. Mention who reviewed the design and who offered feedback. List the suggestions you’ve incorporated. If some of the people in the room had offered input, remind them—saying, for example: “We met last week to discuss this design and mutually agreed upon these changes.” This helps everyone on the team to understand who and what has influenced the design decisions so far. More importantly, you get to restate that it’s been a collective effort, not a solo endeavor.
• Offer clarity around what should be the primary focus of the feedback. Do you want feedback on the overall flow; specific sections, interactions, or concepts; standards or user-interface (UI) design patterns, or visual design? If there are three to four specific questions for which you’re seeking answers, make sure to state them clearly up front.

The slide shown in Figure 2 accomplishes all of these goals.

You could also share this information in advance of a design-critique session, by including it in the meeting invitation.

Rule #3: Recreate the Context

Spell out the business objectives for the design. Share the personas to remind everyone of the people for whom you’re designing the solution. Emphasize higher-level user needs and the context of use. Reiterate the timeframe and technical and business constraints that you took into consideration when creating the design.

Also, talk about any recent research, requirements changes, or new information that have influenced or necessitated alterations to the design. This can seem like a repetitive or redundant step—especially if you conduct feedback sessions often. Nonetheless, make it a rule to spend at least a couple of minutes doing this. Many stakeholders are involved in multiple, concurrent projects, so it’s easy for them to lose track of context and background. A quick refresher can help them keep the right perspective.

Rule #4: Describe Design Decisions from the User’s Perspective

Always keep your users front and center. When going through your design, explain it from the perspective of the relevant personas.

Refrain from expressing design decisions in terms of your personal thoughts or feelings. For example: “I’d rather have this button at the upper right.” “I feel this is the best way to select and edit.” Instead, frame your design decisions around use cases and scenarios.

Scenarios are brief stories involving the personas, which establish the context of use. For example, “John is processing payroll. His deadline is fast approaching. He is using our system to create new payroll entries and edit existing ones.”

Use cases are specific, step-by-step tasks that the user might undertake to achieve a goal or desired result. Here are a couple of examples:

• Use case 1—“John wants to create a new payroll entry. Step 1: He clicks the New button. …”
• Use case 2—“John wants to edit an existing payroll entry. Step 1: He displays the payroll list. Step 2: He selects the entry. Step 3: He clicks the Edit icon. …”

Rule #5: Explain, Don’t Defend

There is no need to defend your work. If you find yourself doing so, consciously check yourself. Designers sometimes get attached to the designs they create, and this can prevent their staying open to new ideas and suggestions.

Remember, design is a collective effort. Make sure everyone knows that this is not your design, but our design. If someone has a better idea, be open to it. Don’t defend. Stay neutral and explain your design decisions by briefly sharing:

• why the user might need or want this solution
• what other options you considered
• who or what influenced the decision—for example, a competitor review, stakeholders, expert input, standards, or UX research

Rule #6: Be Sure to Take Notes

Use your computer, whiteboard, or a pen and notepad to capture everyone’s feedback. It’s important to take clear notes and let your audience know that you’re doing so. Every time someone makes a relevant point, let the team know you’ve made note of it. This reassures them that you’re taking their feedback seriously. Of course, it’s your prerogative to accept or discard certain feedback, but not without giving it due consideration.

Try to capture and attribute important insights, questions, or concerns, including anything that’s off topic and needs to be discussed later. If necessary, it’s okay to ask everyone to wait for a few moments so you can finish writing down a note. After the feedback session, share your notes with the team to avoid “he said, she said” or ambiguity.

Figure 3 shows a suggested template for notetaking.

Rule #7: Avoid Taking Feedback at Face Value

Diligently record all feedback, without rejecting anything right away. However, whenever necessary, you should respectfully ask for clarification or question the rationale behind a critique. Later, this can help you decide whether and how to incorporate the feedback into your design. This is especially important if feedback is vague, is based on personal preference, contradicts your general line of thinking, or could have considerable repercussions on the proposed design.

Ask for specifics—for example:

• Would you please elaborate on why you consider this to be an improvement over the current proposal?
• Would you please tell me how John, our target persona, would benefit from this change?
• The change that you are suggesting would impact these other parts of the design as well. Do you think making this change would be worth having to make all these other cascading changes?
• Your suggestions differ substantially from the way I’ve been thinking about this design. [Explain how it differs.] Just so I can better understand the value of this change, please tell me why you think I might have been wrong?

Again, conduct the questioning respectfully, through an amiable two-way conversation. Discontinue the discussion as soon as you’ve noted the rationale behind a suggestion and communicated that you’ll consider it. At no point should this conversation turn into a fiery back-and-forth argument or free-for-all discussion.

However, if someone’s feedback is controversial or conflicts with your original line of thought, ask the other stakeholders to weigh in. See what the majority think. If you feel strongly that the feedback is wrong, ask for some time to reflect on it, then seek stakeholder consensus. If possible, take the discussion with the person providing the feedback offline. Sometimes a one-on-one conversation is much better than a group discussion when you’re trying to resolve conflicting points of view.

Rule #8: Actively Manage Feedback Sessions

During a design-review session, you must wear multiple hats—presenter, notetaker, facilitator.

Ultimately, these sessions directly benefit your work. Therefore, it is in your best interest to ensure the sessions are well organized and productive. The onus for conducting a session well is on the presenter—who is usually the UX designer. Determine the format and the focus of the feedback you’re seeking. Decide what stakeholders to invite to sessions and at what stages of the design.

Larger groups of more than six or seven people lack the intimacy and focus that design reviews require. So narrow down your invitation list to the stakeholders who are critical to the design process at a particular stage and most likely to provide meaningful feedback.

During the feedback session, make sure everyone remains engaged. Politely ask people to focus if they become distracted or are multitasking. If certain voices are dominating the conversation, intervene and encourage others to express their thoughts as well. If people are quiet and passive, go around the table to ensure everyone weighs in. If you need a specific individual’s viewpoint on a certain issue, it’s alright to ask a direct question of that person.

If too many people are speaking at once, some are having side conversations, or people are expressing conflicting opinions, feel free to remind the group to voice their opinions one at a time so you can record and prioritize their feedback. Recording everyone’s feedback properly helps you to put things in perspective and reflect on the issues.

Ground Rules for Giving Feedback

The UX designers who are presenting a design aren’t the only ones with a stake in a feedback session. The stakeholders who are attending a feedback session have an equal responsibility to weigh in on the solution and provide constructive, actionable feedback. They must follow ground rules for giving feedback.

Rule #1: Avoid Jumping in Before Becoming Familiar with the Background and Context

Commenting on something you don’t fully understand is risky and irresponsible. As a design reviewer, you must insist on getting the context and background for what you’re reviewing. Even if you think you understand the context, inquire whether anything has changed since the last review session or any new information is available. You need to be aware of the following:

• relevant user personas
• high-level business and user needs
• inputs from key stakeholders or SMEs (subject-matter experts)
• history of design iterations
• major constraints, challenges, or blockers

Rule #2: Focus on the Why

When reviewing a design, if you find something amiss, don’t react without first understanding the why behind it. Ask the designer to explain the reason behind that design decision. Don’t just assume it’s because of lack of due thought, negligence, or incompetence.

Raise your concern in the form of a question. “Please explain why you chose to use a drop-down list here instead of radio buttons.” This gives the designer the opportunity to clarify whether there is a legitimate reason for the decision. This approach encourages an open-ended discussion. On the other hand, “I think you should have used radio buttons here,” might sound prescriptive and put the presenter on the defensive.

Rule #3: Put on Your User Hat

When you review a design, put yourself in the position of the user. This helps mitigate your biases and distances you from your personal preconceptions. Keep personal likes and dislikes to yourself. Instead, judge a design by how easy or difficult it would be for users to complete their tasks using a solution. If you don’t know enough about the user, user needs, and the context of use, be sure to ask about them.

Even if you’re reviewing a design from the perspective of your specific area of expertise—for example, business, development, content, or legal—always keep the user at the forefront and be sure to align your feedback with what’s best for the user.

Rule #4: Make Feedback Meaningful

Feedback that is quite useless to designers includes comments such as: “This looks weird.” “I’m not a big fan of this.” “I don’t like this.” Such statements lack two key pieces of information that might make them meaningful and actionable:

1. The reason—other than a personal preference—behind the remark
2. What might work better

In providing feedback, always tie it to a logical, objective requirement. For example, user or business needs, standards, conventions, usability, user experience, or technical or legal constraints.

Also, try to give an example of what might be a suitable alternative. If you don’t have an example handy, offer to provide it later. Or request the designer and other stakeholders to weigh in on what might work better.

If your comment is based on a subjective opinion, acknowledge that, and urge the designer to do some testing to ensure that it’s not an issue for the user as well.

Rule #5: Avoid Focusing on Just the Negatives

Design reviews are not just about finding fault with a design. They also provide an opportunity to reinforce what works well. This helps establish better standards and benchmarks for future designs. Positive reinforcement also enables and encourages designers to consistently move in the right direction. Up-front positive reinforcement also helps the designer to be less defensive and more open to constructive criticism.

When providing feedback, if possible, first point out the positives before getting to the negatives. Highlighting what works well strengthens the contrast between what works and what doesn’t. This makes it easier for the designer to recognize the shortcomings of a design.

Rule #6: Consider the Repercussions

Sometimes a seemingly simple change that you suggest might not be so simple after all. For example, a suggestion to move a button’s position on one page might trigger a need to make similar changes on many pages to ensure consistency. Or your request to add a simple, additional step to the user flow might open a Pandora’s box of technical constraints on the backend.

Often, even a seemingly minor change in the user interface can trigger an avalanche of related changes. So don’t assume that any suggested change is trivial or simple. Ask designers and other stakeholders whether they think it might result in any complications. Being aware of the potential immensity of changes you’re advocating can help to ensure your feedback is balanced and practical.

Rule #7: Mind Your Tone

Always be mindful of the tone of your comments or feedback. Your tone betrays your intent—whether constructive and supportive or disparaging and dismissive. For example, consider the different tone of the following two comments:

1. “I’m not sure why you used a drop-down list here. Radio buttons would have worked much better.”
2. “Would you help me understand why you opted for a drop-down list here? Don’t you feel radio buttons might have worked better?”

The first comment has a judgmental, rigid tone. It questions the intelligence of the designer and dictates a solution. On the other hand, the second comment, while making your preference amply clear, leaves room for an explanation and open discussion.

Rule #8: Know How Far to Push an Argument

Sometimes designers won’t receive your feedback well. They might present counter arguments that may or may not convince you to change your mind. Even after you’ve made a reasonable attempt at persuasion, a designer might dig in and reject what is, to your mind, a critical point. What should you do then? Argue forcefully till you get your way? Display your displeasure at not being heard? Quietly accept the situation?

Really, arguments have no winners. So, even if you win an argument, you risk losing the goodwill of the designer and damaging your relationship. Displeasure or silence could be equally counterproductive. So ensure that the designer notes your feedback. This provides a paper trail of the discussion and the possibility that the team could explore the design alternative you’ve suggested in the future.

Usually, the best approach is to ask other stakeholders for their opinion to see whether they agree or disagree with you. Alternatively, you could request a one-on-one discussion with the designer to follow up. Sometimes people are more open and receptive to new ideas in an intimate conversation rather than in a room full of people.

If you think a failure to consider or incorporate your feedback in a design could pose a potential risk, flag the issue, document your feedback, and share it with the other stakeholders—or even escalate the issue to the leaders of your organization.

In Conclusion

Ultimately, every stakeholder in the room must understand the importance of design critiques—and following the ground rules I’ve outlined here. Well-done design critiques can potentially inform and inspire great design. However, if a design critique lacks structure or decorum, it can devolve into inanity or bitterness that is detrimental to both the team and the users. Therefore, it is absolutely critical to give design critiques their due and, when facilitating them, to ensure everyone maintains the right rigor and follows these ground rules.