wireframes for the wicked

There is not just one wireframe for a project. You need a wireframe for each type of documentation user: design team, business people (how does this affect them during day to day), managers (are the ideas good ones?), developers (details so they know how to build).

Types

Reference Zones – ???

Low Fidelity/Sketch – sketch-city! whiteboard heaven! lets you stay focused on one aspect of the tool, not be flooded with all of the later detail. “stencil library” (good idea!)

High Fidelity – show lots of a detail, as much as you would need for the final product. should show the levels of interaction. toward the end of a design process. focus people on things you need to talk about.

Storyboards – a set of wireframes that shows the screen flow (steps through the interaction). describe entry and exit points. demonstrate core tasks with a storyboard, not necessarily edge cases.

Standalone – a wireframe with every piece of information that a developer would need to create an app exactly the way you intended

Specification – insanely detailed to provide the information for developers as well as testers. Adds information about triggers, content source/target, actions and what happens. Basically a set of metadata about the objects that will be on the screen.

Where do you stop with wireframe detail? Once you’ve decided where something should really go and how it should work, you can usually stop. How close to a prototype do you need to get (37signals–just build it)? It usually depends on how much module-interaction and decision-making that needs to occur.

Where/how do you include edge cases? High fidelity wireframes after you know the core way the app will work, they are just the final details to make sure you have a complete spec. Sometimes needs to be limited to the top 3-5 edge cases.

These are notes from a session at sxsw interactive. My own take on topics are mixed in with what the presenters were actually saying, so do not assume all of this content is my own.