Shades of Gray: Wireframes as Thinking Device | Semantic Foundry, LLC

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. 

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.

1 Notes

Wireframing: Low-Fidelity or High-Fidelity?

Wireframing is an important part of the design process that helps to flesh out new ideas, identify any potential issues, and to communicate ideas and solutions to clients and colleagues.

When creating wireframes you have a couple of options – the first is to create low-fidelity designs which involve scribbling on paper, drawing on a whiteboard, or the use of software to create simple diagrams.

The other option is to use high-fidelity mockups that go a step further and typically include a range of design elements such as a logo, images, a colour scheme, and other basic graphics.

There are pros and cons to each of these approaches – low fidelity wireframes are very quick and cheap to produce. You can easily change and modify them to suit your needs or throw them away and start over from scratch.

The fact that they’re less formal can also be helpful when asking for feedback – it’s somehow easier to criticise something when it’s a rough draft as opposed to a high quality mockup (i.e. people don’t want to hurt a designer’s feelings).

On the other hand, high-fidelity mockups are much more polished – this can be useful for giving everyone a clear idea of how the interface will look and work, but they’re also very time-consuming and expensive to produce.

High-fidelity wireframes can also be confusing for clients – especially those who aren’t particularly tech-savvy as they can struggle to understand the difference between an interactive mockup and the final fully functional application.

So, which is the *right* approach to wireframing? Neither! It depends on the scope and context of the project you’re working on.

You need to consider what your goals are when using wireframes. Are they for your eyes only or do they need to be shown to colleagues and clients? Do you really need to use high-fi when low-fi will suffice? What kind of resources do you have – both in terms of time and budget?

It’s also important to note that you don’t necessarily need to use one approach or the other – it can be useful to start out with low fidelity wireframes and build up to more realistic and accurate mockups as you iteratively enhance the design.

But don’t obsess about which approach you use – remember that wireframes are simply a design tool that enable you to quickly test different ideas, highlight any potential issues, and ultimately help you produce a better design solution.

Chris Creed sums up the differences between low and high-fidelity wireframing and reminds that the choice should be made upon your objectives. I recommend checking out Chris’s Blog where he writes about interface design, usability and user experience.


25 Examples of Wireframes and Mockups Sketches | inspirationfeed.com

Would you start building a website without blueprints? If you said yes, good luck with that. If you said no, then you are 100% right! Before building any website you have to have an idea of how things will function and look. It’s wise decision to do a rough sketch with a pencil for the future website. Usually planning could take a few days, and new ideas arise while you ponder. If new things popup or changes arise, you can easily erase what you’ve done. For future reference, we decided to roundup some great examples of wireframes and mockup sketches. We hope that you will get some ideas of what a wireframe should look like, and how to correctly accomplish this step in web design.

Still Hungry? Get more wireframe inspiration here Flickr.com/groups/ilovewireframes

5 Years of Firefox

sketched wireframes 21 25 Examples of Wireframes and Mockups Sketches

iPad app sketch

4575190482 751d1d26741 25 Examples of Wireframes and Mockups Sketches

Viget Labs Wireframes

Viget Labs Wireframes 25 Examples of Wireframes and Mockups Sketches

Early Ember Sketches

sketched wireframes 121 500x368 25 Examples of Wireframes and Mockups Sketches

OnlyJames Wireframe Sketch of Article Detail

09 sketched ui wireframe1 500x474 25 Examples of Wireframes and Mockups Sketches


sketched wireframes 131 25 Examples of Wireframes and Mockups Sketches

CommLogix Wireframe

sketched wireframes 111 25 Examples of Wireframes and Mockups Sketches

Early BusinessWeek.com Design Sketch

Early BusinessWeek 25 Examples of Wireframes and Mockups Sketches

BPgraphics UI Sketch

BPgraphics UI Sketch 25 Examples of Wireframes and Mockups Sketches

Website UI Sketch

4803582708 8499571550 z1 25 Examples of Wireframes and Mockups Sketches

UI Flow Sketch

UI Flow Sketch 25 Examples of Wireframes and Mockups Sketches

Cartoonity.com UI Sketch

4659003635 d222d68e20 z1 25 Examples of Wireframes and Mockups Sketches

Dew Tour Wireframes

4066790442 01100cff351 25 Examples of Wireframes and Mockups Sketches

HBO SATC UI wireframe

HBO SATC UI wireframe 25 Examples of Wireframes and Mockups Sketches

Pear Note 2.0 Sketch Wireframe v1

4903474616 ca0782f9811 25 Examples of Wireframes and Mockups Sketches

Search Ideas Wireframe

4903473820 ba53a0ba981 25 Examples of Wireframes and Mockups Sketches

Web Sketch Interface v2 – Graffletopia

original1 25 Examples of Wireframes and Mockups Sketches


ada2f 28 31 sqetch1 25 Examples of Wireframes and Mockups Sketches

Verify Home Screen

Verify Home Screen 25 Examples of Wireframes and Mockups Sketches

Vimeo Clip Page Top Nav

sketched wireframes 91 25 Examples of Wireframes and Mockups Sketches

Harvest iPhone App Sketches

34 sketched ui wireframe1 500x362 25 Examples of Wireframes and Mockups Sketches

iPad Radio App Sketches

4691743792 99c2157bb11 25 Examples of Wireframes and Mockups Sketches

Very Rough Sketch

2733732935 84905b0f0c1 25 Examples of Wireframes and Mockups Sketches

“Scratch-Off” Concept

3657128657 41e7268da41 25 Examples of Wireframes and Mockups Sketches

Cloudvox HomPage Wireframe

5126823647 956c8008a31 25 Examples of Wireframes and Mockups Sketches

This week I have found a great collection of wireframes and ui sketches on inspirationfeed complied by Igor Ovsyannykov.


Why wireframes can hurt your project | Attack Of Design

Wireframes are one of the main tools in the user experience designer’s toolkit. Most usability and web design books devote a considerable section to sketching, paper prototyping, and other forms of planning. But while I agree wireframes can have their place in some projects, I think they are actually detrimental in a lot of cases.

A new environment

In recent years, a few factors have started shaping the world of web design and development in a new direction. I’m talking about things like:

  • The emergence of frameworks like Rails or jQuery, and services like Heroku or EC2, who all contribute to minimizing development time.
  • The success of 37Signals and other bootstrapped companies which show that you can be successful with limited resources.
  • The lean startup movement and the notion of minimum viable product.

All of these things have come together to create an environment where web products are quicker to develop, focus on fewer features, and are flexible enough to adapt to a changing market.

The downsides of wireframes

I’m increasingly unsure that traditional wireframes have their place in this new landscape. It’s a basic truth of the design process that the more time you spend working on something, the more attached to it you get. So if you spend hours on a Photoshop mockup, you’ll probably hesitate to discard it even if it becomes apparent that your design doesn’t work in the browser.

A wireframe’s rigid boxes and simple aesthetic can provide comfort compared to the web’s chaos. So even though we should all know better, it’s easy to get attached to a wireframe. You might not think this is a problem. After all, we often hear things like “a good prototype is 50% of the work”. But think about it, this means that you’re restricting your options at the earliest stage possible, before your product has even been used by a single customer!

What’s more, obsessing over wireframes can eat up valuable time, without much to show for it. You can’t even be sure that the solution you found is really better than any other. Wireframes are usually not interactive, and unlike Photoshop mockups they don’t show you contrast or hierarchy, color or typography. It’s easy to find a solution that “works” when most of the problems aren’t addressed at all.

The right way

So what are you supposed to do? In many cases, wireframes are used to kick off a project because they’re relatively fast to create. But many designers work just as fast in Photoshop, and good coders can whip out a html/javascript prototype in a couple of hours. So first, you should ask yourself if you need to use static wireframes at all.

Pinboard: probably didn’t use any wireframes (or Photoshop)

If you do use them, make sure everybody understand that each step of the process exists to support the next one, not dictate what it should be. The wireframe should remain a tool that helps with the creation of a higher fidelity mockup or html prototype, not a perfect blueprint for it. This means that no part of the wireframe should be off limits when it comes to changes (and this is also why I don’t raise a stink if a client’s finished product doesn’t look exactly like my Photoshop mockups).

Beyond wireframes

If you want to go beyond wireframes, there are alternatives. For example, a simple list of a page’s element can be a surprisingly effective way to guide a designer without influencing him, and keeps the focus purely on the content.

Balsamiq Mockups: am I the only one who finds this ugly?

But in my opinion, the ultimate replacement for a wireframe is simply the site itself. This might come as heresy, especially on a design blog, but I actually advocate for development before design whenever possible.

Why force a designer to work from uninspiring and ugly (there, I said it!) Balsamiq mockups when you could simply give him access to your test server and let him try out your prototype by himself? Don’t be ashamed of your site’s bare looks. After all, if you’re not ashamed of your first version, you’ve waited too long.

So here’s my takeaway on wireframes:

  • They can be a useful tool for people who can’t design and can’t code.
  • Getting attached to them is a surefire recipe for wasted time and energy.
  • Wireframes are guidelines, not blueprints.
  • Ask yourself if your time wouldn’t be put to better use actually coding or designing.

How about you, do you use wireframes? Have you ever encountered some of the problems I talked about?

Today I found something different. An article by Sascha Greif, who questions wireframing for various reasons.


The Benefits of Wireframing a Design

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).

Wireframe example 1

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:

Wireframe example 2

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

Wireframe example 3

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.


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.


Sketchboards: Discover Better & Faster UX Solutions

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.


7 myths about paper prototyping

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 are dead, long live rapid prototyping « UX for the masses

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:

An example wireframe with footnotes

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.


Stop trying to kill the wireframe! | Corporate Edge

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.


Don’t forget Blue Beanie Day!

  1. Take a self-portrait wearing a blue beanie (toque, tuque, cap) and upload it to the Blue Beanie Day 2010 pool on Flickr.
  2. Add a blue beanie to your social network avatar on Twitter, Facebook, Flickr, etc.
  3. Write a web standards haiku and post it on Twitter with the hashtag #bbd4 for your chance to win web design books from Peachpit and A Book Apart in the Blue Beanie Day Haiku Contest.

See you on the internets!

Pls support web standards and take part in the international blue beanie day.