If you want users to successful, it helps to know how users actually read your UI text (spoilers: they don’t), and how more text can ruin everything.
A real-life example of well-meaning UI text making things worse
Years ago, I joined a large desktop application project as the lead designer, taking over for another vendor.
One of my first tasks was to observe usability testing on the existing UI design. A realistic prototype of the desktop application had already been developed for that purpose.
One page of the application was a menu screen for navigating to discrete sections of the application. The menu consisted of 6 items. Each item was a large clickable icon button, with a button title and description text to the right of it.
The menu screen exhibited a surprising problem in user testing.
Usability Testing the Menu Screen
During user testing sessions, one of the tasks given to users was to update their data by downloading the latest data records from their device.
Usability results from the menu screen with regard to the download task included:
- Several users clicked on the title label first, and then when that didn’t work, they clicked on the square icon button to the left of it
- Several users clicked the 6th button (“User’s Manual”, lower right) to begin their download task, instead of clicking the 1st button (“Download”, upper left)
The first problem was not surprising. The second issue was very surprising. In each of the cases, the users in question navigated to the User’s Manual section, were disappointed with what they found, backed out the main menu again, and then picked the Download button.
Why did they go to User’s Manual section first? Was it to try to read help documentation about their task?
No. The users who clicked on the User’s Manual button did not do so with the intention of reading about how to download data. They thought they were navigating to the place where they could begin their task.
So why would any users make that mistake?
Well, part of it has to do with how users actually read UI text.
The way users “read” your user interface
Despite our earnest wishes, users don’t actually pore over your user interface and read all the UI text before carefully deciding what to do next.
No, users don’t really read your UI, they scan it.
Users have a goal. It might be paying a bill, or finding the answer to a question, or getting to content they want to actually read (maybe). Regardless, all the UI text they encounter along the way is just a means to an end. The user is scanning the landscape for words and elements that are applicable to their goal. And, if further navigation appears to be required, they are probably jumping at the first thing they notice that seems promising.
Once you know how users read your UI, you can focus on making your app or website more scannable. This includes hierarchical design, concise text, headings and subheadings that stand out appropriately, and emphasizing things that are important to your users.
Back to the problem with that menu screen
Okay, so users “scan”. But how the heck does that explain why users would click on User’s Manual instead of Download for a download task?
Scanning is part of it. Users’ knowledge and unintended consequences are also part of it.
Aside from the button labels being neither clickable nor part of the button, the problem we observed with the menu screen was the “helpful” description text below each button title.
Some users were clicking the User’s Manual button instead of the Download button because of that descriptive text, combined with some knowledge of what the task would entail.
Many users already had a good idea that downloading data from their device would require connecting their device to the PC via cable.
And some of those users, when scanning the UI text, saw the “connecting devices” bit, and—perhaps while thinking, “that’s what I need to do next!”—clicked the associated button.
Note what these users (likely) did not do.
These users did not circle back to the top to see if any other buttons were a better candidate for their download task. These users did not even look up a half inch and chew on the fact that this was the “User’s Manual” button, and therefore probably not what they want. A user’s attention can be extremely narrow.
The description for the User’s Manual button could have been written any number of ways. The unintended consequence of how it happened to be written caused a surprise usability issue.
But rewriting the description text would not have been the right solution to the issue.
A problem of superfluous UI text
The description text, while well-meaning, caused more problems than it solved.
When it comes to scanning, the description text made scanning harder for users.
- More text to scan through
- The additional description text either took more time for users to scan or was actively ignored
- More text competing to define the meaning of a UI item
The description text was also a bad idea for these additional reasons:
- It was mostly unnecessary – most of these buttons had no need for examples.
- It feigns importance – the descriptions’ mere existence made them seem worthy of attention—more meaningful than the button labels, even—but they were not.
- It diluted the meaning and importance of the button labels, which were pretty effective on their own.
- It was misleading to users – once you start listing the contents of a section, if you can’t list everything (and you probably can’t) then users might think that a lack of mention means it’s not in there.
Lesson: Optimize your icon-and-label pairings, and keep labels meaningful but concise. That should almost always be enough. Avoid the temptation to add text to help “explain” things. Or, at the very least, test with minimal text first, and then see if you need to add anything to address actual usability issues.
The menu page that worked better
An iteration on the UI design proved to eliminate the Download / User’s Manual problem, due to simply removing the description text and making the button labels stand on their own.
This would not be the final design for the menu screen, but making this quick change to the prototype between rounds of user testing showed that the problem was indeed understood (well enough) and effectively corrected.
Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.
BetaTesting Blog 