The wireframe.

A low fidelity visual guide to what an app screen or webpage is going to look like, and they are used in the idea and testing phases of a piece of work in order to get across how something might look or interact. They’re a great tool for getting your thoughts across in a simple way.

The idea is that because they are low-fi then they’re easy to change as discussions progress, and they allow people to review screens without getting caught up with ‘design’ elements like colours, fonts or styling.

In the past, wireframes have typically been created by designers as a first step to getting their design brief down straight, but I think there’s an argument that these should be done by anyone thinking through what a product or feature should be delivering, before it even gets to a designer.

What will I get out of wireframing?

The intention of a wireframe is to get down onto paper / monitor the elements that will be present on the final screen, and this allows you to show user journeys and actions, i.e. what your user wants to achieve.

The physical act of creating a wireframe forces you to think through a whole host of factors that you might not do if you were simply to write out the requirements.

What content do we need?

What information is actually going to appear on the page?

If you’re showing a table of data, then what are the actual columns that are going to be shown? This then leads you down the thought process of what format is that data in? Is the data long or short and how will that affect the layout? Will we have access to that data or do you need to write another requirement to get hold of that data?

If you’re showing an input form, then what input fields do you really need? This then leads you down the thought process of what happens if this data is not input correctly? What validation do I need on the input field? Does the validation occur on entry or on submission? What happens to data if the submission fails?

You may also begin to question the relationship between the content, such as relative importance or update frequency, whether the content is likely to change in the future and if so what might you need to add to the screen in the future that could be considered now. These are just a few examples.

How will users interact with the page?

Many times I’ve started working on a wireframe and realized that “Ah! In order to do action X I’m going to need a button Y”, which I’ve not considered when writing my user story. This means I’ve now got to adjust my wireframe and write a new story for the action that will occur when I click on the button.

Once you start to see the outline of the screen on the page then you start to consider the number of interactions that there might be, all of which will impact upon the stories you write and the work the team will need to do. Will the data table be searchable? Will it be sortable? Do you need paging if you go over a certain number of results? How will users find out more information? How will then perform the primary and secondary actions and what happens when they do?

Sometimes just seeing the layout of the page will drive a series of thoughts that will cause you to go back to your audience to find out more, or at least cause you to write out with more clarity what needs to be delivered.

How does the different content relate to each other?

As touched upon with content, once you start drawing out the wireframe then you start to consider the different elements on the page next to each and gauging their importance next to each other.

You’ll start considering the primary and secondary actions, or primary and secondary information, and a hierarchy of content will begin to appear.

If you were to wait until the design stage to start showing this hierarchy then you might be slowing down the process with redesigns, and incurring extra cost in the process.

What does the business get out of wireframing?

As well as getting a better quality piece of work from you, there are huge benefits to working through many of the above questions at the wireframing stage.

The National Institute of Standard Technology (NIST) published a study in 2002 noting that the cost of fixing one bug found in the production stage of software is 15 hours compared to five hours of effort if the same bug were found in the coding stage, which for the purposes of this discussion we can replace ‘bug’ with ‘change’.

If we identify the change early then we’ll avoid some very costly errors by taking a little extra time at the requirements stage

What tools are available?

In no particular order:

Balsamiq

My wireframing tool of choice, as it’s very simple to use, doesn’t have too many features and thus allows you to focus on the basics. After all, you’re looking for a low-fi approach. They provide a free 30-day trial for you to test it out, it doesn’t need any training, and you can export your files when you’re done.

Mockflow

A simple app to drag and drop page elements and bring them together into a full app or website mockup. I’ve used this in the past but the general user experience wasn’t very intuitive and with a limit on the number of pages you can have in the free trial (3) meant that I didn’t want to be using this long term.

Wireframe.cc

One that is perhaps more geared to the designer community, wireframe.cc allows for very precise placement of handful of generic elements which can give a good output, but it doesn’t feel like a quick way to mock up something that you’ll then adjust a number of times.

Draw.io

More of a flowcharting tool that can be used for wireframes, but ultimately if your app or webpage is boxy and pretty standard then it does an OK job. Once you want your wireframes to look a bit more like an app and less like a Powerpoint slide then you’re going to be disappointed by Draw.io.

And one last tool …

Ask yourself how complicated your wireframes really need to be. Do they need full page layouts, or can you get away with small feature mockups. If less is needed then you can always resort to pencil and paper.

The idea is to convey a low fidelity visual guide to what you want to achieve, and sometimes you can do that just by drawing it on a piece of paper.