cause when the button is to the left, it usually means the toggle is “OFF” (thanks

to iOS). But, it’s green here. So, how does it work? Also, the “ADD” button is
blue, which would typically indicate that it’s active. But the toggle is “OFF,” so
users might think that there’s no connection between the two, or they might get
confused. See what I did? I only added two colors, but I made a pretty big mess.
That’s why it’s crucial to test out the wireframes and the visual design separately.

What happens after the test?

When you’re done testing the wireframes, it’s time to implement what you’ve
learned. You’ll have a couple of issues to resolve. Now is the time to go back and
create a better version based on the feedback. Sometimes, it’s necessary to test
again. The goal is to eliminate all the serious and annoying issues that come up
during a test before going into the visual design.

Exercise: The Design Review

Giving feedback on the designs is important. The designers have to know what’s
good and where there’s room for improvement. The Design Review is an exer-
cise for the team to provide meaningful feedback to the designers.

To be honest, I don’t like the word “critique.” When I ask people to critique
something, I’m sure they’ll only focus on the negative side and only look for
problems. Don’t get me wrong; it’s important to learn what’s bad or risky about
a design, but there’s more to feedback than that. Everyone on a product team has
to learn how to give critical but meaningful feedback to the other members (e.g.,
if there’s a dead end in the process, or if there’s a missing element on a page). We
also have to pay attention to risky solutions; when users aren’t aware of a tech-
nical solution, that’s a potential risk (e.g., the elderly generation and gestures).

At the same time, we need positive feedback. What works well in the designs?
Why is that particular solution or design good? How could we further improve a
screen? Sometimes it’s the positive feedback that will show you how to improve

178
other parts of the product. If you find a great solution, you might be able to use
it in other areas as well.

To give valuable and practical feedback to the designers, we need an exercise—the

Design Review. During the review, the team sits down and looks at the designs.
To make sure that every standpoint is covered, we’ll give everyone certain roles.
People with different roles will observe the designs from different perspectives.
There will be roles focusing on the problems and risks and other roles paying
attention to the good things. During the exercise, the team will generate a lot of
ideas and feedback. Then, they’ll have to decide what to implement and what to
discard.

Different hats, different mindsets.

We have four different roles. Each of the roles is represented by a color.

• White looks at the facts.
• Black looks for problems and potential risks.
• Yellow looks at what’s good in the designs.
• Green looks for ways to improve the product​.

179
The White Hat: “The facts, Dr. Watson, just the facts!”
If you’re the white hat, your role is to look at facts and give objective feedback.
Take a look at the designs and ask the following questions:
• What can we see on this screen? What can I do here? What’s clear? What
isn’t clear?
• Do the designs fulfill every user need? Look at the design brief, the perso-
nas, and the user stories to help you figure this out. Do the designs sup-
port the business goals?
• Are the designs consistent? Are we using elements consistently across de-
signs?
• Where do we need more input on the designs (from users, stakeholders,
or clients)?
• Is the content clear and straightforward? Are the microcopies well-writ-
ten and well-placed?​

It’s best to put the white hat in charge of the technical points as well. For exam-
ple, the white hat should make sure the designs only use web fonts (for a web
project) and that the designs look great on any device (desktop and mobile).

The Black Hat: “Houston, we have a problem!”

Then there’s the black hat, which, of course, will focus on the dark side. The
black hat gives some of the most important feedback—the critical feedback. It’s
no wonder everybody focuses on this one. Critical feedback is crucial to improv-
ing the designs. But first, we have to learn how to give meaningful critical feed-
back. If you’re the black hat, consider the designs in the following way:
• What’s not going to work? (e.g., “Users won’t understand this screen be-
cause...”)
• What are the potential risks? (e.g., “This element is great on desktop, but
it doesn’t work on mobile because...”)
• What are the disadvantages of a particular design?​
180
It’s even more important for the black hat to back up their feedback with ar-
guments. Maybe the most important skill to have in product design is learning
how to give good arguments and feedback. We can’t expect that others will al-
ways understand what the problem is with a design.

I know arguing is difficult—especially for most designers. They hate defending

their designs (“Why can’t you see that this works?”). Designers also have to give
reasons for why they think the design is great. This helps get the team on the
same page. It’s all about communication.

This holds true for stakeholders and leaders as well. Saying “It’s not good,” “It
looks awful,” or “I don’t like it” without a viable argument is not feedback. This
will result in making the designers/team unhappy and will lead to a dead end in
communication. As a leader, you always have to explain why you think a particu-
lar design or solution is not viable or why you think a design looks bad. Put all of
this in the context of the users; at the end of the day, we’re not building products
for stakeholders—we’re building products for the users.

There might be a great overlap between the black and white hats. Often, they
make similar remarks (mostly about what’s missing), but there’s nothing wrong
with that. It’s always great to have another set of eyes!

The Yellow Hat: “Always look on the bright side of life!”

It might sound awkward, but you can learn a lot from what’s good in the de-
signs. The yellow hat is in charge of explaining what’s good about the designs
and why.
• If you identify a great design solution, you can reuse it later.
• If you know what’s good in the designs, you can communicate it to the
others. This will be a huge help when presenting to stakeholders, clients,
and investors.
• You’ll make the designers and team happy by acknowledging their work.

181
 When asked to critique, people don’t tend to give constructive feedback.
They usually just give negative feedback, but we all like to be acknowl-
edged. We all like to know that our work is great.

If you’re the yellow hat, do the following:

• Identify what’s good about the designs. Give an explanation as to why it
is good and why it works.
• Identify the advantages of a particular design solution.

The “why” is crucial here. You have to know why a design is good (e.g., “This
blue is great here because...”) or why users will love a particular feature. The yel-
low hat also helps strengthen communication, which is a cornerstone of team-
work. This is especially great training for designers (since most of them have
a difficult time interpreting the designs they created). Practicing the role of a
yellow hat will help you become a better communicator, which will result in less
conflict and frustration.

The Green Hat: “I’ve got an idea!”

One of my favorite roles is the green hat. If you’re the green hat, you have to
think about how to skyrocket the user experience of the product or design. This
is where innovation happens. The green hat has to be fresh and generate new
ideas. A green hat asks questions like the following:
• What new features could we add to make the product better?
• How could we improve the designs?​

Now I know this sounds intimidating. Whoa, expanding the project scope? Re-
lax, it’s not about that. But to start, every idea is welcome—even the crazy ones
and the big ones that would change the project scope. Afterward, the team has
to decide which ideas to implement.

182
A green hat can come up with lots of different ideas. There might be some that
are smaller and easier to implement, but they add value to the designs and im-
prove the experience. Great new feature ideas are usually not something to im-
plement right away, but giving space for great ideas to come to fruition is always
good.

Do your first Design Review exercise!

Duration Who to invite Prepare
1–2 hours Product manager Wireframes or visual
Designer designs
Stakeholders Design Review template

Invite team members!

Book a meeting room for 90 minutes. Invite stakeholders, designers, researchers,
and engineers to the session. Limit the number to four to six people. It’s best to
invite people who aren’t current on the project so they can look at the designs
with fresh eyes.

Set the roles.

It’s best to set the roles randomly. You can learn a lot from switching roles each
time. If you have more than four people in the session, start duplicating the roles
(begin with the black and white hats).

Present the designs.

It’s time for everyone to look at the designs. If you created prototypes earlier,
they’ll come in handy now. The reason I prefer to use prototypes for review
(compared to printed out designs or still images) is that the team can preview
the designs on the actual device. If it’s a mobile app, they can preview it on their
phones. So, go with a prototyping tool like InVision.

183