(Stephen Turbek, at Boxes and Arrows, tells us how to get better results from our wireframes. Wireframe prototyping can provide feedback early in the design cycle, reducing costs and improving the quality of the final software. By putting a little flesh on the bone, we can get even better results.
Hooked From the Start
Stephen starts his article with the following quote…
How many times have you been asked, “So, is the new website going to be black and white too?†after presenting your wireframes to a client or a usability test subject?
A very solid opening to his position that when you only use wireframes, you introduce problems. Wireframes are designed to eliminate problems and “clutter” from the feedback session. Feedback sessions provide us with a lot of information, and the challenge is to separate the noise from the signal. The goal of wireframes is to eliminate sources of noise, to make it easier to focus on the signal. But using wireframes also introduces noise into the data.
He goes on to provide a real world example of a website under development for Verizon – showing wireframes and “low fidelity prototypes” that include more information than just the wireframes.
Why Wireframes?
Stephen makes an interesting point – wireframes (named after 3D modeling techniques) were initially designed to provide quick feedback and insight into 3D models, without the expense of complete rendering. As technology reduced the cost of of rendering, rendering cycles began to replace wireframes as early prototyping tools.
A wireframe, in the user interface world, is a minimalist visualization of a website or application. It shows where information will reside on a page, and what information will be shown. When using a wireframe to get feedback, it allows a designer to (attempt to) isolate the feedback about content and layout from other data (like feedback on color schemes and graphics). It also allows for more rapid prototyping because the prototype can be built as soon as a layout is done, without waiting for colors and graphics and branding to be incorporated into the design.
Why Not Wireframes?
Expanding on Stephen’s point, the lack of information detracts from an understanding of the usability of a design. Colors (such as blue hyperlinks) do provide visual cues for users. Branding and navigation elements provide a sense of context and comfort. The absence of these things can distract the people we were trying so hard to not distract.
What About Cost?
Another goal of using wireframes is to reduce the cost (and time equals money) of prototyping. Stephen shows how in less than 15 minutes, a wireframe prototype is converted into a prototype that leverages existing branding, navigation, colors, and images. 15 minutes is not a long time to spend to achieve this striking difference (check out the images in Stephen’s article). When showing multiple screens in a site with structured navigation, most of those investments will be re-used across multiple screens.
Why It Will Work
The ability to re-use the “extra bits” is the key to why it will work and not just the key to why it won’t cost more.
People who think about website advertising worry a lot about ad-blindness, or the ability of people to ignore ads over time. We actually depend on it here, to allow our regular readers to tune-out ads that appear in consistent locations and formats and instead focus on the content of the articles. This same phenomenon applies to these augmented wireframes.
The lack of context that a wireframe creates can be disconcerting or even confusing. The (valid) concern that drives the use of wireframes is that providing all the other stuff will distract the users and prevent them from providing feedback on content and layout.
The ad-blindness effect will quickly allow people to ignore the “other stuff” and focus on providing feedback on the content and layout of a page. People are good at scanning pages – they have an autopilot that takes them directly to the “meat” of the page. And the presence of the extra content allows them to do that – where the absence of that richness will immediately trigger a “what’s wrong?” or “what’s different?” analysis.
Tips to Making It Work
Stephen provides eight tips, which we really like. We are concerned about one of the tips – to use “real data” instead of fake data. I had always learned that real data risked distracting the users, who might fixate on the fact that you chose incorrect data to display.
Today, after a prototype review session, we got feedback from our reviewers that it would help them if we used real data. The reviewers of our (fleshed out) wireframes were unable to visualize how the interface might behave with some real-world data examples. The data we were presenting and manipulating is fairly complex, and the contrived examples didn’t do a very good job of showing how the interface would handle the complexity it would need to support.
Using representative data is definitely a good idea – and as good as Stephen’s other ideas are, we’ll take his word for it that real data is even better.
Conclusion
Spend the incremental effort to make wireframes “feel real” by fleshing out some of the context that wraps the prototyped pages. That context will provide more comfort than distraction for users.
