Why is every conversation about wireframes I’ve encountered lately so tense? For instance, at a recent UX Book Club meeting whose topic was a discussion of some articles on wireframes, the conversation moved quickly from the actual articles to the question of what a wireframe even was. What the discussion came down to was this: no one knows the answer, and trying to find it feels like a wild-goose chase—or like wandering off on our own down a yellow brick road to find the all-knowing and powerful Oz to figure the answer out for us.

The Wizard of Oz asks questions like: What is courage or heart or a brain? Who should define them for us? As I see it, UX design suffers from similar definitional issues. We don’t all mean the same thing when we say sketch or wireframe or prototype. So how can we all get on the same page? There are differences between a sketch, a wireframe, and a prototype, but how can we understand the distinctions and the best use of each? And what is their value as communication vehicles? Let’s discuss what separates a sketch from a wireframes from a prototype.

Sketches

“The intention of sketching is to separate design from the process of making.”

Sketching and design emerged during the medieval period, so these concepts are nothing new. However, what I believe many people forget is that the intention of sketching is to separate design from the process of making. In the context of design, sketching is rapid, freehand drawing that we do with no intention of its becoming a finished product. In fact, many times, sketching is only a foundation upon which we can overlay our actual design work. Thus, sketching is a tool that supports the process of making, not the actual design itself. Unfortunately, it’s all too easy to forget this fact in our quest to get to an end product. We sometimes hold onto our sketches like they are the be-all and end-all of design. Sketches should be

• quick—Making them does not require long periods of time.
• timely—You can create sketches on demand.
• inexpensive—Creating them is cheap, using materials you have on hand.
• disposable—You don’t care if sketches get thrown away.
• plentiful—Sketches don’t exist in isolation of one another.
• clear and use a common vocabulary—Sketches comprise simple symbols and lines.
• fluid—They have a fluidity of line and flow that imply creativity.
• minimally detailed—Sketches are conceptual and suggest structure.
• appropriately refined—They communicate just enough so others can understand your intent.
• suggestive and exploratory rather than confirming—When sketching, you haven’t yet made any concrete decisions.
• ambiguous—You have yet to work out the details, then overlay your design on the foundation your sketches provide.

Wireframes

“A wireframe’s purpose is to communicate and explore the concepts that come out of sketching—that is, those concepts you actually want to pursue further during user interface design.”

A wireframe, in comparison, is a basic visual guide we use to suggest the structure of a Web site, as well as the relationships between its pages. Wireframes come long before we do any visual design. A wireframe’s purpose is to communicate and explore the concepts that come out of sketching—that is, those concepts you actually want to pursue further during user interface design. Wireframing lets us outline a Web site’s basic, overall structure and flow and helps us explore divergent ideas from our sketches. I like Will Evans’ definition of wireframes in a recent article called “Shades of Grey: Wireframes as a Thinking Device.” He says, “for me, wireframes act as a form of thinking device for the setting and exploration of a given problem space.”

You’ll see there isn’t much change from sketch to wireframe—merely a slight refinement and greater formalism. Our initial drafts of wireframes remain tools or artifacts that we use during the process of making to aid conversations as design moves forward. Wireframes should be

• quick—Making them does not require long periods of time, but they do take longer than sketches.
• inexpensive—Creating them is cheap, using materials and tools you have on hand.
• viable—Wireframes are not as plentiful as sketches, so you should have narrowed your concepts down to viable options.
• clear and use a common vocabulary—Wireframes comprise simple symbols, lines, and indicators of interactivity.
• minimally detailed—They are conceptual and suggest structure.
• appropriately refined—They communicate a sense of structure and layout.
• confirmatory—Wireframes present concepts that need validation. When creating wireframes, you still haven’t made any concrete decisions.
• ambiguous—You have yet to work out the finer points of interaction and content.

Prototypes

“Our designs are still not final, but we have defined a set of ideas we know can actually be pursued, and we begin to refine and exemplify them.”

As we iterate our wireframes and get clarity on requirements and constraints, some of our ideas naturally fall away. It is at this stage I would say a real prototype exists. Our designs are still not final, but we have defined a set of ideas we know can actually be pursued, and we begin to refine and exemplify them. We may invest some light coding in them to achieve a degree of interactivity, but a prototype is still a communication tool and artifact. Prototypes should be

• quick—They should require only minimal development effort.
• inexpensive—The development they require does not require a major investment.
• clear and use a common vocabulary—Prototypes comprise simple symbols, lines, interactive components, and content.
• detailed—Prototypes include content and interactivity.
• appropriately refined—They represent an almost real application—though with a faked user experience.
• validated—In prototypes, a design is no longer ambiguous or suggestive. A prototype is an actual instantiation of an idea. However, it may still require fine tuning.

Understanding the Continuum

“There is no clear boundary line separating these design artifacts….”

Now comes the tricky part: deciding when a sketch stops being a sketch and becomes a wireframe, then a prototype. There is no clear boundary line separating these design artifacts, which is probably what makes our conversations about them so contentious and hard to articulate. In Bill Buxton’s book, Sketching User Experiences, he provides some descriptors of sketches and prototypes that ring true with me (see Table 1). They elicit the feelings the ends of the continuum should embody.

Table 1—The Sketch to Prototype Continuum, from Sketching User Experiences

Sketch	Prototype
Evocative	Didactic
Suggest	Describe
Explore	Refine
Question	Answer
Propose	Test
Provoke	Resolve
Tentative	Specific
Noncommittal	Depiction

In Figure 1, I’ve attempted to articulate a Sketch to Design Continuum visually. This illustration depicts the relationships between a design’s level of commitment and fidelity and what you are trying to communicate. These are the factors that matter when deciding where you are in this continuum. While the lines demarcating sketches, wireframes, and prototypes aren’t clear, the phases of ideation, concept validation, and refinement and usability are—and that’s where we should focus our attention.

Figure 1—The Sketch to Design Continuum

Sketches or wireframes support ideation and concept validation, while wireframes or prototypes are important for refinement and usability testing. When we are exploring and validating our divergent design ideas, a lack of commitment is important and beneficial. This allows us to be more flexible in our iterations and, therefore, more creative. As we start to whittle down our design options and refine those that merit further exploration, we need to start articulating them in a more realistic manner, so everyone on a product team can participate in the design conversation with the same understanding. This is why it’s more important in later phases to create wireframes or prototypes.

There are also clear differences in the communication that happens during each phase that help distinguish which artifact is the best vehicle. And lastly, you can see that the amount of iteration that occurs gets smaller and farther apart as we move toward the ultimate design. This is a natural progression as divergent ideas converge in an actual solution.

Why the Differences Don’t Matter If You Get the User Experience Right

“The reality is that wireframes are a design artifact—that is, a tool that facilitates the process of making that leads to design.”

We often consider our wireframes as deliverables, or final products, but this just isn’t the reality. This can be a tough lesson to learn. I know I’ve already spent a lot of time deciphering the semantics, but we couldn’t have gotten to this point without having first cleared some of that up. The reality is that wireframes are a design artifact—that is, a tool that facilitates the process of making that leads to design. Buxton says the lesson The Wizard of Oz teaches us is that, if we can do an effective job of following the example of the Wizard, we, too, can conjure up systems that let the people who use our products have real and valid user experiences, before any system exists in any real sense of the word. Keep the following in mind:

• It is the fidelity of the user experience, not the fidelity of the sketch, wireframe, or prototype that is important from the perspective of ideation.
• We can use anything we want to conjure up such user experiences.
• The earlier we create such design artifacts during the product development lifecycle, the more valuable they generally are.
• It is much easier, cheaper, faster, and more reliable to find a little old man who can create the illusion of wizardry with a microphone and some loud speakers than it is to find a real wizard. Fake it before you actually build it.

Think about this: Developers never actually implement a wireframe as it is—or, at least, I hope they don’t! That doesn’t diminish the importance of wireframes by any means. Creating these artifacts is critically important to a successful design process that leads to a successful product. Let’s just remember the purpose of these artifacts. As Will Evans says, “I use my sketches and wireframes as [a] means to make explorative moves and assess the consequences of those moves. As I explore the problem space, I could relatively easily keep the design models in my head, but I would fail in my primary objective to create a framework for a conversation among the stakeholders, the intended audience, and me.”

The Rehearsal to Production Continuum

“If we treat our sketches, wireframes, and prototypes as what they are—artifacts of the design process—we can see the whole process as nothing more than an iterative rehearsal process.”

If you’ve read any of my other columns, you are probably wondering where the theater is—besides the example of The Wizard of Oz that is. This time, I felt the need to clear up some preliminary points before getting to any theatrical analogy, but here it is: if we treat our sketches, wireframes, and prototypes as what they are—artifacts of the design process—we can see the whole process as nothing more than an iterative rehearsal process, as shown in Figure 2.

I keep coming back to an idea that I first discussed in my column “The UX Designer’s Place in the Ensemble” and again, in more detail, in “Putting Together a Production: A Rehearsal Strategy for Design.” As I said in that second column, design is not a linear process. Rather, like rehearsal, design is a process that has

• an iterative cycle
• distributed, independent, simultaneous invention
• unifying action
• a director who facilitates
• a forum for conversation
• a way of establishing structure—in design, the design artifact

Figure 2—The Rehearsal to Production Continuum

Looking Beyond a Single Production

“Rehearsal is just one example of how theatrical productions know how to articulate and separate the process from the product.”

Rehearsal is just one example of how theatrical productions know how to articulate and separate the process from the product. Looking at a bigger picture than any actual, individual theatrical production, there are other parallels to the concepts of sketching, wireframing, and final design in some types of theatrical productions as well.

For example, a sketch is like a staged reading. A staged reading is very much what it sounds like. The actors get up on stage, with almost no rehearsal and no memorization, and run through a show with script in hand. There is no production and minimal, if any, blocking or prep time. A staged reading is a creative experiment in a realistic setting, with an audience that provides feedback. It never turns into anything more, and a theatrical group usually performs it only once. Similar to a quick sketch that you can dispose of later, a staged reading is a tool that lets you talk about a story and its concept with an audience.

A show in a black-box theatre, which seats less than 150 people, is not much more than a prototype or proof of concept. It is a performance that occurs in a small space and has minimal production or technology. The people producing it have narrowed down their ideas, and the content and interactions are there, but they have undertaken no major development. We expect a performance that feels real, and such a show is much like a fully produced show, but its run is short lived, lasting only a few weeks at most.

A Broadway show, on the other hand, is a fully developed product. Lots of work, technology, marketing, and money have gone into it. Shortly before opening night, you can do only minor testing to tweak what is essentially a finished product—similar to doing usability testing at the end of a product development cycle—because big changes would be both difficult to do and expensive. This is the kind of production that runs years—or maybe even decades for a show like Cats.

Become Your Own Oz

“Whatever we call them, all three of these design artifacts are relevant when we use them in the right phase, for the right purpose.”

Ultimately, I do feel the conversation at our UX Book Club meeting was a good one. It’s nice to get a handle on the perceptions and semantics that are out there and understand what the issues really and truly are. Whatever we call them, all three of these design artifacts are relevant when we use them in the right phase, for the right purpose. But, to make the right decisions for your own projects, you need to become your own Oz. Create design artifacts that adequately define a user experience to help you get good answers to your design questions. When we use these tools as communication vehicles during the design process and understand that they are not themselves the end product, they can help us to design successful products.

This article was originally posted over at UXmatters by Traci Lepore. The title already tells, Tracy is comparing three tools: sketches, wireframes and prototypes.

Great slidedeck by Grant Robinson, Senior Designer at Xero, from his talk at Web Directions South in Sydney Oct 2009.

Photo credit: Josh DiMauro via Flickr

I recently explained why wireframes can hurt your project. My point was that in a lot of cases, you can save time by designing in Photoshop straight away or using a HTML prototype to flesh out your app. But some people rightly pointed out that wireframes were a better tool for sharing information in a way that’s approachable to people without design or coding skills.

Although that’s a good point, in my opinion there’s a better, faster, and easier way to accomplish that goal: prioritized lists.

Wireframes: an evil force of destruction and despair?

Goals and elements

It’s an extremely simple technique, and you don’t need any special kind of software to do it. You can do it inside a plain old email, and here’s how it works. For each page, make a list of all of that page’s goals and elements.

A goal is the reason that page exists in the first place. For a homepage, it could be something like “make people sign up”. For a support page, it could be “make it easy for people to contact us”, or maybe “route people through the right support channels so they don’t need to contact us”. You goal list should generally have between 1 and 3 items. Any more than that and it means your page lacks purpose and will not be effective.

And an element is simply anything that appears on the page: buttons, navigations, taglines, forms, etc. Your element list should include between 5 and 10 items, depending on how thorough you want to be. For example, it’s usually not very useful to list every single navigation element as separate items, and you can also omit basic elements that already have a fixed location like the logo or footer.

A call-to-action button on Zendesk.com

Once you have your two lists, sort everything in three buckets: Most Important, Important, and Secondary. Your “Most Important” bucket should not have more than 1 to 3 items, otherwise it’s a symptom of an unfocused page. Your “Important” bucket will usually have about 4-5 items, and the “Secondary” bucket simply contains all the other stuff.

Focusing on content

The advantages of this technique over traditional wireframes are two-fold: first, it’s quicker and simpler to do. But the other big advantage is that it encourages people to think in terms of goals and content rather than layout. Removing the layout from the equation completely means that all design decisions will belong to the designer when it comes time to create a Photoshop mock-up or a HTML prototype, and those decisions will be much more meaningful at that stage.

An example: Zendesk.com

Since the easiest way to learn is by studying a concrete example, let’s pick a site (for example, the great Zendesk.com by the fine folks at the Cuban Council) and apply this technique retroactively.

The Zendesk.com homepage

Goals

• Get people to try the service

Elements

Most Important

1. “Try it free” button
2. Tagline

Important

1. Main navigation (home, pricing, customers, your)
2. “What is Zendesk” paragraph
3. Companies using Zendesk

Secondary

1. Secondary navigation (contact us, resources, login)
2. “Close your customer loop”
3. “Register for live webinar”
4. “Your guide to selecting help desk software”

That’s it! Of course, coming up with that list in the first place takes some time and effort, but it’s still a fairly quick process compared to whipping up a wireframe.

You’ll notice I left out some elements. For example I didn’t mention the homepage screenshots illustration at all. That’s because this kind of graphics is there to support your message, but it’s usually not the message itself. At this stage of the process, you probably won’t know what will work best yet, and that kind of decision is best left to your designer.

I hope you’ll get a chance to try this technique for your next project, and be sure to let me know how it worked for you.

Sasha Greif just recently published this follow up on his article "Why wireframes can hurt your project". With "A simpler and faster alternative to wireframes" he introduces a technique that prioritizes content and focuses on goals and elements before a Photoshop design or HTML prototype comes into play.

Over the years I have perfected a special skill. It goes like this:

I send out wireframes for review and feedback. These may be low fidelity sketches or high fidelity interface mock-ups. Whatever they are I send them out for comment because I believe in a collaborative process.

I compose the email, explain what wireframes are and how they are not indicative of actual design etc. and press send. Then I wait...

And here is where my special skill comes in because I sense what is coming next. It's inevitable. At some point - typically within the first 15 minutes - a colleague and/or client is going to come back and write the following:

"These are good but it would be great if you could add more colour."

Figure 1: Spot the difference, one is a low fidelity wireframe the other is a visual design

Obviously at this point I smile/sigh to myself in despair. It doesn't matter how many times I iterate the purpose of wireframes and how they are differentiated from visual design by their very nature and concept, people still misinterpret their purpose.

In some ways I understand this. It's human behaviour. People think visually and so they are cognitively pre-conditioned to think that a wireframe is intended to convey design. They see the broad outline of an interface and rather than focus on perhaps the interactive elements and the mode of navigation, they think about copy and imagery and of course, colour. But here is the crux of my argument.

There is design and there is visual design - in this context the two are very different. The visual graphical layer should come much later in a product's development - it's the skin that brings a product to life but it is not the element that will define:

• What elements rest on each page
• How the navigation and link metaphor works
• How you can cross-sell content/products to users

These attributes are some of the types of things that the wireframes define. They are as equal in importance to the look and feel but theyare a completely separate element altogether.

There is often a lot of debate in the IA professional network - some think wireframes are not a part of design at all, and others fervently disagree. It's a messy area. My take has already been explained. If you search the definition of design you can plainly see that wireframes fall into the idea of "specifiying an object intended to accomplish goals in a particular environment". A technical definition that can be roughly translated as a roadmap of how something is going to interact with your users.

That's what wireframes do. By implication then they won't tell you what colour palette to use. How to brand your product visually. Nor will they tell you what colour to make the links and what treatment you will need to apply to images. That's not an information architect's job. That's a VISUAL designer's.

I am sure you, reader, know what I am on about. If you work as an information architect I am sure you have some stories of your own to share on this matter. Either way, I think this rant has cleared things up and I feel good about getting it all out in the open.

I will step down from my soapbox now.

Amir Karim, User Experience Architect at Microsoft elaborates wireframes.

The right way to wireframe by Russ Unger. #rwtw

Image credit: Chris Depa, Straight North

Additionally, sketching helps us change our ideas to make them more reasonable where they can become a reality, and gives us a general outline when we bring our design ideas to say, Photoshop.

Great design ideas should always be sketched out to be better formulated and somewhat finalized before brought to the digital world. Great design ideas should always be sketched out to be better formulated and somewhat finalized before brought to the digital world. This helps us develop on our design idea, which actually helps us provide a better end result or product, than that of whom did not sketch the idea.

Therefore, eliminating sketching as a process of gaining experience is not a valid point as you are eliminating a crucial process in design that can sometimes make or break a project. To better prove the point on how sketching can strengthen your design ideas, we discuss several benefits to sketching out our designs before making them a reality.

Eliminates Time Wasted

One obvious factor or benefit of sketching your design ideas is that it eliminates time you could have wasted.

You may be wondering how sketching can eliminate wasted time while you could simply start right into Photoshop or Fireworks. You have a valid point; however, even the greatest ideas need refining. Sketching enables you to plan before actually starting to design. You can solve a lot of UX and design problems by sketching ideas on paper prior to firing up your preferred design software.

What this means is, spending the time to sketch your idea on paper will actually help you visualize your idea better than you would when you imagine it.

It allows you to get a better overlook on how it will turn out, and if you do not like how the design idea is turning out on paper, or the idea may not be reachable or feasible, you have not spent the time actually bringing it to life in Photoshop, but rather just a half hour throwing it on paper.

Therefore, a not so great idea will not waste hours out of your day just to realize that it will be heading straight to your trash bin.

Helps Expand on Our Ideas

Whenever we imagine ideas, they are usually the skeleton of what the end result can be.

However, when you take an idea directly to Photoshop, you do not quite have the brainstorming you would if you brought it to paper to expand on it, and thus great ideas are often suppressed and lost, making your great idea turn into an exceptional idea or design.

However, by bringing your designs from mind directly to paper, it gives you a completely new and different level of how you visualized it, allowing you to expand on your ideas for the design often bringing it from exceptional, to a mesmerizing drool-worthy design.

Therefore, it is definitely worth the time and effort to sketch your ideas out before making them a reality.

Helps with Group Feedback

Let’s face it, when we spend hours and days and weeks bringing an idea to life in Photoshop, we are generally not open to major feedback that will attempt to overhaul all the work, effort, and time we have put into it to bring it to life already.

We would just reject credible and excellent feedback if it means we need to change a huge chunk of our design such as a structural change, or we would be forced to perform these major changes by a design firm, which causes delays in the completion of the design project.

However, when you sketch your ideas on paper or on a whiteboard, your group can provide feedback allowing you to bring changes to the sketch in seconds helping make your design an excellent piece of work in the end.

In fact, many new great ideas whether design or not are structured by brainstorming on paper first with their group before going forth and bringing some sort of prototype to life.

Increases Creativity

By bringing your design directly to Photoshop you are limiting your creativity as you are trying to follow the idea you imagined to get some sort of prototype completed before actually changing a few things around.

A sketch on paper acts like your design prototype for your idea or ideas. This allows you to quickly expand on it by using your creativity before actually bringing it into Photoshop or to the browser for a graphical preview.

This also happens to save you time from manipulating your prototype in a graphic editing program rather than on paper which tends to only take several seconds rather than several hours.

Design Evolution

One great thing about sketching out your design ideas is that later on you can look back and see how your design has evolved, from sketch, to prototype, to the final product.

This not only is just for personal satisfactory, but it actually helps you improve on your final product months down the line.

When we design websites, we tend to design them specifically for the content we need for that website at that current point in time, however, our sketches often contain different content containers before we scratched them out.

By going back and looking at our sketches when we are looking for ideas or how our design or designs evolved, it will actually help us bring the containers we eliminated into our current design if we decided we needed such containers or elements later on.

GrindSmart Magazine on idea strengthening with the help of sketch notes and wireframes.

Documentation, of course, is critical to defining and confirming your client’s needs, and it’s critical for providing direction to your design and development teams.  As part of your documentation, wireframes provide visual conceptualization that cannot be captured in a text-only document.

At Urban Insight, when we kick off a new web development project the first document we produce is the formal Project Requirements Document. This starts as a working document and, in its final form provides the client-approved outline of project purpose, feature requirements, technical requirements and creative brief.

On the heels of the Project Requirements Document we begin development of the wireframes. Wireframes also begin as a working document, have two phases and serve two critical purposes.

1. To initially communicate basic content layout requirements to designers as input to the creative process
2. To subsequently provide specific detailed functional requirements to developers

Between these two phases of development, the wireframes will grow and evolve.

Input to the design process

As a major source of input to creative development, wireframes walk a fine line. They must illustrate content priority and content layout as it will best support the website’s business objectives, but beyond that they must not provide a specific sense of design. 

It's important your designer feels that within the creative process he or she has the freedom to rearrange content items while maintaining their relative importance within the presentation.  It's important that your client remains open to the various creative options that your designer presents. 

At the end of the first round of wireframe development, your client
should be happy that the site will effectively communicate what it needs
to communicate, and that it will lead the each website audience into
and through the site as required.

As a wireframe developer, if you have creative sensibilities, this may be a difficult impulse to control. The first round of wireframes, however, should be a technical illustration. Save your thoughts on design for your review you’ll have with your creative team on content layout and creative requirements.

Home page wireframe as input to design process

Home page mockup from wireframe input and creative brief

Input to the development process

Creative development, of course, is its own phase. Once design is signed-off, the wireframe document will subsequently expand to illustrate the requirements for content pages and any further design requirements for those pages, and they will become the document for detailed  page-by-page functional specifications and direction to the developers.

In the end, the newly launched website may not look a lot like the very first round of wireframes, but what’s important is that they trace the site’s evolution from content requirements to functional requirements and help to produce a website that is user-friendly, compelling and effective for the client.

Content page wireframe with functional specifications

Content page final implementation

Kurt Rademaekers on the importance if wireframes.

A year ago, I proposed the future of wireframes.

My proposal centered around relaxing the stranglehold wireframes have on layout decisions. Traditionally, the exact positioning of the different "boxes" of information has been in the information architect's domain. In other words, when a wireframe shows a featured article rotator above a sidebar of resource links, it is expected that the final site will have the featured article rotator above that sidebar of resource links. In fact, it is expected that all such boxes of information show up relative to each other as depicted in the wireframe.

There are several problems with this approach, but let's focus on the fundamental ones.

I Got 99 Problems

Despite how things turned out, nature intended the layout and the visual design of a site to go hand-in-hand. You pay a notable price when you decouple these two aspects of the design process: a price that generally manifests in the form of a design that's not very exciting.

In addition to the decoupling problem, there is the problem of lost opportunity cost. When members of a design team have cross-disciplinary skills—that is, when they are experienced generalists—you endure the opportunity cost of not maximizing the team potential if you decouple IA from the rest of the design process.

But finally, there's the question of responsive design: how does IA adapt to include responsive design?

I suspect that those who specialize in IA will argue for more wireframes: wireframes for every form factor. It may be a great way to inflate the project budget, but remember Biggie's infinite wisdom? In all seriousness, creating wireframes for the full responsive matrix isn't sustainable. It's counterproductive, and as Trent points out, it's unnecessary. It also compounds the decoupling and opportunity cost problems I mentioned earlier.

So, where does that leave us?

It turns out that the key to solving our dilemmas lies in our ability to address the source of all these issues: the issue of control.

Control Freak

For the most part, today's approach to IA is similar to architecture in the physical world: create an exact blueprint for what is to be built, and then build it.

This approach worked well when IA was emerging as a discipline in a time where designing for the Web was unchartered territory. It was a practical way to solve problems up front, control scope, and manage stakeholders. But times have changed, and while it's still necessary to know what you want to build up front, it isn't necessary to have it fully locked down. It isn't necessary for the IA to exert full control over it.

In fact, it's better to ease up on the control.

Fluid Information Architecture

As I proposed in The Future of Wireframes, information architects (or, whoever owns the wireframes for the project) can often improve the quality of a design drastically by relaxing their control on layout decisions. I introduced the concept of functional wireframes to illustrate this.

My proposal this year—something I'm calling "fluid information architecture" in the spirit of our times—is for wireframes to have less control over other aspects of information architecture, like responsive architecture for a site and functional copy decisions.

There are two major benefits to this approach. First, it allows responsive content choreography to happen downstream in a much better way. Secondly, due to the nature of the beast, it introduces a level of delightful unpredictability for our users. Remember, these are exactly the kinds of results we were hoping to gain.

However, the fluid IA approach brings an elephant into the room with it: if the information architect doesn't control the blueprint of the site, then why have the role?

This is worthwhile question, and I've found that the answer varies from project to project depending on scope and makeup of the design team. Sometimes, the answer is for the information architect to focus on other aspects of the process: identifying page-level information, determining relative priority of information (Allison House provides an excellent example), capturing page states, and so on.

But a perfectly reasonable answer is for the role of the IA to be combined with surrounding roles, like creative director, or front-end developer, as we did in the 10K project.

The 10K Apart Case Study

For those of you who haven't heard of the contest, the 10K challenges contestants to build the best application they can with no more than 10K (yes, kilobytes) of code. You can read about this year's contest here.

Among other things, I served as the information architect for 10K Apart. As you'll see, I drastically reduced the scope and influence of the IA role precisely due to the scope of the project, and who was on the design team.

I was fortunate enough to have the Paravel trio come on board to help design the site. This isn't a gratuitous plug. Paravel is on the top of their game in several areas of the design process—among other things, they create wonderfully laid out websites, and have cracked the responsive nut better than most. This helped me adapt the information architecture approach for the project, particularly in three areas:

1. Layout (zero control): I knew I could relax the control I exerted on layout in the wireframes. This is one of Paravel's major strengths, so I put layout in their able hands.
2. Copy (relaxed control): Copy, much like layout, can function as a focal point for the site aesthetic. I encouraged the Paravel team to experiment with copy in the context of the visual design.
3. Responsiveness (zero control): Paravel is pioneering responsive web experiences. It felt natural to leave the responsive architecture of the site up to them.

To fully illustrate my point, I'm making the functional wireframe deck for the project available for your perusal.

Download 10K Apart Wireframes → 1.4MB .PDF

As you can see, I mandated only one thing: page-level information. The rest was at Paravel's discretion.

Some things they chose to keep (like the entry form and the gallery layouts), while others they completely changed (the hero banner and layout of home page elements). The process was seamlessly fluid as becomes apparent in Reagan, Trent, and Dave's posts.

The resulting design—and I may be biased here—turned out to be functional and unpredictably delightful: http://10k.aneventapart.com.

Finally

It's widely accepted that the information architecture phase of a project can make or break the final experience. And this is true. But this belief rests on the assumption that control creates predictability. While this checks out in theory, we've seen how it quickly falls apart in practice.

Ironically, in practice it seems that creating predictably delightful designs isn't about exerting control. It's about judiciously giving it up. It's about identifying the right fluidity for the process and establishing the optimal flow.

Nishant Kothary wrote a follow up on his last years article "The Future Of Wireframes". This time he looks back to what he proposed last year and takes it even a step further.

In the current design atmosphere , I hear the term wireframe being thrown around a lot more than it used to be. Over the last few years, wireframing is a process that has endured a lot of misunderstanding and has been become much more widely known as a software and web design methodology. I’ve begun to notice that the concept is warping and not for the better. This twisting of the terms is making it difficult for newer designers and students to understand the real application of the process.

Wait, whats the problem?

Recently, I gave a talk at a design school and I had a few students ask me about wire-framing and their mental model of it was pretty far off base. Their concept of wireframes included design, finalized layout, and a number of aesthetic decisions to name a few of the inappropriate things they considered part of wireframes. The worst part : they didn’t even want to do it. These students just knew it was a step they were supposed to do but didn’t understand why it was so useful. They just accepted it as step in the process and breezed through it to get to the fun look and feel parts. This was troubling to me. At first, I thought it may have been an isolated incident, but more and more I have been noticing that the workplace application of the process is suffering due to a bit of incorrect and popular saturation among clients, new designers, producers, product designers, etc. Wireframing is an essential step in the web design process and it would be a shame if up-and-coming designers did not learn to love it.

Wireframes are blueprints

It interesting that designers will understand that complex structures such as buildings or cars require careful planning and architecture but then take a similar ideas for the web industry and barrel into them with little or no planning. Granted, a website is not a car, it is still a substantially complex undertaking and leaving out careful planning and structure is the recipe for a lot of wasted time, work and money. I promise I’ll get to the practical implementations but first, part of the initial battle is making sure everyone understands what a wire-frame is and what it is for.

Use the metaphor

The blueprint is my favorite metaphor for wire-frames because no person thinks of a blueprint as a rendering of what the building will look like or uses it to make design or aesthetic decisions. It is purely a map of function, priority and information. Perhaps more importantly, no sane person thinks you can a create a building or car without a blueprint. That’s a healthy attitude.

Wireframing is not…

Before you begin to start using wire-frames in practical situations you have to know and be able to explain to clients, employers and colleagues what wire-frames are NOT for:

Wireframes are NOT designs
In fact, wireframes should be completely devoid of font choices, color, pictures, logos, etc. Most people think visually and it is extremely common to think that a wire-frame is a intended to convey design. It is extremely easy for a non-designer to think or act like wireframes reflect final designs or placements. Don’t confuse the function by putting visual distractions on your wireframes. Remind them: there is little visual fidelity, wire-frames are about working through functional issues and organizing information.

Wireframes are NOT final layouts
Another common belief about wire-frames is that the designer is just going to come in and lay a skin over the top of the frame and BAM! the site is finished. It is clear by the difference in many designers that it is nearly impossible to separate the final effective layout from the aesthetic design. But, that is a different stage and it can be stifling and disastrous to try and cling to a wireframe layout.

Wireframes are NOT prototypes
There is actually quite a bit of confusion between wireframes and prototypes. Its surprising since they are pretty radically different tools in the process. Simply, wireframes are for organizing information and prototypes are for evaluating interaction. While wireframes and prototypes can have similar levels of visual fidelity to the final product they are really completely separate steps with fundamentally different objectives.

Take the time to establish the basic goals and purpose for building wire-frames with your clients and teams. It will always get you off on the right foot.

Using Wireframes

As I mentioned, I have heard from a shocking amount of novice designers and students that they do not want to wire-frame, but they know they should. A few have even told me that they don’t see how it helps them. Absolutely, there is no reason to work within a step of the process if it doesn’t serve any purpose. Fear not, wireframing is one of the most purpose driven and useful pieces of the design process.

Let’s get practical…
In an effort to fulfill my previous promise and give a springboard for production application of wireframing beyond the conceptual : I am going to detail a few main aspects and purposes of wire-frames and give practical uses and action items that I have used in successful client situations.

Pure Usability

Wire-frames are one of the most effective methods to work through usability testing and ideas. Keep in mind, we are taking about usability NOT user experience. A common mistake is to think that Usabilty = UX. It does not. But, that’s really whole other discussion for another time. However, it is important to take away that usability is simply the measure of how easy it is to use a product. Which is a measure of function not design or experience. In a final production situation, sometimes it is difficult to separate the easy of use from the other elements that are at play in the overall experience. When you chose to attack usability while its out in the open you will not be distracted by other elements.

Practical Usability Tips:

• Walk-through a conversion path : Map out every path that a user can take. Map how many steps and how if it is difficult for the user to get to where you want them to go.
• Test system language : Does every member of the team from developer to client understand what the terminology means without explanation?
• Map out user tasks : Using the wire-frame, go through each step that a user needs to take to complete a task via the information only. This can expose fatal site architecture issues early.
• Check for error cases : Wire-frames are a great way of helping designers and developers prepare all potential error cases and be ready with custom, informative and helpful error messages. When you know exactly where each error came from, you can create a check-list to help return the user to a usable recovery in each case.

Detail Site Features

More often than not, clients, managers and product developers have an extremely macro approach to the design. In short, they don’t really have a specific list of features. They are more interested in the big picture and that is really a problem for designers and especially developers. Wire-frames are an effective method of matching every problem with an actionable solution. Many times , there are simple communication issues that arise between the verbiage being thrown around about what a feature actually does. By visually exploring and explaining the features it maps out the scope of work and gets everyone on the same page. You will be surprised at all the details that might have been overlooked or simply not considered.

Practical Site Feature Tips:

• Do a deep dive on each feature: Don’t just use a box to communicate a feature like a photo gallery or map. Dive deep and list out each element that makes that feature work and where it needs to connect to the site map. Write notes on the specific connection and exactly how and where it gets its data from. The more specific you are, the more effective the list will be.

 

• List out relative content limitations: Many designers overlook relative content limitations like text strings, amount of items, overall screen real estate , etc. No one expects exact measurements, but spending the time on wire-frames to determine the reason range and limitation of content allows you to plan for scalability. Discuss with the team and write down roughly how long a title will need to be, how many images will you have, will the content need to scale, and how much will it need to scale. You’ll thank yourself when you don’t have to go back to the drawing board in mid production. It seems superfluous, but you will be glad you have it.

You’ll thank yourself when you don’t have to go back to the drawing board in mid production.

Visualize Architecture

It can be overwhelming and mind-boggling for some members of a team to look at a site architecture when they are well…not site architects. Especially when projects become enterprise level or simply filled with content that site map and information structure will get increasingly complex and abstracted. The architecture is the underlying structure and in and of itself is heavily conceptual. Wire-framing is the first step and beginning to connect the concept of the information to a tangible product.

Practical Architecture Tips:

• Illustrate Navigation: A tangible place to start when visualizing architecture is to visualize the relationships between the navigation pieces as well as the tiers of navigation. Wire-frame out the top level, secondary and local navigation systems and make sure to detail how they connect to each other. Explore what methods of listing or illustration are ideal for the information detailed in the site map.

 

 

• Visualize Steps and Exits: Many times the screen design can feel disconnected from the overall site map. To make sure that no structural paths can lead to dead-ends or trap the user : An incredibly useful exercise is to use the wire-frames to compare to the architecture map and record on each screen, how the user can exit, proceed or move backwards. I recommend using Mind-mapping software such as Freemind.

 

Conclusion

This is only small primer on how wire-frames are an essential , powerful and time saving part of the design process. The practical action tips in this article are a springboard to build a useful wire-frame step in your development process. Many designers have the tendency to dive right into designing look and feel, cool features, and graphics. Take a step back and remember that websites and software are complex ( even the simple ones). Proper planning is not just a formality but the most important step you can take. Getting friendly with wire-framing will build awesome team communication and facilitate solid, professional and well-planned projects.

Shawn Borskys article on the definition of wireframes. This is the article Brett Lutchman was responding to in a previous entry.