Image credit: Chris Depa, Straight North

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.

 

by Will Evans

For me, wireframes act as a form of ‘thinking device’ for the setting and exploration of a given problem space – in this example, a home page for a cruise line operator. To understand the utility of wireframes it is important to understand the nature of designing. I think of “D”esign as an exploration of the conceivable futures. I use my sketches and wireframes as 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.

I think it is quite common for UX folks to view design as problem solving. For me, designing through the use of wireframes is a search in a problem space of alternatives; it’s a process of problem setting as much as it is a process of problem solving, which means that I always start with the context. To simplify, I pick my primary audience and the one activity which allows them to solve one goal quickly, effortlessly, elegantly. In this case, the primary audience wants to easily find the best cruise, at the right time, for the right price. I don’t even look at the requirements document or competitive analysis until after I have sketched a couple of ideas either on paper or using Omnigraffle, which explores the primary goal. I’m not looking for solutions at this point because the first round of wireframes provide a space to engage in a dialogue with other designers, stakeholders, and the wireframes themselves.

My design process could best be described as going from a phase of divergence, through a phase of transformation, to a phase of convergence. Throughout every phase, wireframes are presented to stakeholders for critique and conversation.

During the divergent phase the constraints and possibilities of the design situation are explored. I try to find facts in the design situation that are stable and hold on to them throughout the process. Large parts of this phase consist of information gathering and trying to understand and formulate the design problem. By sketching a number of wireframes, I can explore alternatives. All the impossible and conceivable ideas are presented, tested, and in many cases, tossed away.

My initial visions are formed during this phase. In the cruise line exercise I focused on the ‘centrality of search’ as a driving goal in the design. I already knew that I wanted to design the best cruise line search interface possible, and I wanted that activity to be brought front and center in the design. I sketched the concept of providing immediate suggested cruises even before the user had committed to seeing a complete search results screen. From the homepage, the user would be pulled into a conversation and engaged with the process of finding a great cruise. The concept behind this was first proposed by Peter Hong some years back at Blast Radius while collaborating on a new search interface between their team and ours at Kayak on the PinPoint Travel interface. It was built but then killed – but the idea is worth keeping alive – I think.

In the transformation phase, I decrease the number of alternatives, and the scope of my designs narrows as the wireframes speak back to me. I begin to toss out really bad ideas that I might have fancied in the beginning. It’s usually at this point that I go back and read the requirements document and try to understand the complete ecosystem of stakeholder and business needs, and address those in the context of my primary design goal; the one, central activity of my core audience. It’s also at this point that I begin to address other, competing needs. In the case of the cruise line operator, I sketched out the header, footer, and static content and blocked out areas in the design for content modules such as CTAs (Calls To Action) and promotions. I share the output from this stage with the key stakeholders, but also bring in the visual designer, development lead and quality assurance engineer so they can contribute to the process and provide more ideas while pointing out pitfalls and constraints.

Finally, as the designer, I have to make the decision to implement the design in a specification. During the ‘convergence’ stage, I create two or three candidates for final consideration. I use annotations to empower the wireframe to plead its case to stakeholders and targeted testers. 

via blog.semanticfoundry.com

In this article Will Evans is sharing his wireframe insights and guides through his design process. Please visit Wills site http://semanticfoundry.com/ to learn more about his work. You can also reach him via Twitter @semanticwill.

Wireframing is an extremely important phase of the web development process. While it’s tempting to skip this step and proceed from the design brief and information architecture directly into design, it pays huge dividends to create wireframes somewhere in between of conceptual site planning and actual development of a site. Wireframing will allow you to do several things far more efficiently, and the time and effort you put into this phase pays dividends in the greater scheme of things.

In this article, I will go over five key benefits of website wireframing. What I’ll discuss are direct observations based on what we’ve experienced at the agency I work at.

What Is a Wireframe?

Before exploring these wireframing advantages in more detail, let’s pause for a minute to talk about what a wireframe is. A wireframe is a low-fidelity visual representation of a website’s layout design, sometimes referred to as a skeleton, outline or blueprint. Often, a wireframe represents the basic page layout structure and navigational scheme of the site’s pages, as well as major site components (like web forms and ad units).

A wireframe does not contain finished design elements as such, but does display where design elements will appear on the page. Wireframes are normally produced in grayscale using off-the-shelf wireframing software such as Mockingbird or, in its simplest form, paper and pencil.

Wireframes allow project team members and clients to do such things as:

• Test and refine navigation
• See how content lays out on the page
• Study and rapidly refine the user interface design of web forms and interactive elements
• Evaluate overall effectiveness of the page layout against usability best practices
• Determine web development/programming requirements

Here is an example of a wireframe for a home page:

Here is an example of a wireframe for an interior page:

To learn more about wireframes, as well as to discover tools, software and resources about wireframes, read the Ultimate Guide to Website Wireframing.

Let’s now go over the key benefits of wireframing web designs.

Wireframes Make Design Changes More Efficient

It takes a lot more time, effort and expertise to create a web page design than a wireframe. When the first thing clients see is a finished design, they are seeing something that has taken considerable time to produce and will involve (potentially) considerable expense to revise.

The bad news, especially from a cost standpoint, is that design changes are just about inevitable. I’ve worked on web development projects on the agency and client side for more than 15 years, and I’ve yet to see one that didn’t involve multiple (and often extensive) design changes.

However, when we review wireframes, both internally and with clients, design changes can be reworked in a matter of minutes. Don’t like the size of the header? Make it smaller. Too small now? Let’s see it a hair bigger. Is the conversion zone overshadowed by the logo? Let’s take a look at it this way.

Changes like the ones above, when made to full-blown, high-fidelity designs, can run up thousands of dollars of expense (to say nothing of extending the timeline to complete the project). Knowing the impact in time and cost to making design changes, clients and web development team members become almost reluctant to voice concerns for fear of the time and cost involved in addressing design issues.

The point to remember: Wireframing makes it quick and inexpensive to tweak or even overhaul a design at exactly the time when you want to be doing major changes and fine-tuning.

Wireframes Make Site Navigation Designs Better

One of the most important factors in web design is content findability, and an intuitive site navigation design is important in this regard. If users cannot easily get to where they want to go on a site, they’re gone.

As users become increasingly more web-savvy, the negative impact of shoddy navigation increases. Unfortunately, clients, designers and even developers have a difficult time evaluating navigation until they actually have an opportunity to use it.

Wireframes allow people to give the new site a test run: to see how easy or difficult it is to locate key pages; to determine whether dropdown menus clarify or confuse the user; to find out whether breadcrumbs are useful or distracting; to understand whether the overall navigational scheme is intuitive, incomprehensible or somewhere in between.

When site navigational issues come to light after designs are completed, it’s a bit like realizing your ceilings are too low after the house has been built. Changes to navigation can run the gamut, but many of them are almost prohibitively expensive to correct. I think this is one reason why we see so many websites — even large and sophisticated ones that display wonderfully creative content and dazzling design — still manage to deliver an overall inferior user experience.

Wireframes Make Content Development More Design Friendly

As a content person, I love how wireframes help us get everything we can out of web copy from a design standpoint.

How Wireframes Can Improve Content

Content — whether inserted for SEO purposes or for human readers (great content addresses the needs of both) — can look clunky or elegant.

An example of clunky content is something you see every day: large blocks of undifferentiated text. Nobody is going to read it. Elegant content — content that informs and persuades — makes use of design elements such as readable fonts, properly sized fonts, numbered lists, bullets and well-positioned subheads. In a wireframe, it’s easy to play around with these elements and arrive at a formatting scheme that will maximize readability and persuasiveness.

How Wireframes Can Improve User Interface Copy

For the user’s interface, little pieces of copy can be far more important than big ones. Example: should the call to action button say Learn More, More Information or Click Here? How the client and design team answer that question will have an enormous impact on conversions.

And yet, when content and user interface copy issues are addressed while reviewing a finished design, there’s a tendency to live with a problem and to compromise the effectiveness of the copy in an effort to contain cost and keep the project on schedule.

When content issues are dealt with at the wireframing stage, making changes is a piece of cake. Result: a website that blends the best of copy and design and maximizes user experience on every page.

Wireframes Help Clients Help Their Cause

Wireframes are a visual way to evaluate a new website and, as we all know, a picture is worth a thousand words. When clients green light the design phase of a project based on a sitemap and a few static design layouts, they are, to a certain extent, driving blind.

In my experience, this causes many a web development project to fall short of client expectations. As an agency, we have an obligation to give clients a clear understanding of what is going to be developed, and wireframes, for all the reasons enumerated above, allow us to do exactly that. We want our clients to see what the site will look like (at least roughly), to feel the navigation and to read the content in context.

When clients are confronted with a wireframe, their reaction ranges from shock to total satisfaction (usually somewhere in between). And from our point of view, there is no wrong response. It is far easier and less costly — and puts far less strain on the relationship — to address issues in this early phase of the project than later on, or worse, to launch a site knowing it has serious deficiencies.

Almost inevitably, wireframes generate a useful punch list of changes that are routine to make early on. In some cases, a wireframe leads a client to rethink their approach on a more strategic level. Comments we typically hear include:

• I didn’t realize our product line was this confusing
• We have too many options in our navigation: our key pages are getting lost in the shuffle
• Our call to action is weak
• Our Contact form takes too long to fill out
• We’re talking too much about ourselves and not enough about our customer
• Our most important product photos are below the fold: nobody’s going to see them

When we have conversations around topics like those above at the wireframing stages, they lead to happy resolutions. When these conversations occur after design and development are completed, they frequently do not.

Wireframes Help Web Developers

I’m about as far away from being a programmer as you can get, but my sense is that when you give programmers marching orders without the benefit of a wireframe, you’re asking them to do the job with one hand tied behind their back. If all the web developer has to go on is a sitemap, design templates and a bunch of verbal instructions from the client and project manager, there are going to be a lot of questions and assumptions as the build process moves forward.

Wireframes give web developers a clear path of what has to be done. It clarifies the direction and objectives of the site build and allows for better decision-making as to which web technologies, techniques and processes should be used in order to achieve an excellent result.

Summary

A web development project is a lot like building a house. Both are complicated projects. Both involve teams of specialists working in concert to give concrete form to a client’s vision. If you are going to build a house, you naturally want the best builder you can find. But you also want to equip the builder with the right tools. And you want to make sure the builder has the right process in place to get the job done on time and within budget.

Wireframing is not a cure-all, but is something we’ve found to be a very valuable tool — one we would never dream of giving up.

Brad Shorr from Sixrevisions shares his thoughts on the the benefits of wireframing.

The sketchboard is a low-fi technique that makes it possible for designers to explore and evaluate a range of interaction concepts while involving both business and technology partners. Unlike the process that results from wireframe-based design, the sketchboard quickly performs iterations on many possible solutions and then singles out the best user experience to document and build upon.

It’s what we do well
Designers love the “breakthrough moments” in a working relationship. Those times when you suddenly reveal a picture of a solution that really nails the problem and gives everyone on the team a reason to cheer. Such moments bring together many of the most valuable capabilities of a designer, as follows:

• The ability to convey a solution pictorially
  Showing a solution is more vivid and far less abstract than talking or writing about it; pictures are both louder and more clear than words.
• The ability to presuppose new solutions
  Despite incomplete information about the problem, designers make instinctual leaps to offer potential solutions that would not have been arrived at through deductive logic alone. Designers push the boundaries beyond the obvious alternatives.
• The ability to fuse together a solution from competing constraints
  Design constraints solved one by one can create an unwieldy solution. Great designers arrange components of a solution into a whole that is more elegant than the sum of its parts.

The trouble is that these moments are all too rare on normal design and development projects. After a designer sinks time into communication, requirements gathering, and documentation, there is precious little time to create amazing results.

Where wireframes fear to tread
The wireframe—default design tool of most UX professionals—is a significant part of this problem. While wireframes are often necessary at the end of a process to clearly document and communicate the design, using wireframes earlier in the design process focuses time and attention on all the wrong details and activities.

We often find UX designers working to define and arrange elements on a page when the real issue to confront may be much broader in scope, such as “Does the page need to exist at all?” or “How best can these series of interactions flow together?” Wireframes force your design solutions into a certain level of granularity that can’t match the big juicy problems you face. A design process starts with struggles against scope, flow and gestalt. Yet wireframes arm you with mere dropdown fields and “lorem ipsum.”

Wireframes constrain your creativity. Given the time it takes to generate a wireframe, we find that most designers can only create one wireframe per page. Then they slowly revise and compromise. We call this “the inch-by-inch trial-and-fail method,” where a designer slowly adapts his or her first idea for the page until it eventual meets all the criteria thrown at it, but slowly falls apart in the process. Such a process eliminates the opportunity to explore and choose amongst the myriad of possible forms an interaction could take, nor allows you to evaluate which approach might best adapt to the comprehensive set of criteria.

Wireframes also take designers into a hole. Wireframe development typically results in a designer slaving over a screen at his or her desk, not interacting with others, in order to improve upon the work. As documents, wireframes enable team members not to have to interact, which often results in work just getting thrown over a wall.

Simply put, wireframes are too slow and detailed. They aren’t going to deliver many breakthrough moments for you and your team. Instead, designers need to focus the early stages of work on techniques that achieve the following:

• Ways that focus the designer’s time and attention on the big problems that need solving before tackling the details
• Ways that quickly explore many different possibilities to find the right solution
• Ways that can involve others
• but yet can still do it all pictorially!

Enter sketchboards At Adaptive Path, we’ve adopted a technique, called the “sketchboard.” It starts with a big sheet of paper (think yards, not inches) that forms a large canvas on which we can explore, share and iterate on ideas. The paper is key—it brings all our thinking together into one space that we can roll up and take anywhere.

On this large sheet of paper we roughly organize our problems and constraints. We might paste up personas that we’re designing; stages of a user process; functional requirements; research findings, or screenshots of relevant real-life examples. This brings whatever elements that should be driving or inspiring us onto the same playing field. This way our work focuses on solving the problems that matter because they’re right there, staring us in the face. (Note: We love using drafting dots to tack things up onto the sketchboard. So we can easily rearrange and rethink the relationships of our work.)

At this point, we’re prepared to sketch a wide array of solutions with (gasp!) pen and paper. It may not be the most pixel-perfect portrayal of the final results, but it’s fast, it eliminates needless detail, and it can reasonably convey highly interactive experiences. (As proof of the last point, just think of animation storyboards).

We tend to sketch at two levels:

• We sketch thumbnails using this multi-page template, to quickly force out a half-dozen (or more) approaches to a problem, or to convey a flow of an experience across many pages. Here’s an example.
• Then we sketch full pages using this single-page template, to “zoom in” on a particular thumbnail idea. With slightly more detail, we can see where the idea leads to and better evaluate the possibilities it holds. Here’s an example.

We don’t spend too much time evaluating or critiquing our sketches, we just work on getting all the ideas out onto the sketchboard where everyone on the team can see and help make improvements.

So far this is, logistically, all very easy-peasy—but that’s the point. We don’t have to work very hard to have many ideas. Ideas are cheap, and the sketchboard technique just makes them even more affordable. So, the more ideas we explore, the more likely we’re going to hit upon something really compelling and really appropriate for the problems we’re addressing. Sometimes the best idea is the first one we have, but most of the time it’s the third, fifth, or eleventh one that really nails it, which creates that glorious breakthrough solution.

The sketchboard technique unleashes your right brain to find and convey great solutions pictorially. You get:

• Faster, but higher-quality design iterations that encourage heavy collaboration
• Exploration of many ideas before investing time in polishing one design
• Sketching and collage activities that provide design the same speed and focus that agility gives to coding

As a designer, the sketchboard allows you to create endless possible solutions in a vivid, pictorial form. You’re set-up, again and again, for breakthrough moments. And with more shots on goal, you can’t help but score regular and repeatedly.

Sharing the sketchboard
With a large canvas full of sketched solutions, we can have a very productive discussion with our clients and with our partners from other disciplines. To gain from their experience and insight, we lead our partners through a walkthrough of the sketchboard, presenting the sketches as potential starting points for the ultimate solutions. No matter what discipline or perspective they’re are coming from, they can easily point to a sketch, share their thoughts on what’s good or bad about it, and everyone on the team can understand what they’re talking about because we’re all on the same proverbial page.

This collaborative use of the sketchboard opens up the design process so that everyone can add valuable input before we become married to any one approach. From a process point-of-view, this increases visibility for management. Management can better appreciate the cost-value tradeoff of investments in additional design iterations.

From a solution point-of-view, the team’s walkthrough of the sketchboard brings us to place where we’ve got a pretty tight idea of what solutions we need to take forward into a detailed design. A well-reviewed sketchboard is a visual specification of the solution, with certain elements of specific sketches highlighted and circled, lots of notes, and several new sketches conveying the important details we’d made decisions about. Only at this point do we feel we’ve explored enough ideas, confronted the right problems, and received enough team input and perspectives to move forward into the detailed structure of a wireframe.

Originally, we started using sketchboards for the ability to quickly iterate on interaction design, but in the process, we found these additional benefits:

• Our design solutions are dramatically improved because there are more iterations on the right issues and a lot more people participate in the process
• We earn greater trust and win buy-in from stakeholders because everyone understands why the chosen solution is the best solution
• We rapidly move from loose requirements to a clear understanding of what to wireframe and prototype, and consequently, we are able to quickly produce higher fidelity wireframes
• The sketchboard adapts well to almost any type of design problem we come across, and works well within different types of processes

But, perhaps, the best result of the sketchboard is that you can proceed into wireframe documentation with the right answer in your pocket. You’ve got another breakthrough moment just waiting for you.

Another technique to explore interaction concepts comes from Adaptive Path. Brandon Schauer introduces the method and points out its advantages.

Myth 1: “I can't draw well enough to create a paper prototype.”

When given a pencil and paper, most people (myself included) will tend to doodle words rather than draw pictures. Art was never my subject at school, so when I see wonderful, artistic renditions of user interfaces, I tend to feel somewhat humble. I can't draw like that, my inner voice reminds me, so don't pretend you can sketch a user interface.

But just because its on paper, it doesn't mean it's a paper prototype.

A paper prototype is a sketch — a quick visualisation of your idea. The artistic merit of your sketch is irrelevant. The purpose of paper prototyping is to evaluate the idea behind the user interface, not the sketch itself. Paper prototypes are quite literally 'artless': simple and unaffected.

This focus on 'neat and pretty' is one of the biggest obstacles to overcome with paper prototyping. It has even spawned a real industry. For example, search the web and you'll find imaginative stencil sets for iPhone, web, iPad and Android. These kind of tools simply feed the paranoia of people who worry their sketches aren't pretty enough.

Myth 2: “Wireframes are the same as paper prototypes.”

Wireframes show a skeleton view of a user interface. They identify the areas of the screen where content will appear, such as images, text and navigation. Wireframes often include call-outs and notes explaining certain elements of the design in more detail. They are a useful communication tool for design agencies who want their clients to sign off on a design without getting hung up on the colours and images displayed in the user interface.

But wireframes don't work as paper prototypes for at least two reasons:

• They encourage too much focus on the layout of pages. As a consequence they can attract nitpicky feedback on issues like alignment and fonts. In the early design phase you're more interested in the navigation, workflow, terminology and functionality than in details of the visual design.
• Wireframes are usually produced towards the end of the initial design phase, not at the beginning. At this point, many important design decisions — about functionality, for example — have already been made.

Many information architects are obsessed with wireframes but in most projects, they aren't needed: they are just a bureaucratic overhead. You'll find that an electronic prototype, modified as the project progresses, provides a much more useful design communication tool than a wireframe.

Myth 3: “I can do it just as well with Visio.”

I've often heard developers object to paper prototyping because they can mock up an interface in Visio, or another favourite tool, in the same time it takes to sketch one out. Developers point out that electronic prototyping scores over paper because it is easier to cut and paste repeating elements (like navigation bars) rather than go through the exercise of re-sketching them. And electronic prototypes can be shown to users over the Internet and tested remotely.

Ironically, 'cut and paste' is exactly what paper is good for — you just need real scissors and glue. You can quickly duplicate elements of a paper prototype with a photocopier or even mock-up the repeating elements in Visio and glue them to your sketched user interface. (If you'd like a starter kit, download and print our paper prototyping helper kit. This provides more flexibility than a stencil yet doesn't express the same imperative to draw neatly).

Similarly, paper prototypes can be tested remotely: you simply scan in your sketches and chain the screens together in PowerPoint or Keynote. You can even record the sessions with usability testing software like Morae.

There is certainly a time for prototyping with electronic tools — but that time isn't the early design phase, for a couple of reasons.

• Electronic tools constrain your thinking about what can be achieved. So if you don't have a 'carousel' widget you'll find you don't include that interaction idea in your electronic prototype.
• Electronic prototyping blinkers you into thinking only about incremental improvement. In the early design phase you want to generate a number of completely different ideas, test them, and combine the best parts into a converged solution. Bill Buxton makes the point that you first need to get the right design before you move onto getting the design right. Electronic tools aren't good at supporting the divergent thinking you need to get the right design.

I think there's a deeper issue here, to do with confidence. Developers feel happy in front of a computer: it's their domain and it's what they're skilled at. Take away their computer and they feel a bit… naked. But this massively undervalues another key skill that developers have: problem solving. As the development team at Red Gate Software point out, more developers should realise that their skills extend way beyond that of the keyboard.

Myth 4: “Whiteboarding is just as effective.”

Many designers I've spoken with tell me that they already do paper prototyping — they just do it on a white board or flip chart instead. The design team then discuss the ideas and refine them before moving to implementation.

Whiteboarding, and its close cousin sketchboarding, are terrific creativity tools, used by design heavyweights like Adaptive Path — but they're not paper prototyping. These techniques remind me of Gerry McGovern's joke that the worst possible way to design a web site is to have five smart people in a room drinking lattes and discussing branding. The purpose of paper prototyping is to quickly generate design ideas that you can test out with users. It's not for coming up with design ideas that can be voted on by the design team. This is because paper prototyping isn't just about design — it's about iterative design: creating stuff you can test quickly and then discard or improve upon.

Rather than hold a fruitless design meeting where you spend hours arguing over where you should put the navigation, you could spend the time more productively by creating a couple of different paper prototypes and testing out the alternatives with a handful of users. Not only will this help you make a decision quickly, you'll also have the confidence that the final decision is based on real data rather than on a designer's intuition, or worse: the HIPPO (the highest-paid person's personal opinion).

Myth 5: “Users behave differently with a paper prototype than with a real system.”

Paper prototypes use the participant's finger as the mouse and a pen as a keyboard. Interfaces are roughly drawn and are clearly not finished prototypes. This is clearly different to a real system and so a common objection is that users will behave differently with a paper prototype.

This objection has no basis in fact. A raft of published research shows that paper prototypes are just as effective as high-fidelity prototypes at detecting many types of usability issues.

Myth 6: “It looks unprofessional.”

There is no denying that paper prototypes lack beauty — but this is different from saying that paper prototyping is unprofessional. In my experience, so long as you get participants really using the paper prototype (rather than sitting back and having it demonstrated to them), they quickly get 'lost' in the experience of using a paper prototype. This makes issues of professionalism moot.

In contrast, I would argue that your users will think you're more professional because you're clearly involving them early in the design process and taking their comments seriously.

If your management is still unsure, run a trial with single participant and ask, “Is your opinion of our organisation better or worse after this experience?” I'll bet you'll hear only positives.

Myth 7: “I can't prototype interactivity.”

It's true that there are some intricate interaction styles that don't lend themselves to paper prototyping. Gesture-based interactions on the iPad and iPhone can't be replicated on paper. Panning and zooming, Google Maps-style, isn't practical. Similarly, applications that require continuous scrolling or that include long download or response times can't be properly emulated.

But the vast majority of web and software interaction — even on an iPhone — is still point and click (with a little keyboard too). These can easily be emulated with a paper prototype. Rather than focus on the edge case that won't work, think of the vast majority of situations where paper prototyping will work. The video below shows just how interactive paper prototypes can be.

Good article on paper prototyping by David Travis. David demystifies 7 common presumtions regarding paper prototyping.

Wireframes, your time is up. You’ve served your purpose. You’ve brought order where there was once chaos and provided gainful employment for thousands of UX designers, but I’m afraid now it’s time for you to go to the big recycling bin in the sky. You’re just no longer cut out for the cut and thrust of UX design and have been replaced by that young upstart called rapid prototyping. In this article I argue why you too should ditch wireframes and embrace rapid prototyping.

What are wireframes?

In the same way that architectural drawings might outline what goes where for buildings, wireframes outline what goes where for a set of UI screens. Wireframes typically outline the components for a screen, together with any associated behaviours, such as what happens when a button is click and where a hyperlink should go. They don’t show exactly how a screen will appear, only how it will be composed and how it will behave. For example:

Wireframes are usually put together by a UX designer (or designers) prior to any visual design work and are typically constructed using diagramming tools such as Visio and Omnigraffle, or design and drawing tools such as InDesign and Fireworks. They typically form part of the functional specification for a system, outlining all the requirements for each screen, and as such are usually annotated (as is the case with the example above), often in excruciating detail.

Why ditch wireframes?

So what’s so wrong with wireframes? Well wireframes themselves are not necessarily bad; it’s more the sort of design behaviour they encourage and the way they are often used (and abused) in projects. Here are some reasons why for the vast majority of projects wireframes should be consigned to the rubbish bin.

• Wireframes (which are static by nature) are not well suited to defining dynamic on-page interactions, such as expanding content, AJAX style reveals and animations. As the boundaries between web and desktop applications become increasingly blurred and on-page interactions become more common place wireframes simply no longer cut the mustard.
• Wireframes are not very user friendly (which is kind of ironic for a UX design tool). Project stakeholders are often intimidated by what they perceive to be very technical documentation and find it difficult to understand exactly what wireframes are, and what they show.
• Wireframes are typically very open to interpretation. Wireframes look like they’re very exacting and specific but because behaviours and interactions have to be described they are by nature very open to interpretation. One project stakeholder can read a wireframe very differently from another which can lead to confusion and misinterpretation.
• Wireframes can encourage the ‘lob it over the fence’ approach to design. Designers can spend ages meticulously creating, annotating and updating wireframes and then lob them over the fence for the development team to build; safe in the knowledge that everything is documented, so any dialogue can be avoided.
• Wireframes can be too prescriptive. Many visual designers can feel that wireframes reduce their role to little more than a colouring in exercise; one of applying the necessary branding and look and feel for each screen rather than carrying out proper design work.
• Wireframes often add unnecessary drag to the design process and can encourage death by documentation (a particularly nasty way to go). Creating and annotating detailed wireframes takes considerable time and effort; time and effort that is usually better spent iterating and improving designs, rather than specifying them.

Bypassing wireframes with rapid prototyping

If wireframes are so flawed what’s the alternative? Simple, the alternative is to bypass wireframes altogether and either go straight from sketch / outline designs to developing working code (in an Agile fashion), or as is more use common use a rapid prototyping tool to create a prototype. There are now loads of great rapid prototyping tools out there such as Axure (my own favourite), Balsamiq, EasyPrototype and iPoltz. If you’ve got mad web design skills you can also always create a prototype directly in HTML and CSS.

There are a number of advantages of rapid prototyping over wireframes including:

• Prototypes are a much better at communicating a design. It’s much easier to sit down with designers, developers, product owners and of course users to get feedback and to run through design ideas if everyone can see how things might work with their own eyes.
• Prototypes are more user friendly. Where as people are often scared off by wireframes everyone understands what a prototype is (just make it clear that prototypes are very different from the finished article).
• Prototypes require less documentation as they are less open to interpretation and on-page interactions can be mocked up. If you do need to document your prototypes (hopefully with an emphasis on ‘just enough’ documentation) then you’ll find yourself having to write many fewer comments for a prototype than a set of wireframes.
• Prototypes better support user-centred design. It’s much easier to carry out usability testing with a prototype than a set of wireframes and to get lots of juicy feedback from users in general.
• Prototypes require less work. If you are careful to prototype ‘just enough’ to get the feedback that you need then prototypes typically require less work than wireframes because you’ll need to write (and maintain) less documentation.

Of course like wireframes, prototypes can also be misused. A classic mistake is to mock-up a design to the nth degree and then chuck this over the fence for the development team to build. Prototypes can also be even more prescriptive than wireframes, so it’s just as easy for visual designers to get upset because they feel left out of the loop. This is why it’s so important to always prototype ‘just enough’ to get the feedback you need and to approach prototyping as a collaborative exercise. Designers, developers, product owners and of course users should all be involved in creating, critiquing and evaluating prototypes. This is why I’ve found it best to sketch designs before you even think about touching any prototyping tools.

That’s great, but I still need a paper trail…

If you work in the sort of place where documentation still reigns supreme and the project manager will look at you like a crazy person if you tell him that a prototype with some comments is all the specification required, then fear not. If you absolutely must have wireframe like documentation you can still get by without wireframes because some rapid prototyping tools such as Axure will automatically spit out specification documentation for you. Granted what it spits out isn’t fantastic but it’s much easier than having to maintain a prototype and a separate set of wireframes. As a last resort you can also always screen grab pages using the excellent Screengrab! Firefox plugin and create your own specification document. On screen annotation tools such Protonotes and WebNotes allow you to easily add comments to your prototype so there isn’t even a need to add footnotes to your screen grabs. You can simply grab the pages with the comments shown, so you see, there really aren’t any excuses for not ditching those wireframes!

Another post to heat up the wireframes vs. prototypes discussion, this time by Ux for the masses.

Wireframes have been around for some time now and while they have been vastly discussed, blogged and argued about, I think they are still widely misused and devalued.

I’ve been inspired to write this article in response to a blog post a recently read here. The title alone was enough to shock me and I was pretty much shaking my head in disbelief throughout the whole article. But then I read the “About” section and found that the author has a “technical background”. Well that sort of explains it, but the article still got me thinking it’s worth explaining my take on wireframes for the non-believers out there.

Firstly, the author of the mentioned article compares wireframes to architectural drawings.

“In the same way that architectural drawings might outline what goes where for buildings, wireframes outline what goes where for a set of UI screens.”

This is quite a nice way to explain wireframes to clients and any other non-techies. It sets their expectations from the start. Most people will have a sort of mental model of what an architectural drawing looks like so when they see your wireframes there won't be that initial shock and confusion. I would say this statement also demonstrates the importance of wireframes. I don’t think anyone undertaking a building project would ever dream of removing the architect from the picture and bringing in the builders straight away, would they?

The author then goes on to list some disadvantages to wireframes. Firstly, I think these are very specific to cases where wireframes are done badly by people who don’t understand their purpose and just do them because they read somewhere that they should. Secondly, don’t all tools have their disadvantages anyway and isn’t it up to us, as professionals, to work around the limitations posed by tools and technologies we use?

The author then concludes that the solution to the listed disadvantages is to “bypass wireframes altogether” and jump straight into rapid prototyping.

WHAT? Skip wireframes all together?!

Here’s why I think this is a crazy statement:

1) Wireframes put the focus on the user first, functionality and visual aspects second. They strip down a website to its bare bones enabling clients to focus on what it is they want the website to achieve and what it is they want the user to do on the website. As soon as you introduce design elements into a prototype you are moving the focus to visuals. Clients start to get bogged down with stuff like “can we please make our logo bigger?” or “can we make that photo more exciting?” You end up wasting a lot of energy reminding them to please focus on the bigger issues

2) Wireframes, if explained properly to clients, are a quick and easy way to get sign-off on page layouts and functionality before you even touch any code. It is not logical to use prototypes as first stage feedback. It is much quicker and easier to drag a box across the screen than it is to rewrite code.

3) Wireframes, once signed off, act as a central document for the project team to refer to throughout the project ensuring everyone is on the same page.

I do agree that rapid prototyping is another great technique to use in some web projects. It can be extremely useful when collecting user feedback and testing out functionality, for example. However, I think prototyping is a lot more costly and not all projects will necessarily have the budget for it. Wireframes, on the other hand, are an absolute must for all web projects. They should be instinctively incorporated into the early stages of the project and failing to do that could potentially mean higher costs in the long run.

So to all of you out there who are trying to kill the wireframe – it will never work!

Wireframes are a useful, effective and essential tool.

Trying to avoid them and opt for other techniques instead is not only cutting corners but also compromising the effectiveness of your website.

Wireframes aren't dead they just got smarter. Ven Ganeva is starting a petition for the wireframe and states a couple of good arguments why one should never give up on wireframing.

There are several important factors to consider when you are planning to do prototyping for user testing. You will want to make careful choices about fidelity, level of interactivity and the medium of your prototype.

Degree of fidelity

Fidelity is the degree of closeness to the “depth, breadth and finish of the intended product” (Hakim & Spitzer). Opinions vary a great deal on how much a prototype should resemble the final version of your design. Usability practitioners like Barbara Datz-Kauffold and Shawn Lawton Henry are champions for low fidelity —the sketchier the better! Meanwhile, Jack Hakim and Tom Spitzer advocate a medium- to high-fidelity approach that gives users a closer approximation of a finished version. You’ll want to make a decision about the right approach for you based on the needs of your project.

Low fidelity
You can use hand-drawn sketches to create a paper prototype. If you go this route, you may also want to help your users get into the spirit of things during the test by creating a complete low-fidelity, paper environment. This could include a cardboard box made to look like a computer and an object to hold to point and click with. These techniques help users to suspend their disbelief and get their imaginations involved so that they can better visualize the interface. The advantage of using rough sketches is that users will have an easier time suggesting changes. They may even grab a pen and start making their own changes (Datz-Kauffold and Henry).

In theory, low-fidelity sketches are also a time-saver, but this really depends on your point of view. Personally, I like to draw diagrams and wireframes in Visio where I can revise and move things around without erasing and redrawing. If you prefer to work this way too, and if time allows, you can always have those Visio drawings hand-traced or use them as a roadmap for making sketches to test with. You might even find a graphics tool with a filter that will convert a Visio-generated graphic into a hand-drawn sketch with wavy lines.

High fidelity
This approach takes you as close as possible to a true representation of the user interface —screen-quality graphics. All of the blanks on the page are filled in, and it looks good. However, you might not have all of the technical or backend problems worked out yet, or you might have only a small part of the entire site rendered. That’s why it’s still considered a prototype. For example, it might consist of a small series of Photoshop images or HTML pages with just enough functional links to convey the feel of the site’s flow. You may need to enlist the help of a graphic designer or web developer to build these in a reasonable amount of time. Advocates for high-fidelity prototypes argue that they are easier for users to understand just by looking at them. There is no disbelief to overcome, and it is easier to determine when they really do not understand the design. If you choose a high-fidelity prototype, make sure the you have enough of the design fleshed out so that users can complete several tasks. Decide on these tasks early, so you know which areas of the design need to be represented for your tests. Otherwise, you will be in for a great deal of preparation work.

Medium fidelity
In the grand tradition of Goldilocks, I find myself drawn to the middle approach. A medium-fidelity approach tends to include some visual design and a level of detail somewhere between high and low fidelity. Does this sound familiar? As an information architect, I’m accustomed to creating wireframes I can hand off to decision-makers, graphic designers, web developers and programmers. An information architecture wireframe is NOT graphic design. I swear, it’s really not!!! But… I’ll admit that it has enough visual design to convey a rough version of the user interface. Because I create these with drawing tool software, they tend to have more polish than hand-drawn diagrams. Hakim and Spencer are champions for medium-fidelity prototypes because they fit more seamlessly into the design process while providing more realism for users. I found this to be true during a project to design a search interface for Egreetings with my colleagues at Argus. I created rough draft wireframes for the prototype, and after testing I revised them for use in my deliverables.

Interactivity
Interactivity describes how your prototype behaves. Does your prototype react to user inputs with feedback? Can they “click” on something to go to another page or fill in a form? Will buttons appear to depress and drop-down menus work?

Static prototypes
Prototypes used for testing are static if they are pages or page elements shown to users, which don’t provide any feedback. It can sometimes work well to show a page to a user and ask them to explain it to you or to guess where they can go from here. In this kind of test, the user interprets the prototype rather than interacts with it. This is a good way to validate your design by checking to make sure users understand it. It’s also easy to score this sort of test when you have a standard list of questions to ask about each page.

Automated
Automated prototypes allow users to make choices that cause changes. The testing prototype provides the user with feedback. Elements are “clickable” and forms can be filled out. The interface reacts to the user while the tester observes. One way to do this is to create the prototype in HTML or some application that allows interactive elements such as Flash, Visual Basic or even PowerPoint.

Another way to achieve a kind of pseudo-automated interactivity when you have chosen a paper prototype is to pretend (Datz-Kauffold and Henry). Have you ever seen children at play pretend that they are driving a car by setting up chairs for the front and back seats, drawing a dashboard on a cardboard box, and using a Frisbee for the steering wheel? If you have set up the right environment for your users, you can ask them to pretend scraps of paper on a table are their computer screen. When they “click” on a drop-down menu by touching the element with a pointer, a tester assigned to the role of the computer provides feedback by swapping the closed menu for an open one that shows choices. The “computer” may need to write on some elements before showing them to the user, i.e., “Your search retrieved 523,621 hits.” It takes a few minutes to get test participants used to the idea, but if you encourage them to have fun with it you will learn a great deal. You can also easily try out different possible reactions to user input.

This method worked well during the Egreetings project. We especially emphasized the technique of asking the users to click and then provide feedback. We found it useful to laminate the screen components so we didn’t need to produce a clean copy of the test for every subject. The users could write on the laminated pieces with thin whiteboard markers when making selections and entering search criteria. Of course, this meant that we needed to take careful notes because of the need to erase between each test subject.

Here are some other tips to try for low-fidelity testing with simulated interactivity:

• Bring extra paper so you or the respondent can sketch out an idea if the opportunity arises.
• As with any user test, it really helps to ask the respondent to think aloud.
• If you have the luxury, bring a team of three to the test: someone to take notes, someone to play the “computer” and another to facilitate.
• Use a piece of posterboard as your “screen.”
• Cut your design into separate pieces or zones as appropriate and ask the user to rearrange them in the order they prefer.
• Attach the folder tabs that come with hanging files to components so they are easier to grab.
• Invite users to throw away or cross out components that they don’t think are important.
• Number the pieces so that you can easily refer to them in your notes and keep them organized.
• If you do decide to bring separate copies of the test materials for each session, tape down the components to a larger piece of paper as arranged by each user so you have these artifacts to analyze later.

Prepare a kit for yourself containing:

• Scissors and tape,
• Different sizes and varieties of sticky notes (which make great drop-down menus),
• Markers and pens in various colors and sizes,
• Paper clips and binder clips for keeping slips of paper organized, and
• Objects that the user can pretend are the mouse pointer, such as a feather or a small toy.

Medium
There are many possible combinations to choose from for building your prototype. One of the first choices to make is whether you want to have your prototype viewed on an actual computer screen or if you’ll be working on a tabletop with a paper prototype. Believe it or not, fidelity and interactivity are independent of the medium you choose. It’s probably most natural to think of the extreme cases. An automated HTML prototype is often high-fidelity and, of course, the medium is a computer screen. Likewise, a natural medium for a low-fidelity automated interactive prototype is hand-drawn sketches on paper. However, you can also have the following:

• Low to medium-fidelity wireframes built in PowerPoint that show only lines and boxes with text;
• animation features provide automated interactivity,
• Static Photoshop prototype pages shown to users on a computer screen, or
• Same as above, but printed out in color on paper.

Deciding on Fidelity, Interactivity, and Medium When Prototyping

Mixing the variables
You can mix these three variables (fidelity, interactivity and medium) in many different combinations. The exact combination you choose should match the goals you determine for your testing. Possible goals for an IA prototype include:

• Testing the effectiveness of labels and icons.
• Finding out the right balance of depth and breadth of a topical hierarchy.
• Determining the right options to offer for narrowing a search.
• Choosing the most important metadata elements to show on a search results screen.
• Settling the question of whether your target audience accomplishes tasks better with a task-oriented organization scheme or with a topical organization scheme.

If you live and breathe NetObjects Fusion and don’t have much time, your preference might be to create a medium-fidelity prototype. That way you could test that sitemap you are working on using some rough placeholder graphics or text instead of the finished graphic design. How you mix the variables depends on the time and budget you have available, as well as your work style. Try experimenting with different approaches to learn how prototyping will work best with your design process.

Recommended and really interesting article by Chris Farnum for Boxes and Arrows: The design behind the design. "What you should know about prototyping for user testing" deals with valuable tips delivers distinctive definitions for the fidelity degrees.

Top 10 Wireframe Tips

Start Sketching
Sketch them first with a pencil and paper for a quick sanity check. This should take about 30 seconds and opens up the possibility of getting early feedback. This can save a lot of time and money. The feedback can be gained through peer review or, best of all, from some early and informal user testing (you may need to spend a little more than 30 seconds on the sketches if they’re for user tests).