Design Critiques: Eliciting and Giving Feedback

Loading...

From the course by University of Minnesota

Prototyping and Design

201 ratings

University of Minnesota

Prototyping and Design

201 ratings

Course 3 of 5 in the Specialization User Interface Design

In this course you will learn how to design and prototype user interfaces to address the users and tasks identified in user research. Through a series of lectures and exercises, you will learn and practice paper- and other low-fidelity prototyping techniques; you will learn and apply principles from graphic design, including design patterns; you will learn to write a design rationale; and you will learn how to design for specific populations and situations, including principles and practices of accessible design.

From the lesson

Design Principles and Patterns

An introduction to design principles from graphic design, interaction design patterns, and two examples of commercial design guidelines and standards.

Introduction to Design Principles & Patterns8:43

Color and Consistency16:02

Cultural Factors20:31

Interaction Design Patterns8:29

Direct Manipulation & User Control (Interview with Ben Shneiderman)17:35

Case Example: Google's Material Design11:01

Case Example: Apple Human Interface Guidelines4:41

Design Critiques: Eliciting and Giving Feedback10:45

Meet the Instructors

Loren Terveen
Professor
Computer Science and Engineering
Haiyi Zhu
Assistant Professor
Computer Science and Engineering
Lana Yarosh
Assistant Professor
Computer Science and Engineering
Dr. Brent Hecht
Assistant Professor
Computer Science and Engineering
Joseph A Konstan
Distinguished McKnight Professor and Distinguished University Teaching Professor
Computer Science and Engineering

Welcome back.

Today I'll be sharing the Basics of Design Critique.

Now we've actually talked about design critiques just a tiny bit

when we discussed the design centered approaches.

Now we won't talk about any of those today at all.

We focus mostly on critique in general.

And one thing I'd like to point out is that when we talked about design-centered

critique, we really talked about critique that was given among a team of experts.

While here today, I'm mostly going to be focusing on the idea of critique as

a process of eliciting and getting feedback, whoever it's coming from.

So, in my opinion overall,

critique is a great way to shield against stupid mistakes.

Like, for example if the little pigs had gotten input about the design of

their homes,

perhaps they would have been less likely to have been blown away by big bad wolf.

And if you don't know what I'm talking about,

this is probably a culturally specific term.

But you go look up the story.

It's a common kids' story.

It's not the way to design, it's not about designing by committee, so it's not about

getting a bunch of people in the room and having them make your design for you.

But it is a way to make each individual as smart as the smartest person in the group.

Because you can integrate the advice of all these people who

are available to you who are either experts or

users or otherwise can offer something to your process.

However, giving and accepting critique is not necessarily easy.

So I'm going to use an online comic that I found from Deviant Art,

to communicate how to and how not to give and get critique.

So let's say that you are a content creator, and you come to your critic and

you share something that you've done.

Maybe it's an app.

And they give you some advice.

Maybe they say, I don't think your menus are organized in a way that makes sense.

And maybe they say, also, your color scheme is not bright enough.

People who are color blind will have trouble seeing this.

Now there's some ways to kind

of dismiss that critic that would actually hurt your project.

So for example, you might say something along the lines of, it's my style.

Well the visual aesthetic of the app includes the colors as they are,

and I'm not going to change them.

Or you might say something like, well, I get it, but

I'm not really a UX designer, anyway.

I'm really a hotshot programmer, so it doesn't matter, and

I shouldn't have to make it look pretty.

Or you might say something along the lines of, if you don't think this is awesome,

then you don't know what you're talking about.

And of course, most of us wouldn't say this out loud, but the way some

people receive critique feedback is kind of falling into one of those lines.

So on the other hand, it's also quite possible that

the critiquer is not very good at giving critique.

So perhaps, in response to the critique of your app,

you might say something along the lines of, you're right about the colors.

I didn't think about the fact that some people are color blind and

would have trouble distinguishing these two colors.

But I think the menus are well designed so I'm not going to change those.

So a bad critic might actually say something very snobby or

passive aggressive in the sense, something like, well if you knew more about UX,

then you would have done q better job, but you're kind of hopeless.

Some people are actually kind of just trolling.

They give bad advice.

They are very mean if you don't take their advice, and

they're mean about how they give their advice.

So they might actually say kind of, well you're app was stupid anyway.

I don't know why I'm giving you feedback.

And the other part here that's, in this comic show, as an art perspective.

But it's quite common in the technical domain, is when the person doesn't really

know what they're talking about but they really enjoy using buzzwords.

So they might say something along the lines of, well if you synergized

your crowd sourced cloud criteria, then you would know why your app doesn't work.

And I think that there's quite a few people who tend to use buzzwords

instead of actually giving you concrete feedback about your system.

So this is an online comic, so clearly it's exaggerated.

Also, we're not bunnies.

But I think it gets us some common messages on how to give and get critique.

So in order to get good critique, be prepared.

Say what kind of feedback you actually want in your process.

So, let's say if you weren't interested in getting feedback on how your menu is

laid out, you can actually say that to the group that is critiquing your work.

You can say, today I'm really interested in getting more feedback about the color

pallet of this app, and that's what we focus on.

The other two things are to not get defensive, and to take notes.

And actually I think these two actually help each other.

So it's very difficult not to get defensive or

try to explain yourself when somebody critiques your work.

So if somebody says this menu's not well laid out, It's very easy to start saying,

yeah, you think it's not.

Well, we did a study, and it shows that 95 participants can use it well, and

they think it's well laid out, so you're wrong.

But the point of this process is not for you to prove that you're right but

to actually get as much feedback as you can.

Maybe this particular person who is giving you the critique represents those 5% of

participants who did have trouble with your menuing system.

So one way I find to keep myself from getting defensive is just to take

copious notes while the other person is speaking.

I try not to take it personally.

I try not to interpret it.

Just anything they say, I write down for myself to take a look at later.

It also adds a little bit of emotional distance between when you get

the feedback and when you actually look back on your notes and interpret it and

think about it and actually say, yeah, this could be more clear.

In the end, you don't have to take their feedback.

No matter what they say, if in the end,

you decide that in fact, your menuing system performed adequately and

that you're not going to change it, you don't have to change it.

But in the process of the critique, your goal is just to get feedback and

to record that feedback, take those notes.

Now giving feedback is also challenging.

So in terms of giving critiques, I'd say there's three things to focus on.

The first one is, you do need to find something positive to say.

If you start with only critiques that sort of say what's negative about the work,

that's much more difficult for the person to receive.

And it's much more likely that kind of major things that you're

saying will actually go unnoticed because the person is kind of seething about

the fact that you're saying that you don't like what they've done.

And you're not acknowledging their effort on it.

I think the main thing is to focus on reasons.

So for example, instead of saying, I don't like the color pallet of this app,

if you said, I think this color palette would be difficult for

people who are color blind to distinguish.

I think that's a much more specific reason than just, the colors aren't bright.

Additionally, if you can, and at sometimes very difficult to do, but if you can,

try to find specific and actionable suggestions that can improve the process.

So for example, if you were talking about the color blind aspect of the app,

you might say, I think right now, it would be difficult for the red,

green color blind people.

Perhaps you could think of an alternative scheme

that would use a different set of colors, like maybe red and yellow.

So this is very specific and actionable.

It gives the designer something to try.

And it's just much easier when somebody is not just pointing out a problem but

also maybe pointing out a potential solution to their problem.

Now the next thing may be controversial.

I think it is culturally independent.

But the way I like to give critique is something called the compliment sandwich.

So this is the compliment sandwich.

This is actually a compliment hamburger I believe, but close enough.

So the idea is that you structure the meat, the actual critical parts,

things that could be improved,

between kind of the parts that are more about nurturing the relationship.

Identifying the strengths of this work.

Acknowledging the effort that went into it.

So you can start with a structure like this.

So you can start by talking about what the strengths of the work are.

And there's always some strengths to everything.

You can talk about the areas for improvement in the middle.

And finally, you end with acknowledging the amount of effort that went into

producing the product that you're actually critiquing.

There's always some effort that goes into it, so

it's easy to do this kind of a process.

Now I found this t be very effective in working with groups, but

I have to admit that I mostly worked with groups in the United States and

this may be very culturally different.

Some cultures find it just very inappropriate to give negative feedback

in a public setting.

Other cultures may actually find it very patronizing to do this kind of compliment

sandwich where you start with the good and you end with the good.

And maybe view it as being inauthentic.

So with all that said, I think you need to find the practices that work for you,

wherever it is that you live and

whatever it is that your team looks like that you're actually working with.

But before I kind of end, I want to make sure that I mention that critique is

not just something that designers need to know.

Not just something that UX designers do.

This is really something that's very useful in almost everybody's job.

So for example, at some point you may become the boss.

You may become somebody's manager.

In which case, you need to write the performance reviews.

And you don't want to be like the manager here on the left who doesn't know how to

write a good performance review that can improve somebody's work.

So they just criticize them in public from time to time.

You don't want to be that boss.

If you go into academia, whether as a grad student or maybe you become a professor.

I totally recommend it, it's an awesome job.

Maybe you'll be asked to write some academic peer reviews for papers.

So for example, in this case,

this grad student got asked to review a paper for the year's conference.

And I can tell you, as somebody who's both written and received reviews for

papers, It's very nice when people use the compliment sandwich.

It's very nice when people give reasons for their decisions.

And it's very nice when people are specific about things you can change to

improve your paper.

And lastly, even if you don't do any UX and

you don't go into academia, you just become a programmer, you code a lot.

One of the things that programmers do in many companies is they do code reviews.

And your code reviews will be much better received if you start with something

positive, even if the only positive thing you have to say like in this comic is that

now you don't need to obfiscate the code.

So if you want more information about how to do this,

if you want to learn more about how to be a master at both delivering and

receiving critique, there's two books that I really like on this process.

And there's also a YouTube video that is just,

it's from the New School of Architecture and Design.

And it's just a seven minute video that explains how to structure critique and

how to get the most out of it.

I definitely recommend watching it.

It's not very long.

So I hope now you're prepared to both give people feedback and

elicit feedback from others.

And I hope to see you in the next video, thank you.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2018 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play