Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
Start a free Basic trial
to watch this video
We're Doing It Wrong: Prototyping the Future of the Web
34:34 with Steve HickeyAs an industry we love to tell our clients that we’re agile or lean, that we’re better than the traditional waterfall process. But the reality is that we all stick to old bad habits in the name of convenience and safety. Even worse, our clients expect it. They want comforting checklists and scheduled delivery dates for design artifacts. The list tells them we’re doing it right. But we’re dead wrong when we work that way. A traditional process delivers nothing but assumptions. It’s time to get on board with a process that creates validated learning. It’s time to take responsibility and to do our jobs to the best of our abilities. It’s time to start prototyping.
-
0:02
My name's Steve Hickey, I'm a user
-
0:04
experience designer at Fresh Tilled Soil just
-
0:06
outside of Boston and today I'd like to talk you a bit about prototyping.
-
0:11
Before I jump into that, though, let's get to know you a little bit.
-
0:15
Anyone in the room who's a designer could you raise your hands?
-
0:19
Okay good.
-
0:20
Anyone who's a developer could you stand up, hop on your
-
0:22
left foot, and spin in circles for a bit for me?
-
0:25
Okay.
-
0:26
I figured you'd be used to requests like that from designers.
-
0:30
Okay.
-
0:31
And how many people in the room would classify the way they work as water fall?
-
0:36
Anybody brave enough to admit it?
-
0:38
Okay.
-
0:40
Just in case, none of you remember what that is.
-
0:42
Everyone's whose moved past it, that's the one two three I've gotta do
-
0:45
this first and then that and at the end you launch your product.
-
0:49
Now, could anyone who works agile and lean raise your hand.
-
0:54
yep, okay, keep em up.
-
0:56
Keep the agile and lean hands up for a second.
-
0:58
Good amount.
-
1:00
Sorry.
-
1:01
Sometimes I gotta call B.S. on that.
-
1:03
If you're not as good at high school
-
1:04
Spanish as me, I did subtitle that for you.
-
1:08
It's ok though.
-
1:10
If you do have a bit of waterfall in your process, it's not really your fault.
-
1:13
It's the kinda thing that got taught in design schools.
-
1:16
Big firms work this way, smaller agencies that sprang out
-
1:19
of them work this way and it kinda became a habit.
-
1:24
The thing is, it really doesn't make a lot of sense
-
1:26
to work that way, with the digital products that we work on.
-
1:29
I can sort of understand where it came from from the
-
1:31
print world, where you have fixed production points and things like that.
-
1:35
But, the great thing about the web is it allows us to put something in front of
-
1:38
the user, and see how they react, really quickly
-
1:41
and we can do it really cheaply as well.
-
1:44
We have infinite ability to fix and redo things
-
1:46
and there's a lot of power and opportunity in that.
-
1:49
We should be taking advantage of it.
-
1:51
Instead we've been showing our work to users at
-
1:54
the logical point that springs out of a waterfall process,
-
1:57
which is unfortunately right here at the end when you
-
2:00
launch the product and you think you've done everything else.
-
2:03
And here's what happens when that's the first time they see it.
-
2:06
All the feedback you get is complaints.
-
2:09
If you want a great, big list of things that you that you did wrong
-
2:13
once it's too late to fix them, that was a really great way to work.
-
2:18
Thing is, because, just because your coworkers and your boss thought you did a
-
2:21
great job throughout the process, it doesn't
-
2:23
mean that you actually did a good job.
-
2:25
You don't design for your peers, you
-
2:27
design for your users, users don't appreciate
-
2:30
the subtlety of your color choice if they can't find contact info on the website.
-
2:34
They don't notice the cleverness of you type pairings.
-
2:36
What they notice is that they can't figure out how to cancel an order.
-
2:40
So we need to find a way to avoid these problems and it's pretty simple.
-
2:44
We're just gonna show users the product earlier in the process.
-
2:48
We're gonna do it several times and we're gonna
-
2:49
listen to them every time we show it to them.
-
2:52
When we expose our work to users early and often, and we're going to
-
2:56
do our best to learn from what they tell us when they do that.
-
2:58
But this doesn't fit well into the old process.
-
3:02
Waterfall, for designers creates one very specific deliverable.
-
3:08
Very Pretty BULLSHIT.
-
3:10
It's entirely focused on making things look good, and this
-
3:13
is really the wrong thing for us to focus on.
-
3:15
A lot of us may be visual designers, but
-
3:17
whether or not the product is pretty is actually kind
-
3:19
of unimportant in the grand scheme of things and
-
3:22
it's surprising how often we lose sight of that fact.
-
3:25
Especially cause here in how robotically we spoke the two
-
3:27
sayings on the next two slides were about to show you.
-
3:31
So, sorry about this one.
-
3:32
There really should be a limit on Steve Jobs quotes at conferences,
-
3:35
I'm pretty sure that Matt from Gooza just completely took up the
-
3:39
entire quote the other day during his talk, but design is not
-
3:42
just what it looks like and feels like, design is how it works.
-
3:46
Here's the other one.
-
3:48
Form ever follows function.
-
3:51
Pretty much the same thing.
-
3:53
But with every time you set or agreed with some form of one of
-
3:55
those statements, have you really, ever really
-
3:57
ever stopped to think about what they mean?
-
3:59
The greatest sin of designers is our attachment to making things
-
4:03
look good and as a result, we've forgotten our own commandments.
-
4:07
So we have the ability to focus in on tiny details, to sacrifice every other
-
4:13
consideration just to get the smallest things correct,
-
4:16
and sometimes and for some people, depending what
-
4:18
your role on the team is, that's a really powerful thing to do, but a lot
-
4:22
of times all it really causes is for us to burn time on the wrong stuff.
-
4:26
Waterfall pushes us naturally towards this problem
-
4:28
and we need to be better than that.
-
4:30
So, let's take a look at how we can retro fit our process to help us out a bit.
-
4:35
So, first thing's first in any project what we really need to
-
4:39
do is become familiar with the problems and needs of our users.
-
4:42
Everyone has a completely different way of doing this.
-
4:44
At my company we do something called a deep drive.
-
4:47
Google Ventures has the product design sprint.
-
4:51
It's all based on personal presence, time, resources.
-
4:55
You know, the old stuff.
-
4:56
Figuring out what you're gonna do to do this is beyond
-
4:59
the scope of my talk but let's agree on one premise.
-
5:02
If you feel like you understand the
-
5:03
problem, it's time to move into making something.
-
5:06
I've always found that a natural byproduct of this stage is a great deal of sketching
-
5:09
and white boarding, you're gonna end up with
-
5:12
a lot of really rough ideas for interface elements
-
5:15
and functionality, and this kind of thing is
-
5:17
rarely complete at this stage, but a good
-
5:19
idea is to try to take some of this and just build onto them a little bit.
-
5:23
To see if you can get some tiny piece of product out of them to
-
5:26
learn something, no matter how limited in
-
5:29
scope and functionality it is at that point.
-
5:32
Thing is you don't wanna make them perfect right
-
5:34
then, what we're going here for here is good enough
-
5:38
because until you put it in front of the user
-
5:40
you have no way of knowing if it's just right.
-
5:43
No Photoshop, no Fireworks, no Sketch, not right now.
-
5:46
We wanna keep things rough, so, I know, from my experience, that we all
-
5:51
experience the desire to perfect things, but this in reality is a delaying tactic.
-
5:56
The longer we go without showing somebody else our
-
5:58
work, the more we risk making really serious errors.
-
6:02
Going down wrong paths, wasting a lot of time.
-
6:05
Well, we don't wanna work that anymore.
-
6:09
So, the old way, we would move onto wire frames after
-
6:13
we got a good understanding of how how the users worked.
-
6:18
But do you think we're gonna keep doing that?
-
6:21
No, cuz, one very simple reason, wireframes are a trap.
-
6:27
They trick us into thinking about the wrong
-
6:29
thing, in too much detail, at the wrong time.
-
6:33
We're not going to do them anymore, because they're way,
-
6:36
way, way too specific for this point in the process.
-
6:40
Instead what we can do is make a clickable prototype and in
-
6:43
fact, I would advocate that we
-
6:44
can completely replace wireframes with prototyping.
-
6:48
What you see here is an app that
-
6:50
my company did for a pharmaceutical sales company.
-
6:53
This was designed to help their reps to know what they
-
6:55
were gonna do everyday and what we did was old process.
-
6:59
Move through sketching.
-
7:00
Thought we had everything right.
-
7:01
Moved into wireframes, made some exhaustively
-
7:04
detailed documentation and then, we had a
-
7:07
couple days left before we actually had to go talk to the client.
-
7:10
So, just on a whim, I tossed it onto an iPad and
-
7:12
just to see what would happen if I started clicking on things.
-
7:15
Turns out the navigation was terrible and I didn't know that.
-
7:20
I burned two weeks on exhaustively
-
7:22
documenting something that didn't work at all.
-
7:25
But I found that out really quickly.
-
7:27
I had a couple days to fix it and so I was able to put
-
7:29
something together that function properly, put it
-
7:31
on the iPad, walk in the clients office.
-
7:34
Turns out they actually kinda love this shit.
-
7:37
You hand a client something right from the get go that
-
7:41
actually works, that you can click on, that you can do things.
-
7:44
They tend to think you're a wizard of some sort.
-
7:46
They thought that we had actually made the entire applica, whoa.
-
7:49
[LAUGH] Was that an earthquake?
-
7:53
They thought that we had actually made the application for them and they were pretty
-
7:58
excited to play with it a bit and give us really great feedback early on.
-
8:01
The
-
8:04
goal here was to get to something testable as quickly as possible.
-
8:07
Our first test was when I tried the first version on iPad and it was terrible.
-
8:12
So we fixed it, the second test was when we gave it to
-
8:15
the client and they could walk around with it and understand how it works.
-
8:18
The third test was when we refined that a little bit.
-
8:20
We're able to put it in front of a couple
-
8:22
of their sales reps and see how they did and
-
8:25
from then on we were able to run more tests
-
8:27
every couple of days as we improve and refined things.
-
8:30
And that was a lot better than just a stack of PDFs that were going
-
8:34
to go off to a development team without
-
8:36
any validation whatsoever, so, this is what I
-
8:40
think beyond a reasonable doubt is the most
-
8:42
important thing you can do to make sure
-
8:44
you're building the right thing in the right
-
8:45
way is to prototype as early as possible.
-
8:48
Instead of checking off 1, 2, 3 on some
-
8:50
sort of list until the client is happy, what
-
8:52
we're gonna do is make really rough, really dirty
-
8:55
functional prototypes and we're gonna do a lot of them.
-
8:57
We're gonna find out if they make users happy.
-
9:00
We're gonna fix the things that don't and then
-
9:02
we're gonna keep doing it a few more times.
-
9:05
Ideally the last prototype is well on its
-
9:07
way to being some sort of production ready code.
-
9:10
A good enough artifact to actually communicate to the team
-
9:12
building the product exactly how it's gonna work and the great
-
9:16
news is there are now some great tools out there
-
9:19
that will help you build functional prototypes as quickly as possible.
-
9:23
So I talked about Sketches a little bit earlier and how much they can convey.
-
9:28
There are a couple of tools, that'll actually let you
-
9:29
take those sketches and turn them right, into the clickable prototypes.
-
9:32
This is a good one called POP, for prototyping on paper.
-
9:36
It's an iOS and Android app.
-
9:39
It allows you to photograph your sketches.
-
9:40
You can add clickable areas to them, that'll
-
9:42
help progress to other sections of the mock-up.
-
9:45
You can create an entire prototype in a matter of minutes just from
-
9:48
the sketches you've done on a white board or on a piece of paper.
-
9:51
This will actually also incidentally work with high fidelity
-
9:54
mock ups that have been uploaded into your photo gallery.
-
9:56
So you can make this better and better as you move along.
-
10:00
This is mobile only though, it's restricted
-
10:03
to small screen output at the moment.
-
10:06
InVision App has become really popular lately.
-
10:09
We started using in my company a few months ago, I've talked
-
10:12
to a lot of other designers and they've been really happy with it.
-
10:14
We're very excited to keep going with this and see how
-
10:16
it develops but some of the features you get out of
-
10:19
this are the ability to click and drag to create hot
-
10:22
spots and quickly pull links together in a visual interface online.
-
10:27
You can get transition animations for mobile devices.
-
10:30
You can determine scrolling versus non-scrolling areas.
-
10:34
You can do both web and native prototypes so there's full range here.
-
10:38
They can be installed on mobile devises directly on the home
-
10:41
screen so you can actually mimic a native app very effectively.
-
10:44
They have a dragon drop image loader or you can sync with a folder in Dropbox, so
-
10:48
instead of having to upload new files every
-
10:50
time you change something, it'll just sync them automatically.
-
10:53
And one of the best parts, I think, is results can be annotated by members of
-
10:57
the team and commented on, and they can be commented on by the clients as well.
-
11:00
You can send them a private link that other people can't find.
-
11:03
They can comment in line in the prototype, and then you have
-
11:06
a checklist embedded in your artifact that you can use to keep working.
-
11:10
I think this has made a huge difference in how we work.
-
11:12
We've been using it on most of our projects lately.
-
11:15
There's also some great competitors to it.
-
11:17
Flinto and Marvel come to mind, so I'd recommend checking a few of those out.
-
11:21
But these make a huge difference in workflow for us.
-
11:26
There's also all the old stuff.
-
11:27
The things you were using to make wire frames before.
-
11:30
Every one of these pieces of software, I
-
11:31
think with Balsamiq, Axure, InDesign, Keynote and PowerPoint,
-
11:36
give you the ability to create hotspots and
-
11:38
click from slide to slide in different ways.
-
11:40
So if you're already really used to one of
-
11:42
these pieces of software and you wanna stick with it.
-
11:45
You want to get the speed that you've
-
11:47
learned out of it and you know, maybe you're
-
11:49
arguing with a project manager, about how much
-
11:51
time it's gonna take, to learn the new tool.
-
11:53
They can't really argue with you, doing it the way you were already doing it,
-
11:56
and spending a few extra minutes to make
-
11:57
something you know, communicate better to the client.
-
12:00
So, I would recommend looking at one of these, if you're
-
12:02
not quite ready to jump over to a new tool yet.
-
12:06
There's also good old HTML, CSS, and JavaScript.
-
12:10
You can write a really good prototype, a really rough prototype, really
-
12:13
quickly if you have a lot of experience and know what you're doing.
-
12:16
There's a lot of frameworks and tools that'll allow you to do this quickly.
-
12:20
So Bootstrap, Foundation, Sass, and let's you write CSS a little bit faster.
-
12:26
There's even built in functionality from Dreamweaver and Fireworks
-
12:29
you know, if you're into that sort of thing.
-
12:33
The great i, the great thing about all of those though, is it allows you
-
12:36
to get your code out quickly it allows you to get your idea out quickly.
-
12:39
And if you're disciplined in how you write
-
12:41
your code, you can even evolve as things go
-
12:43
along so that your final prototype is production
-
12:46
ready instead of having to go through another step.
-
12:50
There's also another great side effect of using JavaScript in your prototypes.
-
12:54
It's that you can start faking database interactions really quickly.
-
12:59
I suck at databases and it's actually probably fair
-
13:02
to say that I worse than suck at them because
-
13:04
I've never successfully gotten one to work long enough
-
13:06
for me to determine if I could figure it out.
-
13:09
They just don't work for me.
-
13:11
But I can write really bad JQuery as you can see here.
-
13:14
That's really easy for me.
-
13:16
So you can use the HTML5 local storage API with
-
13:19
JavaScript to load data in and spit it back out.
-
13:22
You can even actually take user modifications throughout a
-
13:26
session, store them as if it's a database and allow
-
13:29
the interface to react to them, so they can, you
-
13:31
can get a much better testing experience out of it.
-
13:37
This also gives you a really great excuse to involve developers from the beginning.
-
13:42
I've heard through different talks this week,
-
13:44
a, about many different ways of working.
-
13:46
Some people still hand off PSDs to a developer later on in the process.
-
13:51
Other people are lucky enough to
-
13:53
start working with developers from the beginning.
-
13:54
That's how we do it at my company.
-
13:56
That's how we advocate people do it and this is just a really great excuse
-
13:59
to say you need a developer from day one so you can collaborate with them.
-
14:06
But if you don't get to work from the,
-
14:08
with the developer from day one, if you're gonna
-
14:10
have to hand this off eventually, this is a
-
14:13
good way to hold everyone accountable towards what you developed.
-
14:16
As a prototype gets refined, as all the little
-
14:19
interactions get smoothed out and all the niceties get figured
-
14:22
out, the client is going to fall in love with this in a way they can't fall in love
-
14:26
with a static mock up and when the devs
-
14:28
come in to handle it, they now have an example
-
14:32
of what needs to be built, a very clear and
-
14:34
communicated example the client loves and is bought into already.
-
14:38
So this helps hold everyone on the team
-
14:40
accountable for the final quality of the product.
-
14:45
So, going into detail on usability testing would take
-
14:48
a lot longer than I have available for this talk.
-
14:51
The only really valuable piece of advice I have to give you here
-
14:54
is just to buy this book and read it six or eight times.
-
14:58
It's a really great book.
-
14:59
It's got some good tips like tricking people into going into user testing
-
15:02
with boxes of donuts and things like that, so Steve Krug knows what
-
15:05
he's talking about, it's well worth the 20 bucks or so, and I
-
15:09
will reinforce one point from his book again, test early, and test often.
-
15:15
The entire reason we're gonna be prototyping is so that we can do
-
15:18
that, so that we can learn as much as possible before we launch.
-
15:21
[BLANK_AUDIO]
-
15:24
All right, so, what about web design?
-
15:27
I've said a couple of times that we're way too worried about you
-
15:30
know, things being pretty, and we need to concentrate on more important things.
-
15:33
But visual design does come into it at some point.
-
15:36
A polished visual design is part of the
-
15:38
experience and helps users understand what's going on.
-
15:40
So, how do we work an effective visual design process,
-
15:44
like what we've become used to, into our new prototyping world?
-
15:48
To do that, we're gonna have to admit an unpopular truth first.
-
15:51
Mock-ups are completely and utterly useless.
-
16:00
See, Keanu's confused.
-
16:03
Look, a Photoshop mockup does one thing really well,
-
16:07
it makes clients feel comfortable and if your client wants
-
16:12
to burn money on being comfortable instead of getting
-
16:15
the best product possible for their users, then that's great.
-
16:18
Just do Photoshop mockups all the time, and work the way you used to work.
-
16:23
But the problem I have was not, with them is that I think it
-
16:26
forces you to make really complex final
-
16:28
visual decisions way too early in the process.
-
16:32
And because the level of polish and consistency expected in
-
16:35
visual comps is so high, you're gonna burn a ton
-
16:38
of time getting those little details right, because the client
-
16:41
will notice every time something is a couple of pixels off.
-
16:44
We've all encounter that.
-
16:46
Somethings just like a buttons five pixels too narrow and it's
-
16:49
the only thing the client sees in the entire review process.
-
16:52
It's really annoying.
-
16:55
But the thing is we're not gonna totally avoid comps.
-
16:58
We're just gonna be way smarter and more efficient about them.
-
17:02
So the sketch phase is actually gonna accomplish a lot
-
17:04
of the functionality and layout problems that you've been dealing
-
17:07
with and as you move through some of the early
-
17:09
prototyping stuff, you're gonna get more of that figured out.
-
17:12
So, you really don't have to go into
-
17:14
full exhaustive detail with that in Photoshop, what you
-
17:18
would do wanna do, is figure out the
-
17:20
visual style, and Photoshop is pretty good for that.
-
17:23
You don't have to make a full mockup
-
17:25
though if you use a couple of different tools,.
-
17:27
So, one thing I've started doing is what I'm calling UI studies.
-
17:32
If you look at the notebooks of master painters from
-
17:35
the renaissance up to today, it's not like they set
-
17:38
down, it's not like Da Vinci sat down and painted
-
17:40
forty Mona Lisa's until the last one was just right.
-
17:44
Like you go through notebooks and you'll find
-
17:46
little details of pieces of the final composition.
-
17:49
You know, he'll spend months figuring out how to
-
17:51
draw two hands and their relationship to each other,
-
17:54
something like that, and then you have this entire
-
17:57
collective group of interface, well not interface in his
-
18:01
case, but little experiments that combine to form the
-
18:04
final whole and I've started trying to do stuff
-
18:06
like that with Photoshop and with tools like code
-
18:09
pen and any variety of other things available to me.
-
18:13
Like, one thing that works for me is take in like a half size canvas in
-
18:16
Photoshop or sketch and doing a really zoomed
-
18:19
out experiment with final look and feel because
-
18:21
it keeps me out of the little tiny details so that I can refine later but
-
18:25
it gives me a great idea of what this is gonna feel like to a user overall.
-
18:29
And I can also work on various break points next
-
18:31
to each other, this and start to give an idea
-
18:33
of how things shuffle around for a responsive design, and
-
18:37
when I'm having problems with specific interface elements a lot
-
18:40
of time I'll try to work on those a bit
-
18:41
in isolation from the rest of the project, just to
-
18:44
try to figure out the specific problems I'm having there
-
18:46
before I reincorporate them back into the prototype as a whole.
-
18:52
Another useful method would be style tiles.
-
18:55
So maybe you get some of the look and feel stuff out of the
-
18:57
way and then you wanna start experimenting
-
18:59
with more detail in your interface elements.
-
19:01
So I might assemble an example of part of the interface and start dealing with that.
-
19:06
You know, button radiuses and shadows and typographic relationships.
-
19:11
I think that's really useful instead of
-
19:13
having 700 different Photoshop files that are all
-
19:15
attempting to copy the exact same distance between
-
19:18
the bottoms of paragraphs and things like that.
-
19:21
If I just have one good example of how it's supposed to
-
19:24
happen universally, and then that into,
-
19:25
that gets incorporated back into a prototype?
-
19:31
I've also been working on designing in the browser a lot more.
-
19:35
Like I said, if I want the same spacing at the
-
19:37
bottom of paragraphs, it's a lot easier to go into the inspector
-
19:41
and just tweak that value in Chrome, instead of going back through
-
19:44
my 700 Photoshop files and trying to make sure it's consistent everywhere.
-
19:47
I can actually do a lot of
-
19:48
really simple effective refinement, that will apply globally.
-
19:53
And if you get the settings right in chrome it's even
-
19:54
possible to save those refinements directly back to your CSS files instead
-
19:58
of having to copy and paste or remember them, so the
-
20:01
inspector can be a really powerful tool once you get comfortable with
-
20:06
it, but I think the overall point I want to make here though, is
-
20:09
what you want to do is use the right tool for the job at hand.
-
20:13
Throughout your entire visual design process, you're going
-
20:15
to come across a great variety of problems.
-
20:18
Sometimes your problem, the most effective way to
-
20:20
solve it is gonna be a Photoshop mockup.
-
20:22
Other times it's way more effective to solve in code.
-
20:25
For example let's say you're working on transitions.
-
20:27
A Photoshop mockup is never gonna convey a transition properly because it's static.
-
20:32
A Photoshop mock up is a picture of a website, not a website.
-
20:35
And so, a problem like that, the logical place
-
20:38
to figure it out is in code in the browser.
-
20:41
Maybe it's even easier to go back and figure out in sketch
-
20:43
form if you're just trying to get layout problems figured out right.
-
20:46
But, there's no reason to be in Photoshop just because
-
20:49
this is the part of the process where we do Photoshop.
-
20:52
Just pick the one that's best for you, where you are right then.
-
20:55
And you're gonna end up with much better results.
-
21:00
So let's take a look at a couple
-
21:02
of examples of why prototyping can be so effective.
-
21:06
First one is gonna be Google Glass.
-
21:08
I'm sure you've seen, there's been a couple
-
21:10
people walking around wearing it today and yesterday.
-
21:12
I actually wish I'd gotten a chance to take a look through it
-
21:15
yet, somehow I've never encountered one but i hear they're kind of interesting
-
21:21
tom chi who lead prototyping on the project for google was kind
-
21:24
enough to do a write up on their process and he provided some
-
21:26
really great insights on his project so the quote we have here
-
21:29
we were working with the hud literally on my first day at work.
-
21:32
And we're learning a tremendous number of
-
21:34
things that you couldn't possibly just guess or
-
21:36
estimate or print out on a spreadsheet, or a project map, and that sort of thing.
-
21:39
That's because the first thing they did
-
21:41
was assemble this disgusting conglomeration of wires
-
21:45
and pieces of little plexiglass and things like that that told them if this could
-
21:48
even work, whereas maybe, even as early as recent as a couple years before
-
21:53
that they might have actually just burned
-
21:54
a thousand engineering hours talking about it instead.
-
21:58
This is a picture of what they built, this is the
-
22:00
first sketch for what would be the first prototype of Google Glass.
-
22:04
It's basically pieces of plexiglass suspended
-
22:07
from coat hangers hanging from a whiteboard
-
22:09
with some little hairbands attached to strings so that the use can keep
-
22:13
their hands down by their side and trigger actions, changing what was on
-
22:17
the screen which was projected by a
-
22:19
Netbook and a crappy little Piko projector.
-
22:21
But that told them that Google Glass could work.
-
22:23
That you could actually put a little, tiny monitor right in front
-
22:26
of somebody's eyes and accurately project things unto it and have them be
-
22:29
able to react to them while still interacting with the environment around
-
22:32
them and the best part is, it was incredibly cheap to do that.
-
22:36
They just grabbed stuff they had lying around the office and assembled it.
-
22:40
So, another trick they figured out.
-
22:42
Your ears can take a lot more weight than
-
22:44
your nose, so if you can create a system where
-
22:46
the ear becomes a fulcrum, then the perceptual weight disappears
-
22:49
and this took me about two hours to figure out.
-
22:52
So this was one of the vital tricks they learned that made it more wearable.
-
22:56
If they had taken all of the electronic components and the battery
-
22:59
and all that stuff and shoved it right up here where the
-
23:01
computer actually is in Google Glass, then somebody would have had this
-
23:04
thing sliding slowly down their nose every couple of minutes, all day long.
-
23:09
And maybe if you're demoing the product for
-
23:11
five minutes, that doesn't seem like a big deal.
-
23:13
But the first time you have to
-
23:14
wear it around that's gonna become intolerably annoying.
-
23:18
So, using modelling clay and coat hangers and some paper,
-
23:22
they just moved some of the weight backwards to a
-
23:24
place that could handle it much more easily and all
-
23:26
of a sudden, the perceptual weight of Google Glass disappeared.
-
23:30
Two hours of work with children's
-
23:32
construction materials solved a huge engineering problem.
-
23:38
So this is the second example I want to go through.
-
23:40
This is a game called Encantor, which we worked on fresh tilled soil.
-
23:44
This is a real world massive multiplayer RPG
-
23:47
game and the gist of it is that players
-
23:50
are in contact with encantors who come from, and
-
23:54
they're basically wizards from like, five lost magical realms.
-
23:58
And so they figured out how to reach into our
-
24:00
world with magic and so, people who play the game,
-
24:04
they have a phone, which is how they communicate with
-
24:06
their Encantor and they also have a Bluetooth magic wand.
-
24:11
Harry Potter style.
-
24:13
It's, the game was just so, so fucking cool.
-
24:19
I don't think i could've ever brought myself to play it because i don't think i
-
24:22
would want to run around the streets of
-
24:24
Boston with a wand casting lightning bolts at people.
-
24:27
But i know a whole bunch of people i talk to who
-
24:29
immediately wanted to know when it was being released and were very excited
-
24:32
about it when we were engaged to do is design an interaction model
-
24:36
where we keep users involved in the real world as much as possible.
-
24:40
Because the thing is, what they're doing is interacting with
-
24:42
these digital sprites and ghouls and things like that and you
-
24:46
can't just see them running off over in the distance,
-
24:49
you have to look down at your phone and see them.
-
24:51
But the point of this game is keeping people in the real world.
-
24:53
So how do you design an interface that supports that?
-
24:57
My colleague Mark Rambo, he designed the interface for a playable demo
-
25:03
and this was our first prototype.
-
25:06
The client came into the first meeting with us, and they had
-
25:09
already come up with their own version of interaction model for this.
-
25:14
The way the user would navigate the interface, cause they would have
-
25:17
this phone strap to their wrist, and they would bump their fist left
-
25:22
or right or forwards or backwards to move around the interface, and, they
-
25:26
are pretty convinced that this would be the best way to do it.
-
25:29
So while we are talking, it sounded to me like you would be
-
25:31
a problem so what I did was i downloaded an accelerometer app from
-
25:35
the app store and then I strapped my iPhone to my wrist and
-
25:38
then I verified that you could in fact get unique signatures on the accelerometer.
-
25:43
So we learned two things the first is that you could actually
-
25:45
navigate that way and the second is that if we did set
-
25:49
it up that way you'd have groups of children running around Boston
-
25:51
common looking like rejects from the Jersey shore fist bumping the entire time.
-
25:55
And we really didn't want that we thought
-
25:57
it would look ridiculous and would be kind of
-
25:58
tiring and weird so we started casting a
-
26:02
vote for a different way of dealing with it.
-
26:04
So, the game also involves, as I mentioned before, a bluetooth magic wand,
-
26:08
which attaches to the phone and it allows the user to cast spells.
-
26:13
So we needed to test the spell
-
26:15
versions, and then make some recommendations to them.
-
26:18
Originally, every single spell in the game, and there were dozens of them.
-
26:22
had its own unique gesture that the wand was supposed to pick up.
-
26:25
So, whatever combination of things you wanted to cast, you had to
-
26:28
learn a movement for that, so you go throw them at your friends.
-
26:32
You can also modify them, by chaining the different spell sequences together.
-
26:37
And I'm sure as you can imagine, this gets immeasurably complex.
-
26:40
We had to make sure this worked, and if it
-
26:42
didn't work, we had to figure out how to fix it.
-
26:45
But.
-
26:45
The company could not spare any of the wands for us.
-
26:49
They had these beautiful vacuum formed plastic
-
26:51
wands that they were going around to investors
-
26:53
with to try and sell the game on, so we had to make our own.
-
26:59
That's my wand.
-
27:01
I suck at wand making, in case you can't tell.
-
27:03
It's a stick and duct tape and this little off the
-
27:07
shelf bluetooth module that's basically like the guts of a Nintendo Wii.
-
27:11
I just taped everything together.
-
27:13
And we found out is, that once you take the bluetooth module which
-
27:16
is fairly high fidelity on it's own and you tape a stick to it.
-
27:20
The stick sort of even's out a lot of the
-
27:22
differences which allows the bluetooth module to determine what failure casting.
-
27:26
And all of a sudden everything just goes completely wrong.
-
27:29
Just completely changes the physics of the entire thing.
-
27:33
So we learned that with a stick, which I was pretty happy about.
-
27:36
And I have to keep this on my desk as a trophy because of how atrocious it is.
-
27:40
I'm required now.
-
27:42
So, this pushed us to a solution where the user has a spell bag instead.
-
27:46
This is the spell bag, down at the bottom of their, Their screen.
-
27:51
At any given time they see four to six icons at the bottom of the screen
-
27:54
corresponding with their spells and all they have
-
27:56
to remember for gestures is one through six.
-
28:01
If they cast one, first spells goes, if they cast four, fourth spells goes.
-
28:06
Very simple.
-
28:08
You could even swipe the spell bag left and
-
28:10
right as you gain more spells and grew in levels.
-
28:12
So, you might have another six set of spells that you like to use regularly.
-
28:16
You swipe over and all of a sudden one through six are remapped.
-
28:19
We found people could remember this fairly easily and
-
28:22
people also tended to use the same small set
-
28:25
of spells so it's much easier to give them
-
28:27
a few gestures to remember that they could map themselves.
-
28:30
Then it was to have them remember this
-
28:32
really complex, borderline language for assembling things together.
-
28:37
When
-
28:39
we got to designing the rest of the UI, we took advantage of the device API
-
28:44
in Firefox for Android so that we could
-
28:46
fake full screen native apps in the browser.
-
28:49
So these would do things like vibrate to provide feedback
-
28:51
to the users, just like the native app eventually would.
-
28:54
And what this did was, it helped us validate a swipe-based UI, where the phone
-
28:58
was the central play hub, and support screens
-
29:01
were accessed with quick swipes in different directions.
-
29:04
So instead of having to look down and hit very precise buttons.
-
29:07
You could just swipe the phone in a different
-
29:09
direction without even paying any attention to it, and
-
29:11
you would trigger different parts of the interface, We
-
29:14
also used web sockets to tie the two interfaces together.
-
29:17
So, what we have here is a large screen
-
29:20
with some options that a controller can click on.
-
29:22
Somebody would sit in a different room with this,
-
29:24
and then the test user would have a phone.
-
29:26
And they would see this interface.
-
29:28
Depending on what the user did on the phone,
-
29:31
the interface on the test screen would change to match.
-
29:34
And if the user controlling the test screen
-
29:36
wanted to change the scenario, they would just click
-
29:39
on a different link, which would cause the user's
-
29:41
phone to react and go to a different state.
-
29:42
So we were basically able to build this in sort of like web sockets
-
29:46
Dungeons and Dragons game with this diabolical
-
29:48
dungeon master sitting in a different room.
-
29:50
Instead of a horrifying complexity data base and bunch of algorithms for
-
29:53
how things are suppose to behave, which are not things were good at.
-
29:56
So, this was incredibly cheap and easy for us to assemble.
-
30:00
And we were able to learn a lot from.
-
30:03
So, wanna wrap up things up a bit for you.
-
30:07
This are the important points of my talk today.
-
30:11
Wants you to sketch a lot because it's quick and efficient.
-
30:14
I want you to stop wire framing and start prototyping.
-
30:17
That is incredibly important.
-
30:18
Test early and often, that's why you wanna get the prototypes.
-
30:22
We're gonna void comps for every screen and
-
30:24
state now because we can work more efficiently.
-
30:27
We're going to eliminate all the redundant parts of our workflow as much as possible.
-
30:31
And we have to remember process is not a straight line.
-
30:34
A good process jumps all over the place so that you use the tools you have available
-
30:37
to you to solve the problem at hand in the best way possible at any given time.
-
30:42
So thank you [SOUND] It looks like I have
-
30:50
time for questions if anybody has any.
-
30:57
>> [INAUDIBLE] But you, you talk about.
-
31:03
[INAUDIBLE] comps to get the clients sign-off [INAUDIBLE] etc, But isn't
-
31:08
it part of the testing also that [INAUDIBLE] argument with the test.
-
31:12
>> Mm.
-
31:13
>> Like you prove something works, or you prove something didn't [COUGH] [INAUDIBLE]
-
31:19
>> Yeah, I mean.
-
31:21
We're focused in our process a lot more on the
-
31:23
functionality of the prototype displays, so when we're testing the
-
31:27
prototype, and we get res, the results we're looking for
-
31:30
outta that, that validates a lot of our decision making.
-
31:32
We've been able to prov, persuade our clients of
-
31:34
in many cases that well, visual design isn't purely decoration.
-
31:38
It's less important then the functionality then were actually testing.
-
31:41
Which is how we get the way with not being tied to mock up so much.
-
31:44
And that when they have us doing mock ups, there really just
-
31:47
paying for us to burn time on the wrong part of the process.
-
31:50
It's going to be much more important to them if there users are actually
-
31:53
able to use something, than if the screens we gave them earlier on are prettier.
-
31:57
And on.
-
31:58
I'm not sure I'm sorry if that answered your question or not.
-
32:00
But.
-
32:01
Yep.
-
32:02
All right.
-
32:02
Anybody else?
-
32:03
Yeah.
-
32:05
>> Hi, I'm wondering how has it been working with clients when you have
-
32:10
been able to get [INAUDIBLE] how have you been able to,
-
32:16
talk to clients and make sure that they're okay with having that many people?
-
32:21
Do you ever get push back and if so how do you deal with that?
-
32:26
>> I'm sorry I missed the middle of that, could you say it one more time?
-
32:29
>> Oh.
-
32:29
When you have [UNKNOWN] >> Hm-mm.
-
32:32
>> [UNKNOWN].
-
32:33
>> Oh, OK.
-
32:33
>> [UNKNOWN] talking about cost and having [UNKNOWN]
-
32:39
early on.
-
32:39
How do you [UNKNOWN].
-
32:42
What are some [UNKNOWN].
-
32:45
>> We basically don't give them the option.
-
32:48
What we tell them is, you hired us for a reason,
-
32:50
our process is very effective, you've vetted us through other channels.
-
32:54
We do good work by working this way, and it's not like developers
-
32:59
in the room at the beginning are a line item that saves you money.
-
33:01
We're gonna charge you the same amount of money regardless of who's in the room
-
33:04
at the beginning, so you might as well
-
33:05
have the developers there because they're incredibly helpful.
-
33:08
I know not everyone has the luxury of doing thing, things that way,
-
33:11
but we thought at first that that was gonna be really stressful as well.
-
33:15
And it turns out people just go,okay, we're good.
-
33:19
>> [INAUDIBLE]
-
33:20
>> It's mostly the part where you tell them
-
33:22
it's going to cost the same, that fixes it.
-
33:24
[LAUGH] >> [INAUDIBLE].
-
33:27
To a project if they have like one project [INAUDIBLE] and
-
33:30
then another project in development which could go to that company?
-
33:36
>> Probably not.
-
33:37
We do a lot, we're moving a lot towards strategy these days.
-
33:39
So a lot of the beginning part of the process, into the prototyping.
-
33:44
So there are definitely some projects where we don't handle the
-
33:46
final visual design or we don't do the frontend development for it.
-
33:50
But that's part of why we're focusing a bit more on prototyping these
-
33:53
days because we want to make sure that whatever part of the process we're
-
33:56
involved in we're delivering something that communicates
-
33:58
really well to the final team what
-
34:00
they're supposed to be building and is gonna be most effective for the users.
-
34:04
>> So a developer actually has a place in
-
34:08
that first project even though it's not a developer project?
-
34:11
>> Oh yeah, yeah.
-
34:11
actually, my co-worker Tim sitting right behind you, he's our development director.
-
34:15
And what he likes to say, is that everyone of
-
34:17
fresh soils and experience designer, just some people's tool and Photoshop.
-
34:21
Another people's tools are code.
-
34:23
[SOUND] Any other questions [SOUND] All right, thank you everybody.
-
34:31
[APPLAUSE]
You need to sign up for Treehouse in order to download course files.
Sign up