Validating product design ideas with low-fidelity wireframes
“The most striking truth of the curve is that zero users give zero insights. — The Nielson Norman Group
The above statement relates to an article by the Nielson Norman group. Beyond the obvious wisdom to be found in the article, I consider the above statement to be compelling as someone who works in human centred design.
In this article I will champion the benefits of validating product design ideas with low-fidelity wireframes and provide a framework that can be used to implement the practice within your design organisation, if you aren’t doing so already.
Why go ‘low-fi’?
Short of scribbles on napkins or sketches, wireframes often represent the first tangible stage of the UX design process and low-fidelity wireframes in particular are perfect for validating early stage ideas and concepts. They represent a quick and easy way to get feedback on your initial ideas and don’t allow you or your users to get distracted by details afforded by prototypes or ‘design’ work ...
Essentially they allow you to answer two very important questions early on in the design process -
- Does anyone give a shit about this product?
- If they do, is it being designed the right way?
Without either of those questions being answered you are at best designing something that works well that nobody wants to use, and at worst, well let’s not go there.
Process
I generally follow a very simple five step process when validating ideas with wireframes. This allows me to move quickly, building out a rough product structure and experience with wireframes, get them tested with real users and then refine them based on feedback.
1. Create
Wireframes
You can create wireframes in all major design software, but for low fidelity wireframes in particular i’d recommend Balsamiq.
Their drag and drop library of low fidelity components makes it quick and easy to build layouts for testing and refinement.
The rough visual aesthetic of the components helps to keep things informal too, and ensures you and the people you are sharing them with focus on the bigger picture, rather than design details.
Obviously the level of detail you want to go to at this stage is entirely up to you but it’s worth noting that the key things you should be focusing on at this stage are -
- Mapping user flows and journeys
- Navigation
- Page structure and layouts
- Content information and hierarchy
Prototype
To go one step further than simply presenting flat wireframes, i’ll often use a simple prototyping tool such as InVision to link up screens and create a clickable experience for the user.
Rather than just presenting them, it allows people to actually click through as if they were using the real product which often prompts a different thought process and set of reactions from the user.
It sometimes take a bit of time to create a clickable prototype, but I find it’s totally worth it and also allows users to engage better when you get them to perform tasks and provide feedback.
2. Test
Define your users
When trying to validate and test your wireframes it’s important to consider who’s testing them and providing feedback.
While input from clients and stakeholders is certainly useful from a strategic standpoint, the people providing feedback on your product should ideally be the people using it and if that’s not possible, then a sample of people from the same demographic.
The number of users you test with should also be considered. A common assumption is that a larger testing group will yield a greater number of insights (more people=more insight), which isn’t necessarily true.
The Nielsen Norman group recommend testing with no more than five users at any one time and as a general rule of thumb - multiple tests with a small number of users (<5) are generally considered a more effective use of budget and resources than just one or two tests with many users.
The difference between zero and even a little bit of data is astounding.
Test structure
When validating and testing your ideas it’s important to have a structure in place to inform and guide your users when giving feedback. This ensures everyone’s time is used effectively and the quality of your insight is maximised. When validating ideas i’ll often use the following structure -
- Get users to perform specific tasks
- Ask users for their feedback and opinions
- Ask users specific questions I want to know answers to
You will also need to communicate how and when users should do this. if you are doing testing in-person, then it will simply be a matter of guiding users through the tasks, questions etc in the workshop.
If testing is being done online, then I recommend you write clear and specific instructions and share these with each user in the testing group.
Note - InVision let’s users leave comments directly on your prototype which is very handy, I recommend you make full use of this feature. I also recommend using Google Surveys to ask questions from users and record their answers.
Get users to perform specific tasks
Getting users to complete tasks is a great way to validate your thinking with regards to user journeys. Of course it’s not possible to replicate detailed functionality in your wireframes but if a user finds it easy to navigate through screens and find the intended key information at this early stage, then you know you are at least on the right track.
Tasks that users will be able to complete are obviously platform specific, but here are some examples of the format tasks may follow -
- Asking a user to navigate to a page and perform a specific action
- Asking a user to navigate to a page and find a specific piece of content
- Asking a user to create X (where ‘X’ could be a blog post, item, document, video etc)
Ask for user feedback and opinions
While asking only for general feedback from users is not a good approach to user testing, opening up the floor for people’s thoughts and opinions can prove useful.
It’s worth bearing in mind that as with anything in life, people’s thoughts and opinions are often just that, so it’s your job to analyse the kind of feedback people give you and understand if it’s useful or not in the context of the project. More on that later.
Invariably you will have users whose attitudes vary from the extremely positive to the extremely negative, and everything in between.
Users may also have pre-conceived notions and attitudes toward the product that might not have anything to do with your work at this point, and again it’s your job to understand that and facilitate discussion and feedback in a healthy, progressive way regardless.
Situations may arise where people are effectively shitting on your work for lack of a better phrase, and that’s fine. I often like to remember a favourite quote of mine when this happens
“Success is a poor teacher” — Robert Kiyosaki
Ask questions you want to know the answer to
Generally, if you ask vague and subjective questions, you will receive vague and subjective responses which are never useful. The kinds of questions you ask should be succinct and be posed to provide clear answers and feedback on your work.
Avoid vague questions like -
- What do you think to the wireframes?
- Do you like the wireframes?
Instead focus on questions that will reveal insightful answers -
- Was it easy to find common task functionality?
- Was their any content or information that wasn’t clear?
3. Analyse
Recording data
After you’ve conducted your first user testing session, take some time to sit down and pour over the feedback you’ve received. If you did the testing in person you’ll likely have all your feedback written and recorded in a central place.
If it was done online then you will likely have a collection of comments on your prototype and answers on your Google Survey.
Organising and understanding
Now the fun starts! I find using a Google Sheet works perfectly to record user information and feedback, allowing you to group and organise information under appropriate headings and cross reference relationships easily.
Task and feedback analysis
Using our spreadsheet we can organise our feedback by functional heading, so we can give what the user has said some context.
Once we’ve organised our feedback by functional heading, then we can start to assign comments to categories, so we understand the nature of the comment and how to deal with it. A useful way to categorise comments is as follows -
- Comment about UX/UI
- Feature request
- Complaint
Comment about UX/UI
This is normally something a user will have feedback on in regard to their experience using the wireframes or trying to complete a task. This might include comments such as -
- It was difficult to find the right button
- I liked how easy it was to find X piece of content
Feature request
This tends to be when a user goes off the beaten path and describes a feature they’d like to see added to the product. These comments might look like this -
- It would be really cool if you could do X
- If when we click the button, it would be useful if X could happen
Complaint
This is normally when someone takes issue with what’s been designed. Complaint is perhaps a bit of a negative term, but for the purposes of the spreadsheet it’s easy to understand. These comments might look like this -
- I really didn’t like the way X happened
- I don’t understand why you’ve done X this way
On the spreadsheet, record what category each piece of feedback falls under by adding a ‘Y’ to the relevant cell to let you know a piece of feedback falls within that heading on the spreadsheet.
Question analysis
Often you will have multiple questions and their corresponding answers, so it makes sense to organise these on a separate sheet to our other feedback.
Record each question and it’s relevant answer by user (a separate row for each user) and then add a column at the end of each row called ‘Action steps’ or something similar. After you’ve analysed each question and it’s answer you can then decide if and how you will act upon that information, if at all.
4. Iterate
Now we’ve recorded all of our feedback and taken the time to analyse it, it’s time to start making decisions. Generally, we have three options when acting on our feedback -
Ignore
Sometimes a user’s comment doesn’t make sense or seem logical to consider. Perhaps someone wildly missed the mark with their comment or perhaps they were just being off key. You generally can’t action compliments either, so if someone says something like ‘Great work! Keep it up’, although it makes you feel good, there’s also generally not much you can do about it.
Discuss
Sometimes it’s not obvious what the piece of feedback means or how best to action it, in which case it will need discussion with either the user and/or the project stakeholders. It’s best to shortlist everything for discussion and then discuss in one go in a simple meeting or call to clarify.
Action
If it’s very obvious or you are confident what needs to be done, then this type of feedback can be considered actionable straight away.
5. Repeat
Depending on the type of project or product, resources and budget, this entire process can be repeated several times to really refine and finesse areas of a user experience using just low-fidelity wireframes.
Most likely you will reach a point after 2–3 rounds of iteration and refinement where it is natural to move beyond low-fidelity wireframes and into prototyping and design where you can begin solving a myriad of other interaction and design challenges in much the same way!
Continue the conversation..
If you’ve got thoughts on my process, would like to contribute your own ideas or would like further help with validating your design ideas, then leave me a comment below or shoot me an email! 🙌🏻
