Interaction design starts on paper

An architectural plan is to building a house as a wireframe is to designing a user interface. Wireframes are our way of experimenting with ideas, visualising concepts and gaining valuable feedback before cementing our work in code.

‍

‍

In this session we cover:

• Ideation vs. validation
• The 8 traits of a good wireframe
• 8 UI principles to get you started

‍

Start with sketching first!

When you sit down to start designing a website or app, it can be tempting to go directly into Photoshop and start playing with colours and drop shadows right away. This is almost always a mistake!

There are two problems with the Photoshop-first method:

‍

1. It is almost always a waste of time

No matter how quickly you can use Photoshop, it is inevitably more time-consuming than just sketching out an idea. In reality, you can probably sketch out 50 ideas before you can finish a single page in Photoshop. I’m not talking Rembrandt — just rough lines, boxes and arrows.

‍

2. ‘Visual sugar’ can hide structural issues

People don’t like to give feedback on screens that appear finished. The more time and effort it looks like you put in, the less likely someone is to want to make you redo it. It also limits the scope of the feedback to superficial choices like colour or alignment. There is a time and place for that type of refinement: after the foundations are laid and agreed upon.

‍

You select curtains after you decide how many rooms and how many windows.

‍

Side note: Sometimes spelling in wireframes is important. Depending on who you show it to, some people just can’t sea passed a speeling misstake.

‍

‍

Ideation vs. Validation

Wireframes start as simple sketches and evolve over time, gaining higher visual fidelity as we get feedback from our peers and users.

As you move though the design process you can use wireframes in two ways.

‍

‍

First, for ideation (discovery).

This is where we use wireframes to explore and visualise our thinking. Ever have an idea that seems AMAZING to you in the moment but when you go to explain it to someone, it starts to break down and you forget what made it seem so brilliant?

When an idea pops into your brain it can often be a mirage. You think you can see it clearly but it isn’t until you try to bring it into focus that you notice there is detail missing. The danger of leaving ideas in your head for too long is that you start to focus too much on the nice feeling the idea gives you and not on the practicalities of making it real. (This phenomenon is known as ‘brain crack’.)

Next time you have an idea for a website or app, try to capture it right away in a quick sketch (or series of sketches). What does the screen look like? What does the text say? Is there navigation? If so, is it on the left or the right? Once you have the initial idea down start exploring variations and improvements.

‍

Ideation wireframes should be:

• quick — try to keep up with your creativity
• collaborative — share your work; get others involved
• numerous — paper and ink is cheap; embrace ‘quantity’
• hand drawn or very, very simple digital mockups
• available for feedback.

‍

Second, you can use wireframes for validation (refinement)

After you have found the basic structure and direction of your idea, it is time to refine it. It is now alright to start spending more time finessing each revision before getting feedback as you start to make smaller, more directed changes.

‍

Validation wireframes should be:

• black, white and shades of grey. It isn’t time for visual design just yet.
• higher fidelity. Start to consider placement, hierarchy and content.
• computer generated.

‍

‍

The 8 traits of a good wireframe

Let’s now have a look at what makes a good wireframe, irrespective of whether it is for ideation or validation.

‍

1. It facilitates conversations

Creating wireframes should be a team sport. Everyone can sketch out a rough idea, and sharing an idea visually is so much faster than trying to explain it! Make the sketches public, hang them on a wall, discuss them, cover them in sticky notes and then create another one based on the discussion.

‍

2. It doesn’t use colour

Wireframes shouldn’t use colour, they are deliberately kept ‘rough’. Think of a wireframe as an X-ray of your product. So no clothes, skin, hats or hair allowed! Sometimes as a designer it can be hard to share work that feels ‘unfinished’. Make it clear that what you are showing is not the final version and you are more likely to gain constructive and meaning feedback.

‍

3. It is simple and doesn’t include advanced visual formatting

This is also not the time to bevel your buttons or add fancy fonts. Keep your interfaces simple and standard. Use default system dropdown menus, search boxes, buttons, text and navigation.

‍

4. It’s mobile first

Very rarely do our designs only end up on a large desktop screen. Most likely, your design will need to work on mobile screens, tablet screens, old screens and of course, large desktop screens. So why not design for mobile first? Designing for a small screen makes you focus on the essentials; it means you have to make the hard decisions of what is most important because the screen real estate is limited.

‍

What is your idea in its simplest form?

‍

Once you have nailed the mobile design it is easy to then ‘progressively enhance’ your design as you are afforded more room. Alternatively, when designing for large screens first it can be tricky to try to squish your large idea down onto a smaller screen.

‍

5. It uses actual text (no placeholder lorem ipsum)

Why do users come to your site? Is it for your interface or for your content? Although sometimes designers like to think it is for their designs, it isn’t. Content is what users want to see; it should help inform your wireframes.

‍

6. It has basic annotations

Wireframes should speak for themselves — they shouldn’t require you explaining and advocating for them. Once your design gets built and becomes live you won’t be standing in every user’s home telling them how it works.

Use simple annotations to indicate any behaviour or functionality that may not be obvious in the static drawing.

‍

7. It is based on a grid

There are 2 main reasons why designing on a grid is a good idea. Firstly, it helps you keep the lines straight and your hierarchy consistent. Secondly, designs on a grid are easier for developers to make.

‍

8. Lastly, it can be criticised without ramifications (it shouldn’t be your baby)

It is important that you don’t treat your wireframes as a work of art, or an extension of yourself. This is partly why you shouldn’t be investing too much time in each one. Stay open to feedback and keep your perspective.

‍

Wireframe Inspiration:

http://wireframes.tumblr.com/

‍

8 UI principles to get you started

Lastly, aside from user testing and peer review, another way we can evaluate our wireframes is by referencing design best practice and usability heuristics. This is by no means a complete list but hopefully it is enough to get you started.

(I have included links to more lengthy usability reference material at the end.)

‍

‍

1. Users have limited attention and limited time

Your user isn’t sitting in a quiet room focused on your website. They’re standing on a train, sitting in front of the TV or being interrupted at work.

‍

Review your wireframes and ask yourself:

• How long will it take the user to complete this task?
• If they get interrupted or distracted mid-way, will they be able to pick it back up again when they return?

‍

Things to consider:

• Try to split a long task down into manageable steps.
• Make it clear to the user which step they are currently on and how many steps are left to achieve their goal.
• Allow users to save their current progress. This could be a bookmark, a checklist, a shopping cart, a save button, or even just save their progress automatically (thanks Medium 😉).

‍

‍

2. Minimise the need for users to use their short-term memory

Human short-term memory isn’t photographic, and when you also take into consideration a limited attention span and the large number of apps the average person uses every day, it is no surprise they struggle to remember the nuances of your app’s interface.

‍

Review your wireframes and ask yourself:

• To complete this task successfully, what will the user need to know or remember that isn’t on the screen?

‍

Things to consider:

• Keep navigation lists under seven items. Most people can’t mentally work with more than seven items at a time.
• Make sure users have access to relevant information when they need it.
• Allow the user to review information entered in previous steps.
• Make sure help and instructions are shown inline and not on a different screen buried in another section of your site.
• Make it clear if a user is in a specific mode. For example, are they are logged in?

‍

‍

3. Recognise rather than recall

Linked to the principle above, users are much better at recognising what they want to do, than remembering what they can do.

‍

Review your wireframes and ask yourself:

• What features, functions or actions aren’t immediately recognisable to the user?

‍

Things to consider:

• Make sure the meaning of your icons are INCREDIBLY obvious or are accompanied by a label. If you’re not sure, test it. You will be amazed by all the different and unexpected ways people can interpret icons.
• Show users their options. Don’t hide functionality behind drop-down menus, hamburger buttons or settings screens. Don’t force users to remember where you put/hid something. (RIP Dropdown Menus)
• When showing users a list of options to choose from, try to give them a visual preview to support the text label. For example, add product images to a shopping cart or a profile photo next to a list of names.
• Use breadcrumbs and clear headings to make it obvious to a user where they are within your site’s hierarchy. Make it clear to the user where they are on your site so they don’t have to remember how they got there.

‍

‍

4. Visual hierarchy and content structure

It is often said that ‘on the web, users don’t read’. Not true. The truth is that users generally come to a site with a question or a goal. They will happily read anything that will answer their question or get them closer to their goal, but don’t have time for anything that doesn’t or won’t.

When a user gets to your site they will quickly scan it for clues to find the information they are looking for. They will ignore anything that is either irrelevant to their goal or too dense to make head or tail of. We can assist them by properly formatting and structuring our pages.

‍

Review your wireframes and ask yourself:

• Why has a user likely come to this page?
• What questions might they want answered?
• What goal might they want to achieve?

‍

Things to consider:

• Make your headings clear, prominent and relevant.
• Use bullet points, numbered lists and tables where appropriate.
• Format information like phone numbers appropriately so they can be recognised at a glance.

‍

‍

5. Make text easy to read

Now that we know that users do in fact read, let’s make it easy for them to do so.

‍

Review your wireframes and ask yourself:

• If I had to read this and many pages like it, would I get a headache?

‍

Things to consider:

• Make sure the line length is reasonable (not too long, not too short) on all device types.
• Use a clear and legible font, at or above 16px.
• Make sure you have significant contrast between the text and background colour.
• Don’t centre align large chunks of text, and never ‘justify’.

‍

‍

6. Various screen sizes

You can’t control what device your user owns. You can’t control how much screen room the users chooses to give your interface.

So don’t try.

‍

Review your wireframes and ask yourself:

• What happens if a user has a smaller device than my current design?
• What happens if a user has a larger device than my current design?

‍

Things to consider:

• Responsive or adaptive design.

‍

‍

7. Error prevention

It is unavoidable — sometimes things go wrong. Sometimes it is the website’s fault; sometimes it is the user’s mistake. No matter who’s at fault there are things as a designer you can do to reduce frustration.

‍

Review your wireframes and ask yourself:

• What happens if the user does something unexpected?
• What happens if the system fails or falters?

‍

Things to consider:

• We learn better and explore more when risk is low. Help users feel comfortable by making it easy to recover from mistakes.
• If something goes wrong with the system, provide the user with clear and instant feedback explaining the problem.
• Provide enough information so the user can diagnose and recover from errors themselves, without contacting customer support.
• If a call to customer support is required, display the contact details prominently and give the user information that will help them explain the issue to the operator.

‍

‍

8. Consistency

Users start to feel uncomfortable when faced with the unfamiliar or unexpected. Your app should be consistent both with itself and with other applications that do similar things.

‍

Review your wireframes and ask yourself:

• What on my interface might the user never have come across before?
• How might the user have completed this function before? What do they expect?

‍

Things to consider:

• Resist the urge to create something ‘clever’ or ‘fancy’ just for the sake of it.

‍

Usability reference material:

‍

Designing with the Mind in Mind: Simple Guide to Understanding User Interface Design Guidelines

Heuristic Evaluation Articles & Videos

UX Tools for Wireframing and Prototyping

‍

Hi, I’m Ben. By day, I’m the Founder & Head of Product Innovation at Beaker & Flint, where I help organisations design and deliver amazing customer experiences. By night you can find me running a trail or tinkering with code.

If this post sparked a question or idea you want to run by me, I’d love to chat it over with you. Reach out via the comments below or start a conversation via email here.

‍

‍