Techniques, Uses, and Artifacts
Wireframes are dead.
I prefer sketching to wireframes.
I don’t create functional specifications, I only use prototypes.
I’m seeing and hearing more statements like these throughout the user experience design community, commenting on the obsolecense or inferiority of a particular approach over another. Generally, I’ve been reluctant to get involved in these discussions because (a) they are usually inflammatory to serve some other purpose and (b) people should be allowed to use whatever tool they feel best communicates their ideas. Talking up prototyping by dismissing wireframing ignores the varied and nuanced circumstances designers face, and undermines the value of having a greater choice of tools.
Mixing Apples and Oranges
Something else always bothered me about these blanket comparisons between approaches that sometimes looked alike or sometimes served the same need. It hit me the other day. To compare “wireframes” and “prototypes” strikes me as missing the point: this isn’t an apples and oranges comparison. They’re not even both fruits.
Instead, our work product has nuances that make simple comparisons puzzling. To explain the distinctions, you have to take a closer look at the outputs of our activities. When I did that, I got this:
Work product (I hesitate to call them “deliverables”) may be categorized along three axes:
- Technique: What is the tool you’ll use to prepare the product? Pen and paper? Whiteboard? Vector diagramming program? Bitmap painting application?
- Artifact: What is it that you’re drawing? Is it a screen? A more abstract representation of a screen? A thumbnail of a screen? A flow chart? A site map? A concept model?
- Use: What role will the work product serve in the project? Is it meant to capture design decisions? Explore different design options? Present a nascent concept for buy-in?
Three Facets of Deliverables
Permit me to get a little more esoteric. You can assemble values from each of these three axes into a sentence:
I’m going to create a [artifact] with [technique] to use in a [use].
Swap out the variables with any of the possible values and you get reasonable sentences:
- I’m going to create a wireframe with vector graphics to use in a prototype.
- I’m going to create a thumbnail with sketching to use in functional specifications.
- I’m going to create screen concepts with HTML to use in a storyboard.
(My grammar isn’t perfect, but you get the idea.)
These combinations should be up to the individual designer. Several variables will contribute to the decision: proficiency in different techniques, the current stage of the project, the capability of stakeholders to understand different work product, the level of effort, the nature of the ideas to be conveyed.
In the context of this model, some of the more controversial terms lose their status as a hot button:
- As a technique, sketching is only the act of drawing something with pen and paper. I can draw anything (wireframe or concept model), though the fidelity inherent to the definition of some artifacts precludes the use of sketching to a greater or lesser extent (eg: screen comps). I can use sketched artifacts in various ways.
- As an artifact, wireframes make no claims about how they’re rendered or employed. In this model, a wireframe is a representation of a screen or user interface or portion thereof that varies by its abstraction and fidelity.
- Finally, a prototype is defined by its use or function. Prototypes demonstrate behavior and functionality and may be used in a variety of contexts: usability testing, feasibility assessment, or design documentation. The exclusion of certain techniques and artifacts toward these ends, however, is the designer’s perogative.
Implications
Some combinations of technique-artifact-use are less compelling (or useful or efficient or realistic) than others. Some combinations have well-worn paths between them and others barely tread are worth exploring. Regardless, the only comparisons worth making are within an axis. Let’s debate the merits of creating screen abstractions with HTML vs. vector graphics, but let’s do so by controlling two of the other variables. Keep artifact and use constant, and debate technique. Or keep technique and artifact constant (“hand-drawn concept models,” for example) and debate appropriate usage.
The other thing this model makes explicit is the underlying need driving a designer’s decisions. Such exposure forces us to consider circumstance and rationale when asking designers about their chosen approach. We might look at a technique-use-artifact combination and assess what needs it addresses and what needs would be ill-supported by the approach. Tell me you create vector-based wireframes for prototyping and I might tell you that I don’t have time to invest in the production.
Perhaps because we can turn any approach into a verb, like “wireframing” or “prototyping” or “sketching” is what makes us think they can be subject to apples-to-apples comparisons. But breaking work product down into a meaningful classification scheme lets us introduce nuances into every aspect of our approach: Something drawn by hand can be as formal as anything prepared digitally; vector graphics can be in an illustrating application or in a diagramming application. Ultimately, creating a finer-grain axis elevates our conversations, allowing us to use a more formal theoretical framework for talking about our approach.