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.

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!

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. via boxesandarrows.com

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

Focus on Communication
The key point of wireframes is to communicate. Don’t forget this. Keep them simple and stop working on them as soon as they communicate their key information.

Use Proper Documentation
Since wireframes are meant to communicate something, provide some accompanying notes. Whenever possible, each wireframe should include documentation, i.e. revision date, author, page title, interaction notes, etc.

Host the Wireframes
If possible, host the wireframe files yourself, rather than sending them out as email attachments. My preferred method is to export the files as PNGs and then embed them within some simple HTML files. This way they’re easy to share and update.

Don’t Forget the Goal Of the Page
Keep the goals of the page in mind when designing a wireframe. Focus on driving action. Organize the information into a hierarchy that serves the goal of the page.

Pick Your End Point
Prior to commencement, work out who will be consuming the wireframes, how they’ll consume and what level of fidelity is required. Remember that there’s a relationship between the level of fidelity and type of feedback. Will quick paper sketches suffice or will they need to be fully interactive with accurate dimensions? Keep in mind: the less precise the wireframes are, the more liberty and creativity a designer is going to take with them. On the other hand, if you they look perfect designers may feel inhibited and merely “color in” the wireframes, preventing the design process from really getting going.

Loop the Rest of the Team in
Wireframes are not just for clients. All members of the web team should provide feedback on them, buying into the process at an early stage.

Consider the Content
If your wireframes aren’t sketches then be realistic about the amount of content that will be added to the page. This holds true also for number (and length) of links in navigation. If practical, use accurate sized fonts, images and consider what will happen when more text than is ideal is added. Nothing on the web should be etched in stone, so ask if the design will flow as required.

Use Common Elements
If designing a set of pages, use tools that allow you to make multiple changes to all common page elements at once. Moreover, as you’re creating the wireframes, look out for design patterns that repeat. Leveraging these is key to gaining efficiency and consistency.

Get Feedback
Don’t be afraid to test your wireframes in a couple of informal user tests. Grab people from around the office and ask them to find various bits of information or explain what they think the function of certain elements is.

Top 10 Wireframe Tips brings you a couple of insights on how to improve your wireframing. Top 10 Wireframe Tips is an excerpt from Neal McGann’s article: Wireframing: Tips, Tools and Techniques (Pt2). Pls visit UXBooth for the full article.

How long has it been since you’ve heard designers argue about which method is better: sketches, wireframes, mock-ups, or HTML prototypes?

Probably not long enough…

One designer will claim that you shouldn’t do anything without sketching it out while another claims that doing anything less than full-on HTML prototypes is a waste of time. All of these tools have a special purpose so there’s no point in discussing which one is better. That would be a lot like an electrician saying his wire-cutters are better than the plumber’s pipe-cutters. Within the context of cutting wires it makes sense, but everywhere else it’s just silly.

There is one thing all these tools have in common: they help remove layers of ambiguity within a project. Think of them more as communication tools that help you clarify and demonstrate your intentions to other designers and to your clients. Occasionally they become deliverables, but it’s important to remember they can never provide the final answer.

This piece is about bringing clarity to this discussion. It will help you decide which tool to use without worrying what other designers are arguing about.

Match the tool to the problem

Sketches are usually hand-drawn graphics that contain screen ideas or explanatory graphics outlining the high-level problem or solution. They are the most valuable when the idea hasn’t been fully formed, explored, or realized in any way. Sketches will help you understand what general pieces are needed to accomplish your goals.

Wire-frames tend to be computer generated graphics illustrating the organization of content, features and functionality. Prioritizing the elements of a design and determining general page layout can be a very messy part of any project. A well built wire-frame will help you pull apart the individual pieces and make sure they are appropriate to the goal of the page.

Mock-ups are rich graphics intended to simulate the look and feel of a project so you can understand the impact visual elements have on the brand. A mock-up can set the right impression and communicate emotions and personality. Without actually building the website (which a lot of people do), there really isn’t any other way to concretely define what a website should look like.

HTML Prototypes are partially-complete versions of a website used to understand how pages interact with each other and flow from one area to another. More complicated interactions between sophisticated components might require a fully functional prototype to actually understand. When there are a lot of moving parts and goals have multiple steps involved, HTML prototypes can really help you find the gaps in your plans.

Let’s play with a few examples

You’re building a Basic Marketing Website and you already know the website’s goal, are confident in the assumed layout, and understand how the pages interact. Jumping directly into the mock-ups will be the best use of your time. That way you can get as close to the final result as possible in the least amount of time.

It’s the ninth time you’ve built a Well Understood Application and you deeply understand the goal and know how all the pages interact, but want to make it fit perfectly with your client’s team. This is where wireframes really make a difference. They can help you communicate how the application is organized and identify potential ways to make the interface more intuitive.

You’re starting a Brand New Idea, and the hardest parts are grasping the concept and determining how the pages will work together. For this to happen, you’ll probably need to jump back and forth between sketching and HTML prototypes until you’re confident the core purpose is captured. These initial HTML prototypes can also become great tools to illicit feedback from your team or potential customers (alpha/beta testers).

Now what?

Every project may need one or all of these tools in various order depending on the challenges you’re confronted with. So the discussion shouldn’t be about which tool is better or how to align them into a formal and rigid process. It should be about which one, at any given time, can give the most clarity and boost productivity.

Article by Daniel Ritzenthaler released on 52 Weeks of UX. Dan is a web design consultant based in Boston. He makes videos about common questions he hears from clients on Design Thoughts, and can always be reached on Twitter @danritz. Learn more about him at http://wurkit.com/.

In this article Daniel sums up why it is important to look at design tools as communication tools and how to choose the appropriate tool for the right task.

I have a love hate relationship with wireframes. In the last 10 years they’ve been a part of every web project I’ve worked on. There have been times when I can’t imagine how we would have solved a particular problem without them. Yet there are also times when I’ve been completely exasperated at the amount of time and energy they’ve consumed, seemingly to very little reward.

This frustration has forced me to change the way that I approach wireframes. And as my approach has changed, I’ve been able to extract more and more value from black key lines and grey boxes…

From functional to visual

10 years ago the first wireframes I used were about as functional as you can get – a long list of page elements: static text, dynamic text, input text, radio button and so on. They were universally awful. About the only concession to help people understand how the page worked was to group common functionality into individual tables.

The wireframes were functional rather than visual as they were used to describe how the page should be built. Certainly, when you consider the screen from a developer’s perspective a list of different functional elements is probably quite logical.

However, from a user experience point of view this was a killer. Functional wireframes are incredibly difficult to read – the method of presentation gets in the way of being able to translate the information into a real screen, especially at the review stage.

Looking at this image it seems obvious that wireframes should be visual, however, IA was in it’s infancy ten years ago. Everything was new.

Wireframes also took a long time to produce. Changes to one wireframe often meant updating countless others. Change to the global nav? Certainly. Just one moment whilst I update 120 wireframes with that one.

Understandably, this hampered attempts to create wireframes that more closely represented real life screens. To help get around this, when they did become visual, they also become modular.

The modular approach to wireframes also reflects the reality of building sites. Functionality and snippets of code are built once and then reused over and over again. So why not create wireframes in the same way?

Visual wireframes also started to break down a belief that information architecture can be considered in isolation to information design. The information is the interface. How can the two possibly be separated? Join them together and you start creating wireframes that can be read and understood by everyone on the team, including the client.

Of course, this can raise the problem of clients expecting the final screens to be identical to the visual wireframes. “In the wireframes the submit button is on the right of the drop down, but in the designs it’s below. Why?” This requires careful client management, but it can be largely avoided if the wireframes concentrate on getting the ideas and thinking across, rather than just laying out a page.

Once wireframes are created using information design as a technique rather than just a visual conceit, they can be used to explain how a site will be experienced by the end user. In the example above the different colours represent different areas of content, targeted at different types of users. The client and the team can then get inside the screen and understand how it works and what the priorities are. It’s a very different world from 1999 – a list of functional elements that only be read by the one person – the author of the original wireframe.

As wireframes have evolved, the methods behind creating them have changed too.

Isaac Pinnock speaks from his own 10 years of experience and from his personal lessons learnt when it comes to wireframing. This article is wrap up through the history of wireframes: the past, the present and the future peppered with tips and best practice models. This article is only an excerpt for the full version or commenting please head over to the Made By Many blog.

Third Episode of the web documentary Bedrift 2.0 by citomedia recorded at this years Frontend conference in Oslo. The topic of this week is going to be the key factors of successful webdesign feat. Aral Balkan, Daniel Burka, Paul Boag …

Have you ever deliv­ered your wire­frames to a client only to have them quickly tell you what things they dis­like and want you to change? The prob­lem here is that biases occur when peo­ple judge some­thing before they under­stand it. One can­not objec­tively judge a design unless they thor­oughly under­stand it. It is likely your client is not well versed in the prin­ci­ples and prac­tices of user expe­ri­ence design. This is why it is your respon­si­bil­ity to com­mu­ni­cate your ratio­nale for your design deci­sions on your wireframes.

Anno­tat­ing your wire­frame ele­ments with clear and con­cise expla­na­tions is impor­tant and nec­es­sary, so that clients can under­stand your design before they judge it. If you leave them off, your clients have the power to assert their biased judge­ment on your design, which can cre­ate a breed­ing ground for sub­jec­tiv­ity. To pre­vent this from hap­pen­ing, it’s impor­tant to anno­tate your wire­frames and offer rea­sons and ben­e­fits about why your design is effec­tive. This will give them insight to your think­ing process and allow them to think about the things that you think about when you design. Below is an exam­ple and four best prac­tices on how to anno­tate your wireframes.

1. Keep them short and to the point

This is where your writ­ing skills come in handy. Giant blocks of text aren’t attrac­tive to read. Keep your expla­na­tions short and to the point. You may have a lot of anno­ta­tions, which is why keep­ing them short will make for a faster and eas­ier read. Any fur­ther elab­o­ra­tion could be fol­lowed up with a meet­ing if needed. How­ever, clients are usu­ally scarce on time, so I wouldn’t count on it. Get every­thing you want to say on your wire­frame, but keep it concise.

2. Focus on user benefits

Every design deci­sion you make should ben­e­fit the user. Thus, your anno­ta­tions should focus on explain­ing how each design ele­ment helps the client’s users. Focus on the ben­e­fits because that’s what clients care about.

3. Use numer­i­cal mark­ers and order them

Enu­mer­ate your anno­ta­tions and order them from left-to-right going down the page. This makes it eas­ier to read and will pre­vent clients from hav­ing to jump around the page to read each annotation.

4. Keep them in a col­umn on the right

Keep your anno­ta­tions on the right next to the wire­frame, so that clients won’t have to look too far to read them. It fol­lows the nat­ural left-to-right pro­gres­sion peo­ple use when they’re reading.

Anno­tat­ing your wire­frames is an extra step in the process, but it is well worth it. If you truly believe in your design you will go through great lengths to help your clients under­stand it. It’s hard for clients to look at a wire­frame and notice every grain of detail you have put into it. Anno­ta­tions allow your clients to look at your design with­out pass­ing judge­ment. As a designer, your job is to think objec­tively. Some­times in order for a project to suc­ceed you will have to help the peo­ple you work with think objec­tively as well.

Don’t use notes just for feedback use them for guidance! Anthony explains in this article why it’s important to put notes next to your wireframes.