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.