My name's Steve Hickey, I'm a user

experience designer at Fresh Tilled Soil just

outside of Boston and today I'd like to talk you a bit about prototyping.

Before I jump into that, though, let's get to know you a little bit.

Anyone in the room who's a designer could you raise your hands?

Okay good.

Anyone who's a developer could you stand up, hop on your

left foot, and spin in circles for a bit for me?

Okay.

I figured you'd be used to requests like that from designers.

Okay.

And how many people in the room would classify the way they work as water fall?

Anybody brave enough to admit it?

Okay.

Just in case, none of you remember what that is.

Everyone's whose moved past it, that's the one two three I've gotta do

this first and then that and at the end you launch your product.

Now, could anyone who works agile and lean raise your hand.

yep, okay, keep em up.

Keep the agile and lean hands up for a second.

Good amount.

Sorry.

Sometimes I gotta call B.S. on that.

If you're not as good at high school

Spanish as me, I did subtitle that for you.

It's ok though.

If you do have a bit of waterfall in your process, it's not really your fault.

It's the kinda thing that got taught in design schools.

Big firms work this way, smaller agencies that sprang out

of them work this way and it kinda became a habit.

The thing is, it really doesn't make a lot of sense

to work that way, with the digital products that we work on.

I can sort of understand where it came from from the

print world, where you have fixed production points and things like that.

But, the great thing about the web is it allows us to put something in front of

the user, and see how they react, really quickly

and we can do it really cheaply as well.

We have infinite ability to fix and redo things

and there's a lot of power and opportunity in that.

We should be taking advantage of it.

Instead we've been showing our work to users at

the logical point that springs out of a waterfall process,

which is unfortunately right here at the end when you

launch the product and you think you've done everything else.

And here's what happens when that's the first time they see it.

All the feedback you get is complaints.

If you want a great, big list of things that you that you did wrong

once it's too late to fix them, that was a really great way to work.

Thing is, because, just because your coworkers and your boss thought you did a

great job throughout the process, it doesn't

mean that you actually did a good job.

You don't design for your peers, you

design for your users, users don't appreciate

the subtlety of your color choice if they can't find contact info on the website.

They don't notice the cleverness of you type pairings.

What they notice is that they can't figure out how to cancel an order.

So we need to find a way to avoid these problems and it's pretty simple.

We're just gonna show users the product earlier in the process.

We're gonna do it several times and we're gonna

listen to them every time we show it to them.

When we expose our work to users early and often, and we're going to

do our best to learn from what they tell us when they do that.

But this doesn't fit well into the old process.

Waterfall, for designers creates one very specific deliverable.

Very Pretty BULLSHIT.

It's entirely focused on making things look good, and this

is really the wrong thing for us to focus on.

A lot of us may be visual designers, but

whether or not the product is pretty is actually kind

of unimportant in the grand scheme of things and

it's surprising how often we lose sight of that fact.

Especially cause here in how robotically we spoke the two

sayings on the next two slides were about to show you.

So, sorry about this one.

There really should be a limit on Steve Jobs quotes at conferences,

I'm pretty sure that Matt from Gooza just completely took up the

entire quote the other day during his talk, but design is not

just what it looks like and feels like, design is how it works.

Here's the other one.

Form ever follows function.

Pretty much the same thing.

But with every time you set or agreed with some form of one of

those statements, have you really, ever really

ever stopped to think about what they mean?

The greatest sin of designers is our attachment to making things

look good and as a result, we've forgotten our own commandments.

So we have the ability to focus in on tiny details, to sacrifice every other

consideration just to get the smallest things correct,

and sometimes and for some people, depending what

your role on the team is, that's a really powerful thing to do, but a lot

of times all it really causes is for us to burn time on the wrong stuff.

Waterfall pushes us naturally towards this problem

and we need to be better than that.

So, let's take a look at how we can retro fit our process to help us out a bit.

So, first thing's first in any project what we really need to

do is become familiar with the problems and needs of our users.

Everyone has a completely different way of doing this.

At my company we do something called a deep drive.

Google Ventures has the product design sprint.

It's all based on personal presence, time, resources.

You know, the old stuff.

Figuring out what you're gonna do to do this is beyond

the scope of my talk but let's agree on one premise.

If you feel like you understand the

problem, it's time to move into making something.

I've always found that a natural byproduct of this stage is a great deal of sketching

and white boarding, you're gonna end up with

a lot of really rough ideas for interface elements

and functionality, and this kind of thing is

rarely complete at this stage, but a good

idea is to try to take some of this and just build onto them a little bit.

To see if you can get some tiny piece of product out of them to

learn something, no matter how limited in

scope and functionality it is at that point.

Thing is you don't wanna make them perfect right

then, what we're going here for here is good enough

because until you put it in front of the user

you have no way of knowing if it's just right.

No Photoshop, no Fireworks, no Sketch, not right now.

We wanna keep things rough, so, I know, from my experience, that we all

experience the desire to perfect things, but this in reality is a delaying tactic.

The longer we go without showing somebody else our

work, the more we risk making really serious errors.

Going down wrong paths, wasting a lot of time.

Well, we don't wanna work that anymore.

So, the old way, we would move onto wire frames after

we got a good understanding of how how the users worked.

But do you think we're gonna keep doing that?

No, cuz, one very simple reason, wireframes are a trap.

They trick us into thinking about the wrong

thing, in too much detail, at the wrong time.

We're not going to do them anymore, because they're way,

way, way too specific for this point in the process.

Instead what we can do is make a clickable prototype and in

fact, I would advocate that we

can completely replace wireframes with prototyping.

What you see here is an app that

my company did for a pharmaceutical sales company.

This was designed to help their reps to know what they

were gonna do everyday and what we did was old process.

Move through sketching.

Thought we had everything right.

Moved into wireframes, made some exhaustively

detailed documentation and then, we had a

couple days left before we actually had to go talk to the client.

So, just on a whim, I tossed it onto an iPad and

just to see what would happen if I started clicking on things.

Turns out the navigation was terrible and I didn't know that.

I burned two weeks on exhaustively

documenting something that didn't work at all.

But I found that out really quickly.

I had a couple days to fix it and so I was able to put

something together that function properly, put it

on the iPad, walk in the clients office.

Turns out they actually kinda love this shit.

You hand a client something right from the get go that

actually works, that you can click on, that you can do things.

They tend to think you're a wizard of some sort.

They thought that we had actually made the entire applica, whoa.

[LAUGH] Was that an earthquake?

They thought that we had actually made the application for them and they were pretty

excited to play with it a bit and give us really great feedback early on.

The

goal here was to get to something testable as quickly as possible.

Our first test was when I tried the first version on iPad and it was terrible.

So we fixed it, the second test was when we gave it to

the client and they could walk around with it and understand how it works.

The third test was when we refined that a little bit.

We're able to put it in front of a couple

of their sales reps and see how they did and

from then on we were able to run more tests

every couple of days as we improve and refined things.

And that was a lot better than just a stack of PDFs that were going

to go off to a development team without

any validation whatsoever, so, this is what I

think beyond a reasonable doubt is the most

important thing you can do to make sure

you're building the right thing in the right

way is to prototype as early as possible.

Instead of checking off 1, 2, 3 on some

sort of list until the client is happy, what

we're gonna do is make really rough, really dirty

functional prototypes and we're gonna do a lot of them.

We're gonna find out if they make users happy.

We're gonna fix the things that don't and then

we're gonna keep doing it a few more times.

Ideally the last prototype is well on its

way to being some sort of production ready code.

A good enough artifact to actually communicate to the team

building the product exactly how it's gonna work and the great

news is there are now some great tools out there

that will help you build functional prototypes as quickly as possible.

So I talked about Sketches a little bit earlier and how much they can convey.

There are a couple of tools, that'll actually let you

take those sketches and turn them right, into the clickable prototypes.

This is a good one called POP, for prototyping on paper.

It's an iOS and Android app.

It allows you to photograph your sketches.

You can add clickable areas to them, that'll

help progress to other sections of the mock-up.

You can create an entire prototype in a matter of minutes just from

the sketches you've done on a white board or on a piece of paper.

This will actually also incidentally work with high fidelity

mock ups that have been uploaded into your photo gallery.

So you can make this better and better as you move along.

This is mobile only though, it's restricted

to small screen output at the moment.

InVision App has become really popular lately.

We started using in my company a few months ago, I've talked

to a lot of other designers and they've been really happy with it.

We're very excited to keep going with this and see how

it develops but some of the features you get out of

this are the ability to click and drag to create hot

spots and quickly pull links together in a visual interface online.

You can get transition animations for mobile devices.

You can determine scrolling versus non-scrolling areas.

You can do both web and native prototypes so there's full range here.

They can be installed on mobile devises directly on the home

screen so you can actually mimic a native app very effectively.

They have a dragon drop image loader or you can sync with a folder in Dropbox, so

instead of having to upload new files every

time you change something, it'll just sync them automatically.

And one of the best parts, I think, is results can be annotated by members of

the team and commented on, and they can be commented on by the clients as well.

You can send them a private link that other people can't find.

They can comment in line in the prototype, and then you have

a checklist embedded in your artifact that you can use to keep working.

I think this has made a huge difference in how we work.

We've been using it on most of our projects lately.

There's also some great competitors to it.

Flinto and Marvel come to mind, so I'd recommend checking a few of those out.

But these make a huge difference in workflow for us.

There's also all the old stuff.

The things you were using to make wire frames before.

Every one of these pieces of software, I

think with Balsamiq, Axure, InDesign, Keynote and PowerPoint,

give you the ability to create hotspots and

click from slide to slide in different ways.

So if you're already really used to one of

these pieces of software and you wanna stick with it.

You want to get the speed that you've

learned out of it and you know, maybe you're

arguing with a project manager, about how much

time it's gonna take, to learn the new tool.

They can't really argue with you, doing it the way you were already doing it,

and spending a few extra minutes to make

something you know, communicate better to the client.

So, I would recommend looking at one of these, if you're

not quite ready to jump over to a new tool yet.

There's also good old HTML, CSS, and JavaScript.

You can write a really good prototype, a really rough prototype, really

quickly if you have a lot of experience and know what you're doing.

There's a lot of frameworks and tools that'll allow you to do this quickly.

So Bootstrap, Foundation, Sass, and let's you write CSS a little bit faster.

There's even built in functionality from Dreamweaver and Fireworks

you know, if you're into that sort of thing.

The great i, the great thing about all of those though, is it allows you

to get your code out quickly it allows you to get your idea out quickly.

And if you're disciplined in how you write

your code, you can even evolve as things go

along so that your final prototype is production

ready instead of having to go through another step.

There's also another great side effect of using JavaScript in your prototypes.

It's that you can start faking database interactions really quickly.

I suck at databases and it's actually probably fair

to say that I worse than suck at them because

I've never successfully gotten one to work long enough

for me to determine if I could figure it out.

They just don't work for me.

But I can write really bad JQuery as you can see here.

That's really easy for me.

So you can use the HTML5 local storage API with

JavaScript to load data in and spit it back out.

You can even actually take user modifications throughout a

session, store them as if it's a database and allow

the interface to react to them, so they can, you

can get a much better testing experience out of it.

This also gives you a really great excuse to involve developers from the beginning.

I've heard through different talks this week,

a, about many different ways of working.

Some people still hand off PSDs to a developer later on in the process.

Other people are lucky enough to

start working with developers from the beginning.

That's how we do it at my company.

That's how we advocate people do it and this is just a really great excuse

to say you need a developer from day one so you can collaborate with them.

But if you don't get to work from the,

with the developer from day one, if you're gonna

have to hand this off eventually, this is a

good way to hold everyone accountable towards what you developed.

As a prototype gets refined, as all the little

interactions get smoothed out and all the niceties get figured

out, the client is going to fall in love with this in a way they can't fall in love

with a static mock up and when the devs

come in to handle it, they now have an example

of what needs to be built, a very clear and

communicated example the client loves and is bought into already.

So this helps hold everyone on the team

accountable for the final quality of the product.

So, going into detail on usability testing would take

a lot longer than I have available for this talk.

The only really valuable piece of advice I have to give you here

is just to buy this book and read it six or eight times.

It's a really great book.

It's got some good tips like tricking people into going into user testing

with boxes of donuts and things like that, so Steve Krug knows what

he's talking about, it's well worth the 20 bucks or so, and I

will reinforce one point from his book again, test early, and test often.

The entire reason we're gonna be prototyping is so that we can do

that, so that we can learn as much as possible before we launch.

[BLANK_AUDIO]

All right, so, what about web design?

I've said a couple of times that we're way too worried about you

know, things being pretty, and we need to concentrate on more important things.

But visual design does come into it at some point.

A polished visual design is part of the

experience and helps users understand what's going on.

So, how do we work an effective visual design process,

like what we've become used to, into our new prototyping world?

To do that, we're gonna have to admit an unpopular truth first.

Mock-ups are completely and utterly useless.

See, Keanu's confused.

Look, a Photoshop mockup does one thing really well,

it makes clients feel comfortable and if your client wants

to burn money on being comfortable instead of getting

the best product possible for their users, then that's great.

Just do Photoshop mockups all the time, and work the way you used to work.

But the problem I have was not, with them is that I think it

forces you to make really complex final

visual decisions way too early in the process.

And because the level of polish and consistency expected in

visual comps is so high, you're gonna burn a ton

of time getting those little details right, because the client

will notice every time something is a couple of pixels off.

We've all encounter that.

Somethings just like a buttons five pixels too narrow and it's

the only thing the client sees in the entire review process.

It's really annoying.

But the thing is we're not gonna totally avoid comps.

We're just gonna be way smarter and more efficient about them.

So the sketch phase is actually gonna accomplish a lot

of the functionality and layout problems that you've been dealing

with and as you move through some of the early

prototyping stuff, you're gonna get more of that figured out.

So, you really don't have to go into

full exhaustive detail with that in Photoshop, what you

would do wanna do, is figure out the

visual style, and Photoshop is pretty good for that.

You don't have to make a full mockup

though if you use a couple of different tools,.

So, one thing I've started doing is what I'm calling UI studies.

If you look at the notebooks of master painters from

the renaissance up to today, it's not like they set

down, it's not like Da Vinci sat down and painted

forty Mona Lisa's until the last one was just right.

Like you go through notebooks and you'll find

little details of pieces of the final composition.

You know, he'll spend months figuring out how to

draw two hands and their relationship to each other,

something like that, and then you have this entire

collective group of interface, well not interface in his

case, but little experiments that combine to form the

final whole and I've started trying to do stuff

like that with Photoshop and with tools like code

pen and any variety of other things available to me.

Like, one thing that works for me is take in like a half size canvas in

Photoshop or sketch and doing a really zoomed

out experiment with final look and feel because

it keeps me out of the little tiny details so that I can refine later but

it gives me a great idea of what this is gonna feel like to a user overall.

And I can also work on various break points next

to each other, this and start to give an idea

of how things shuffle around for a responsive design, and

when I'm having problems with specific interface elements a lot

of time I'll try to work on those a bit

in isolation from the rest of the project, just to

try to figure out the specific problems I'm having there

before I reincorporate them back into the prototype as a whole.

Another useful method would be style tiles.

So maybe you get some of the look and feel stuff out of the

way and then you wanna start experimenting

with more detail in your interface elements.

So I might assemble an example of part of the interface and start dealing with that.

You know, button radiuses and shadows and typographic relationships.

I think that's really useful instead of

having 700 different Photoshop files that are all

attempting to copy the exact same distance between

the bottoms of paragraphs and things like that.

If I just have one good example of how it's supposed to

happen universally, and then that into,

that gets incorporated back into a prototype?

I've also been working on designing in the browser a lot more.

Like I said, if I want the same spacing at the

bottom of paragraphs, it's a lot easier to go into the inspector

and just tweak that value in Chrome, instead of going back through

my 700 Photoshop files and trying to make sure it's consistent everywhere.

I can actually do a lot of

really simple effective refinement, that will apply globally.

And if you get the settings right in chrome it's even

possible to save those refinements directly back to your CSS files instead

of having to copy and paste or remember them, so the

inspector can be a really powerful tool once you get comfortable with

it, but I think the overall point I want to make here though, is

what you want to do is use the right tool for the job at hand.

Throughout your entire visual design process, you're going

to come across a great variety of problems.

Sometimes your problem, the most effective way to

solve it is gonna be a Photoshop mockup.

Other times it's way more effective to solve in code.

For example let's say you're working on transitions.

A Photoshop mockup is never gonna convey a transition properly because it's static.

A Photoshop mock up is a picture of a website, not a website.

And so, a problem like that, the logical place

to figure it out is in code in the browser.

Maybe it's even easier to go back and figure out in sketch

form if you're just trying to get layout problems figured out right.

But, there's no reason to be in Photoshop just because

this is the part of the process where we do Photoshop.

Just pick the one that's best for you, where you are right then.

And you're gonna end up with much better results.

So let's take a look at a couple

of examples of why prototyping can be so effective.

First one is gonna be Google Glass.

I'm sure you've seen, there's been a couple

people walking around wearing it today and yesterday.

I actually wish I'd gotten a chance to take a look through it

yet, somehow I've never encountered one but i hear they're kind of interesting

tom chi who lead prototyping on the project for google was kind

enough to do a write up on their process and he provided some

really great insights on his project so the quote we have here

we were working with the hud literally on my first day at work.

And we're learning a tremendous number of

things that you couldn't possibly just guess or

estimate or print out on a spreadsheet, or a project map, and that sort of thing.

That's because the first thing they did

was assemble this disgusting conglomeration of wires

and pieces of little plexiglass and things like that that told them if this could

even work, whereas maybe, even as early as recent as a couple years before

that they might have actually just burned

a thousand engineering hours talking about it instead.

This is a picture of what they built, this is the

first sketch for what would be the first prototype of Google Glass.

It's basically pieces of plexiglass suspended

from coat hangers hanging from a whiteboard

with some little hairbands attached to strings so that the use can keep

their hands down by their side and trigger actions, changing what was on

the screen which was projected by a

Netbook and a crappy little Piko projector.

But that told them that Google Glass could work.

That you could actually put a little, tiny monitor right in front

of somebody's eyes and accurately project things unto it and have them be

able to react to them while still interacting with the environment around

them and the best part is, it was incredibly cheap to do that.

They just grabbed stuff they had lying around the office and assembled it.

So, another trick they figured out.

Your ears can take a lot more weight than

your nose, so if you can create a system where

the ear becomes a fulcrum, then the perceptual weight disappears

and this took me about two hours to figure out.

So this was one of the vital tricks they learned that made it more wearable.

If they had taken all of the electronic components and the battery

and all that stuff and shoved it right up here where the

computer actually is in Google Glass, then somebody would have had this

thing sliding slowly down their nose every couple of minutes, all day long.

And maybe if you're demoing the product for

five minutes, that doesn't seem like a big deal.

But the first time you have to

wear it around that's gonna become intolerably annoying.

So, using modelling clay and coat hangers and some paper,

they just moved some of the weight backwards to a

place that could handle it much more easily and all

of a sudden, the perceptual weight of Google Glass disappeared.

Two hours of work with children's

construction materials solved a huge engineering problem.

So this is the second example I want to go through.

This is a game called Encantor, which we worked on fresh tilled soil.

This is a real world massive multiplayer RPG

game and the gist of it is that players

are in contact with encantors who come from, and

they're basically wizards from like, five lost magical realms.

And so they figured out how to reach into our

world with magic and so, people who play the game,

they have a phone, which is how they communicate with

their Encantor and they also have a Bluetooth magic wand.

Harry Potter style.

It's, the game was just so, so fucking cool.

I don't think i could've ever brought myself to play it because i don't think i

would want to run around the streets of

Boston with a wand casting lightning bolts at people.

But i know a whole bunch of people i talk to who

immediately wanted to know when it was being released and were very excited

about it when we were engaged to do is design an interaction model

where we keep users involved in the real world as much as possible.

Because the thing is, what they're doing is interacting with

these digital sprites and ghouls and things like that and you

can't just see them running off over in the distance,

you have to look down at your phone and see them.

But the point of this game is keeping people in the real world.

So how do you design an interface that supports that?

My colleague Mark Rambo, he designed the interface for a playable demo

and this was our first prototype.

The client came into the first meeting with us, and they had

already come up with their own version of interaction model for this.

The way the user would navigate the interface, cause they would have

this phone strap to their wrist, and they would bump their fist left

or right or forwards or backwards to move around the interface, and, they

are pretty convinced that this would be the best way to do it.

So while we are talking, it sounded to me like you would be

a problem so what I did was i downloaded an accelerometer app from

the app store and then I strapped my iPhone to my wrist and

then I verified that you could in fact get unique signatures on the accelerometer.

So we learned two things the first is that you could actually

navigate that way and the second is that if we did set

it up that way you'd have groups of children running around Boston

common looking like rejects from the Jersey shore fist bumping the entire time.

And we really didn't want that we thought

it would look ridiculous and would be kind of

tiring and weird so we started casting a

vote for a different way of dealing with it.

So, the game also involves, as I mentioned before, a bluetooth magic wand,

which attaches to the phone and it allows the user to cast spells.

So we needed to test the spell

versions, and then make some recommendations to them.

Originally, every single spell in the game, and there were dozens of them.

had its own unique gesture that the wand was supposed to pick up.

So, whatever combination of things you wanted to cast, you had to

learn a movement for that, so you go throw them at your friends.

You can also modify them, by chaining the different spell sequences together.

And I'm sure as you can imagine, this gets immeasurably complex.

We had to make sure this worked, and if it

didn't work, we had to figure out how to fix it.

But.

The company could not spare any of the wands for us.

They had these beautiful vacuum formed plastic

wands that they were going around to investors

with to try and sell the game on, so we had to make our own.

That's my wand.

I suck at wand making, in case you can't tell.

It's a stick and duct tape and this little off the

shelf bluetooth module that's basically like the guts of a Nintendo Wii.

I just taped everything together.

And we found out is, that once you take the bluetooth module which

is fairly high fidelity on it's own and you tape a stick to it.

The stick sort of even's out a lot of the

differences which allows the bluetooth module to determine what failure casting.

And all of a sudden everything just goes completely wrong.

Just completely changes the physics of the entire thing.

So we learned that with a stick, which I was pretty happy about.

And I have to keep this on my desk as a trophy because of how atrocious it is.

I'm required now.

So, this pushed us to a solution where the user has a spell bag instead.

This is the spell bag, down at the bottom of their, Their screen.

At any given time they see four to six icons at the bottom of the screen

corresponding with their spells and all they have

to remember for gestures is one through six.

If they cast one, first spells goes, if they cast four, fourth spells goes.

Very simple.

You could even swipe the spell bag left and

right as you gain more spells and grew in levels.

So, you might have another six set of spells that you like to use regularly.

You swipe over and all of a sudden one through six are remapped.

We found people could remember this fairly easily and

people also tended to use the same small set

of spells so it's much easier to give them

a few gestures to remember that they could map themselves.

Then it was to have them remember this

really complex, borderline language for assembling things together.

When

we got to designing the rest of the UI, we took advantage of the device API

in Firefox for Android so that we could

fake full screen native apps in the browser.

So these would do things like vibrate to provide feedback

to the users, just like the native app eventually would.

And what this did was, it helped us validate a swipe-based UI, where the phone

was the central play hub, and support screens

were accessed with quick swipes in different directions.

So instead of having to look down and hit very precise buttons.

You could just swipe the phone in a different

direction without even paying any attention to it, and

you would trigger different parts of the interface, We

also used web sockets to tie the two interfaces together.

So, what we have here is a large screen

with some options that a controller can click on.

Somebody would sit in a different room with this,

and then the test user would have a phone.

And they would see this interface.

Depending on what the user did on the phone,

the interface on the test screen would change to match.

And if the user controlling the test screen

wanted to change the scenario, they would just click

on a different link, which would cause the user's

phone to react and go to a different state.

So we were basically able to build this in sort of like web sockets

Dungeons and Dragons game with this diabolical

dungeon master sitting in a different room.

Instead of a horrifying complexity data base and bunch of algorithms for

how things are suppose to behave, which are not things were good at.

So, this was incredibly cheap and easy for us to assemble.

And we were able to learn a lot from.

So, wanna wrap up things up a bit for you.

This are the important points of my talk today.

Wants you to sketch a lot because it's quick and efficient.

I want you to stop wire framing and start prototyping.

That is incredibly important.

Test early and often, that's why you wanna get the prototypes.

We're gonna void comps for every screen and

state now because we can work more efficiently.

We're going to eliminate all the redundant parts of our workflow as much as possible.

And we have to remember process is not a straight line.

A good process jumps all over the place so that you use the tools you have available

to you to solve the problem at hand in the best way possible at any given time.

So thank you [SOUND] It looks like I have

time for questions if anybody has any.

>> [INAUDIBLE] But you, you talk about.

[INAUDIBLE] comps to get the clients sign-off [INAUDIBLE] etc, But isn't

it part of the testing also that [INAUDIBLE] argument with the test.

>> Mm.

>> Like you prove something works, or you prove something didn't [COUGH] [INAUDIBLE]

>> Yeah, I mean.

We're focused in our process a lot more on the

functionality of the prototype displays, so when we're testing the

prototype, and we get res, the results we're looking for

outta that, that validates a lot of our decision making.

We've been able to prov, persuade our clients of

in many cases that well, visual design isn't purely decoration.

It's less important then the functionality then were actually testing.

Which is how we get the way with not being tied to mock up so much.

And that when they have us doing mock ups, there really just

paying for us to burn time on the wrong part of the process.

It's going to be much more important to them if there users are actually

able to use something, than if the screens we gave them earlier on are prettier.

And on.

I'm not sure I'm sorry if that answered your question or not.

But.

Yep.

All right.

Anybody else?

Yeah.

>> Hi, I'm wondering how has it been working with clients when you have

been able to get [INAUDIBLE] how have you been able to,

talk to clients and make sure that they're okay with having that many people?

Do you ever get push back and if so how do you deal with that?

>> I'm sorry I missed the middle of that, could you say it one more time?

>> Oh.

When you have [UNKNOWN] >> Hm-mm.

>> [UNKNOWN].

>> Oh, OK.

>> [UNKNOWN] talking about cost and having [UNKNOWN]

early on.

How do you [UNKNOWN].

What are some [UNKNOWN].

>> We basically don't give them the option.

What we tell them is, you hired us for a reason,

our process is very effective, you've vetted us through other channels.

We do good work by working this way, and it's not like developers

in the room at the beginning are a line item that saves you money.

We're gonna charge you the same amount of money regardless of who's in the room

at the beginning, so you might as well

have the developers there because they're incredibly helpful.

I know not everyone has the luxury of doing thing, things that way,

but we thought at first that that was gonna be really stressful as well.

And it turns out people just go,okay, we're good.

>> [INAUDIBLE]

>> It's mostly the part where you tell them

it's going to cost the same, that fixes it.

[LAUGH] >> [INAUDIBLE].

To a project if they have like one project [INAUDIBLE] and

then another project in development which could go to that company?

>> Probably not.

We do a lot, we're moving a lot towards strategy these days.

So a lot of the beginning part of the process, into the prototyping.

So there are definitely some projects where we don't handle the

final visual design or we don't do the frontend development for it.

But that's part of why we're focusing a bit more on prototyping these

days because we want to make sure that whatever part of the process we're

involved in we're delivering something that communicates

really well to the final team what

they're supposed to be building and is gonna be most effective for the users.

>> So a developer actually has a place in

that first project even though it's not a developer project?

>> Oh yeah, yeah.

actually, my co-worker Tim sitting right behind you, he's our development director.

And what he likes to say, is that everyone of

fresh soils and experience designer, just some people's tool and Photoshop.

Another people's tools are code.

[SOUND] Any other questions [SOUND] All right, thank you everybody.

[APPLAUSE]