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

[Lyle_Kantrovich at cargill.com]

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/