10 Simple Ways to Make Wireframes More Useful
I get to work with a lot of wireframes – not just the ones I’ve designed myself but ones that other UXers designed, as well as product managers and business analysts. This is great because it exposes me to a lot of fantastic work. The work is always good, but the elements I’m going to discuss in this article are often missing from a lot of wireframes, stopping them from becoming as useful as they could be.
Here’s a typical example of the kind of wireframe we often get given to user test with.
A wireframe showing where elements should be placed
It shows which elements need to be placed on the page and where they need to go, but there are several things that are not being communicated to the designers, developers and indeed the users that we test with. The following rules will help your wireframes communicate with more insight.
Advertisement
1. Show visual priority with shading
What should users be looking at on this page? Where should their focus be? What is the key action we want them to take next? The above example of a wireframe does not show any of this.
If you’ve been following a user centred design process, then you will have gathered information about what the business wants the users to do on this page, as well as what the users themselves want to do. The problem with this style of wireframe is that it’s not communicating all this great insight through to the design team.
To add visual priority, simply remove the harsh black lines around all your elements and use shading to give certain elements on the wireframe more prominence then others. You can see in the example below that the hotel details and booking form has more focus now and the Proceed button is the darkest element on the page (because that’s what we want the user to do next).
Shading communicates what areas of the page we want the user to focus on
It’s important to note that by doing this we are not taking away the role of the designer. We are not saying, one element should be darker than the other. All we are communicating is what elements need more visual prominence than others. How that visual prominence is achieved is down to the skill of the designer.
2. Use real data
It is incredibly important to populate wireframes with real data. By real data I mean everything from page titles to navigation labels, form labels, icons and even example copy. Anything that can be interpreted by the user in some way.
This emables you to design for a worst case scenario. You want to make sure that your beautifully laid out wireframe is still going to work once the site is populated with copy and images.
More importantly, using real data is imperative for creating a believable user journey for participants during user testing. Without it participants in testing are having to use their imagination to populate it themselves. It’s hard to ask someone to get into the frame of mind of booking a holiday or buying a car, if all they are presented with is Lorem Ipsum instead of actual product descriptions.
Real data also gives you much more insight when user testing. Bearing in mind the wireframe example at the start of the article, if you were to take this into user testing, with no copy or icons or labels, the questions you could ask users would be limited.
Asking leading questions such as ‘Can you see the key features of this hotel?’ is problematic. By asking you are highlighting to the participant that there are key features displayed somewhere on the page, and they then know to look for them. It also limits the depth of response the participant can give you. ‘Yes I see them down there’ is not going to help you gain much insight.
Instead, testing this wireframe with actual copy and icons enables you to ask much broader and open questions such as, ‘How do you feel about this hotel?’. This opens up the opportunity for the participant to give much more insightful answers such as ‘The hotel looks nice, but they’ve got a family pool and I hate hotels with kids running all over the place’.
Testing wireframes with data gives you more insightful results
This tells you not only whether or not they have spotted elements of the page, but also how they respond to language and icons being used.
If you test a wireframe without data, you test its usability. Test a wireframe with data and you can test its user experience.
3. Make sure everything adds up
When you put all that lovely realistic data in your wireframes, you need to make sure you create a consistent journey through the pages. If your wireframe for a basket page has two products at £50 each, and the total is mistakenly displayed as £107.99, the user will notice, and it will throw them of their task.
Mistakes like this are easy to miss when you have been working on wires for a while, so its always worth getting someone else to go through them for you.
4. Consider and describe images
Images are an incredibly important element of the user’s experience. They’re a fundamental factor in people’s decision making when searching for products and services, and deciding if they are worth investigating further. They also have a large effect on how people perceive the quality of your site and your business. Yet when we wireframe the only thing we use to represent these incredibly important pieces of information is a grey box with a cross through it.
I’m not saying we should come up with every image to be used on the site. What we should be doing is trying to communicate insights about the type of images that would be used. If you perform benchmark testing prior to wireframing, you are guaranteed to learn something about the images used on the site you test.
For example, I worked on a redesign for a shirt retailer; before any wireframing took place the existing site was user tested. Once of the key things that stood out was that the product shots were confusing users. In order to make the shirts look nice they were dressed with ties and cufflinks. This lead to some confusion as to whether the ties and cufflinks were included with the shirts. When it came to wireframing I included a sketch of a shirt with no tie or cufflinks in order to pass this insight across to the client, and make sure the issue was avoided in any future product shots.
Describing images doesn’t have to be as prescriptive as showing sketches. Simply explaining the types of images the user would see on the page can be enough. For example when designing a hotel website, what images will the user want to see on a hotel details page? The room? the bathroom? The view out the window? This is all insight you will learn during research so its worth including this in your wires.
Describing images communicates what the users what to see from a product
5. Be careful when using colour
Colour on a wireframe is usually reserved for annotation. However, it can be used to flag specific areas that you want clients to focus on, or for showing different page states such as error messages. However all colour should be removed from you wires before they go into testing to avoid coloured elements drawing the user’s attention and skewing the results.
6. Ensure that interactive elements have the appropriate affordance
Interactive elements need to look how they work; buttons looking clickable, for example. This enables you to learn whether calls to action are clear enough during testing, as well as showing the designer and developer which elements need affordance.
Make buttons look like buttons
7. Work in actual pixels
This isn’t much of an issue if you are wireframing in HTML. But if you are creating flat wires, working in pixels takes away a lot of guesswork for you and for the designer. It sounds obvious but I see it happen a lot. I didn’t used to work in pixels when our wireframing tool of choice was Powerpoint, but this then caused issues when going into design. Wireframing in the actual pixels of the final design enables you to accurately size and place elements on the page.
8. Include a change log
As your wireframes go through several iterations, the changes being made become smaller and smaller. Going from complete page restructures to minor copy changes. As you get down to these small tweaks, it’s hard for the people reviewing the document to notice all the changes that have been made. A simple change log at the start of the deck helps keep everyone up to date with the changes that need reviewing. Each entry in the change log should include the document version number, who made the changes and all the changes made with page references.
Change logs help everybody know what updates have been made
9. Avoid black lines
It’s easy for wireframes to look cluttered with all their lines, boxes and bullets. This is always made worse by the overuse of heavy black divisions. Try to avoid lines altogether: use shaded boxes to group items instead, and if you need to use lines go for thin grey dotted ones – your wireframes will look far less cluttered.
Use shading and lighter dotted lines to reduce visual clutter
10. Don’t just wave them goodbye
This is less of a design technique and more part of the overall delivery process. It’s important not to just throw your wireframes over the wall to the client and wave them goodbye. Set aside some time to support the design and development teams as they implement your ideas. With the best will in the world, the things you commit to wireframes may not always be understood, or may not work when put into practice. It’s important to be on hand to clarify any issues and help come up with solutions based on your user research.
So those are some key ways in which you can show more user insight in your wireframes and make them easier to use. You can find more information on how to research and deliver wireframes, as well as practical advice on creating them in OmniGraffle and Axure, in Communicating the User Experience: A practical guide for creating useful UX documentation, by Richard Caddick and I.
Source: netmagazine.com
