Testing wireframes is an easy way to get feedback extremely early in the design process. This saves both time and effort in the long run, improving the design before it is built and saving potential costly future changes.
A first-click test on a wireframe allows you to easily identify issues with user navigation or experience, allowing you to improve the design based on the feedback given.
In this test, we wanted to learn whether users would be able to easily find the current play queue in a music playing application.
Setting up a wireframe test is easy to do. We simply uploaded an image of the wireframe and then set a task for the participant to carry out by clicking on it.
We wanted to find out whether the play queue would be easy for users to find, so in this example we asked this question:
“Where would you click to find out which song is going to play next (but keep the current song playing)?”
This was followed by the question, “Why did you click there?”, allowing us to gain further qualitative feedback from the participants.
We ran this test with 25 participants.
- Give participants a focused task to complete. Broad questions will yield unsatisfactory responses.
- Where possible, give users a goal to complete (e.g. "find out which song is going to play next") rather than a target to find (e.g. "click on the play queue").
- Don't overload the test; stick to only a single task at a time.
As the heatmap shows, there was a wide variety of clicks dependent on how the user interpreted the question and wireframe.
- You can highlight individual clicks or clusters of clicks to learn more about the time taken to click in that location and to see the reasons given for clicking there.
Only 13 of the 25 participants correctly identified where they should click to find the play queue; a concerning result! Additionally, even those participants who found the correct place to click took a long time to find it.
A few participants thought that the 'Playlists' button would show them the play queue. This is understandable, given that a playlist could be reasonably expected to list the songs that are playing.
Analyzing written answers to "Why did you click there?" for the other locations can give us ideas on how users thought the interface worked.
For instance, participants who clicked in the lower area (highlighted blue) gave the following answers, indicating that they thought they already were looking at the current play queue:
- “I imagine the songs would play from top to bottom.”
- “I don't think there's anywhere I could click to see the next song without interrupting the current song so I would scroll down to see the list.”
- “This is next track, nice design.”
Feedback like this reveals the expectations of users who misunderstood the interface, which can help you to correct confusing areas and elements of the design.
- An unexpected click can teach you something, so make sure you study the feedback from these participants for new insights.
- What counts as a "good" result will vary depending on your expectations. Try to set targets before you test, or benchmark against a previous design.