Why Visio wireframes are outmoded (Was [Sigia-l] NYU IA class description link)

[Anthony Hempell]

It seems like many workflows use the wireframe and the prototype for the
same functions (iterative design of UX), where it would really be better
to have both, with a paper-based wireframe coming first and a code-based
prototype afterwards.

Visio or other paper-based wireframes have two advantages that are tough
to give up: they can be presented quickly and easily without a computer,
and you can write notes, annotations and explanations on them all you
want -- you can also include things like process flows, state transition
diagrams, etc. that are all necessary to communicate your ideas.

Jumping from wireframes to production is indeed a great leap, and having
code-based prototypes is a great way for smoothing the transition from
concept to execution.  As with many things, the trouble lies in finding
time and budget to do both.

Anthony





-----Original Message-----
From: sigia-l-bounces at asis.org [mailto:sigia-l-bounces at asis.org] On
Behalf Of Lyle_Kantrovich at cargill.com
Sent: Monday, July 11, 2005 7:06 AM
To: sigia-l at asis.org
Subject: RE: Why Visio wireframes are outmoded (Was [Sigia-l] NYU IA
class description link)

Dave said:
> That's why I prototype in Flash.

Yes, but we're not talking about prototypes...we're talking wireframes.

There's a big difference.

For me, many "wireframes" start out pretty conceptual...showing what 
info/content/functionality should go where.  These early kinds of 
wireframes can be pretty "boxy" - with just labels and short 
descriptions of the kinds of content that might go in that area of the 
screen/page.  As design details take shape, the wireframe will tend to 
evolve into an *example* of a page/screen of that page type.  We use 
legal sized paper (in landscape layout) and use the area to the sides of

the picture of the screen to document functionality, interaction, and 
any questions remaining about the screen design.  The problem with using

an interactive prototype *instead of a wireframe* is that a prototype's 
interaction can be used, but it may not be visible (e.g. you don't know 
a mouseover is there unless you happen to mouse over that area).   
Developers can print out design documents and refer to them as they 
code...and see the documentation of the details.  An interactive 
prototype is more difficult to refer to as you code...you have to switch

from one window to another, and the interaction details are hidden in 
the prototype.

We often use our wireframes as a starter set of page examples, and they 
may be used as part of a paper prototype for early usability testing.  
Once we get beyond conceptual design, we may work with a developer to 
build a higher fidelity prototype of key interactions (e.g. and 
interactive component)...or build a higher fidelity prototype of the 
whole design.  Sometimes that hi-fi prototype is done using a different 
tool than the final product.  For example, we might whip up a prototype 
of a dynamic navigation bar in Flash for as part of a hi-fi prototype 
for usability testing...knowing that if it tests well, the final product

will be done with DHTML.  We've learned that Flash can be faster to 
prototype these kinds of things in...and sometimes the design concept 
gets changed drastically after testing.  We also don't burden our 
developers with creating "production quality" code for a prototype...so 
we plan for prototypes to be "throw-away-able".

For my team:
- Wireframes (and site maps, concept maps, task flows, story boards, 
etc.) are about design documentation.
- Prototypes are for testing...hopefully with real end-users of the 
product.  Sometimes we'll have paper and hi-fi prototypes, depending on 
the project needs.
- Prototype testing yields changes to design documentation.
- "Final" design documentation leads to production quality code.

Sure, you can document in code and just "iterate" until you think it's 
ready for production...but I've found that path to be full of it's own 
risks.  Code is costly to change.  The more that is "codified", the more

you'll have invested in it, the less you'll want to change it.  


Dave said:
> In fact most of my IA roles has been more about documenting my ideas 
then about
> actually ideating them in the first place.

That makes sense. After all, ideas are in *your* head...documentation is

meant to help communicate those ideas so they become shared ideas across

the whole team.  Not to mention that no *one* person has all the good 
ideas.  The team should be helping refine your initial ideas and making 
them better.  If it weren't for documentation and communication, you 
would (potentially) have too much control/sway over the design.  

In IA, as in business, good ideas are cheap...it's the communication and

implementation that have real value.

Lyle
----
Lyle Kantrovich
User Experience Director, Cargill
Cargill: http://www.cargill.com/
My Blog: Croc O' Lyle - http://crocolyle.blogspot.com/ 




------------
When replying, please *trim your post* as much as possible.
*Plain text, please; NO Attachments

Searchable Archive at http://www.info-arch.org/lists/sigia-l/

IA 06 Summit.  Mark your calendar.  March 23-27, Vancouver, BC


________________________________________
Sigia-l mailing list -- post to: Sigia-l at asis.org
Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l