Paper is not a prototyping tool

5 Nov 2007 - 3:52pm
6 years ago
83 replies
2273 reads
Andrei Herasimchuk
2004

On Nov 4, 2007, at 6:39 PM, KS Wang wrote:

> Paper! ... Good for drafting out, materialising and visualising the
> ideas I have
> in mind, before moving on the the standards like Visio, Omni Graffe

Paper is not a prototyping tool. It's a design tool. It's a sketching
tool. It's a way to get ideas directly from one's brain into the
world with as little information loss as possible. But it's not a
prototyping tool. Paper prototyping is nothing more than iterative
design to help people get the ball rolling and to keep things at a
level of manageable, inexpensive and iterative before getting to
brass tacks with real, pixel precise mockups and a true product
prototype.

Also, I've been really trying my best to avoid responding to this
thread as I know I'll just upset folks, but I can' t resist anymore...

The fact that Visio seems to be a "legitimate" tool in the field just
makes me want to cry. I mean, would you create a scale model if you
were building the original iPod out of PlayDough to show to the guy
who signs the checks what the design will be? Or Legos for that matter?

And someone mentioned PowerPoint? Are you kidding?

XHTML+CSS, Javascript, Fireworks, Photoshop, Illustrator, Flash
ActionScript, etc. This is what our products are built using, so it's
high time those in the field who to call themselves "designers" stop
avoiding learning how to build prototypes using real technology

Really. Just stop it. The tools are not that hard. It's almost 2008.
It's time to evolve already.

</rant>

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

Comments

11 Nov 2007 - 7:56pm
Eric Scheid
2006

On 12/11/07 11:19 AM, "Andrei Herasimchuk" <andrei at involutionstudios.com>
wrote:

> Maybe we should flip this question as you guys seem to be thinking
> different than I am. What do you think pixel perfect means?

if in the final design, for a given screen, window size, interaction state
(etc) a given element is "x" pixels in size, then the same element in the
prototype under the same conditions would also be exactly "x" pixels in
size.

e.

11 Nov 2007 - 10:19pm
Andrei Herasimchuk
2004

On Nov 11, 2007, at 4:56 PM, Eric Scheid wrote:

> On 12/11/07 11:19 AM, "Andrei Herasimchuk"
> <andrei at involutionstudios.com>
> wrote:
>
>> Maybe we should flip this question as you guys seem to be thinking
>> different than I am. What do you think pixel perfect means?
>
> if in the final design, for a given screen, window size,
> interaction state
> (etc) a given element is "x" pixels in size, then the same element
> in the
> prototype under the same conditions would also be exactly "x"
> pixels in
> size.

Ok. That's what I mean as well. So what's so controversial then about
a prototype that basically acts just like the real thing?

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

12 Nov 2007 - 12:17am
Eric Scheid
2006

On 12/11/07 2:19 PM, "Andrei Herasimchuk" <andrei at involutionstudios.com>
wrote:

> Ok. That's what I mean as well. So what's so controversial then about
> a prototype that basically acts just like the real thing?

what do you use prototypes for?

e.

11 Nov 2007 - 10:19pm
Andrei Herasimchuk
2004

On Nov 11, 2007, at 4:56 PM, Eric Scheid wrote:

> On 12/11/07 11:19 AM, "Andrei Herasimchuk"
> <andrei at involutionstudios.com>
> wrote:
>
>> Maybe we should flip this question as you guys seem to be thinking
>> different than I am. What do you think pixel perfect means?
>
> if in the final design, for a given screen, window size,
> interaction state
> (etc) a given element is "x" pixels in size, then the same element
> in the
> prototype under the same conditions would also be exactly "x"
> pixels in
> size.

Ok. That's what I mean as well. So what's so controversial then about
a prototype that basically acts just like the real thing?

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

12 Nov 2007 - 10:45am
Todd Warfel
2003

On Nov 11, 2007, at 10:19 PM, Andrei Herasimchuk wrote:

> Ok. That's what I mean as well. So what's so controversial then
> about a prototype that basically acts just like the real thing?

Because in the real world often prototypes don't look exactly the same
as the final product for many, many reasons. You use the prototype to
test, you discover some things you need to change, you change them and
that's the final production piece. Concept cars aren't exactly the
same as the final production car. High fashion on the runway is a
prototype of the final clothes you find in the store—not the same as
what was on the runway. The foam prototype of a remote control is
probably the closest to the final remote in "pixel perfect" terms. But
in my tour of the Boston IDEO office, I saw dozens of mice and remotes
made of foam core—all prototypes, few resembled the final production
piece.

One of the points of a prototype is to test out concepts, design
ideas. So, you're going to build a number of prototypes that aren't a
true pixel perfect reflection of the final design. And according to
what you're saying, then those aren't prototypes. Or are they?

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

12 Nov 2007 - 9:14am
Bob Miller
2007

If you had said "Paper is not a prototyping tool for visual-centric,
electronic interactive devices," then I might agree with you. But
interaction extends far beyond just computers, cell phones, and
iPods.

Paper is just a tool. Crude perhaps, but still in the tool box of
many imaginative people.

And let's not forget the legions of designers who must work with the
tools their employers pay for. Often, that's Powerpoint. Sad, yes.
But invalid? Hardly.

Sounds like your true position is "Working in visually-centric
electronic media as I do, I wouldn't waste my time with paper,
powerpoint, or Visio. I prefer to use X, Y, Z."

Fair enough.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=22174

12 Nov 2007 - 1:14pm
Andrei Herasimchuk
2004

On Nov 12, 2007, at 6:14 AM, Bob Miller wrote:

> If you had said "Paper is not a prototyping tool for visual-centric,
> electronic interactive devices," then I might agree with you. But
> interaction extends far beyond just computers, cell phones, and
> iPods.

So this is a perfect opportunity to ask who on this list does *not*
work in the high-tech sector, doing interaction design for software,
web based products or products that include software components? Is
that number more than 10% of the association's population?

> Paper is just a tool. Crude perhaps, but still in the tool box of
> many imaginative people.

Of course it's a tool! That's been my entire point from the
beginning. It's a design tool. I've only said it's not a prototyping
tool or medium.

> And let's not forget the legions of designers who must work with the
> tools their employers pay for. Often, that's Powerpoint. Sad, yes.
> But invalid? Hardly.

Anyone who calls themselves a designer and is forced to use
PowerPoint as a design tool because their employer won't buy them
something like even Fireworks for the same price seriously needs to
change jobs. That's a ridiculous condition and an example I find
absurd to the tenth degree. Hell... even Photoshop Elements is better
for designing digital products than PowerPoint.

> Sounds like your true position is "Working in visually-centric
> electronic media as I do, I wouldn't waste my time with paper,
> powerpoint, or Visio. I prefer to use X, Y, Z."

I wish people would stop putting words in mouth. I use paper all the
time as a primary design tool, but not as means for prototyping.
However, I do feel PowerPoint and Visio are indeed a wastes of time
as design tools.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

12 Nov 2007 - 1:21pm
Andrei Herasimchuk
2004

On Nov 12, 2007, at 7:45 AM, Todd Zaki Warfel wrote:

> You use the prototype to test, you discover some things you need to
> change, you change them and that's the final production piece.

Obviously.

> Concept cars aren't exactly the same as the final production car.
> High fashion on the runway is a prototype of the final clothes you
> find in the store—not the same as what was on the runway. The foam
> prototype of a remote control is probably the closest to the final
> remote in "pixel perfect" terms. But in my tour of the Boston IDEO
> office, I saw dozens of mice and remotes made of foam core—all
> prototypes, few resembled the final production piece.

Somewhere along the way, they very likely made the one that was
indeed the final and it indeed looked pretty much like the real deal.
Otherwise, how did they come to a decision it was the indeed the
final one and that the product they were going to build was that
design? Just more sketching and hand-waving?

> One of the points of a prototype is to test out concepts, design
> ideas. So, you're going to build a number of prototypes that aren't
> a true pixel perfect reflection of the final design. And according
> to what you're saying, then those aren't prototypes. Or are they?

Of course you build a number of prototypes that eventually lead to a
prototype that is the final design. And of course along the way you
start lower and get higher fidelity. For software products, there's
absolutely no reason to build towards a final prototype that is pixel-
perfect.

Again, this is how most other design fields behave. I have no idea
why my position on this is such a controversial topic in this list.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

12 Nov 2007 - 2:40pm
Dave Malouf
2005

Andrei,
I want to jump in here. I've been reading on the sidelines and I
have to say I'm really dismayed with the community as well.

I hear a few things from the group which are all "true", but
further don't contradict what you are saying either:

1. prototypes are iterative and change in fidelity over time. What I
read from Andrei is that as you iterate you move up in fidelity until
you prototype is just that a "proto version of the application"
which communicates and behaves as the final one. The issue of whether
or not it is "production quality code" is a red herring. That is
between you and "your maker" (engineer/construction worker).

2. What is a prototype anyway?
Who cares? It means what it means to you? Yup, I'm saying semantics
is not necessary here. (me?) Model, prototype, mockup, etc. These are
all design and communication tools and trying to tell one person what
is and isn't one of them doesn't work, b/c the contexts of their
meaning is jut that contextual. Some of us have more technical
backgrounds and some are more design oriented. That is the beast of
UX.

In the end what Andrei is saying (at least my interpretation) is that
detailed models have to be a part of our design process if we are to
indeed consider ourselves designers. Designers make things ... not
semblances of things or virtualizations of things. To me one of the
biggest failings of IxD and IA is that we have traditionally let
other people create the things that we conceptualize. We immediately
loose our value to the process and fight to explain ourselves.

As someone who has written recently about my own lack of visual
design abilities (Andrei is more than aware of this)) I am facing
this NOW in my current job where I work within an industrial deign
studio where I never hear the phrase, "But the visual designer does
that." Every ID is a visual designer and a jr. mechanical engineer
(some not so jr.). They constantly humble me with their ability for
designing everything and delivering detailed models (not working as
there is no guts to it) that have full graphic design and in many
cases button feel/response.

"He who controls the presentation controls the relationship. He who
controls production, controls the product."

-- dave

ps. Andrei, you expecting that?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=22174

12 Nov 2007 - 2:51pm
Andrei Herasimchuk
2004

On Nov 12, 2007, at 11:40 AM, David Malouf wrote:

> "He who controls the presentation controls the relationship. He who
> controls production, controls the product."

/applause!

> ps. Andrei, you expecting that?

No. But damn was it music to my ears.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

12 Nov 2007 - 3:50pm
jrrogan
2005

My main beef on this thread is that goofy statements are made, ("paper is
not a prototyping tool" and "the only way to design complex software is with
high fidelity prototyping"), and then these statements are backed up with
"mumbo jumbo" speak, posturing to be enlightened thinking, and then double
tracked back upon:

For example:

>I want to jump in here. I've been reading on the sidelines and I
>have to say I'm really dismayed with the community as well., ...

>I hear a few things from the group which are all "true", but
>further don't contradict what you are saying either:...

>1. prototypes are iterative and change in fidelity over time. ...

>2. What is a prototype anyway?
>Who cares? It means what it means to you? ...

Given the above 2 statements and that Dave indicates "paper is a prototyping
tool", and that this posts title is "Paper is not a prototyping tool" don't
these concepts contradict the title of this post? Should this posts title be
interpreted as an "ironic statement" reinforcing that paper "is" a
prototyping technique, but there are other techniques as well?

>In the end what Andrei is saying (at least my interpretation) is that
>detailed models have to be a part of our design process if we are to
>indeed consider ourselves designers.

I'm not at all convinced that the above statement is true. I would agree
high fidelity prototyping can be very good for sure. I would also say that
you could design a great product that could be built without "high fidelity
prototyping", how about good design via well annotated diagrams and screens?

>To me one of the biggest failings of IxD and IA is that we have
traditionally let
>other people create the things that we conceptualize. We immediately
>loose our value to the process and fight to explain ourselves.

Not sure I agree with the above statement either - a designer who can
articulate their ideas, in any manner, which then can be built be that built
as a prototype or as the end product, could be the most as successful
designer, (given they had the support team around them). In architecture, an
architect may never build "models", or do high fidelity drawings, rather
they may have a team that builds models for them, (this is what Frank Gehery
does at least, pretty sure Frank Lloyd Wright did this as well).

Hence Dave's below statement misses the point of "the architect and
craftsman":

>"He who controls the presentation controls the relationship. He who
>controls production, controls the product."

Basically what I would like to point out is there's more then one way to
"skin a cat". And a great designer could very well be the worst craftsman.

12 Nov 2007 - 4:25pm
Andrei Herasimchuk
2004

On Nov 12, 2007, at 12:50 PM, Rich Rogan wrote:

> And a great designer could very well be the worst craftsman.

I'm not going to reply. I think this statement says it all about why
I disagree.

I have yet to meet a great designer who was not also a great craftsman.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

12 Nov 2007 - 4:33pm
Peter Boersma
2003

Andrei wrote:
> Of course you build a number of prototypes that eventually lead to a
> prototype that is the final design. And of course along the way you
> start lower and get higher fidelity.
[..]
> Again, this is how most other design fields behave. I have no idea
> why my position on this is such a controversial topic in this list.

Your position seemed to be, *until this post*, that only high fidelity models of how a product would behave could be called prototypes.

Lower fidelity prototypes, like paper prototypes, got hammered down with statements such as:
"Paper prototyping is nothing more than iterative design to help people get the ball rolling and to keep things at a level of manageable, inexpensive and iterative before getting to brass tacks with real, pixel precise mockups and a true product prototype." (http://ixda.org/discuss.php?post=22174 first entry).

Prototypes that are not pixel-perfect get a similar treatment with replies like:
" Of course you can guarantee pixel perfection. [..] Pixel perfection, as I'm using it, means nothing more than the prototype as rendered in pixels on the screen looks exactly like the real product that will ship, at minimum in it's visual presentation, including all the things that will happen if you resize windows, change font sizes, etc. [..] Given the nature of web applications these days, this is very simple to do."

IMHO that is the reason why people objected to your point of view.

But I must confess that, as I'm tracking through the archives, you do mention that you use paper models (I won't use the word prototype) early on in the design process with the team, client and users:
"What people call "paper prototyping" is something I do at the very beginning of the design process with the initial team, and I use it as a design tool to get a project started."
and:
"I find showing end users, product managers or CEOs a paper drawing to be of nominal value, and only at the up front stages of the design process."

Peter
--
Peter Boersma | Senior Interaction Designer | Info.nl
http://www.peterboersma.com/blog | http://www.info.nl

12 Nov 2007 - 5:10pm
jrrogan
2005

Well Andrei...

I've got to admit, I'm "OK" at best with Javascript, and would develop
pretty crap AJAX code, hence I hire great "craftsmen" who are JS and CSS
wizards. I "design" the concept, they build it as per my spec, which is
often on paper or even on a whiteboard.

Simply put, there are better skilled individuals to do certain tasks, and
someone who is a JS/CSS guru,may not be the best person to "architect" the
entire system, (big picture thinking is not synonymous with great
craftsmanship, although the architect has to be knowledgeable/open to the
latest techniques).

Technology is changing so fast that it is often a different skill set with
"big picture vision" VS "guru level latest coding techniques".

Have you never heard of great architects who were not AutoCad geniuses?

On 11/12/07, Andrei Herasimchuk <andrei at involutionstudios.com> wrote:
>
>
> On Nov 12, 2007, at 12:50 PM, Rich Rogan wrote:
>
> > And a great designer could very well be the worst craftsman.
>
> I'm not going to reply. I think this statement says it all about why
> I disagree.
>
> I have yet to meet a great designer who was not also a great craftsman.
>
> --
> Andrei Herasimchuk
>
>

12 Nov 2007 - 5:21pm
Andrei Herasimchuk
2004

On Nov 12, 2007, at 2:10 PM, Rich Rogan wrote:

> Technology is changing so fast that it is often a different skill
> set with "big picture vision" VS "guru level latest coding
> techniques".

I agree with this. And here at our studio I have the same luxury
having folks who do the brunt of the that work as well.

But I don't keep up with the latest technology simply because I'm
waiting for it to settle down, not because I believe I should not be
required to code front ends for the software I design. That's
probably a large difference between me and lots of other folks. In
fact, I hope the technology settles down quickly so I can finally
dive back in and build things with my own two hands again.

I miss the days when I use to prototype interfaces with Director. So
much has changed since then, and while I can build web products with
my own two hands using XHTML+CSS+JS, I've purposefully kept myself
away from building Flash prototypes and things with Silverlight
because I'm waiting for something to "win" so I can invest the right
amount of time in learning it. If nothing changes in the next three
years, I'll just dive back in with whatever is there again.

> Have you never heard of great architects who were not AutoCad
> geniuses?

All the time. However, building virtual models in AutoCad is a far
cry from building physical scale models. I think if you asked a lot
of good architects, if they'd say they'd have no problem building the
design at a scale level off the computer if they had the time between
projects.

In fact, why would you ever trust an architect who has never picked
up a hammer and nail in his life before? I know I wouldn't. I want
the guy who built his own house. Or built something with his own two
hands.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

12 Nov 2007 - 5:22pm
Robert Hoekman, Jr.
2005

>
> I have yet to meet a great designer who was not also a great craftsman.

How do you define "craftsman"?

-r-

12 Nov 2007 - 5:27pm
Andrei Herasimchuk
2004

On Nov 12, 2007, at 2:22 PM, Robert Hoekman, Jr. wrote:
> How do you define "craftsman"?

A person who practices and is highly skilled in a craft, and does so
with their own two hands. In other words, someone who can design and
build something with their own two hands.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

12 Nov 2007 - 5:31pm
Andrei Herasimchuk
2004

On Nov 12, 2007, at 1:33 PM, Peter Boersma wrote:
> Your position seemed to be, *until this post*, that only high
> fidelity models of how a product would behave could be called
> prototypes.
That is still true from my point of view -- hi-fi models are really
the only true prototype. The part I keep leaving out that people make
logical leaps that I do not intend is that everything I tend to do
these days within a project design is towards building a prototype.
Everything up to the point of a usable prototype is basically design
process and needs to be as iterative as possible.

Time and budget constraints hinder this goal, but it is still the
goal nonetheless. And when time and budget get in the way, you make
do with however far you can get.

And fwiw, I also now tell clients that the prototype can be thrown
away at any stage when it's proven its the wrong design. And we have
to restart the design at some point in the process where it wasn't
wrong. I don't get myself married to anything. And my *preferred*
method of working given the time and budget is to build the prototype
of the product as fully as possible, try it out, then throw away
whatever doesn't work and redo that part.

We also do smaller chunks of prototyping when the feature or function
is modular enough to be a contained element. But we also do that with
pixel precision as well, as interactive as we can make it to get it
out before it gets folded into the larger prototype.
> Lower fidelity prototypes, like paper prototypes, got hammered down
> with statements such as...
> Prototypes that are not pixel-perfect get a similar treatment with
> replies like...
>
> IMHO that is the reason why people objected to your point of view.
I guess that makes sense. But again, I've mentioned paper as a
*design* tool in this whole thread, and I think people keep skipping
over that part of my argument. Probably because the moment I say
paper is not a prototyping tool, they disagree so vehemently with me
that they can't read anything else I say about the subject where I
also qualify my point of view.

I take the aggressive point of view that paper is not prototyping and
that prototypes for software and digital products need to be pixel
perfect and include interaction as much as possible because I think
to not take that position gives too many people in our field an
excuse to not dive into building the product for real. Versus
describing the product in whatever design deliverable they prefer,
which is not a prototype.

There is such a massive difference between any deliverable that
"describes" the design, no matter how clever or thorough, and a
functioning prototype that I cannot imagine any designer of a digital
product or software application -- again, given the time and budget
-- would opt to not build one.

And yes... I'm back to work now and will probably lurk for a while
until the next lull. 8^)

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

12 Nov 2007 - 6:16pm
Todd Warfel
2003

On Nov 12, 2007, at 1:21 PM, Andrei Herasimchuk wrote:

> Of course you build a number of prototypes that eventually lead to a
> prototype that is the final design. And of course along the way you
> start lower and get higher fidelity. For software products, there's
> absolutely no reason to build towards a final prototype that is
> pixel-perfect.
>
> Again, this is how most other design fields behave. I have no idea
> why my position on this is such a controversial topic in this list.

Because your statement that prototypes are pixel-perfect is silly and
by your description above, you don't even agree with it. You're saying
above that in software there's no reason to build towards a prototype
that is pixel-perfect, but you say that they have to be pixel perfect,
and if I recall correctly, you're in the business of designing
software. So, your views seem to be at odds with themselves.

It's not that your view is so controversial, but rather that you're
contracting yourself, but refuse to either admit that you are, or
admit that prototypes don't need to be pixel-perfect, or that pixel-
perfection isn't a necessary requirement.

BTW, rendering pixels on a screen doesn't constitute pixel-perfect.
Rendering pixels on a screen is just that. Pixel-perfect is pixel-
perfect—an exact duplicate in every single way. And prototypes are not
an exact duplicate in every single way. They are a simulation of the
vision for the final product and should mimic it, but are rarely, if
ever, an exact duplicate in every single way—especially in software.

Prototypes are meant to communicate the original intent, the concept,
the vision of a design or interaction. They're for simulation and
communication. They're for working through a design. And as such, they
are typically not going to be a pixel-perfect production, but rather a
representation of what you're trying to accomplish in the final
product. Additionally, it's very common to prototype pieces of the
product as you're working your way through the design. Can they be
pixel perfect? Absolutely. Are they? Not very often.

Think about all the prototypes that have been made over the years in
industrial design and architecture. Most of them were not pixel
perfect prototypes—especially in architecture, they're scale models.
In architecture, they build from drawings. In software, we often build
from either drawings, a written documents, prototypes, or a
combination. So, we have overlap with other industries and some
uniqueness to our own situation.

But prototypes it's very easy to see that prototypes do not have to be
and rarely are pixel-perfect.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

12 Nov 2007 - 6:26pm
Mark Schraad
2006

I sooo... wish I had asked those questions last week. We have
different views of what constitutes a prototype. Simple as that.

Mark

On Nov 12, 2007, at 6:10 PM, Andrei Herasimchuk wrote:

>
> On Nov 12, 2007, at 2:52 PM, Mark Schraad wrote:
>
>> You mean you draw on the paper and then look at it right?
>
> Draw, sketch, redraw, whiteboard, sketch some more, draw some more,
> etc. Either on paper or on lots of whiteboards.
>
>> Ever show it to anyone not a designer and not the client? If the
>> answer is yes, could it then be called a prototype? Or, does your
>> definition of prototype require a specific level of polish or a
>> specific type if interactivity? If so, what are those levels?
>
> Rarely do I show my sketches and such with non-designers. Even if I
> did, I would never refer to it as a prototype of anything, only a
> sketch.
>
> A prototype for me requires:
>
> * Real color palette in place
> * Real typography and font choices in place
> * Enough real content to make an impact; Lorem ipsum only in worst
> case scenarios
> * Enough real interaction for front end features, like sliders,
> dragging behaviors, pop-ups, alerts, transitional animation, etc.
> * Enough workflow built in to make a reasonable assessment of the
> workflow itself, from screen to screen or main view to main view
> * Real icons
> * If audio is involved, then real audio as well
>
> A few other things but that's the major points.
>
> --
> Andrei Herasimchuk
>
> Principal, Involution Studios
> innovating the digital world
>
> e. andrei at involutionstudios.com
> c. +1 408 306 6422
>
>

12 Nov 2007 - 6:57pm
Andrei Herasimchuk
2004

On Nov 12, 2007, at 3:26 PM, Mark Schraad wrote:

> I sooo... wish I had asked those questions last week. We have
> different views of what constitutes a prototype. Simple as that.

I know. That has been the basis of the entire debate. But I'll say it
again, from my very first message in this thread:

--

Paper is not a prototyping tool. It's a design tool. It's a sketching
tool. It's a way to get ideas directly from one's brain into the
world with as little information loss as possible. But it's not a
prototyping tool. Paper prototyping is nothing more than iterative
design to help people get the ball rolling and to keep things at a
level of manageable, inexpensive and iterative before getting to
brass tacks with real, pixel precise mockups and a true product
prototype.

XHTML+CSS, Javascript, Fireworks, Photoshop, Illustrator, Flash,
ActionScript, etc. This is what our products are built using, so it's
high time those in the field who to call themselves "designers" stop
avoiding learning how to build prototypes using real technology.

--

Obviously, this is my opinion. But nowhere do I say in there is paper
somehow not part of the process.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

12 Nov 2007 - 7:08pm
Andrei Herasimchuk
2004

On Nov 12, 2007, at 3:16 PM, Todd Zaki Warfel wrote:

> It's not that your view is so controversial, but rather that you're
> contracting yourself, but refuse to either admit that you are, or
> admit that prototypes don't need to be pixel-perfect, or that pixel-
> perfection isn't a necessary requirement.

I'm not contradicting myself. I feel software prototypes do require
those things so I feel no need to admit otherwise, regardless of how
much you dislike that point of view. If there's no time or no budget,
one makes do, but no way and no how is some sort of sketch or even
fully realized Photoshop screenshot mockup a prototype of a software
product that inherently requires interaction as a core component of
its overall design.

> BTW, rendering pixels on a screen doesn't constitute pixel-perfect.

This is why you seem to think I'm contradicting myself. Your
definition of "pixel perfect" is apparently not the same as mine. To
me, when I present a software prototype to someone, and also present
the real product, and if they can't tell the difference visually
between the two, that's "pixel perfect." Even better when the
prototype behaves in a way that makes people think it's the real deal
as well.

> Rendering pixels on a screen is just that. Pixel-perfect is pixel-
> perfect—an exact duplicate in every single way. And prototypes are
> not an exact duplicate in every single way. They are a simulation
> of the vision for the final product and should mimic it, but are
> rarely, if ever, an exact duplicate in every single way—especially
> in software.

And this is again where we disagree. But please stop saying I'm off
base or contradicting myself when I'm doing no such thing. I'm just
saying something that you obviously disagree with at a definition
level. That doesn't make me wrong or you right or vice versa.

> Prototypes are meant to communicate the original intent, the
> concept, the vision of a design or interaction.

I'll post the same Henry Dreyfuss quote I did a few months back:

-----

Too much emphasis cannot be placed on the importance of three-
dimensional models. We come to this step after we have analyzed and
evaluated hundreds of designs and blueprints, trying to bring some
quality to the product that will make it easier to use without
increasing the cost, more pleasant to look at without any drastic
changes in the factory routine. When our ideas have been formulated,
we design in clay, then plaster, finally in a material that will
simulate the material to be used in manufacturing the actual product.
Wherever possible, such models are done in full size. In developing
the exterior of a train or a ship, accurate scale models must suffice.

The cost of a model is more than compensated for by future savings.
It not only presents an accurate picture of the product for the
executives, but it also gives the toolmakers and production men an
opportunity to criticize and to present manufacturing problems.
Models of some products can be made for a few hundred dollars. Full-
scale models of ship or train interiors can cost many thousands of
dollars. A mock-up of a modern passenger airplane cabin may cost
$150,000 but it will be worth it, for it permits engineers and
designers to develop techniques of installation that would not be
otherwise possible. Furthermore, sales executives can bring potential
customers into a faithful, full scale fuselage to see what it offers,
long before production begins. ***It is far more effective to sit in
a chair that judge its comfort by a picture of it.*** [Emphasis added]

Henry Dreyfuss, Designing for People, 61-62.

-----

Of course the prototype is meant to communicate the final design. But
why do you think Dreyfuss says that's its more effective to sit in a
chair than judge its comfort by a picture of it? And the really
important part of that quote is that in the high-tech industry, the
thing that has prevented us from doing what ever other design
profession does as a base part of their design process is time and
money. It's not that the prototyping is only useful some of the time
or whatever other reason is tossed out there. If given the time and
money, building a real prototype will *ALWAYS* be better than any
other design deliverable.

Why? Because sitting in a chair is more effective to judge how
comfortable it is than looking at a picture of it.

> They're for simulation and communication. They're for working
> through a design. And as such, they are typically not going to be a
> pixel-perfect production, but rather a representation of what
> you're trying to accomplish in the final product.

I would argue that the reason for this has largely been a
technological one and an issue of not enough people in our field
getting hands on with the design of the product by building a
prototype themselves.

> Additionally, it's very common to prototype pieces of the product
> as you're working your way through the design. Can they be pixel
> perfect? Absolutely. Are they? Not very often.

For you they may not be. For me, that's all I push for anymore. The
technology is sufficient enough that building what I call pixel
perfect prototypes for software or digital products is not a barrier
anymore like it used to be. The only barrier is the education a lot
of us have to do to code Javascript, Actionscript or any other
scripting language that provides front-end interaction. For visuals,
Photoshop+Illustrator or Fireworks is plenty, and XHTML is very easy
to get a handle on for web based stuff. Flash or Director for desktop
client prototypes is a little more involved, but not at all out of
reach.

That barrier is a small price to pay to regain control of the final
end design of our products.

> Think about all the prototypes that have been made over the years
> in industrial design and architecture. Most of them were not pixel
> perfect prototypes—especially in architecture, they're scale
> models. In architecture, they build from drawings. In software, we
> often build from either drawings, a written documents, prototypes,
> or a combination. So, we have overlap with other industries and
> some uniqueness to our own situation.

How is a scale model, one that is also attempting to reflect the look
of the materials used, the environment (even the trees!), the size
and scale, and all those pieces not a hi-fidelity prototype? The
scale models I used to build for set design in the theater, which is
far more budget restrictive than any profession I've ever been in
since, were quite detailed down to the paint and look of it. In fact,
no set was ever built until the scale model was approved by the
director. And when the final piece was built, it had to look exactly
the like the scale model.

As for industrial design, most professional firms do build scale
models and do everything possible to make their prototypes as real as
they can given time and budget. I know of no ID firms that do not
have that as an integral part of their design process.

> But prototypes it's very easy to see that prototypes do not have to
> be and rarely are pixel-perfect.

Obviously, I disagree.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

12 Nov 2007 - 7:24pm
Robert Hoekman, Jr.
2005

>
> > I sooo... wish I had asked those questions last week. We have
> > different views of what constitutes a prototype. Simple as that.
>
> I know. That has been the basis of the entire debate. But I'll say it
> again, from my very first message in this thread:

Anyone ever taken a Logic class? I've never forgotten the idea I learned
there that most seemingly unsolvable arguments have stem from a lack of
clear definitions of key terms. For us to explain what tools we use for
prototyping, we must first define "prototype". Then, I suppose, we should
define "tool".

Of course, after doing all that, we'll just have to do it again in another
thread next week because new people will show up and no one will remember
what was said. ;)

-r-

12 Nov 2007 - 7:45pm
Chris Bernard
2007

"Questions about whether design is necessary or affordable are quite beside the point: design is inevitable.

The alternative to good design is bad design, not no design at all."

Douglas Martin

I'm also particular fond of this quote from Clement Mok that he wrote in an op ed piece for Commarts when he was running the AIGA. Now, I don't think this comment applies to people on this list but there 3k people on this list? How many designers in the world?

"There has clearly been a steady decline in the design profession for over 30 years, and the source of that decline is the profession's intractable stasis.

We are unchanged professionals in a changing professional climate, clutching at old idols, while failing to create new offerings, failing to reinvent and reinvigorate the practice when needed, failing to inculcate a professional culture that is accessible and fair."

Clement Mok

Chris Bernard
Microsoft
User Experience Evangelist
chris.bernard at microsoft.com
630.530.4208 Office
312.925.4095 Mobile

Blog: www.designthinkingdigest.com
Design: www.microsoft.com/design
Tools: www.microsoft.com/expression
Community: http://www.visitmix.com

"The future is already here. It's just not evenly distributed." William Gibson

12 Nov 2007 - 9:21pm
Jeremy Yuille
2007

On 12/11/2007, at 4:17 PM, Eric Scheid wrote:

> On 12/11/07 2:19 PM, "Andrei Herasimchuk"
> <andrei at involutionstudios.com>
> wrote:
>
>> Ok. That's what I mean as well. So what's so controversial then about
>> a prototype that basically acts just like the real thing?
>
> what do you use prototypes for?
>

hey great question!
(hi all - been lurking and reading this thread)

"Is a brick a prototype? The answer depends on how it is used."

see http://www.viktoria.se/fal/kurser/winograd-2004/Prototypes.pdf

sorry don't have the exact ref with me but its from Chap 2 in the
handbook of hci.
http://www.elsevier.com/wps/find/bookdescription.cws_home/524988/descrip...

in this paper Houde and Hill propose a 3d model for understanding
prototypes. I have found this helpful to use when describing the role
of prototype to collaborators and stakeholders, not as the last word,
but definitely as a starting point. They describe some good examples.

“Role” refers to questions about the function that an artifact serves
in a user’s life — the way in which it is useful to them.

“Look and feel” denotes questions about the concrete sensory
experience of using an artifact — what the user looks at, feels and
hears while using it.

“Implementation” refers to questions about the techniques and
components through which an artifact performs its function — the
“nuts and bolts” of how it actually works.purpose of any prototype in
context for the designer and their audiences. It gives a global
sense of what the prototype is intended to explore; and equally
important, what it does not explore.

hope this helps, apols if its already been covered.

cheers
jy

12 Nov 2007 - 11:45pm
Eric Scheid
2006

On 13/11/07 11:08 AM, "Andrei Herasimchuk" <andrei at involutionstudios.com>
wrote:

> Why? Because sitting in a chair is more effective to judge how
> comfortable it is than looking at a picture of it.

Similarly, interacting with a mockup of an interface is more effective than
just looking at a picture of it .. which holds true even if that interface
is 2 dimensional in nature (eg. a website), and is rendered onto a 2
dimensional surface (eg. paper).

I do hope you are not confusing "interacting with a paper prototype" with
"looking at a picture of an interface".

e.

13 Nov 2007 - 1:47am
Deepak Pakhare
2005

Andrei said:
"Paper is not a prototyping tool. It's a design tool. It's a
sketching tool."

While reading, I have been looking up at the ceiling away from the
thread and running that statement over and over in my head. Allow me
to put forth what I have understood so far from the discussion - a
thought experiment, if you will. Please stay with me on this.

Here goes:
1) I visualize a screen-based interface in my head and draw it out on
paper.

Then,
2) I visualize the shape of a mobile device around the screen in my
head and draw it out on paper.

Next, I hand over paper number 2 to a modeller who works
clay/wood/plasticine. He goes on to create a model of the device.

In the meantime, I quickly run out on the street, assemble a bunch of
10 random people and show them paper number 1. My design research
question to myself at this point: "Does the interface give out any
HINTS to the random bunch of people what the mobile application is
intended to do?"

So who designed and who prototyped in the above scenarios?

1) Can I assume to have used a PAPER PROTOTYPE or PROTOTYPED ON
PAPER? Because I could draw and coz I care for user-feedback, all I
needed was a PAPER PROTOTYPE at that point to share with potential
users. As I keep refining the interface design on paper, based on the
initial feedback, I decide to abandon paper-for-prototyping and do
mid-fidelity prototype in MS EXCEL(at this point I am tool-agnostic)
I may choose to simulate some soft-key navigation in this specific
design iteration. Now, even if I knew how to create hi-fidelity
prototypes in Flash-lite would I have needed or used them at this
point?

2) The clay/wood/plasticine modeller did the other part of the
prototyping (which I wud prefer an industrial designer to test with
potential users) moving gradually from clay, wood to plasticine
during which key decisions about the form-factor, aesthetics etc. are
arrived at. Depending on my levels of curiosity I may exchange notes
with the device designer, but maybe not.

Andrei seems to suggest along the way, that the designer alone should
be able to do detailed modeling all the way up-to the finished
hi-fidelity model/prototype. A lot of designers are quite adept at
building prototypes physical or pixel and hence are designers
prototypers rolled into one. While some others abandon building at
the lo/mid-fidelity stage and instead take on communicating/reviewing
(with the protoyper) right thru to hi-fidelity. That doesn't mean
they have contributed any less up until that point.

I haven't come across any writing that posits paper as a PROTOTYPING
TOOL in the sense that some designers use Flash to generate
prototypes. However I have come across substantial material that
talks about PAPER PROTOTYPES as a means to generate user feedback.
Just one random article about paper prototyping:
http://www.alistapart.com/articles/paperprototyping

So as a designer I am naturally inclined to quickly sketch the first
iteration of the design (that is still evolving in my head) on PAPER.
Does it make paper a design tool then? No, it makes it a SKETCHING
tool. I may choose to skip paper when designing altogether. Likewise
I may hit flash/power-point/HTML straight on to prototype(hi-fidelity
but without the innards) for all I care. So where does that leave
paper?

So here's my final take on PAPER, IMHO. Paper is a humble sketching
tool - ONLY a sketching tool. Not a design tool, not a prototyping
tool! :)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=22174

13 Nov 2007 - 11:56am
Adrian Howard
2005

On 12 Nov 2007, at 03:19, Andrei Herasimchuk wrote:
[snip]
> Ok. That's what I mean as well. So what's so controversial then about
> a prototype that basically acts just like the real thing?
[snip]

Nothing - but I'd tend to call it "the product" :-)

Where does "prototype" end and "initial version of product" start I
wonder?

Cheers,

Adrian

13 Nov 2007 - 12:11pm
Stew Dean
2007

On Mon, 12 Nov 2007 11:40:59, David Malouf <dave at ixda.org> wrote:

> In the end what Andrei is saying (at least my interpretation) is that
> detailed models have to be a part of our design process if we are to
> indeed consider ourselves designers. Designers make things ... not
> semblances of things or virtualizations of things. To me one of the
> biggest failings of IxD and IA is that we have traditionally let
> other people create the things that we conceptualize. We immediately
> loose our value to the process and fight to explain ourselves.

Take two steps back for a second. Consider an architect, you know, the
real ones that design buildings. They make nothing as part of a
project, just as I make nothing as part of a project.

So not you don't have to make anything to be a 'designer' - you just
need to specify and guide. Depending on the role and make up of a team
I will do differing things in different ways - for example my current
project is a software project and I'm using real interface looking
elements in my page designs as opposed to web stuff where it's all
very lo-fi.

If you're saying that having visual design skills or technical skills
are a benefit then yes, I agree. I have a smattering of both and they
help, I am totaly capable of putting together a website including CMS,
graphic design and a fair amount of scripting. BUT others can do it
better - so I work as part of a team.

I also hold that good experience design requires a degree of
seperation between design and implimentation. Why? Because the
engineering mindset is not the same as the design mind set and tends
to lead to feature rich and finely engineered solutions that, well,
suck. You can end up with a Nokia N95 instead of an iPhone, to use a
product design example. Nokia - what happened?

Because you can do everything does not mean you should and often it's
better you don't.

--
Stewart Dean

13 Nov 2007 - 2:23pm
Michael Micheletti
2006

A couple-few careers ago I was an aircraft mechanic at Boeing, first
in the mockup shop, then on the flight test modification crew. I
installed, removed, tweaked, measured, and cussed at a lot of very
early stage designs. Sometimes those designs came from engineers who
"got it", like the two guys who designed the very complex over-wing
emergency exit doors on the 757. I must have built three or four
iterative miniature versions in the mockup shop with those guys
looking over my shoulder and talking with me a couple times a shift
until they were happy with the prototype. Years later this stands out
in my mind as an example of a great prototyping collaboration.

And then there were prototype modules I needed to install, say beneath
an airliner's cockpit in a very confined space, where it was plain
that the design engineer had never before held a screwdriver and
hadn't the faintest clue in the world how basic mechanical things
worked.

Same goes with webcraft and software. Maybe you don't need to be an
expert Java developer or graphic designer or AJAX guru to design for
various platforms, but it will sure become instantly apparent to the
implementers whether you know squat about how things work (or not).

Software prototyping is one way to bridge the gap between design and
development skills. Even if you don't become a serious development
threat, through hands-on craft work you gain a basic understanding of
some of the concerns and mindset that developers and visual designers
will apply to your wonderful wireframes and interaction designs. Your
informed designs are more likely to be built as-designed rather than
recrafted on the developer's forge or tossed as unbuildable (and take
it from me this can sure puncture and deflate your poor old ego).

Michael Micheletti

On Nov 12, 2007 2:21 PM, Andrei Herasimchuk
<andrei at involutionstudios.com> wrote:
> In fact, why would you ever trust an architect who has never picked
> up a hammer and nail in his life before? I know I wouldn't. I want
> the guy who built his own house. Or built something with his own two
> hands.

13 Nov 2007 - 2:33pm
David Walker
2007

Architects create models. In the old days, they created detailed physical models using little sticks of wood and paper. The bigger the project, the more detailed the model. The model would be part of their deliverable. Nowadays, architects often deliver extremely detailed Illustrations and 3D walkthroughs as well as very detailed wood and plastic models.
Architects, car designers, aircraft designers, software designers: we all need to build concept models to prove concepts. This happens near the end of a design cycle as the model-building requires a lot of work - a lot of which is not design related. My models are my creations. I make them. Web and Flash designers often end up actually making the site. Likewise, Blend developers are starting to deliver the actual presentation layer to dev teams. This is a sneaky change and the temptation is to build our concept models using the same physical method that we use to deliver the actual presentation layer. I think this is a mistake because inevitably, we turn our concept models over to the dev team prematurely.
David and Stewart, you are correct: designing is not building. We can also be builders, using tools such as Blend and Silverlight, but we need to be disciplined and follow our design process thoroughly. We need to build our concept models and be as detailed as necessary with these models in order to prove that our designs work well. I know for myself that when I take shortcuts, I cheat the product that I am working on.
Dave

>-----Original Message-----
>From: Stew Dean [mailto:stewdean at gmail.com]
>Sent: Tuesday, November 13, 2007 12:11 PM
>To: 'David Malouf'
>Cc: discuss at ixda.org
>Subject: Re: [IxDA Discuss] Paper is not a prototyping tool
>
>On Mon, 12 Nov 2007 11:40:59, David Malouf <dave at ixda.org> wrote:
>
>> In the end what Andrei is saying (at least my interpretation) is that
>> detailed models have to be a part of our design process if we are to
>> indeed consider ourselves designers. Designers make things ... not
>> semblances of things or virtualizations of things. To me one of the
>> biggest failings of IxD and IA is that we have traditionally let
>> other people create the things that we conceptualize. We immediately
>> loose our value to the process and fight to explain ourselves.
>
>Take two steps back for a second. Consider an architect, you know, the
>real ones that design buildings. They make nothing as part of a
>project, just as I make nothing as part of a project.
>
>So not you don't have to make anything to be a 'designer' - you just
>need to specify and guide. Depending on the role and make up of a team
>I will do differing things in different ways - for example my current
>project is a software project and I'm using real interface looking
>elements in my page designs as opposed to web stuff where it's all
>very lo-fi.
>
>If you're saying that having visual design skills or technical skills
>are a benefit then yes, I agree. I have a smattering of both and they
>help, I am totaly capable of putting together a website including CMS,
>graphic design and a fair amount of scripting. BUT others can do it
>better - so I work as part of a team.
>
>I also hold that good experience design requires a degree of
>seperation between design and implimentation. Why? Because the
>engineering mindset is not the same as the design mind set and tends
>to lead to feature rich and finely engineered solutions that, well,
>suck. You can end up with a Nokia N95 instead of an iPhone, to use a
>product design example. Nokia - what happened?
>
>Because you can do everything does not mean you should and often it's
>better you don't.
>
>--
>Stewart Dean
>________________________________________________________________
>*Come to IxDA Interaction08 | Savannah*
>February 8-10, 2008 in Savannah, GA, USA
>Register today: http://interaction08.ixda.org/
>
>________________________________________________________________
>Welcome to the Interaction Design Association (IxDA)!
>To post to this list ....... discuss at ixda.org
>Unsubscribe ................ http://www.ixda.org/unsubscribe
>List Guidelines ............ http://www.ixda.org/guidelines
>List Help .................. http://www.ixda.org/help
>

14 Nov 2007 - 9:03am
Adrian Howard
2005

On 13 Nov 2007, at 19:33, davewalker at interfacevisuals.com wrote:

[snip]
> My models are my creations. I make them. Web and Flash designers
> often end up actually making the site. Likewise, Blend developers
> are starting to deliver the actual presentation layer to dev teams.
> This is a sneaky change and the temptation is to build our concept
> models using the same physical method that we use to deliver the
> actual presentation layer. I think this is a mistake because
> inevitably, we turn our concept models over to the dev team
> prematurely.
[snip]

Why would it be "premature"?

Curiously...

Adrian

14 Nov 2007 - 4:18pm
Chris Borokowski
2007

Actually, I like paper as a prototyping tool, but I do more than one
type of prototype, so flexibility is more essential than visual specificity.

http://technical-writing.dionysius.com/
technical writing | consulting | development

____________________________________________________________________________________
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

Syndicate content Get the feed