The Future of WireframesMar 2, 2010 In Design By Nishant Kothary
As we move into the next decade of web design, it's time for us to reevaluate our understanding of wireframes—a tried and tested user experience staple
This article is part II in a series covering the topic of Web Design. Check out Part I—The Anatomy of Web Design, Part III—A Common Sense Content Strategy and Part IV—Discovering Trustworthiness. Evan Sharp will contribute the remaining article. Follow us on Twitter or subscribe to our RSS feed to be notified of its publication.
Riddle me this: How do you piss of a UX professional? The answer: Call him a “designer”.
These days, user experience professionals look down on the word “designer” because it implies that their primary role is to paint pretty pixels. UX is more than that, they clarify. Much more!
Just how much? Well, here’s a diagram (that uses pretty pixels) to explain how much more—
Holy guacamole, Batman! Elliptical hotness!
But wait! Does this diagram mean there is only one successful UX professional in the world? Steve “DamnItNotHimAgain” Jobs? Because no so-called “designer” can possibly wear all these hats.
It’s time we end this madness! While we’re squabbling over why one type of designer is different or better than another (and falling prey to one of the oldest colonization tactics in the book: divide and conquer), our industry continues to build crappy software. And without us.
Convergence in the Simulacrum
IA, content strategy and visual design are quickly converging on the Web. As design becomes democratized and users demand more than the “craigslist experience”, business owners are discovering that the way to keep users on a site is to differentiate themselves through intelligent content and innovative design that exist within the natural patterns available to the respective mediums (browsers, phones).
In 1999, Jakob Nielsen wrote an article that was undeniably ahead of its time: Differences between Print Design & Web Design. He argued that anything that is a great print design is likely to be a lousy web design due to the inherent differences between the two mediums. Most notably:
- Print design is 2-dimensional while web design is 1-dimensional and n-dimensional simultaneously. The web experience is fundamentally a “scrolling experience” dominated by movement between pages through hyperlinks.
- Print is about seeing, web is about doing. The “look and feel” of a web site is dominated by “feel”,i.e. the user experience. This is because doing always makes a stronger emotional impact than seeing.
- Print is immensely superior to the Web in terms of speed,type, image quality and canvas size. The Web has problems associated with low bandwidth, low screen resolution and limited screen sizes that affect the user experience significantly.
Fast-forward to 2010 and it’s pretty easy to see how these differences have diminished drastically—or even disappeared. Users have become savvier and technology has improved. The leading edge of web design capitalizes on how minor these differences are today. Print-y web sites like Jason Santa Maria’s personal blog or Carsonified’s business site are just two examples of this. You can find hundreds more on web design showcases like Drawar.
I daresay to God that the Web is finally converging with Print. So, where does this leave our trusty wireframes?
The Problem with Wireframes Today
You can find hundreds of definitions of the word ‘wireframe’ on the Web. Here’s one that represents what’s typically practiced today [courtesy webopedia]:
A wireframe is a visualization tool for presenting proposed functions, structure and content of a Web page or Web site.
Unfortunately, the most common interpretation of this definition practiced in workplaces leaves much to be desired:
A wireframe is a line drawing that dictates exactly what functionality and content is located where on a Web page or Web site.
This interpretation drastically limits the potential of a web design. It sets a glass ceiling for the visuals and copywriting, two supremely important aspects of great web design. It promotes the notion that visual designers and copywriters needn’t bother themselves with size, location and functionality of the elements of a design and that their individual products—the UI and the copy—don’t play much of a role in shaping the flow and interaction on a web site.
This may have been true in 1999, when we were all getting used to the new UX metaphors of the Internet. But it certainly isn’t the case today, in a time where mediums and disciplines are converging and metaphors like the “back button” or “scrolling” have become muscle memory.
Bottom line? We need to update our interpretation of the word “wireframe”.
A little less than a year ago, Isaac Pinnock of Made by Many wrote an article titled, The Future of Wireframes? Our articles share titles and arrive at very similar conclusions, but they use some very contradictory terminology along the way.
Isaac wrote about terrible “functional wireframes” from the 90′s being replaced with wonderful “visual wireframes” of today, for example:
10 years ago the first wireframes I used were about as functional as you can get – a long list of page elements: static text, dynamic text, input text, radio button and so on. They were universally awful. About the only concession to help people understand how the page worked was to group common functionality into individual tables.
The wireframes were functional rather than visual as they were used to describe how the page should be built. Certainly, when you consider the screen from a developer’s perspective a list of different functional elements is probably quite logical.
However, from a user experience point of view this was a killer. Functional wireframes are incredibly difficult to read – the method of presentation gets in the way of being able to translate the information into a real screen, especially at the review stage.
This is going to seem very confusing, but unlike Isaac, I use the term “functional wireframe” in a very positive light and take for granted that wireframes are “visual”. By attaching the label “functional” in front of “wireframe”, I am asserting what is and isn’t in scope for that particular wireframe. The first page of my wireframe deck explains this clearly:
Functional wireframes—call them whatever you want—strike a balance between functional specifications and traditional wireframes. They have some very powerful benefits, especially when the members of a design team have cross-disciplinary skills (this is usually the case today). Most notably:
- They democratize layout decisions, allowing the natural synthesis of a more unified final design.
- They encourage collaboration and allow designers (visual, IA, content, interaction, etc.) to arrive at a holistic vision.
- They help manage client and stakeholder expectations by focusing the discussion on page-level functionality during reviews.
Of course, for functional wireframes to work, there is a higher tax on softer skills like communication, feedback loops, and trust. Functional wireframes are not for organizations that haven’t grasped basic principles that allow us to predictably design great solutions that meet business needs.
But, as the MIX Online redesign case study demonstrates, functional wireframes can truly promote the behaviors necessary to create more cohesive designs.
The MIX Online Case Study
We created MIX Online’s functional wireframes over the span of exactly one week (the IA phase). As promised on the introductory page of the wireframe deck, I attached a color code at the top of each wireframe to indicate my confidence in its layout. Here’s an example of a profile page wireframe:
The process I used was pretty simple: I created a couple of wireframes a day, updated the deck and then posted it on both Basecamp projects. You may remember from Part I of this series—The Anatomy of Web Design—that the MIX Online stakeholders were restricted to one dedicated Basecamp project, while the design team was restricted to another. I served as the conduit.
On the stakeholder side, the MIX Online team was focused on finding gaps in my thinking and ensuring that I wasn’t missing any needed functionality. On the design team side, Tiff, Matt and I were engaged in intensely iterative conversations—digging into the content strategy, formulating a strategy and tone for copy, brainstorming around visual design, developing a category/sub-category taxonomy, and so on.
What we didn’t spend any time discussing was layout—in other words, the location of all the different boxes of information. Functional wireframes postpone layout discussions and ultimately rely on the Visual Designer to finalize layout of the various elements on the page. This is not to say that I didn’t suggest page-level layout in my wireframes. In fact, I did—and in many cases, strongly so.
For the most part, though, I didn’t get caught up in layout details. My primary interests were to ensure that I had created a sensible sitemap and captured all the right functionality to support our business. I was also focused on ensuring that I’d partitioned the functionality between pages to encourage the right behaviors among users.
You can download the final set of wireframes by clicking on the image below. I encourage you to compare the wireframes to the actual site. Notice that in many cases, even the layouts marked “green” didn’t quite work out. For instance, the Labs page is one where Matt decided to go with a simplified layout similar to our prior lab page.
As a whole, this approach departs from traditional IA methods—which include providing an actual blueprint for the site, layout and all. But it’s precisely this departure that is necessary to take designs to the next level.
In parts III & IV of this series—Tiffani’s article on Content Strategy and Matt’s on Visual Design—you’ll see more examples and evidence relating to effectiveness of the organic functional wireframe approach.
Back to the Future
Daniel Pink argues in his book—A Whole New Mind: Why Right-Brainers Will Rule the Future—that software design is fairly unchartered territory, but will mature in this century.
Web design is one of the sub-genres of software design that’s just started a slow crawl, characterized by constant retracing of steps, out of its infancy. Less than a decade ago, the introduction of WYSIWYG editors promised to deliver the holy grail of web design. Today, good ol’ text editors like TextMate—the ancestors of WYSIWYG editors—are taking their place yet again.
The point is that the discipline of user experience could and probably will look completely different a few decades from now. IA as we understand it could cease to exist, and it could very well merge with visual design. The possibilities are endless.
Which is why we need to entertain the idea that we’re doing it all wrong at the moment and embrace the notion of cross-disciplinary approaches whenever we get the opportunity. Functional wireframes are but one attempt at that.
Isaac Pinnock said it best in the conclusion of his article:
The best sites are those where there’s a seamless divide between the look, the content and the experience. Being able to model an interaction and understand how someone moves through a site are crucial skills in this trilogy. It’s time designers stepped up to the plate and claimed wireframes as their own.
p.s. If you liked this, then you may like what I write at rainypixels.com.