RailsConf 2014 - Discovering User Interactions by Cameron Daigle

CAMERON DAIGLE: Oh. There it goes.

The big red clock is counting down. I have
to start.

Hey guys. My name is Cameron Daigle. I'm the

senior designer at HashRocket. We are out
of Chicago,

Boulder, and Jacksonville Beach is our main
office. I'm

the longest senior member of the design team.
And

we build Ruby on Rails apps. We build iOS

apps. We do a lot of different things.

So what I'm gonna talk to you guys about

today is, well, this is gonna be yet another

code-free design talk, so I hope you guys
didn't

want to see anymore code today. And it's almost

an app and website-free talk as well, because
what

I'm really talking to you about today are
not

interactions that you're gonna have in a normal
context,

like on a, on a, on your phone or

your laptop. But I want you to discover the

interactions around you.

So what that means is that I want, I

want you guys to be able to build up

the ability to actively participate in interactions
and, that

might not, that you might not otherwise think
about,

that may be your habits or that kind of

stuff. And be able to quantify those and what

you do and don't like about them, and hopefully

apply that to how we design products.

So, my first example. So this is Publix. Who

likes Publix? Is anybody from the Florida
area? OK.

Publix is a really nice grocery store. I don't

know what you guys in Chicago have. But Publix

is, Publix is the best we've got in, in

Florida.

And it's a really nice grocery store, really
nice

user experience, getting your groceries there
and everything. You

go to pay, at Publix, and this, this is

a regular occurrence for me. You go to pay,

you go play with plastic because it's 2014.
You

don't have any cash. And you, this is the

last screen that you see.

So I've, I've, I've swiped my card, I've seen

the total, I have agreed to everything. I
get

to the cash back screen and Publix, the little

thingy at Publix says, cash back? And if I

tap no here, the purchase is completed. That
no

is a, is a form submission, essentially.

And it drives me nuts every time, because
the

last thing to tell Publix to get my, my

weekend beer or whatever, is no. And so it's,

it's this grating experience. But it's, it's
just a

little detail that, that really does matter.
I mean,

that every single person that goes to Publix
and

interacts with them as a store encounters
this screen

where, just for a half a second, you know,

they stop breathing and they're like, wait,
what? And

then they press no and they're OK.

In contrast, Target, which for me is about
a

hundred yards from Publix, their final screen
looks like

this. Now, there's a separate issue here which
is

that this kind of feels like a weird question

to ask. I literally never wanted it all on

my card. Like, I don't, I don't know why.

And the no is super angry. You notice the

no is all caps. It's like NO! But, but

I mean the, it's a big red and a

big green button. You press the big green
button

to buy your stuff. I mean that, that feels

better. And now, the wording is a different
issue.

But my point here is that the world is

full of forms. There, that we are constantly
putting

information into something and getting some
sort of a

result. And it, so, the interactions that
we encounter

when we're trying to build apps, whether we're
developing

or designing for them, have a lot of parallels

in the actual world. And paying attention
to these

will help you pay attention to those.

So, I was in Vegas a couple of years

ago, and this is mostly what I remember of

Vegas is the, the traffic and the concrete.
But

I took a cab ride. I was there with

Daniel, our other designer, at a design conference.
Took

a cab ride and ended up paying like, eighteen

dollars to go two blocks or something. And,
and

when I swiped my card, this was two or

three years ago, I swiped my card and the

little thing inside the cab calculated my
tip for

me.

And I thought, that's fantastic. You know,
it, on

my otherwise miserable cab experience is made
nicer by

the fact that when someone built this thing,
it

didn't matter, necessarily, what it looked
like, so I

hate to say it was someone designed it, cause

then you think it's visual. It's really just,
when

someone built this, the, the software for
this, they

thought to take, put, take advantage of the
fact

that there's an extra step here that's always
going

to happen. And you might recognize this, I
mean,

this is in Stripe now. So you see any

businesses with Stripe, see that kind of stuff
all

the time.

Now, in contrast to that, I took a monorail

later, cause after two or three days of spending,

like, fifty dollars a day on cabs, it turns

out there's a monorail that's, like, way less
money.

So we, we were like cool. We're gonna take

the monorail.

Now, we walk up to the monorail display, and

this is what we see. I wish I had

a better picture, but I was. We were in

a hurry. And this is, this is the screen.

So, single ride tickets, five dollars each.
First question.

Would you like more than one individual ticket?

No?

Or. Yes, two, three, four, five.

So all this has to be is just like,

buttons of one, two, three, four, five, and
it

was this completely baffling thing that we
were just

floored by. But it was something we noticed.
You

know, who knows. So who knows why this came

to be? So the, the, I, I mean, it's

fun to send all this stuff up, but, what

this talk is about is understanding why this
might

have happened.

In this case, I have no clue why the,

they chose to design it this way. I feel

like there must be a reason. But, so I

play a lot of video games. This is from

Super Mario Galaxy a few years ago. I wish

I had a better photo of this, but I'm

not going through Super Mario Galaxy again
just to

find this one dialogue box.

So this, this, this fat star man says, you

gotta save her? Am I right? And my two

options are that's right and yes. And I was

like, heh. You know. That's, that's cute.
Like, cool

job, Super Mario Galaxy. Fun joke.

But then I thought, like, maybe the reason
that

they did this was because there's like a dialogue

prompt object somewhere and it expects, like,
two answers.

You know. So maybe it was a funny joke

and maybe they were just, like, we're not
rewriting

the dialogue prompt thing. You know. Just
to have,

like, an OK button at the corner.

So who knows? But, I mean, sometimes you,
you

get a glimpse into, like, behind the curtain,
and

sometimes you don't.

Here's an example of getting a glimpse behind
the

curtain that I never, ever wanted to actually
see.

This is from the Amer app, a few versions

ago, and it is, too date, the most terrifying

error message I've ever seen in iOS.

In case you can't read it, it's an unexpected

token wanted and then a really strange list
of

symbols and commands, including the word string
with double

quotes around it, within single quotes. And
things like

that. So, I, you guys are the people that

would know why this would happen or where
it

was coming from. I just took a screen shot

and tried to get on with whatever I was

trying to do.

So, and honestly iOS is full of really fun

stuff like this, where, you know, Siri sort
of,

I mean. She seems confident. But she parsed
that

sentence in a certain way that makes me wonder

about, like, how that's being implemented.
Like, how is

this stuff being parsed. And, really, I can
tell

you one thing, the way that it tries to

parse phrases is really more trouble than
it's worth,

you know.

So, someone, they've decided to try to, you
know,

underskirt oats is what it says. It says that,

not me. And what they're trying to do is

parse spaces. But of course, as soon as you

start throwing spaces into your grammatical
checker, you're running,

you're increasing the difficulty of doing
this accurately versus

doing it hilariously wrong. By an order of
magnitude.

And, man, I got, I got these for days.

So, I feel like the, the one on the

right, I really feel like iOS is getting tired

of me making fun of it, a little it.

I love Siri. We have a very intense relationship.

But, my point here is that we judge truly

good design not by its beauty or innovation
or

efficiency, but rather by how well it responds
to

its original problem. At what point are you
sacrificing

complexity, or sacrificing simplicity - either
one - to

confuse what problem you're actually responding
to.

I don't feel like I need iOS to, you

know, to correct an entire phrase for me.
It's

very impressive when it works, but it's very
frustrating

when it doesn't. So at what point is, is

the actual goodness of the design being hurt
by

that?

So we're gonna look at three separate types
of,

of ways to quantify this stuff. So, it's one

thing to be able to, to notice it and

to get, to make, to laugh about it or

to figure out a better way to do it.

It's another thing to actually be able to
do

so on the basis of, like, a principle. So

these are some basic principles, I think,
that you

could take and use when you, when you notice

this stuff.

Respect for intuition, having a common language,
and having

a sense of place. Respect for intuition is
very

simple. All I mean is, does it do what

I think it will do? Which you think would

be very basic, but honestly it's very easy
to

find stuff, all the time, where you put yourself

in the shoes, in someone else's shoes, or
even

your shoes before you learned how to use the

thing, and you, you realize some things are
just

not what they seem.

So, this is two coffee makers ago for me.

This guy broke. The guy after this wasn't
good.

And my current one. But this one, I, this

is a very old photo, but I can not

get over this button. All right, I'm gonna
ask

the room. The brew button. What do you think

will happen when I press the brew button?

AUDIENCE: It will brew a pot of coffee.

C.D.: No, that says zero. None of you guys

are gonna. All right, so, you press the brew

button, and it wakes up the display, cause
this

coffee has a sleep mode. So the coffee maker

has a sleep mode. So, the button says brew.

It's on the front of the coffee maker. It

looks aesthetic. You know, it's symmetrical,
it looks good.

But the button doesn't do what it says it

will do.

You actually have to press it again and then

it lights up, and that means it's brewing
coffee.

So you've got two issues here. One, that the

button straight up just doesn't do what it
says

it will do. It's a lying button. Number two,

that the button now is lit up, which actually

makes, makes it more of a call out. But

it's actually an indicator.

So what you have here is something where you,

you've gotta talk about where something's
an indicator or

a call out. This is an app that I

designed a really long time ago, in iOS years.

This, this came out on iOS 3 I think.

And it was a recording app. This came out

before the Apple voice memos app was a thing.

And we designed it, we said, hey, this app

only needs to do one thing. It needs to

record. So let's just make it a big red

button that says press to record.

Well, the issue with the app that we found

after the first couple versions wasn't the
press to

record. It was what would have after you pressed

press to record. So, initially, you press
press to

record, that button would turn bright green.
Cause we

said, or I said, it was my fault. We,

I said red means record, like, I meant have,

you gotta have the button say record. And
green

means go, so it's going. It's recording something.

But we were confusing people, because they,
they thought

red meant recording and then. So people were
like,

it needs to turn red when it records, and

I'm like, well then the record button will
be

green initially. That, that doesn't make any
sense. Even

though green is brighter. That's.

So, there was this disconnect. And really,
the solution

that we ended up with was, after a couple

of versions in the app store is, the button

pulses. So the button pulses slowly brighter
to darker.

And so sometimes the, the, the solution that
you're

looking for is, you're just using the wrong
format.

I was in photoshop. It didn't occur to me

to use animation at the time.

So that's, that's that story. We're gonna
talk a

little bit about microwaves. And we're gonna
talk a

lot about microwaves, actually. Because microwaves
are probably the

single most-often used bad interface that
there is, I

think. That's probably way too strong. I,
you know,

it's worked well for this talk so I'm gonna

go with it.

This is a wall of controls. I mean, there's

just a thousand things to do on a microwave.

This, by the way, is the inside of a

boat from ages ago, and there was a guy

who stood there and did that. Whatever it
was.

So, I really like this quote from Gary Bernhardt.

Programmers are good at building machines
with seventeen meta-knobs

that turn the ninety underlying knobs. They're
bad at

asking, why are there so many knobs? And I

don't think that's just a, I mean, you can

say that about programmers. I think it applies
to,

to anyone. So I'm not just trying to call

you guys out.

But, all right. So we have this microwave,
and

we have the, the intuition test. What. Does
it

do what I think it will do? Now, if

you've never seen a microwave before, you've
never seen

this microwave before, and regardless of the
fact that

we've all sort of learned to bypass what the

microwave says it will do, like, immediately.
You might,

you might say you try to start pressing buttons

or whatever.

Well, the top left button on this microwave
says

cook, right. So it's in the top left, which

is normally a good place to put an important

thing, and it says cook, which is normally
what

a microwave should do. So, maybe you try to

push, you know, the cook button in the upper

left. You press the cook button and this is

my, obviously my beautiful hands. You press
this, the

cook button, and the microwave goes, Ac - 1.

I don't know what Ac - 1 is. I

didn't actually press start for fear of, of
hurting

something. This, this microwave fails the
intuition test. It

also fails the other test we'll get to that,

let's finish this section with a button that
does

do what it says it's going to do, which

is, this is from my xBox. That button returned

me to what I was doing and I was

like, all right. Thanks xBox.

Kind of hilariously wordy but, that's why
I took

a picture of it, but.

Second. Common language. So, and, and, by
common language

I mean, consistency both within interface
and also outside

of the interface. Like, a consistency with
a user's

common language. So let's look at a, a car

dashboard really quick. Car dashboards are
also, you know,

this really crazy, like, heavy interface that
tends to

vary widely and things like that.

This is actually Daniel, the other designer,
this is

his car. I think it's a Mazda. And every

person that gets in this car does the same

exact thing I did, which is they try to

use that middle knob to adjust, like, the
volume,

or anything really. But that left knob is
the

volume.

Let's break it down. So we've got three knobs

here. This left knob. You push it to turn

the stereo on and off. You turn it for

volume. We could argue that it shouldn't be
on

the left. Someone else could say, but it's
closer

to the driver, so it should be on the

left. So that one can go either direction.

This middle knob. You push it to go to

the next menu item. Like, cycle through, like,
bass

and treble and balance and stuff like that.
And

you turn it to change the value. So what's

important about that is, it's not a toggle.
The

first button, when you push it, is a toggle.

The second button, which looks more or less
exactly

the same, that walks you through a set of

menu options. And the turning changes the
value, which

is sort of like volume, but it's important
to

remember that until you push it, this button
doesn't,

this knob doesn't do anything. Cause it hasn't
selected

anything.

So, the initial interaction with that button,
it was

fifty percent non-functional until you know
how to activate

the button. The third one over here doesn't
push

in at all. And it's, and it tunes, when

you turn it, which doesn't apply to like half

the thing that you're, that you're doing with
the

car. So, I mean, there's an in, there's a

severe lack of internal consistency here.

Here's another example we're gonna go back
to a

couple times. This is the terminator-esque
expensive coffee maker

that we have in the Jacksonville office. It's
very

fancy and nice, but there are also some very

fundamentally non-nice things about it. Let's
look at the

top.

So, I've got controls over more than I probably

ever would need. I've got nine sizes of cup.

I'm sure you have nine sizes of cup for

your. I've got flavor and shrink. Flavor goes
from

light to bold. I, I don't know what, I

honestly don't know what flavor really does.
We just

crank it all to bold.

And strength, strength goes from mild to strong
to

intense. So, there's three, there's, look,
you can do,

you can make a panopoly of coffees with this

thing, apparently. But, so our buttons down
here, our

ways to interact with this coffee maker. We
have

a single cup button, caraf button, and up
and

down and a strength, all right.

So, say I want to change the strength of

my coffee. I press the strength button, which
actually

cycles between strength and flavor. And the
proper one

is lit up. And then I press my up

and down arrows to, like, crank up the strength

or crank down the strength. Whatever. By the
way,

intense is way too strong. It's really strong.

So I go over here to the cup, and

maybe I want to crank up or down my

cup size. That button, you press that button,
the

up and down arrows don't do anything. That
button

actually cycles. It actually walks all the
way through.

Those two arrow buttons, they do set the clock

and they do, like, obviously we didn't set
the

clock. No, I took all these pictures at exactly

twelve o' clock. And they do change the strength

but they don't, they don't, they don't function
for

those other two buttons, even though those
buttons function.

They do the exact same actual thing in the

software side. They're cranking a value up
or down.

So, there's internal inconsistency there.
Oh, yeah, so I,

so, yeah. So there you go. I'm up to

XL.

Video games, again. Video games are great.
I think

they're really, I, I like playing video games,
but

also there's a re-invented UI all the time
in

video games, so I think it's really interesting
how

often those guys start from zero and work
their

way up into a completely different interface
depending on

what kind of game you're playing. It's tough.

But, outside of the software, the controller
has been

the same for a relatively long time. There
are

more shoulder buttons and stuff but you have
a

directional control and you have A, B, X,
and

Y. Generally speaking, it's safe to say that
A

means cool, and B means no. Most of the

time, right. Would you agree? I mean, since
like

1985 or whenever the NES game went out. Or

actually, those buttons are reversed. But
that's kind of.

So, for example, in Mass Effect, this is old,

in Mass Effect one, I think, which explains
why

the iPhone photo is bad quality. A is land

and B is leave orbit for this part of

the game where you are in orbit and you

need to land or not.

So, cool. Like, A, basically does the thing.
B

backs you out of the thing. Same exact game.

Different screen. Same space ship, whatever.
A is enter

system, B doesn't do anything, and X is exit,

which actually backs you out of the menu.
So

there's no particular reason for this, other
than somebody

didn't think about maintaining a common language
with basically

all of video games. At least I, I assume

there isn't a reason. I don't know. I'm, I'm

the user on the other side accidentally hitting
B,

right.

So on this screen, my loud out screen, I

think this is Mass Effect two, A doesn't actually

bring me to the next screen here. It actually

walks the weapon with another weapon. So there's
a

bunch of stuff going up on this page, but

you're eventually gonna choose weapons and
then go into

the mission.

A doesn't do that. A actually changes your
weapon

selection. X modifies, so it actually activates
this weapon

mod screen. Y toggles a, a flavorful sci-fi
description.

And B confirms and sends you into the mission.

So I hope you weren't expecting to, like,
back

out of this screen, because you're just gonna
get

landed on a planet with angry people shooting
at

you.

So, I mean, this, these are off. I mean,

this is from the next game in the series.

This a common language that is there that
needs

to be paid attention to and isn't. So, really,

I like this quote. Innovate as a last resort.

In that, that applies in so many different
ways,

but the context I'm talking about here, it's
that

before you start doing something different
than maybe you've

already done or, or, or other people have
already

done, you need to justify it and you need

to be aware of like the, the existing languages

that, that, or the commonality of the, the
history

of whatever you're using.

So, obviously, accidentally, semi-accidentally
putting a button on X

instead of B is not innovation so much as

an oversight. But this speaks to the respect
that

you need to have for existing patterns and
existing

user assumptions.

Number three, we're gonna look at here is
a

sense of place. So, what I mean here is

the navigation of an item. Where is a user

when they're using your thing. Where are they
in

your website, for example.

So Steve Krug says, navigating isn't just
a feature

of the website; it is the website, in the

same way that the building, shelves, and cash
registers

are Sears. So like, navigation is everything
when it

comes to helping your user understand where
they are.

And this quote's pretty old. So he means like

navigation between pages and stuff. We, with
a lot

of fat client apps and things like that, it's

not just pages. It's modes of interface, it's
states,

it's what is active and available at any time

to me. Maybe my url hasn't change for awhile,

but there's all of these different ways and
navigating

and walking into and out of states of interface

and flows.

So, button modes might get you thinking about
something

that you're familiar with, which is VIM. And
one

of the reasons that I, I started using VIM

like a month ago. I like it, I guess.

So, the, all the HashRocket guys are making
fun

of me. So, VIM, if you've ever tried. How

many of you have not tried to use VIM?

OK. So there's a few of you. So when

you try to use VIM, for you five guys,

VIM is really popular. When you try to use

VIM, you might try to just start typing a

word. But it's not going to do anything. It's

not going to do what you think it's going

to do, even though it looks like a text

editor and your keyboard looks like a keyboard.

You actually have to, you actually have to
go

into insert mode, which is a specific mode,
so

the reason that VIM is so complicated is because

the modes are not immediately apparent. And
that's fine

for an expert tool. You can do an incredible

amount of powerful, incredible amount of powerful
things with

VIM. But it is so heavily modal that it

is very fundamentally confusing and it can
be really

hard for someone to get the hang of initially.

So, something else that's heavily modal is
my microwave.

And it is a lot worse designed than VIM.

Let's, let's be clear. So say I want to,

for some reason I want to soften something.
So,

I, I, I press soften with my well-manicured.
That's

my wife's hand. Press soften, and the, it
says

one.

So, through trial and error, I was able to

discover what it wants you to do here. And

what the soften button wants you to do is

select a value from one to four and then

press start. All right. So the reason that
that

is confusing is not only, well, not only is

there no indicator of that, what that, what
is

going to happen there, it's that the microwave
has

switched modes.

And the reason I blacked all this out is

once you press that soften button, you're
no longer

in microwave mode. You're in softness selector
mode, right.

So while all of these other buttons are still

there, but the mode of the entire thing is

switched. I'm actually, I've actually walked
a step down

into, I've navigated somewhere. Walked a step
down into

a flow, without getting any feedback or, you
know,

unless you count one on the screen as feedback.

I have very little feedback that I have actually

gone anywhere. So what the, what badly designed
modes

can do to you is that they result in

a secret sequence of actions, like I, unless,
till

I discovered what the app or, or interface
or

microwave wants me to do, I don't know what

it is. And if it's a mode, then that

will drive me down what is, potentially, can
be

a long chain of, of sequential actions.

So, for example, with this microwave, I like
cooking

things on power five, cause then, like, it
heats

it a little bit more evenly and you don't

end up with, like, lava combined with ice,
if

you're cooking a Hot Pocket or whatever. So,
like,

I would say, with this microwave, and this
is

very specific to this microwave. Don't go
back and

think that this is, it will apply to your

microwave. Because this, this microwave, you,
you can't push

the buttons first. You have to press cook
time

in order to put time in at all.

Then, you actually have to press power, after
you

have time entered into the display. Then you
can

press five and change the power to five and

then start. So this microwave has, like, there's
so

much here, but like, in order to do what

is a relatively basic feature of the microwave,
you

have to know a specific chain of commands.

I, I really don't want to compare that to

VIM, but that is pretty much like VIM. But

VIM is an expert tool and this microwave is

supposed to be for, for everyone who needs
to

use a microwave. So, you know.

But after entering a mode, you have to do

one of two things. You have to either force

completion of the mode, which is what my microwave

does. None of the other buttons will work
until

you, you know, cancel out and panic and just

cook on ten. And, you know, cook your thing

too much. Or destroy your existing progress.

So I actually checked with a very similar
microwave

at my parents' house when I was there over

Easter. And their microwave, if you start
typing and

you press something else, it just kills whatever
you

were doing before. So what'll happen then
is that

you'll switch the power to five, but then
you'll

type in time and it'll start cooking at ten

because when you switched to put in the time,

it just canceled whatever you did before.

So, microwaves. You know.

So, let's go back to the coffee maker, because

destroying progress can have very real-world
implications aside from

accidentally cooking a thing stronger than
you wanted to.

So this microwave has a very rich user experience

when it comes to actually getting coffee into
and

out of the thing.

So you press the open button. This flips out.

That thing unfolds. You've got all of this
different

stuff going on there. Well, it's got, it's
a

grinder, too. I should point this out. It's
out

of frame. Up there at the top, you put

your beans in there. You close, you get a,

you get the filter emptied out. You close
it

up, you hit start. It goes whirr, and it

starts grinding your coffee.

Well, here's the problem. Is that open button,
fully

functional the whole time. So, and this has
happened,

I would say, this has happened a handful of

times and it's really bad, because you, you
end

up wanting to fight somebody before the day
has

even started. But you're standing there with
your mug

next to it. You're first in line. You know,

you've just started the coffee. It's finished
grinding. It's

started to brew.

And some guy walks up and he goes boink,

and he hits the open button and the coffee

maker's like, pfft. You put it back in, you

press start and it goes whirr, and it starts

grinding a new batch of coffee. So you can

destroy. That one button will destroy an entire,
like,

entire thing of coffee. Like, you don't, it,
it

doesn't know what it, why it's doing that.
It's

really annoying. You have to go in and empty

the filter and reset the whole thing. So you

can destroy an entire pot of semi-brewed coffee
just

by pressing the open button.

So that's awful.

Here's a, here's the coffee maker I have at

home now. It is simple. It was, it was

not expensive. It's not, it doesn't look like
as

much like a terminator as the other coffee
maker

does. You, it doesn't have a grinder in it

or anything like that. We're talking pretty
minimal. It

makes water hot and it puts it on the

coffee.

On the inside here, this is a, this is

the spout. So this is your little water spout

that's actually gonna put the, the water into
the

coffee. It flips over here. So, like, you
fill

up the thing, the tank with water. You pull

that over. Close the lid. It puts water on

the coffee like it's supposed to, you know.
Not

very glamorous.

But here's one thing that I discovered on,
completely

on accident that I thought was great and I

got probably way too excited about it. Let's
watch

a cinematic recreation of, of this, of this
coffee

maker and what I discovered.

I should have. I should have had music.

Oh my gosh! I was so excited. I was

like, oh, whoever designed this but a little
tab

thing right there, and it's slanted just a
little

bit, and it cost probably almost zero dollars,
but

it was. That pushes the little arm in there

to keep you from accidentally just putting
hot water

back into your tank. And I was like, this

coffee maker has developed a lowfi like very
non-technical

solution to a problem, and this was probably
done

by whoever engineered the coffee maker. Like,
it was

probably not done by the guy who designed
the

outside of the coffee maker. It was done by

the guy who designed the inside of the coffee

maker.

But he's avoided a very basic kind of user

error. So let's, let's do a, let's do a

feature comparison here.

This coffee maker was $200. This coffee maker's
#35.

This coffee maker has a one-button self-destruct,
right.

This has a one-tab coffee saver.

This thing's got a thermal carafe.

This thing's what I like to call a visual

quantity indicator. That means, that means
you can see

how much coffee is in it, which is a

whole other thing.

All right, design is the decision making in
the

presence of constraint. You give somebody
$200 and you

want a coffee maker with this giant list of

features, versus a #35 with, with like way
less

features. You're, maybe, well the design on
the, of

the later might actually be better. You know,
it's

not. Constraint is not necessarily a bad thing.
I

really like this quote.

So here's what we're not talking about. I've
got

to speed it up. Here's what we're not talking

about. We're not talking about button styles
or what

things look like. That's important, but generally
speaking we

know what a button looks like. We know where

it is. You know, buttons have looked more
or

less the same up until this year.

So, like, that's, that's decoration. It's
ridiculously important, but

that's not what you'd have to worry about
in

order to have an interaction feel good. And
it's

also. I also just want to say that, like,

as a designer, I wanted to facilitate good
experiences

and not have them get hurt at the expense,

or, at the expense of my design preferences.

So Ancient City Ruby was at this hotel last

year. This is, or, this year, too. This is

the Casa Monica Hotel in Saint Augustine.
So, beautiful

on the outside. Absolutely gorgeous. Really
nice architecture in

the whole place.

We walk into the room, and this is our

window. All right, so our window is like three

feet tall. It's this little square window.
The room

is all dim. There's just, if you see up

here, there's a little plaque. This is what
the

plaque says.

These uniquely shaped and placed windows,
blah blah blah.

As to why some windows are regularly shaped
and

low to the floor is known only to Franklin

Smith, who is the, he was the amateur architect

that designed this building. So he was really
into

the outside of the building and not so much

the inside, at the expense of his users, I

should say.

Here's something that's actually well-designed,
but it's not well-decorated.

So this is the hotel receipt, or. Hotel receipt?

Or, the parking receipt at the airport. It's
ugly,

you know. I would like to redesign it from

a decorative sense. But the actual fundamental
design of

it is actually all right. Because it's probably
really

low-cost to print these things, like, that's
like nine

lines of dot matrix, right. So there's probably
a

lot of money saved just in terms of the

complexity of the hardware and things like
that.

And here's the, here's the thing you put it

in. This thing, also really ugly. But, it
performs

great. There's one slot. You put your ticket
in.

You put your card in after your ticket. It

spits out your card and your receipt. So there's

almost no way to screw this up. They actually

have instructions. It says insert ticket.
Insert credit card.

Take credit card. Take receipt. You almost
don't need

instructions for that, but I appreciate it.

It's well, it's not pretty. It's not well-decorated.
But

it's well-designed and that is solving the
right problem.

Good design solves the right problem. So this,
when

we come back to things like this, we look

at the, the microwave. Why? Like, why did
this

end up like this? And I, I really think

that it's because microwaves are not designed
the way

we design soft- or, hopefully not designed
the way

we design software. And, like, this industry
doesn't necessarily

work the same way we do. And I think

that the process can have all the influence
in

defining the product.

So, with that said, let's design a microwave
the

way we would design a product really quick
here.

So, I want to design to solve a problem.

I want to design it feature by feature, to

justify the most important stuff that you
would need

to have a microwave work well.

So let's start with a clean slate. So the

first thing I'm gonna need on my microwave,
is

I'm gonna need to know how much time, cause

the microwave counts down, and I'm gonna need
to

know I'm gonna be able to start and stop

it.

So that's the first thing we'll need. Well,
I

need to be able to increment and decrement
the

time. So let's do that. I probably don't have

a use case for less than ten second increments

for cooking something. So that seems reasonable.

I do have a use case for, like, defrosting

or something like that, where I might have
to

hammer that button a bunch of times. So let's

add minute selectors as well, so we can go

up to, you know, five minutes relatively quickly,
with

very little fuss. It makes sense immediately.

And I also need to adjust the power level.

Well, let's do that too. Let's use our existing

design metaphor. Let's use our existing design
language, and

we'll put a power selector right there. And
that's

it.

So, what we've done is we've, we've followed
user

needs and we've followed specific feature
needs. We've avoided

inconsistency. We've avoided confusion. We've
also avoided modes. So,

hypothetically, if you were to design something
that, that,

that backed this up, hardware wise, you should
be

able to just change power on the fly. I

mean, maybe there's something I don't know
about microwaves

where you can't do that and you wouldn't be

able to use those buttons, but as far as

I know, there is no, like, there's no secret

sequence of events to set time and power and

start. You should just be able to do it.

So that's the kind of thing that we could

do instead. And, so this talk is about, I

mean. Hopefully at this point you know what
this

talk is about. But, we need, we need to

look at things, and we need to look at

the interactions around us and we need to
learn

from them, even if they don't apply to our,

even if they're not software based.

Because the way that you design something
in the,

fundamentally, like the way you think about
it and

the way you think about your users is gonna

affect the final product every step of the
way.

And I feel like that's some, that's our obligation.

We can show people that we value their experiences

top to bottom and that we're constantly thinking
about

how to solve problems, ease friction, remove
barriers, and

serve them in world-class ways. And we have
a

huge opportunity to change someone's expectations.

So what I want you guys to do is

discover the interactions around you, no matter
what they

are. Respect your user's intuition, language,
and their sense

of place, those basic, fundamentals of understanding
where those

things can go wrong. And I really do think

that interactions are for everyone. This isn't
just design

stuff. This isn't, this isn't based on some
science

that you don't know. There's a certain level
of

awareness and a certain level of active experiencing
of

interactions that I think apply to anybody
in our

field.

So, that's all I got. Thanks a lot guys.