Death to “Wireframes”

How to limit your creativity with little grey boxes

I hate the word wireframe. I hate this word mostly because to people who are not familiar with what XD is they get confused and associate XD with “the people who make the wireframes.” and (worst of all) the person who figures out the mess made by someone else who didn’t think through a design.

I hate it also because of the limiting way what most people think of as a wireframes limits creativity and true experience design.

Wireframes are:

• Wireframes are schematics that are best used for on-screen experiences.
• Grey and only account for information categorization and hierarchy
• Linear and difficult to account for complex operations, animation, motion and anything that is dynamic.

And I dare say old school wireframes should die. Now.

What was the purpose of them in the past?

• Help to make decisions about information belongs at different points of an on-screen user flow
• Describe the functions
• Determine proper placement of functional elements
• Are an easy way to edit and change working designs

And I submit prototypes are much better way to do this.

We live in a world where the user experience is not always going to be on-screen. Most great design involves a complicated set of scenarios that involve on and offscreen interactions.

That will still require specifying certain parameters of the interaction.
More importantly, we live in a world where we are designing over specific platforms, adding to an existing design or ecosystem or working in very different ways.

So I like the more generic term “design specification”.

A design specification is the handy handy document that captures the thinking and the process and the details that got you from point A to point B of a design.

It shows the overall conceptual model, the journey a user goes through showing what happened from the first time someone interacts with the system (offline and online) until the end of any given scenario.
It is a living catalog of the things the prototype is not able to say for itself like the specific behaviors and the flows of the screens and the details of specific tasks.

And most importantly, a prototype is part of this design specification. The prototype shows the motion, the way I traverse through screens.

So I say skip the wireframes especially if you are:

• in a Lean team
• A “Pair design” environment
• When existing visual design patterns and libraries exist
• You can get away with a pretty robust prototype & can get away with specifying just the core screens and flows.

That said, there are times when you must make wireframes.

This is when:

• Complex, information heavy on-screen (web/software) experiences
• Linear processes
• Key informational or functional screens
• When teams are working on separate parts of experience (Waterfall process)
• Creating something entirely new
• When development team is working on infrastructure or object modeling
• When outsourcing development or design to other teams

So… for you app happy people, service designers and people like me who are designing for oddball experiences… go forth and make prototypes and anything that doesn’t neatly communicate in the prototype.. make a design specification.