Paper is not a prototyping tool

5 Nov 2007 - 3:52pm
6 years ago
83 replies
2307 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

5 Nov 2007 - 4:38pm
bminihan
2007

Paper is a perfectly legitimate tool for prototyping airplanes.

Probably not so vehemently stated, but I tend to agree with Andrei that the
tools below are classified typically as "mockup tools" and not so much
prototyping tools. I draw the distinction because I was the only
"prototyper" at my last company, and when folks asked for prototypes, they
typically meant what I do, and not PPT, Visio or any other medium. In fact,
we built a prototyping service specifically to augment design agency
"prototypes" that did nothing remotely prototype-ish (and hence, were all
but useless to developers).

On the other hand, a good designer can communicate his/her design in any
medium, and as long as the definitions are understood at the outset, there's
no reason they HAVE to build the D/X/HTML/CSS/JS to go with their design(s).
As previously discussed here, too, some non-web media are much more
difficult to prototype than others.

Bryan
http://www.bryanminihan.com

5 Nov 2007 - 4:57pm
Steven Pautz
2006

On 11/5/07, Andrei Herasimchuk <andrei at involutionstudios.com> wrote:
>
> Paper is not a prototyping tool. It's a design tool. It's a sketching
> tool.

Why can't it be both? Paper is only a tool, and restricting *any* tool's use
or application doesn't bring us any value. Many tools (such as you mention
below -- X/HTML, CSS, etc) can be used for prototyping or for
implementation, depending on who's wielding it -- why deny the same
flexibility of purpose for tools which could apply to both sketching and
design?

And someone mentioned PowerPoint? Are you kidding?

For the right audience, I think PowerPoint can be very effective: I'm using
it for a large personal project involving some participatory, passionate,
and geographically-scattered friends, and it's the best format I've found
for our particular uses. Everybody can read and annotate them -- the
"review" features, especially comments, are easy for them to create and use,
and they can be tagged to specific design elements if need be -- and they're
much more malleable than pdfs or images (and much less likely to crash my
friends' computers). ;-)

Sure, I *could* build and communicate everything via XHTML+JS+etc -- and I
will for later prototypes and the final system -- but at this stage those
formats would just get in the way of the feedback I'm trying to gather.

Why draw lines between various tools and goals? What value does it bring, so
long as the goals are addressed appropriately? How is it any different from
drawing lines between roles or disciplines?
~Steven

---------------------------
Steven Pautz
seeking junior- to mid-level IxD/IA/UX/UCD work
http://stevenpautz.com/portfolio/

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

>
> 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
>

There are also some good reasons *not* to use these tools.

First, prototype code tends to be hacked together just well enough to make
something look like it works (or work, but minimally), and when code has
already been written, developers will often attempt to reuse it, often
without changing it. It's never a good idea for this less-than-optimal code
to live on in the final product, but very often it ends up there
nonetheless.

Second, when you prototype the front-end - the part the customer actually
interacts with - the people who have to sign off on the work often think
most of the work has been done. As in, "It looks like it's done, so there
must not be much left to do". After this point, the pressure can start
getting very strong to deliver something quickly, despite that the *real*
product may take months to build.

-r-

5 Nov 2007 - 8:37pm
KS Wang
2007

I think there is nothing wrong with using paper as a prototyping tool.
There have been many instances where paper does help to make a big
difference when users were involved. They help to cut down a lot of
time in making changes as compared to a half-functioning software
prototype.

Additionally I have worked on certain mobile appication projects that
do use PowerPoint as a prototype for user testing. This helps us in
finding out the users mental model before we actually implement the
application on mobiles for further testing.

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

5 Nov 2007 - 9:31pm
Kel Smith
2007

In the end, doesn't it really come down to the sort of feedback
you're looking to collect? In my mind, the level of fidelity should
match the intent. Also figuring into the equation is at what point in
the lifecycle you introduce your prototype.

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

5 Nov 2007 - 10:47pm
Anonymous

Hmm, this is all very strange. So someone wrote and entire book on it, we
did it many times in grad school, buts it's not a prototyping tool?

*Paper Prototyping: The Fast and Easy Way to Design and Refine User
Interfaces (Interactive Technologies) *
by Carolyn Snyder<http://www.amazon.com/exec/obidos/search-handle-url/104-4239408-2128720?%5Fencoding=UTF8&search-type=ss&index=books&field-author=Carolyn%20Snyder>

http://www.amazon.com/Paper-Prototyping-Interfaces-Interactive-Technologies/dp/1558608702/ref=pd_bbs_sr_1/104-4239408-2128720?ie=UTF8&s=books&qid=1194318540&sr=8-1

6 Nov 2007 - 6:49am
.pauric
2006

Robert wrote: "There are also some good reasons not to use these
tools."

I would argue that the tools used for a task such as prototyping are
pretty much irrelevant. As long as it gets the job done.

Now, understanding what it will take to get the job done requires you
understanding who the audience of that document is.

It seems to me a lot of different things get called 'prototypes',
right up to near specifications. Which is fine, but Robert
highlights an issue with such a generic label for a document that can
be for anything from a personal feasibility eval right up to a client
presentation or something that might be handed off to implementation.

As I said previously, the first and foremost part of prototyping for
me is understanding the audience, producing the right level of detail
required for that audience to interpret the design decisions captured
withing. I chose to label some of these docs 'mockups', that suits
my process. It would seem a worthwhile exercise to put a coversheet
on your 'prototyping' to explain whether the doc is up for review
or just a heads-up presentation level release.

We put annotations on the elements within a prototype, why not
annotate the entire thing with its purpose?

In the past when I've called something a prototype in the wrong
context I've set myself up for a world of mess when what I had was
almost final.

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

6 Nov 2007 - 9:58am
Billy Cox
2007

Hello,

I am working on a touchscreen interface for a manufacturing application. I
sketched out on paper the various screens in rough detail, and now I can
impress my friends and neighbors by calling it a 'paper prototype.'

I work for a small company, so my paper prototype is primarily a development
tool and not a means of measuring usability. In my context, I perceive that
users give better feedback if the prototype is a closer approximation of the
real thing.

I AM prototyping the touchscreen buttons along with 'click' behavior to get
some user feedback. The actual touchscreen arrives today...fun fun. :)

Btw, I'm new to the list - looks like a really good community.

Billy Cox
Old World Spices
billy at oldworldspices.com <mailto:billy at oldworldspices.com>

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of pauric
Sent: Tuesday, November 06, 2007 3:49 AM
To: discuss at ixda.org
Subject: [QUAR] Re: [IxDA Discuss] What tools do you use for prototyping?

Robert wrote: "There are also some good reasons not to use these tools."

I would argue that the tools used for a task such as prototyping are pretty
much irrelevant. As long as it gets the job done.

Now, understanding what it will take to get the job done requires you
understanding who the audience of that document is.

It seems to me a lot of different things get called 'prototypes', right up
to near specifications. Which is fine, but Robert highlights an issue with
such a generic label for a document that can be for anything from a personal
feasibility eval right up to a client presentation or something that might
be handed off to implementation.

As I said previously, the first and foremost part of prototyping for me is
understanding the audience, producing the right level of detail required for
that audience to interpret the design decisions captured withing. I chose
to label some of these docs 'mockups', that suits my process. It would seem
a worthwhile exercise to put a coversheet on your 'prototyping' to explain
whether the doc is up for review or just a heads-up presentation level
release.

We put annotations on the elements within a prototype, why not annotate the
entire thing with its purpose?

In the past when I've called something a prototype in the wrong context I've
set myself up for a world of mess when what I had was almost final.

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

________________________________________________________________
*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://gamma.ixda.org/unsubscribe List
Guidelines ............ http://gamma.ixda.org/guidelines List Help
.................. http://gamma.ixda.org/help

6 Nov 2007 - 11:06am
Jack L. Moffett
2005

Welcome to the list, Billy!

> In my context, I perceive that
> users give better feedback if the prototype is a closer
> approximation of the
> real thing.

That may be true. In other contexts, users may not give as much
feedback about a "polished" design/prototype due to the fact that it
already seems finished, and therefore not easily changed. When it's
just a drawing, the possibilities are endless.

Jack

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

You could design a process to catch
everything, but then you're overprocessing.
You kill creativity. You kill productivity.
By definition, a culture like ours that
drives innovation is managed chaos.

-Alex Lee
President, OXO International

6 Nov 2007 - 11:37am
Andrei Herasimchuk
2004

On Nov 6, 2007, at 8:06 AM, Jack Moffett wrote:

> That may be true. In other contexts, users may not give as much
> feedback about a "polished" design/prototype due to the fact that it
> already seems finished, and therefore not easily changed. When it's
> just a drawing, the possibilities are endless.

I completely disagree with this. I have never had the experience of
ever getting less feedback with true prototypes. I have no idea why
this point comes up.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

6 Nov 2007 - 11:41am
Andrei Herasimchuk
2004

On Nov 5, 2007, at 2:06 PM, Robert Hoekman, Jr. wrote:

> There are also some good reasons *not* to use these tools.

I disagree. We're talking prototypes here. Any other means of making
a software prototype will always lack in some significant way, in
either it's prototyped interaction model or it's prototypes visual
presentation. When either of those two pieces are lacking in the
prototype, the feedback you get on what to adjust and tweak is
significantly less valuable.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

6 Nov 2007 - 11:48am
Mark Schraad
2006

We frequently assess mocks or prototypes on two measurements, polish and fidelity. Plish is obvious, fidelity it the extend that fnsiton and fit have been thought out and details. We sometimes deliver mocks that are high polsh and low fidelity so that we can assess brand, or to show sales how it might be finfished. This is typically not a conversation about functionality.

I think that the degree of finish changes the feedback that you get. If you want to restrict that feedback to function, then you can take away the polish or the visual styling. I agree with Andrei here, I don't think that these variances ever sginificantly change the quantity of feedback.

Mark

On Tuesday, November 06, 2007, at 11:39AM, "Andrei Herasimchuk" <andrei at involutionstudios.com> wrote:
>On Nov 6, 2007, at 8:06 AM, Jack Moffett wrote:
>
>> That may be true. In other contexts, users may not give as much
>> feedback about a "polished" design/prototype due to the fact that it
>> already seems finished, and therefore not easily changed. When it's
>> just a drawing, the possibilities are endless.
>
>I completely disagree with this. I have never had the experience of
>ever getting less feedback with true prototypes. I have no idea why
>this point comes up.

6 Nov 2007 - 11:49am
Adrian Howard
2005

On 6 Nov 2007, at 16:37, Andrei Herasimchuk wrote:

> On Nov 6, 2007, at 8:06 AM, Jack Moffett wrote:
>
>> That may be true. In other contexts, users may not give as much
>> feedback about a "polished" design/prototype due to the fact that it
>> already seems finished, and therefore not easily changed. When it's
>> just a drawing, the possibilities are endless.
>
> I completely disagree with this. I have never had the experience of
> ever getting less feedback with true prototypes. I have no idea why
> this point comes up.
[snip]

Well it happens with me all the time. It's been my experience that
folk are much more willing to criticise the "big picture" issues when
dealing with rough paper sketches than they are when dealing with a
polished high-res system.

As ever YMMV.

Cheers,

Adrian

6 Nov 2007 - 11:47am
Andrei Herasimchuk
2004

On Nov 5, 2007, at 7:47 PM, Mike Scarpiello wrote:
> Hmm, this is all very strange. So someone wrote and entire book on
> it, we did it many times in grad school, buts it's not a
> prototyping tool?

I'll say it again. Paper is *NOT* a prototyping tool. I don't care
what you've been taught or who's written a book where their sales
rely on a title to claim otherwise.

Paper is a design tool. If you attempt to show others who are not
designers the "paper prototype," the kind of feedback you will get
versus showing them a real prototype is vastly inferior to make final
design decisions. Think of it this way: If you saw a drawing of the
Volkswagen Beetle back in 1995 you'd think it was pretty cool and
some opinions. But when you went to the car show and saw a real live
concept car fully built and can even sit inside it, you can provide
all sorts of feedback never possible from seeing a simple drawing.

I'm not sure why this point would be particularly controversial.
Paper is a design tool. I use it all the time... to DESIGN. 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.
When the rubber hits the road, you simply have to build a real
prototype if you want t make good design decisions.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

6 Nov 2007 - 12:59pm
Mark Schraad
2006

I respectfully disagree Andrei, and I know that I am not alone. We all understand your beliefs, but you are phrasing them as an edict. You candecide this for yourself, or even your own company, but not for the profession or the industry. Sorry.

Mark

On Tuesday, November 06, 2007, at 12:51PM, "Andrei Herasimchuk" <andrei at involutionstudios.com> wrote:
>On Nov 5, 2007, at 7:47 PM, Mike Scarpiello wrote:
>> Hmm, this is all very strange. So someone wrote and entire book on
>> it, we did it many times in grad school, buts it's not a
>> prototyping tool?
>
>I'll say it again. Paper is *NOT* a prototyping tool. I don't care
>what you've been taught or who's written a book where their sales
>rely on a title to claim otherwise.
>
>Paper is a design tool. If you attempt to show others who are not
>designers the "paper prototype," the kind of feedback you will get
>versus showing them a real prototype is vastly inferior to make final
>design decisions. Think of it this way: If you saw a drawing of the
>Volkswagen Beetle back in 1995 you'd think it was pretty cool and
>some opinions. But when you went to the car show and saw a real live
>concept car fully built and can even sit inside it, you can provide
>all sorts of feedback never possible from seeing a simple drawing.
>
>I'm not sure why this point would be particularly controversial.
>Paper is a design tool. I use it all the time... to DESIGN. 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.
>When the rubber hits the road, you simply have to build a real
>prototype if you want t make good design decisions.

6 Nov 2007 - 1:46pm
Katie Albers
2005

At 8:37 AM -0800 11/6/07, Andrei Herasimchuk wrote:
>On Nov 6, 2007, at 8:06 AM, Jack Moffett wrote:
>
>> That may be true. In other contexts, users may not give as much
>> feedback about a "polished" design/prototype due to the fact that it
>> already seems finished, and therefore not easily changed. When it's
>> just a drawing, the possibilities are endless.
>
>I completely disagree with this. I have never had the experience of
>ever getting less feedback with true prototypes. I have no idea why
>this point comes up.
>
>--

It isn't really a point to be disagreed on. It isn't an opinion. I
have often had the experience of getting less feedback...and
certainly less useful feedback on a more nearly finished prototype.
I've had reports from other members of teams about test participants
talking on their way out and saying "Well, I think X could have been
better, but they did it this way instead" (Obviously, paraphrased)

And that's why the point comes up.

Katie

--

----------------
Katie Albers
katie at firstthought.com

6 Nov 2007 - 2:09pm
Matt Nish-Lapidus
2007

On this matter I have to agree with Andrei. Paper is a design tool,
and a design is different than a prototype.

For prototyping interactivity the prototype has to be interactive...
otherwise it's just a design comp with notes.

That being said, paper is a valuable design tool and can be used to
great advantage. But if what you need is a true interaction prototype
then you need an interactive medium.

On 11/6/07, Mark Schraad <mschraad at mac.com> wrote:
> I respectfully disagree Andrei, and I know that I am not alone. We all understand your beliefs, but you are phrasing them as an edict. You candecide this for yourself, or even your own company, but not for the profession or the industry. Sorry.
>
> Mark
>
>
> On Tuesday, November 06, 2007, at 12:51PM, "Andrei Herasimchuk" <andrei at involutionstudios.com> wrote:
> >On Nov 5, 2007, at 7:47 PM, Mike Scarpiello wrote:
> >> Hmm, this is all very strange. So someone wrote and entire book on
> >> it, we did it many times in grad school, buts it's not a
> >> prototyping tool?
> >
> >I'll say it again. Paper is *NOT* a prototyping tool. I don't care
> >what you've been taught or who's written a book where their sales
> >rely on a title to claim otherwise.
> >
> >Paper is a design tool. If you attempt to show others who are not
> >designers the "paper prototype," the kind of feedback you will get
> >versus showing them a real prototype is vastly inferior to make final
> >design decisions. Think of it this way: If you saw a drawing of the
> >Volkswagen Beetle back in 1995 you'd think it was pretty cool and
> >some opinions. But when you went to the car show and saw a real live
> >concept car fully built and can even sit inside it, you can provide
> >all sorts of feedback never possible from seeing a simple drawing.

--
Matt Nish-Lapidus
email/gtalk: mattnl at gmail.com
++
LinkedIn: http://www.linkedin.com/in/mattnl
Home: http://www.nishlapidus.com

6 Nov 2007 - 7:04pm
Andrei Herasimchuk
2004

On Nov 6, 2007, at 9:59 AM, Mark Schraad wrote:

> I respectfully disagree Andrei, and I know that I am not alone. We
> all understand your beliefs, but you are phrasing them as an edict.
> You can decide this for yourself, or even your own company, but not
> for the profession or the industry. Sorry.

That's all fine and good, but the opposite holds true as well, right?
In other words, if I'm not allowed to make "edicts" that paper is not
prototyping, then who are you or anyone else on this list to say to
say that paper is indeed legitimate prototyping? Or to make such
claims to the industry and sets those types of expectations with
clients or non-designer types? And then we go down the road of it
depends, it's all personal opinion, etc., at which point, discussing
anything seems irrelevant, don't you think?

At the end of the day, I'll make this prediction: In the very near
future (let's say within ten years), those designers in the high
technology field that don't increase their skill set to create more
robust prototypes with their own hands will fall by the wayside as
those designers that do start to overtake the field.

Then obviously it won't matter who has what opinion.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

6 Nov 2007 - 7:25pm
Mark Schraad
2006

> On Nov 6, 2007, at 9:59 AM, Mark Schraad wrote:
>
>> I respectfully disagree Andrei, and I know that I am not alone. We
>> all understand your beliefs, but you are phrasing them as an edict.
>> You can decide this for yourself, or even your own company, but not
>> for the profession or the industry. Sorry.

On Nov 6, 2007, at 7:04 PM, Andrei Herasimchuk wrote:
>
> That's all fine and good, but the opposite holds true as well, right?
> In other words, if I'm not allowed to make "edicts" that paper is not
> prototyping, then who are you or anyone else on this list to say to
> say that paper is indeed legitimate prototyping? Or to make such
> claims to the industry and sets those types of expectations with
> clients or non-designer types?

Well unless you think I am either a moron or a hypocrite, then it
would stand to reason that I believe this to be point of view, not of
fact. So effectively what you have stated here is something along the
lines of, "no I'm not, you are". I guess I expect more from someone
as experienced and seasoned as you.

> And then we go down the road of it
> depends, it's all personal opinion, etc., at which point, discussing
> anything seems irrelevant, don't you think?
> At the end of the day, I'll make this prediction: In the very near
> future (let's say within ten years), those designers in the high
> technology field that don't increase their skill set to create more
> robust prototypes with their own hands will fall by the wayside as
> those designers that do start to overtake the field.

I will make a prediction as well. Most every aspect of what we do
will change radically in the next ten years. Andrei, while you are
occasionally misinformed, I anticipate a more guiding voice from you
- and you often deliver. It was your demonstrative and absolute tone,
as well as the repeated message (as if no one heard you) that
triggered my comment. I have used paper prototypes with great
results. There is a time for them, and a time for other types of
prototypes. Various teams I have assembled have used flash, html, css
and javascript for more than ten years (yes each and all of these for
that long). Sometime a bit of IMHO goes a long ways. Most of us,
given an opinion can come to our own conclusion.

> Then obviously it won't matter who has what opinion.

I beg to differ. Opinions matter a great deal when leadership is of
issue.

Mark

6 Nov 2007 - 8:14pm
Todd Warfel
2003

On Nov 5, 2007, at 3:52 PM, Andrei Herasimchuk wrote:

> 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.

Andrei,

How would you define a prototype?

Would you see prototyping as a design tool, or something else? How
does iterative design relate to prototyping?

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.

6 Nov 2007 - 9:16pm
Eric Scheid
2006

On 7/11/07 3:47 AM, "Andrei Herasimchuk" <andrei at involutionstudios.com>
wrote:

> Think of it this way: If you saw a drawing of the
> Volkswagen Beetle back in 1995 you'd think it was pretty cool and
> some opinions.

uh .. waitaminit .. since when would a *drawing* of a Volkswagen Beetle be
thought of as representative of the category of things we call "paper
prototypes"?

> But when you went to the car show and saw a real live
> concept car fully built and can even sit inside it, you can provide
> all sorts of feedback never possible from seeing a simple drawing.

If that "real live concept car fully built" was built out of modelers foam,
wood, and other not-real-car materials, could you not still sit inside it
and provide all sorts of feedback (sans actually driving across europe, that
is)? It would even be sufficient to present the instrument panel in the form
of a colour printout instead of real live electronics - sightlines could be
tested, comprehension could be tested etc.

The medium of paper is great for prototyping things which appear on a flat
surface (eg. websites), just as foam core and wood and such do a pretty good
job of prototyping human-interface interaction possibilities of 3D objects.

e.

7 Nov 2007 - 3:14pm
Christopher Fahey
2005

>> 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?

One of the "prototyping" methods used for the original Palm Pilot was
balsa wood, the equivalent of PlayDough or lego bricks. The purpose
was to test one critical aspect of the product: The aspect they were
prototyping was "how does it feel in the hand" and "how does it fit
into a person's various pockets and bags". They built lots of
different blocks and tried them all before settling on the deck-of-
cards size we all know today as the de-facto PDA standard form
factor. The universal consensus today is that Palm completely nailed
that form factor question, and I don't doubt that the balsa
prototyping made that success happen.

The balsa wood blocks didn't *do* anything, any more than a paper
prototype *does* anything. Andrei, would you say that the balsa wood
block was not a prototype just because it didn't have a computer in it?

How is a block of wood (which tests how something works with the
hands) any less a prototype than a piece of paper (which tests how
well the design works with the eyes)?

It seems to me that whenever you make an artifact and put it in front
of someone and say "pretend this is the real thing", it is a
prototype. Even a piece of paper.

Even if the only test user is you, the designer him or her self: Just
yesterday I was sliding my finger around the surface of a piece of
paper with some life-size iPhone UI marker sketches on it, to
simulate for myself the interaction feel of the final product. My
piece of paper is, thus, a prototype.

Andrei, you seem to be arguing about the degree of fidelity an
artifact must possess for it to qualify as a prototype. If it's any
consolation, there are some people who are *far* more strict about
this than you are. For example, I've known people who think that you
can't prototype a web site without actually building a robust
functional back end (logic, database, content) that really works with
real data.

Higher fidelity is almost always better, of course, but prototypes
come in all degrees of fidelity, from rough paper sketches to
products that are nearly indistinguishable from the final release.
And testing early, before coding stuff, can be immmensely valuable.

I would hope that you are simply quibbling over words and not
contending that it's useless to even show low-fidelity artifacts to
potential users.

-Cf

Christopher Fahey
____________________________
Behavior
biz: http://www.behaviordesign.com
me: http://www.graphpaper.com

7 Nov 2007 - 7:08pm
Andrei Herasimchuk
2004

On Nov 7, 2007, at 12:14 PM, Christopher Fahey wrote:

> Higher fidelity is almost always better, of course, but prototypes
> come in all degrees of fidelity, from rough paper sketches to
> products that are nearly indistinguishable from the final release.
> And testing early, before coding stuff, can be immmensely valuable.

First of all, higher fidelity isn't just "almost always better," it
*is* always better. That's a key point, imho.

On your main point, I don't disagree. But the problem I see are
people in our field using the "paper" prototyping as an escape hatch
from getting down to brass tacks and learning how to build the higher
fidelity ones, which in turn would also give them the skills to take
over aspects of the construction of the software/product so tey don't
rely on engineers to translate what the real design is supposed to be.

So in that context, if someone used a lower fidelity prototype
because their boss won't give them the budget or time to do it
properly, that's fine. We all do what we have to in order to get the
job done. But outside of that, our field needs to get on the
prototyping bandwagon and start wresting the fate of our product's
design away from the engineers. For me, that starts with
significantly higher fidelity prototypes than anything that can be
made with "paper."

> I would hope that you are simply quibbling over words and not
> contending that it's useless to even show low-fidelity artifacts to
> potential users.

I would only say it's "nearly useless" to show to potential
customers. 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. In that context, I
consider it a design tool, something to iterate with, try out all
sorts of ideas very quickly, sketch, etc. But it's simply not a
prototype in my opinion and should never be used as a means to avoid
the topic of what it takes to build a useful prototype.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

7 Nov 2007 - 11:46pm
Eric Scheid
2006

On 8/11/07 10:57 AM, "Andrei Herasimchuk" <andrei at involutionstudios.com>
wrote:

> a pixel perfect representation

Why is "pixel perfect" a requirement, particularly with websites where the
final product can't even be guaranteed to meet that requirement?

Similarly so with other superficial elements of design ... when testing the
usability of a workflow, does it *really* matter if the links are #0000FF
and not #0000CC?

e.

8 Nov 2007 - 11:51am
Fred Beecher
2006

On Nov 7, 2007 5:57 PM, Andrei Herasimchuk <andrei at involutionstudios.com>
wrote:

>
> Too many people in our field use Visio as a replacement for
> production level drawing tools, like FreeHand, Fireworks r
> Illustrator. In doing so, they stop themselves from learning the
> skills they need to actually do more design at the production level,
> which in turn are skills that help in dealing with richer prototypes.
>

How many of us *want* to do design at the production level? I certainly
don't. Hell, I can't be trusted with much color of any sort in my wardrobe,
let alone on a client's Web site.

I don't have "production design skills," but what I do have is almost 10
years of IA, IxD, usability, & user research experience. Understanding users
and designing for their needs & behaviors is what I'm good at, and
prototyping... that is to say *lo-fi* prototyping... is a *key* component of
my ability to deliver quality work. Lo-fi prototyping is crucial to
understanding whether basic structures (from simple navigation to fancy Web
2.0 gew-gaws) of interaction make sense to their intended audience. If they
do, great, I can move forward. If they don't, it's back to the drawing board
for me.

I am also a big proponent of hi-fi prototyping. But I really feel that it
should only take place after at least one round of lo-fi prototyping and
revisions. To me, the purpose of hi-fi prototyping is to determine whether
the design (and possibly code) that the original IxD has been translated
into has gotten in the user's way. Just like in lo-fi prototyping, there's
bound to be some revisions required.

(There are other situations in which *only* hi-fi prototypes make sense, but
I see them as the exception rather than the rule.)

To get somewhat back on the thread of this conversation, for me, tools like
Axure are what allow me (someone with no design and only basic HTML
experience) to use prototyping as part of my practice. Axure I definitely
consider a prototyping tool. Visio, however, is a tool that can produce
prototypes. If I know going into a project that prototyping is required, I
will definitely start that project using Axure rather than Visio.

(This is a great discussion, btw... as the Web matures, prototyping skills,
I think, are critical for IxDs to be considered competent at what we do)

- Fred

8 Nov 2007 - 12:38pm
Andrei Herasimchuk
2004

On Nov 7, 2007, at 8:46 PM, Eric Scheid wrote:

> It isn't better *when* (not *if*) it introduces noise, which is
> anything
> other than signal. If the user could look at your prototype and
> waste your
> time complaining about your *stylistic* colour choices when you are
> trying
> to test the *usability* of the functionality, then you are not in a
> better
> place.

Yes you are. All data regarding feedback is data you must pay
attention to as a designer. If enough people are complaining about
your aesthetics while disregarding the stuff you want feedback on,
then you obviously have a higher level problem that might need to be
solved as well.

> When the user gets nit picky about apostrophes and spelling and
> grammar of your filler content, then you'd be wishing you simply
> stuck with
> Lorem Ipsum ... which is *lower* fidelity than real content.

Again, all feedback is useful feedback. Whether you *do* anything
about it or not is an entirely different matter.

> If you are
> testing the shopping cart functionality, and the user starts
> gabbing on how
> they can get the same item for $2 cheaper elsewhere, then you'd be
> wishing
> you simply used "obviously fake" prices like "$9999.99" (which,
> again, is
> lower fide

It's interesting. All the things you are claiming are useless pieces
of feedback are exactly the kinds of things I like to get feedback on
in conjunction with everything else I need feedback on.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

8 Nov 2007 - 1:39pm
Katie Albers
2005

At 9:38 AM -0800 11/8/07, Andrei Herasimchuk wrote:
>On Nov 7, 2007, at 8:46 PM, Eric Scheid wrote:
>
>> It isn't better *when* (not *if*) it introduces noise, which is
>> anything
>> other than signal. If the user could look at your prototype and
>> waste your
>> time complaining about your *stylistic* colour choices when you are
>> trying
>> to test the *usability* of the functionality, then you are not in a
>> better
>> place.
>
>Yes you are. All data regarding feedback is data you must pay
>attention to as a designer. If enough people are complaining about
>your aesthetics while disregarding the stuff you want feedback on,
>then you obviously have a higher level problem that might need to be
>solved as well.

To me this argument is like saying that if you test in a room with a
prism in the window and users spend their time captivated by the
pretty shiny thing, that is user feedback.

And yes, of course in some senses it is...but ask any school teacher
-- pretty shiny things are more interesting than work.

In the same sense, blue is everyone's favorite color: people just
don't agree what color *is* blue...and different monitors in
different situations will render it differently in any case. How much
effort do I want to expend in sorting out the "I don't like the
color" responses from the "I have trouble tracking what to do next"
responses. And yes, anytime you decide to exclude some element that
will be in the final product, you are in some sense testing it, but
it removes focus from the elements that aren't being tested. On the
other hand, if every tester remarks on the absence of Whatever, then
you need to assess whether that is a more important element than you
had believed.

My general preference is to separate the elements that need to be
tested and test them separately insofar as is possible and then roll
them progressively into a more nearly complete entity which gets
tested. Often, when the elements bang up against each other they
alter previous results, but that enriches previous findings. It
doesn't render them irrelevant.

And since the question of the car prototype keeps coming up, I would
just ask that we keep in mind that prototyping a car starts with
drawings - external, internal, elevations andand so on; then the
external becomes a clay model that is tested for drag, efficiency,
etc and refined, while the question of the interior becomes a
separate set of tasks that -- again -- starts from drawings and
elevations and becomes more and more tightly specified and measured
and examined by potential drivers and is tested against human
ergonomic requirements -- often by doing a mock up of a seat,
steering wheel and paper prototypes of gauges and controls and so
on...until gradually you have an actual functioning prototype car.
And, in the cases as outlined here -- where it isn't just a series of
tweaks to an existing car -- this is actually referred to as a
"Concept Car" so you don't confuse it with something you're going to
see on the street tomorrow. Concept cars are designed for a couple
reasons (1) they're cool and good publicity and (2) they contain a
lot of innovations, bits and pieces of which will be used in
production cars. So far, we've been talking about that process as
though one day Joe Designer walked into a workshop and built a car
and then tested it and then rebuilt it after he had the results.

I'm not sure how much of this thread is due simply to differing
definitions of the word "prototype" and how much is due to different
processes and how much is due to having worked in different
situations which imposed different requirements...but I'd be very
interested in finding out.

Katie
--

----------------
Katie Albers
katie at firstthought.com

8 Nov 2007 - 2:18pm
Andrei Herasimchuk
2004

On Nov 8, 2007, at 10:39 AM, Katie Albers wrote:

> To me this argument is like saying that if you test in a room with
> a prism in the window and users spend their time captivated by the
> pretty shiny thing, that is user feedback.

I think that's a bit of a stretch. The thing I'm talking about are
"distractions" related to the product itself, not general world
environment. If you were testing the room, the analogy would be
correct, but outside "distractions" are not nearly the same things as
distractions inherent in the design of the product itself.

> My general preference is to separate the elements that need to be
> tested and test them separately insofar as is possible and then
> roll them progressively into a more nearly complete entity which
> gets tested. Often, when the elements bang up against each other
> they alter previous results, but that enriches previous findings.
> It doesn't render them irrelevant.

Agreed. We tend to largely work like this as well. But the feedback
when the prototype reaches critical mass is often far more intense,
rich and detailed than at earlier stages. And far more useful in
making the kind of adjustments needed in my experience. The challenge
for me is how to get to that stage as quickly as possible while still
being able to iterate.

> And since the question of the car prototype keeps coming up, I
> would just ask that we keep in mind that prototyping a car starts
> with drawings - external, internal, elevations andand so on; then
> the external becomes a clay model that is tested for drag,
> efficiency, etc and refined, while the question of the interior
> becomes a separate set of tasks that -- again -- starts from
> drawings and elevations and becomes more and more tightly specified
> and measured and examined by potential drivers and is tested
> against human ergonomic requirements -- often by doing a mock up of
> a seat, steering wheel and paper prototypes of gauges and controls
> and so on...until gradually you have an actual functioning
> prototype car.

Beyond being a excellent Nabokov impersonation, I agree.

The problem I have is that people too often in this field attempt to
avoid going for this approach for a variety of factors that seem
unnecessary. I'm erring on the side of being dogmatic towards a
process that builds a high fidelity prototype -- where "paper" is
design tool, not a prototyping tool -- because in my experience, too
often in the high technology field, people tend to avoid them like
the plague because they require "coding."

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

8 Nov 2007 - 2:43pm
Andrei Herasimchuk
2004

On Nov 8, 2007, at 8:51 AM, Fred Beecher wrote:

> I don't have "production design skills," but what I do have is
> almost 10
> years of IA, IxD, usability, & user research experience.
> Understanding users
> and designing for their needs & behaviors is what I'm good at, and
> prototyping... that is to say *lo-fi* prototyping... is a *key*
> component of
> my ability to deliver quality work. Lo-fi prototyping is crucial to
> understanding whether basic structures (from simple navigation to
> fancy Web
> 2.0 gew-gaws) of interaction make sense to their intended audience.
> If they
> do, great, I can move forward. If they don't, it's back to the
> drawing board
> for me.

This is a general comment mostly for Dave Malouf, but the sentiment
Fred is expressing is precisely why I think most "interaction"
designers or the field of "interaction" design is a subset of
interface design or the larger digital product design picture and not
the other way around. There's nothing wrong with this in and of
itself, but you have to recognize that if this is all you want to do,
you are only doing one component of the larger digital product design
picture.

> I am also a big proponent of hi-fi prototyping. But I really feel
> that it
> should only take place after at least one round of lo-fi
> prototyping and
> revisions.

I don't think this is in question.

> To me, the purpose of hi-fi prototyping is to determine whether
> the design (and possibly code) that the original IxD has been
> translated
> into has gotten in the user's way. Just like in lo-fi prototyping,
> there's
> bound to be some revisions required.

I'll disagree again with this. The purpose of prototyping is to build
as much of the product as you can before you get to engineering so
you can test it on all accounts: interaction, graphics, information,
workflow, terms, brand, the whole thing.

> (There are other situations in which *only* hi-fi prototypes make
> sense, but
> I see them as the exception rather than the rule.)

Considering I'm seeing this more often than I expect... I have to
ask. Why would one think this? Every other design profession out
there builds prototypes, scale models, working forms, etc. Why on
earth if given the time and budget would you never build one as a
designer?

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

8 Nov 2007 - 3:51pm
Fred Beecher
2006

On Nov 8, 2007 1:43 PM, Andrei Herasimchuk <andrei at involutionstudios.com>
wrote:

>
> > (There are other situations in which *only* hi-fi prototypes make
> > sense, but
> > I see them as the exception rather than the rule.)
>
> Considering I'm seeing this more often than I expect... I have to
> ask. Why would one think this? Every other design profession out
> there builds prototypes, scale models, working forms, etc. Why on
> earth if given the time and budget would you never build one as a
> designer?

Because time and budget are *always* limits. : ) With a lo-fi prototype, not
very much effort has gone into the design. Just the IA, IxD is responsible
for that. If you go straight to a hi-fi prototype, then you're risking
having to make coders, graphic designers, etc. do re-work too because
something in the IA isn't working.

If your basic lo-fi prototype is working and you've got the time and budget
then I think a hi-fi prototype is valuable. There is a chance that some
IA/IxD problems will be found, but the major ones should be weeded out by
lo-fi testing and shouldn't cause too much re-work for others on the
project.

- Fred

8 Nov 2007 - 4:13pm
Mark Schraad
2006

Protoypes should only be as finished as they need to be. Early in the design stage they will likely be lo-fidelity. Later they would logically be more polished but not very likely fully functional. I can not imagine building an entire application and calling it a prototype. To me it is like building a 3D model - yoiu only build the parts you need. Testing an entire application - isn't this the apha or bet stage?

As for the other argument I think the interaction designer's job typically encompasses a much broader set of skills than interface design. But an interface designers expertise may be more in depth and narrow in appication. I do much more interaction design than I do interface design. In the 80's I did a lot of interface design. My design functions and thinking are much different now.

Mark

On Thursday, November 08, 2007, at 03:34PM, "Andrei Herasimchuk" <andrei at involutionstudios.com> wrote:
>On Nov 8, 2007, at 8:51 AM, Fred Beecher wrote:
>
>> I don't have "production design skills," but what I do have is
>> almost 10
>> years of IA, IxD, usability, & user research experience.
>> Understanding users
>> and designing for their needs & behaviors is what I'm good at, and
>> prototyping... that is to say *lo-fi* prototyping... is a *key*
>> component of
>> my ability to deliver quality work. Lo-fi prototyping is crucial to
>> understanding whether basic structures (from simple navigation to
>> fancy Web
>> 2.0 gew-gaws) of interaction make sense to their intended audience.
>> If they
>> do, great, I can move forward. If they don't, it's back to the
>> drawing board
>> for me.
>
>This is a general comment mostly for Dave Malouf, but the sentiment
>Fred is expressing is precisely why I think most "interaction"
>designers or the field of "interaction" design is a subset of
>interface design or the larger digital product design picture and not
>the other way around. There's nothing wrong with this in and of
>itself, but you have to recognize that if this is all you want to do,
>you are only doing one component of the larger digital product design
>picture.
>
>> I am also a big proponent of hi-fi prototyping. But I really feel
>> that it
>> should only take place after at least one round of lo-fi
>> prototyping and
>> revisions.
>
>I don't think this is in question.
>
>> To me, the purpose of hi-fi prototyping is to determine whether
>> the design (and possibly code) that the original IxD has been
>> translated
>> into has gotten in the user's way. Just like in lo-fi prototyping,
>> there's
>> bound to be some revisions required.
>
>I'll disagree again with this. The purpose of prototyping is to build
>as much of the product as you can before you get to engineering so
>you can test it on all accounts: interaction, graphics, information,
>workflow, terms, brand, the whole thing.
>
>> (There are other situations in which *only* hi-fi prototypes make
>> sense, but
>> I see them as the exception rather than the rule.)
>
>Considering I'm seeing this more often than I expect... I have to
>ask. Why would one think this? Every other design profession out
>there builds prototypes, scale models, working forms, etc. Why on
>earth if given the time and budget would you never build one as a
>designer?

8 Nov 2007 - 4:24pm
Ari
2006

low-fi is definitely the way to go when:
1) time is limited
2) you want to catch logic flow or use cases issues early on

On 11/8/07, Fred Beecher <fbeecher at gmail.com> wrote:
>
> On Nov 8, 2007 1:43 PM, Andrei Herasimchuk <andrei at involutionstudios.com>
> wrote:
>
> >
> > > (There are other situations in which *only* hi-fi prototypes make
> > > sense, but
> > > I see them as the exception rather than the rule.)
> >
> > Considering I'm seeing this more often than I expect... I have to
> > ask. Why would one think this? Every other design profession out
> > there builds prototypes, scale models, working forms, etc. Why on
> > earth if given the time and budget would you never build one as a
> > designer?
>
>
> Because time and budget are *always* limits. : ) With a lo-fi prototype,
> not
> very much effort has gone into the design. Just the IA, IxD is responsible
> for that. If you go straight to a hi-fi prototype, then you're risking
> having to make coders, graphic designers, etc. do re-work too because
> something in the IA isn't working.
>
> If your basic lo-fi prototype is working and you've got the time and
> budget
> then I think a hi-fi prototype is valuable. There is a chance that some
> IA/IxD problems will be found, but the major ones should be weeded out by
> lo-fi testing and shouldn't cause too much re-work for others on the
> project.
>
> - Fred
> ________________________________________________________________
> *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
>

--
--------------------------------------------------
www.flyingyogi.com
--------------------------------------------------

8 Nov 2007 - 4:47pm
Andrei Herasimchuk
2004

On Nov 8, 2007, at 12:51 PM, Fred Beecher wrote:

> Because time and budget are *always* limits. : ) With a lo-fi
> prototype, not
> very much effort has gone into the design. Just the IA, IxD is
> responsible
> for that. If you go straight to a hi-fi prototype, then you're risking
> having to make coders, graphic designers, etc. do re-work too because
> something in the IA isn't working.

I never mentioned anything about skipping lo-fidelity or skipping the
design process in general. Why are you (and others) making that leap
from what I'm saying?

Also, you mentioned there are situations in which *not* using
(emphasis yours) hi-fi prototypes make sense. Again, if budget and
time were not an issue, which situations are you then referring to?

> If your basic lo-fi prototype is working and you've got the time
> and budget
> then I think a hi-fi prototype is valuable. There is a chance that
> some
> IA/IxD problems will be found, but the major ones should be weeded
> out by
> lo-fi testing and shouldn't cause too much re-work for others on the
> project.

This is going in circles. Let's stop presuming building a prototype
constitutes skipping the design process or even skipping lo-fi
versions on the path the hi-fi. Remember, I stated "paper is a design
tool." Design for happens well before prototyping, and continues all
the way through.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

8 Nov 2007 - 5:55pm
Dave Malouf
2005

Andrei said:
"This is a general comment mostly for Dave Malouf, but the sentiment
Fred is expressing is precisely why I think most "interaction"
designers or the field of "interaction" design is a subset of
interface design or the larger digital product design picture and not
the other way around. There's nothing wrong with this in and of
itself, but you have to recognize that if this is all you want to do,
you are only doing one component of the larger digital product design
picture."

interface design is a subset of product design. interaction design is
a subset of product design as well.

interface design is ONLY a subset of product design.

Interaction design is a subset of product and service design.

interface is the presentation layer of a product ...

interaction or behavioral design works at the product level but also
at the eco-system level.

Too bad using our great tool you can't easily spawn off new threads
from existing threads. Note to self ... put in next requirements. ;)

-- dave

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

8 Nov 2007 - 6:13pm
Mattias Arvola
2007

Maria Johansson (at Findwise in Guthenburg) and I presented a paper at
HCI 2007 on what different stakeholder groups focused when presented
with UI-sketches, a written high-level scenario, and a computer
prototypes.

The scenario did not facilitate aesthetic nor ethical viewpoints, nor
did it facilitate operational or perceptual topics. The prototype did
not facilitate discussions on the overarching concept of the design,
to the same extent as the sketches did, but it did facilitate
operational issues. The sketches in general gave the broadest
discussion.

If you are interested in the paper:
http://www.bcs.org/server.php?show=ConWebDoc.13315

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

8 Nov 2007 - 8:21pm
Andrei Herasimchuk
2004

On Nov 7, 2007, at 8:46 PM, Eric Scheid wrote:

> Why is "pixel perfect" a requirement, particularly with websites
> where the
> final product can't even be guaranteed to meet that requirement?

The stretchability and how you construct a web based product makes it
even more vital that the prototype is pixel perfect. Otherwise, your
making design decisions where you might not be properly taking that
into account.

> Similarly so with other superficial elements of design ... when
> testing the
> usability of a workflow, does it *really* matter if the links are
> #0000FF
> and not #0000CC?

Yes. It does matter.

Color is not superficial. If color is part of your end product, the
prototype needs to use whatever color you intend to use for real.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

8 Nov 2007 - 10:01pm
Eric Scheid
2006

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

>> Why is "pixel perfect" a requirement, particularly with websites
>> where the
>> final product can't even be guaranteed to meet that requirement?
>
> The stretchability and how you construct a web based product makes it
> even more vital that the prototype is pixel perfect. Otherwise, your
> making design decisions where you might not be properly taking that
> into account.

<boggle>

Let me rephrase - you can't guarantee pixel perfection in the final designed
product, so why are you trying to achieve it in the prototype?

An analogy: the weather can't be precisely predicted to the degree, so when
you plan out your outdoor wedding rehearsal do you rig up special shade
cloths or heat focusing mirrors and tweak all the settings such that the
temperature at the altar is exactly 24 degrees C and not 25 degrees C? The
temp on the day is going to vary by 5 degrees in either direction,
attempting that level of fidelity in your rehearsal is a waste of time.

e.

9 Nov 2007 - 9:42am
Fred Beecher
2006

On 11/8/07, Andrei Herasimchuk <andrei at involutionstudios.com> wrote:
>
>
> I never mentioned anything about skipping lo-fidelity or skipping the
> design process in general. Why are you (and others) making that leap
> from what I'm saying?

One of the things you said seemed to indicate that you felt we should *just*
be doing hi-fi prototyping. It seems I've misunderstood

Also, you mentioned there are situations in which *not* using
> (emphasis yours) hi-fi prototypes make sense. Again, if budget and
> time were not an issue, which situations are you then referring to?

Actually, I was talking about there being situations not using *lo-fi*
prototypes makes sense. For example, the users of one system I've worked on
aren't very Web savvy to begin with and are resistant to change on top of
that. Presenting wireframe-looking prototypes of new functionality to this
audience would just confuse them and give us bad data. So what I do is work
with the client to make a higher fidelity prototype... matching fonts,
graphics colors, etc. We get much better information from testing in that
situation.

- Fred

9 Nov 2007 - 12:18pm
jrrogan
2005

Is this thread related to the idea the Paper is not a Prototyping tool? Or
is this a semantic discussion on the boundaries of job/skill description?

As far as the statement "Paper is not Prototyping Tool" this really seems
like a ridiculous statement.

Mustard on a hot dog bun could be used as a prototyping tool.

Lets get real here, if this is a semantic discussion related to job
description of who does what, what are we doing here? Maybe we should be
working for a Union defining who can and cannot use a hammer.

8 Nov 2007 - 10:20pm
Andrei Herasimchuk
2004

On Nov 8, 2007, at 7:01 PM, Eric Scheid wrote:

> Let me rephrase - you can't guarantee pixel perfection in the final
> designed
> product, so why are you trying to achieve it in the prototype?

Of course you can gaurantee pixel perfection. How on earth does the
client/product team know what the heck they are building if you
couldn't?

It seems you might be equating "pixel perfection" with a static,
immovable, print-exact, screen layout or the "px" value in something
like CSS meaning of the word. 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. The tools are finally maturing for the desktop client
environment that will make this equally as easy to do there. As for
Flash/Flex or Silverlight types of products, the prototype code for
the visual presentation is often the exact same that's in the final
product, so tat's covered as well.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

8 Nov 2007 - 4:47pm
Andrei Herasimchuk
2004

On Nov 8, 2007, at 12:51 PM, Fred Beecher wrote:

> Because time and budget are *always* limits. : ) With a lo-fi
> prototype, not
> very much effort has gone into the design. Just the IA, IxD is
> responsible
> for that. If you go straight to a hi-fi prototype, then you're risking
> having to make coders, graphic designers, etc. do re-work too because
> something in the IA isn't working.

I never mentioned anything about skipping lo-fidelity or skipping the
design process in general. Why are you (and others) making that leap
from what I'm saying?

Also, you mentioned there are situations in which *not* using
(emphasis yours) hi-fi prototypes make sense. Again, if budget and
time were not an issue, which situations are you then referring to?

> If your basic lo-fi prototype is working and you've got the time
> and budget
> then I think a hi-fi prototype is valuable. There is a chance that
> some
> IA/IxD problems will be found, but the major ones should be weeded
> out by
> lo-fi testing and shouldn't cause too much re-work for others on the
> project.

This is going in circles. Let's stop presuming building a prototype
constitutes skipping the design process or even skipping lo-fi
versions on the path the hi-fi. Remember, I stated "paper is a design
tool." Design for happens well before prototyping, and continues all
the way through.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

9 Nov 2007 - 9:26pm
Oleh Kovalchuke
2006

Andrei,

The final product is a prototype for the next iteration. The best possible
prototype, indeed.

When making the final product (Hi-Fi prototype) is not time consuming (time
is very relative here), than high fidelity prototyping is preferable. The
feedback will be much richer.

The low fidelity prototypes are needed to save time between iterations of
design concept. To test simple form factors or interaction paths. These
tests will produce approximate and inferior results. These results should be
useful and should save time nevertheless.

Should designers to be able to write production code to make Hi-Fi
prototypes? No, they do not have time to keep up with the latest
developments in programming.

--
Oleh, attempting to channel Hemingway.

PS Kudos for the Nabokov reference, the style was more like Joyce though -
less florid.

On Nov 8, 2007 12:18 PM, Andrei Herasimchuk <andrei at involutionstudios.com>
wrote:

> On Nov 8, 2007, at 10:39 AM, Katie Albers wrote:
>
> > To me this argument is like saying that if you test in a room with
> > a prism in the window and users spend their time captivated by the
> > pretty shiny thing, that is user feedback.
>
> I think that's a bit of a stretch. The thing I'm talking about are
> "distractions" related to the product itself, not general world
> environment. If you were testing the room, the analogy would be
> correct, but outside "distractions" are not nearly the same things as
> distractions inherent in the design of the product itself.
>
> > My general preference is to separate the elements that need to be
> > tested and test them separately insofar as is possible and then
> > roll them progressively into a more nearly complete entity which
> > gets tested. Often, when the elements bang up against each other
> > they alter previous results, but that enriches previous findings.
> > It doesn't render them irrelevant.
>
> Agreed. We tend to largely work like this as well. But the feedback
> when the prototype reaches critical mass is often far more intense,
> rich and detailed than at earlier stages. And far more useful in
> making the kind of adjustments needed in my experience. The challenge
> for me is how to get to that stage as quickly as possible while still
> being able to iterate.
>
> > And since the question of the car prototype keeps coming up, I
> > would just ask that we keep in mind that prototyping a car starts
> > with drawings - external, internal, elevations andand so on; then
> > the external becomes a clay model that is tested for drag,
> > efficiency, etc and refined, while the question of the interior
> > becomes a separate set of tasks that -- again -- starts from
> > drawings and elevations and becomes more and more tightly specified
> > and measured and examined by potential drivers and is tested
> > against human ergonomic requirements -- often by doing a mock up of
> > a seat, steering wheel and paper prototypes of gauges and controls
> > and so on...until gradually you have an actual functioning
> > prototype car.
>
> Beyond being a excellent Nabokov impersonation, I agree.
>
> The problem I have is that people too often in this field attempt to
> avoid going for this approach for a variety of factors that seem
> unnecessary. I'm erring on the side of being dogmatic towards a
> process that builds a high fidelity prototype -- where "paper" is
> design tool, not a prototyping tool -- because in my experience, too
> often in the high technology field, people tend to avoid them like
> the plague because they require "coding."
>
> --
> Andrei Herasimchuk
>
> Principal, Involution Studios
> innovating the digital world
>
> e. andrei at involutionstudios.com
> c. +1 408 306 6422
>
>
> ________________________________________________________________
> *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
>

--
Oleh Kovalchuke
Interaction Design is the Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

11 Nov 2007 - 8:03am
Todd Warfel
2003

How do you define lo-fi and hi-fi?

Let's take an on-line banking application, for example. What's the lo-
fi prototype? What's the hi-fi prototype?

On Nov 8, 2007, at 4:24 PM, Ari Feldman wrote:

> low-fi is definitely the way to go when:
> 1) time is limited
> 2) you want to catch logic flow or use cases issues early on

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.

11 Nov 2007 - 8:08am
Todd Warfel
2003

On Nov 8, 2007, at 8:21 PM, Andrei Herasimchuk wrote:

>> Similarly so with other superficial elements of design ... when
>> testing the usability of a workflow, does it *really* matter if the
>> links are #0000FF and not #0000CC?
>
> Yes. It does matter.
>
> Color is not superficial. If color is part of your end product, the
> prototype needs to use whatever color you intend to use for real.

Well, it depends. It depends on what the goal of the prototype is. Is
the goal simply to communicate the intent of the idea, or the concept
of an interaction to another designer, the engineers, or product
management? If so, then no—a "black and white or greyscale model" will
do the job. If on the other hand you're actually testing near final
functionality, or using the prototype as an external marketing tool,
then yes. It should be much closer, or as close as you can get it, to
the vision of the final product.

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.

11 Nov 2007 - 8:12am
Todd Warfel
2003

On Nov 8, 2007, at 10:01 PM, Eric Scheid wrote:

> The temp on the day is going to vary by 5 degrees in either
> direction, attempting that level of fidelity in your rehearsal is a
> waste of time.

Now that's an interesting example. And I'd tend to agree. After all, a
prototype is like a test run, or rehearsal, or like dating before you
finally get married. It's the trial period before your committing to
the real things. It's the time you're feeling things out, working
through them to see what works and what doesn't work. It's a simulation.

Simulations are similar to, but identical to, the real situation, but
they are still highly effective. A prototype is there to serve the
purpose of providing an example and communicate the original idea and
intent of your design. It doesn't need to be pixel perfect to
communicate this intent, but it does need to be close enough that when
the final design comes around it's not a dramatic change. Dramatic
changes can create bias, or even invalidity in the previous test
results.

It's about balance.

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.

11 Nov 2007 - 8:23am
Todd Warfel
2003

On Nov 8, 2007, at 10:20 PM, Andrei Herasimchuk wrote:

> It seems you might be equating "pixel perfection" with a static,
> immovable, print-exact, screen layout or the "px" value in something
> like CSS meaning of the word. 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.

So, then you don't really mean pixel perfect perfection literally.
You're meaning it figuratively. Or do you? You're kind of
contradicting yourself here. If equating pixel perfect to px values in
CSS isn't pixel perfect perfection, but rendering pixels exactly like
the real product is, then that's a bit of a contradiction.

Perhaps you mean that it should function the same, visually use the
same colors, fonts, interactions, etc., but it doesn't exactly have to
be pixel perfect?

Either way, if this is how you're defining prototyping, then almost
every single prototype that I've ever encountered, even the best ones
I've encountered, would not be a prototype, or would be a bad
prototype. Things change over time. Between the time a prototype is
handed to engineering and the actual launch date, things change. So,
by your description, those either aren't valid prototypes, or they are
simply bad prototypes. Neither of which I agree with, think is
accurate, valid, or realistic.

Prototypes have a number of purposes, as I've stated before, and none
of them require pixel perfection. It's a great thing to have, but not
a necessity.

> Given the nature of web applications these days, this is very simple
> to do. The tools are finally maturing for the desktop client
> environment that will make this equally as easy to do there. As for
> Flash/Flex or Silverlight types of products, the prototype code for
> the visual presentation is often the exact same that's in the final
> product, so tat's covered as well.

Um, I sure hope not. That would be a disaster in most cases. Code
often generated by prototyping tools is not production level code and
should not be used for production. I'm not saying it can't be done,
we've done it, but I'm saying that it's often rare and for good
purpose. Often times a prototype is a quick and dirty communication
method and the prototyping tool isn't the final production tool.
Prototype in Flash/Flex/HTML, build in C. Even if you are using the
same language to produce the final piece, the prototype is a discovery
model. You're going to make mistakes. Make them in the prototype. Once
you've learned, recode in production to make it more stable,
streamlined.

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.

11 Nov 2007 - 8:57am
Mark Schraad
2006

I define mocks and prototypes (prototypes being interactive mocks...
mocks being still images) along two axis. The first is polish. This
is the visual finish where the visual presentation does not effect
interaction. The second is fidelity, which is the degree to which
data, content and interactions are flushed out or accurately
specified. Both of these are gut check measures on a scale of 1 to
10. Hardly scientific, but quick and effective none the less.

Also of note, a mock can obviously be of a single state or page load.
Similarly, a prototype may be a single interaction that needs to be
tested or researched.

These measurements can be used for communicating testing, research or
for presentation quality - and often changed as the prototype is
developed and we see what it is.

Mark

On Nov 11, 2007, at 8:03 AM, Todd Zaki Warfel wrote:

> How do you define lo-fi and hi-fi?
>
> Let's take an on-line banking application, for example. What's the lo-
> fi prototype? What's the hi-fi prototype?
>
> On Nov 8, 2007, at 4:24 PM, Ari Feldman wrote:
>
>> low-fi is definitely the way to go when:
>> 1) time is limited
>> 2) you want to catch logic flow or use cases issues early on
>
>
> 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.

11 Nov 2007 - 12:11pm
Chauncey Wilson
2007

Fidelity is defined in a number of ways in the literature and the
debate in this forum is reminiscent of the debate about low versus hi
fidelity that has been going on for about 20 years. The major
questions that show up in the debates include:

How do you define fidelity?
What are the dimensions of fidelity?
When is low-fidelity preferred over high fidelity?
What are the major problems with both low and high fidelity prototypes?
Can you find the same usability problems using low-fidelity and
high-fidelity prototypes?
(More recently, here and in Bill Buxton's new work) Are sketches prototypes?

Here are a few definitions and some of the articles and books that
discuss issues around fidelity and prototyping.

Arnowitz, Arent, & Berger (2007) have published an excellent and
detailed book that describes a range of prototyping methods including
card sorting (prototyping the information structure), Wizard of OZ
prototyping, wireframes, paper prototypes, storyboards, coded
prototypes, blank model prototypes, and video prototypes. Each
chapter describes a process and the issues with various prototyping
methods. Arnowitz and his colleagues refer to 6 levels of fidelity:

- Information design fidelity
- Interaction design fidelity
- Visual design fidelity
- Editorial fidelity
- Branding expression
- System performance

Some other definitions:
• Tullis (1990) Fidelity is the degree to which a prototype represents
the appearance and interaction of the product.
• Virzi (1989) "To the extent that a person using a prototype cannot
distinguish it from the final system, the prototype is high fidelity.
If the prototype can readily be distinguished from the service, then
fidelity is low." (Virzi, p. 224)
• Nielsen (1989) uses the concept of vertical versus horizontal
prototypes (bread versus depth of functionality)
• Virzi, Sokolov, & Karis (1996) Four primary dimensions of fidelity:
breadth of features, degree of functionality, similarity of
interaction, and aesthetic refinement.

Another view of the dimensions of prototyping from the work of Houde
and Hill in the 1997 Handbook of HCI involves three "dimensions" or
questions that various types of prototypes can answer: Look & Feel
(What is it like to look at and interact with the product?), Role
(What can this product do for the user?), and "Implementation (How can
the product be made to perform its functions?). Houde and Hill give a
large number of examples of protoytpes that fall at different places
on these 3 dimensions (they use a triangle to illustrate this in their
article). For example, a "storyboard" could be a powerful way to
prototype the role of the product (what can this product do for the
user?), but not very useful on Implementation or look & feel. The
premise behind the Houde and Hill article is that a portfolio of
prototypes can examine each of these questions or areas (Arnowitz and
colleagues also take that approach). Similarly, a developer might
write code to test the performance of something like a new search
feature in the actual code with no UI and this would be at the extreme
of the implementation end though the testing might influence the UI
depending on potential performance issues.

Some other "dimensions of prototyping that don't come up as much as
fidelity include:
- Ownership
- Discardibility
- Support required for creation and evaluation
- Ease of change
- Degree of user involvement (GOMS can be considered a way to
prototype system performance or compare two designs, but it doesn't
require any users versus other methods that do require users).
- Integration with other tools

Tom Erickson (1995) classified prototypes into two categories: vision
prototypes (which could be high-aesthetic fidelity interactive
prototypes like the Apple Knowledge Navigator vision prototype (1988)
. Erickson and others have noted that rough paper sketches may not be
powerful enough to get funding to work on a real project, but there is
also the danger that slick vision prototypes like the Apple Knowledge
Navigator video can result in inappropriate expectations (which
occurred with the Apple video).

The terminology for prototypes varies a lot between companies with the
exact same thing called a "mockup" in one company and a "paper
prototype" in another. Wireframes can range from roughed out block
diagrams to pixel-performance high-gloss images for example.

So, what I get from reading through the debates here and in the
literature is that there are a number of dimensions of fidelity and
various combinations of levels of fidelity are required to answer
different questions (and to get funding) and different levels of
fidelity can be used throughout the product design process. You can
also have hybrid prototypes that mix working prototypes with paper or
video for example.

Chauncey

Some research on the fidelity issue can be found at:
http://guir.berkeley.edu/projects/fidelity/pubs/Walker_HFES_2002.htm

On Nov 11, 2007 8:03 AM, Todd Zaki Warfel <lists at toddwarfel.com> wrote:

> How do you define lo-fi and hi-fi?
>
> Let's take an on-line banking application, for example. What's the lo-
> fi prototype? What's the hi-fi prototype?

11 Nov 2007 - 7:19pm
Andrei Herasimchuk
2004

On Nov 11, 2007, at 5:23 AM, Todd Zaki Warfel wrote:

> So, then you don't really mean pixel perfect perfection literally.

I do mean it literally. The prototype behaves in the same way the
final product does. If that means users can resize windows, change
font sizes, etc., then the prototype should reflect that.

> You're meaning it figuratively. Or do you? You're kind of
> contradicting yourself here. If equating pixel perfect to px values
> in CSS isn't pixel perfect perfection, but rendering pixels exactly
> like the real product is, then that's a bit of a contradiction.

I'm not sure at all how you arrive at the conclusion. Pixels are
rendered to the computer screen. Pixel perfect for software products
refers to the pixels being rendered on the screen in the prototype
are the same pixels rendered in the final product.

> Perhaps you mean that it should function the same, visually use the
> same colors, fonts, interactions, etc., but it doesn't exactly have
> to be pixel perfect?

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

> Either way, if this is how you're defining prototyping, then almost
> every single prototype that I've ever encountered, even the best
> ones I've encountered, would not be a prototype, or would be a bad
> prototype. Things change over time. Between the time a prototype is
> handed to engineering and the actual launch date, things change.
> So, by your description, those either aren't valid prototypes, or
> they are simply bad prototypes. Neither of which I agree with,
> think is accurate, valid, or realistic.

Then I guess we'll have to disagree.

>> Given the nature of web applications these days, this is very
>> simple to do. The tools are finally maturing for the desktop
>> client environment that will make this equally as easy to do
>> there. As for Flash/Flex or Silverlight types of products, the
>> prototype code for the visual presentation is often the exact same
>> that's in the final product, so tat's covered as well.
>
> Um, I sure hope not. That would be a disaster in most cases.

It's happening in web based products already and will happen more as
Flash based or other RIA type of applications make their ways into
non-computer related products. And it's far from a disaster. The
front-end code for prototypes, the stuff that defines the look and
feel, is easily portable from a prototype to the final product. More
and more of front end interaction is also become portable.

> Prototype in Flash/Flex/HTML, build in C. Even if you are using the
> same language to produce the final piece, the prototype is a
> discovery model. You're going to make mistakes. Make them in the
> prototype. Once you've learned, recode in production to make it
> more stable, streamlined.

I don't disagree with this. But again, more and more of the work put
into the prototype is becoming more and more useful in various
software products. Desktop clients are indeed still different in this
regard, but even that is starting to change somewhat.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

11 Nov 2007 - 7:19pm
Andrei Herasimchuk
2004

On Nov 11, 2007, at 5:23 AM, Todd Zaki Warfel wrote:

> So, then you don't really mean pixel perfect perfection literally.

I do mean it literally. The prototype behaves in the same way the
final product does. If that means users can resize windows, change
font sizes, etc., then the prototype should reflect that.

> You're meaning it figuratively. Or do you? You're kind of
> contradicting yourself here. If equating pixel perfect to px values
> in CSS isn't pixel perfect perfection, but rendering pixels exactly
> like the real product is, then that's a bit of a contradiction.

I'm not sure at all how you arrive at the conclusion. Pixels are
rendered to the computer screen. Pixel perfect for software products
refers to the pixels being rendered on the screen in the prototype
are the same pixels rendered in the final product.

> Perhaps you mean that it should function the same, visually use the
> same colors, fonts, interactions, etc., but it doesn't exactly have
> to be pixel perfect?

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

> Either way, if this is how you're defining prototyping, then almost
> every single prototype that I've ever encountered, even the best
> ones I've encountered, would not be a prototype, or would be a bad
> prototype. Things change over time. Between the time a prototype is
> handed to engineering and the actual launch date, things change.
> So, by your description, those either aren't valid prototypes, or
> they are simply bad prototypes. Neither of which I agree with,
> think is accurate, valid, or realistic.

Then I guess we'll have to disagree.

>> Given the nature of web applications these days, this is very
>> simple to do. The tools are finally maturing for the desktop
>> client environment that will make this equally as easy to do
>> there. As for Flash/Flex or Silverlight types of products, the
>> prototype code for the visual presentation is often the exact same
>> that's in the final product, so tat's covered as well.
>
> Um, I sure hope not. That would be a disaster in most cases.

It's happening in web based products already and will happen more as
Flash based or other RIA type of applications make their ways into
non-computer related products. And it's far from a disaster. The
front-end code for prototypes, the stuff that defines the look and
feel, is easily portable from a prototype to the final product. More
and more of front end interaction is also become portable.

> Prototype in Flash/Flex/HTML, build in C. Even if you are using the
> same language to produce the final piece, the prototype is a
> discovery model. You're going to make mistakes. Make them in the
> prototype. Once you've learned, recode in production to make it
> more stable, streamlined.

I don't disagree with this. But again, more and more of the work put
into the prototype is becoming more and more useful in various
software products. Desktop clients are indeed still different in this
regard, but even that is starting to change somewhat.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

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

Syndicate content Get the feed