UX/IxD terminology: Prototype

16 Mar 2008 - 12:37pm
6 years ago
6 replies
1126 reads
Kevin Doyle
2007

Okay, I've heard lots of words around here that I think we all have
different meanings to us personally. The one that seems to be currently
messing up a few of us in one thread is the word "prototype", so let's start
with that.

To me, a prototype is a scaled down model of what you want things to look
like. I think what's messing us up the most is that it's too general of a
term and could be used to describe just about anything we do at any point.

I'll break down some of the terminology I use with the client and you can
agree or disagree from there. The goal of this thread is to get some clarity
when we're talking about this stuff and to prevent future arguments on
semantics.

At the beginning of a project, when I'm starting to put the business
requirements to design, I prefer the term "wireframe". I'm sure most of you
know what this term means, and those of you who don't, you can probably pick
up what it means -- a wireframe is a line drawing of a page or application
layout. I sometimes describe wireframes as the page or application
"blueprint". Another metaphor that I've used for wireframes or wireframe
documentation is "the skeleton" -- the bare bones of the application or site
behavior.

Anyway, you can use pencil and paper for wireframing or a vector-based
design tool like Visio or Illustrator. I prefer Visio because I have a huge
selection of stencil templates for page and application elements and
behavior. Color isn't used yet (although, I sometimes use blue to denote
links, buttons and "hot" areas like linked images, etc.) mainly because I
don't want the client to get distracted with the visual design yet. Someone
on the prototype tools thread used the metaphor of color as "the prism in
the classroom" -- something that dazzles, but usually distracts. My
wireframes spec out every dropdown, every drag-n-drop menu, link location,
etc... -- all page or application behavior as reflected in the business
requirements. Then, I go into a review cycle with the client and make
adjustments as necessary.

Once the general layout is figured out, I can then move to the color
version, or visual design, of the site -- what I sometimes call the "skin".
These I create using a mix of Illustrator and Photoshop and are pixel
perfect... with a few caveats here and there, of course. I usually create 3
to 5 versions, all as stylistically different as possible, so the client has
a well-rounded selection. Since we're not also deciding upon the page or
application behavior or general layout, the client doesn't usually need more
than 3 design compositions. Then, I go into another review cycle with the
client, adjusting and redesigning as necessary.

When the visual design and wireframe documentation is finished, I have
occasionally used the term "prototype" with the client. Prototype, like I
stated earlier, is a scaled down version of what things will look like. The
prototype, in this case, is the final visual design and the final wireframe
documentation.

Once that is decided upon, I start on the CSS and HTML templates for the
developers, while they start figuring out how to code the "muscle" to get my
skeleton and skin moving.

Heh, okay, sorry for the long-winded definition or explanation of
"prototype", but I thought describing my process would also help with the
definition... or maybe I just like writing about this stuff. ;-) You decide.

Oh -- just thought of this -- does IxDA have a wiki? Using a wiki, we can
hammer out some of these definitions in a public format... just an idea.

Comments

16 Mar 2008 - 1:19pm
Charlie Kreitzberg
2008

I think that the problem with "prototype" is that it means different things
to developers and designers. To many developers who are working in a
language like C++, a prototype is what we might call a "proof of concept."
They use it to validate the basic architecture and tools. Actually, Alan
Cooper used it in the same way in his keynote.

I have started calling what I produce as "mock-ups" to minimize the
confusion.

Charli

16 Mar 2008 - 3:03pm
Jeff Howard
2004

See also:
The Five Types of Prototypes, October 2007
http://www.ixda.org/discuss.php?post=20959&search=prototype

// jeff

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

16 Mar 2008 - 8:14pm
Itamar Medeiros
2006

On the page of "prototype means different things to different
people", there was an interesting issue that Dave Malouf brought up
regarding Cooper's thoughs on Prototypes... check it out at:
http://www.ixda.org/discuss.php?post=25888#25888

--
{ Itamar Medeiros } Information Designer
designing clear, understandable communication by
caring to structure, context, and presentation
of data and information

website ::: http://designative.info/
mobile ::: 86 13671503252
skype ::: designative

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

17 Mar 2008 - 5:51am
John Wood
2005

I don't think of prototypes in trms o the fidelity of representation,
but rather in terms of functionality. Any flat, drawn representation
is a wireframe, whether turned out as a series of grey boxes or as a
luscious photoshopped mock-up. Add behaviour at any stage, even
something as simple as links in Visio or Omnigraffle, and you have a
prototype.

I think this is the key to he difference in the minds of software
engineers. To them, a prototype is created in code and therefore has
moving parts (even if they lack full functionality). To them, a
drawing is a drawing, a prototype is something you can play with.

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

17 Mar 2008 - 8:54am
Kevin Doyle
2007

Hmm... okay, I think I'm getting it. When I was at AOL, for usability
testing, we'd create a Flash version and test users on it. It wasn't the
application at all, really -- just something that looked and behaved like
what we wanted to develop. That Flash version, if I'm understanding the
input here, is really a prototype... right?

On Mon, 17 Mar 2008 03:51:46, John Wood <john.wood at iqcontent.com> wrote:

> I don't think of prototypes in trms o the fidelity of representation,
> but rather in terms of functionality. Any flat, drawn representation
> is a wireframe, whether turned out as a series of grey boxes or as a
> luscious photoshopped mock-up. Add behaviour at any stage, even
> something as simple as links in Visio or Omnigraffle, and you have a
> prototype.
>
> I think this is the key to he difference in the minds of software
> engineers. To them, a prototype is created in code and therefore has
> moving parts (even if they lack full functionality). To them, a
> drawing is a drawing, a prototype is something you can play with.
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=27157
>
>
> ________________________________________________________________
> 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
>

17 Mar 2008 - 9:20am
Kristof Versluys*
2008

I'm into what John said;
"Add behaviour at any stage, even something as simple as links in
Visio or Omnigraffle, and you have a prototype."

In a mac-environment, I mostly use Omnigraffle and can actually use it
for all phases we're going through.
I start by making a flowchart, turning some pages into wireframes &
linking it to the flowchart so I can easily make an 'interactive'
presentation.
It actually shows how it's all structured and specifies some of the
page's layout & functionality in the wireframes. To really get a hold
on how the application will interact with the user, I create
additional wireframes that are linked to eachother.
It's a really quick & easy way to visualise and you can re-use what
you already made.
Surplus, you got a finished document with the whole application-layout.

On Mon, 17 Mar 2008 03:51:46, John Wood <john.wood at iqcontent.com> wrote:
> I don't think of prototypes in trms o the fidelity of representation,
> but rather in terms of functionality. Any flat, drawn representation
> is a wireframe, whether turned out as a series of grey boxes or as a
> luscious photoshopped mock-up. Add behaviour at any stage, even
> something as simple as links in Visio or Omnigraffle, and you have a
> prototype.
>
> I think this is the key to he difference in the minds of software
> engineers. To them, a prototype is created in code and therefore has
> moving parts (even if they lack full functionality). To them, a
> drawing is a drawing, a prototype is something you can play with.
>

Syndicate content Get the feed