Wireframes are 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 to 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.
Don’t I need to buy software to make wireframes?
The short answer is ‘no’, you don’t need software to make them, as you can just sketch them out with a pencil and paper and they’ll do the same job, but you might find that a little tedious after a while.
The slightly longer answer is that ‘yes, it certainly helps to have some software that can help you create wireframes’, and there are quite a few out there.
I’ve used the following:
- 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, 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 this one, 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.
If we’ve got to consider how we want a product or feature to work, and get this idea over to someone else then we shouldn’t be afraid to get our hands dirty and mock up what we think needs to happen on the page, if for no other reason than it helps us form our thoughts and prompt us to ask more questions about what we’re hoping to achieve and what we need to consider in order to achieve it.
Seeing the beauty in a user story
User stories are small expressions of end goals, not descriptions of features, and can be little works of art in…
Want more content like this?
If you’d like to receive more product management focused content like this then subscribe to my newsletter below to get it straight to your inbox.
Rob was a professional soccer player, and cinema manager, before moving into software development 20+ years ago. He was a founding team member at a FinTech startup and is now the product owner at luxury watch retailer Watchfinder.