The other day we looked at a few takes on a current debate in the user experience (UX) community of the role of wireframes in user centered design, what causes problems and ways to work together to get the most value from creating wireframes.
Problems with wireframes
Over the course of our practice here and elsewhere we’ve seen many ways for wireframes to get abused. Here’s a few places where wireframes fall apart:
- They betray a past in which UX tools were less complex and reviews were paper-based
- They don’t account for the role of graphic design in interaction and perception
- They exhibit limited or no interactivity: Interaction described in serial pictures or (worse) words.
- Over-documented wireframes become functional specs, slowing team velocity and increasing the likelihood of errors in comprehension
Wireframes have been accumulating cruft for too long, trying to do too much and too little: Too many words to describe features uninformed by visual exploration, and not enough interactivity to know if you have the experience right. Wireframes are a vehicle for speeding the team towards delivery, that’s it. If you find your wires are more than sketches with a bit of annotation, it’s time to stop and reconsider how your team is working together. You could be wasting your time and effort on things that don’t matter, or using the wrong form of communication to keep your team moving.
Wireframes and ideation
For getting down a new idea, there’s two steps to this dance: an initial sketch to get flow and function right and a visual design to make that product appealing and more useful. There are two dancers, who must be able to operate in tandem. It’s the same as the schematic for a blender and the industrial design of the blender. The difference is the prototype must carry much more information than simple, static wireframes. Prototypes are not the same as wireframes, not even close, but for the most part people (including us) use the terms interchangeably.
How we make the wireframes go
So let’s get our hands dirty. How does Fuzzy Math do wireframes? There’s many tools out there for creating wireframes like Balsamiq, Axure, iRise and many other tools (Visio, Powerpoint, Illustrator, InDesign, Dreamweaver, etc.), we prefer Omnigraffle to all comers, online, offline, desktop or what have you.
We can access it on our laptops, and use DropBox to sync and version our work. Omnigroup has already announced plans to produce the application for the iPad and it exports/imports to Visio, HTML, PDF and more.
At its most basic, our process is to arrive at the end of discovery with an understanding of:
- People who may use the product or service, the people around them, and what makes them different from people who would never use it.
- The tasks those people want to complete, and enough knowledge of the domain to understand the relationships between tasks: their importance, frequency, difficulty, duration and ordering
- The contexts in which they’ll perform those tasks. At work? At home? On the go?
Once we get there, we have a good idea of how things could work, and now it’s time to share those ideas. During discovery, there was probably some whiteboarding and sketching happening. Now it’s time to polish those into a more complete experiences vision of the experience. For us, that’s a wireframe with some prototype behaviors built in.
Using Omnigraffle we can change the states of individual pages, make navigation clickable, and do many other prototyping tricks, but it does have its limits. Over the next few weeks we’ll talk about how we use Omnigraffle and AppleScript at Fuzzy Math to overcome some of those limits in making a hybrid wireframe/prototype solution for capturing user experiences.