Another UI Stack Exchange question and my answer:
It’s important for me to keep my prototyping in at least two threads, and three if I am trying to understand detailed interactions with animation.
Thread 1: Flow, function, form, and data
- Starting on paper (actually usually a whiteboard design session with others). Focus on screen flow, then major functions and potential layouts of particularly important screens. Try for at least two different ideas.
- Next level of fidelity in Balsamiq. Add functional details, tune the layout, add concrete, meaningful sample data to the screen (in the context of a demonstrable scenario).
- Create a workflow prototype by stringing together a step by step, single path scenario with screens and specific expected interactions to move to the next screen. I tend to use powerpoint, putting all the screen mockups in sequence. This prototype lets you get early feedback with real users by pluralistic walk-throughs, which are very effective for refining concepts, workflows, functional requirements, terminology, etc.
- Iterate early, often, and quickly.
Thread 2: Visual program and style
- Using some of the key mockups from thread 1, visualize them (as comps) in pixel-level detail using Photoshop or some other similar mechanism. Explore color, proportion, visual metaphors, typography, etc. Generate at least 3 ideas.
- Get feedback on these independently of the workflow prototypes. Use preference-testing, AB testing, critiques, charettes, etc.
- Iterate and refine.
Thread 3: Detailed interaction and animation
- Focusing on a single, detailed interaction or animation sequence hack together a functional prototype in whatever tools work best for you: HTML/CSS/JS, Flash, lower-level programming languages, UI component frameworks/libraries, etc. At least two alternative interactions.
- Run a small number of short usability tests including timing data collection. Do comparative tests. Count keystrokes/mouseclicks/gestures.
- Iterate and refine.
In summary, build specific kinds of prototypes for specific purposes… to answer specific questions. No one type works for all situations. Keep the aesthetic concerns out of the workflow/function feedback loop. Use appropriate, effective methods for the different types of questions. “Don’t cross the streams.”
I’ve found that almost all the fundamental design improvements come from thread 1 and thread 2, but thread 3 is necessary if you are going beyond the standard controls or your domain is new/complex/specific (e.g. gestural interactions, multi-dimensional model manipulation, custom controls for a fancy new OS, optimizing human performance in some dimension).
