Don’t subvert user expectations.
The first thing everyone says after they try to use this pen: “well, that’s dumb.”
My wife attended a conference and came home with the world’s dumbest pen. Earnest promotional material by a well-meaning organization, the pen was given to attendees as one more piece of conference swag. The pen is dumb because when you click the top button to extrude the pen point and begin writing, the pen only lights up green. You can’t write with it until you fiddle around, eventually learning to twist the bottom of the pen. The clicker is functionally useless — just a green light for no reason. Perhaps out of sheer self-punishment, I leave it in the pen drawer, and in moments of needing to jot something down, I reach for it, click the button… and get only a green light.
Expectation is a key component of user interactions
The pen is dumb because your expectation of its functionality doesn’t match its actual functionality. Clicking it, you expect it to do one thing (extrude the pen tip) and it does another (lights up green).
Software user interactions follow the same rules. User expectations shouldn’t be subverted. Users should always know what’s going to happen when they click, tap, or swipe in your application.
The phenomenon of “knowing what’s going to happen” is set up through two main principles:
“Conventions are your friends” writes Steve Krug in the seminal book on web user interaction, Don’t Make Me Think, but “designers are often reluctant to take advantage of them.”
There is no faster way to get the user to learn how to use your application than to use a convention they already understand. Designers must put their pride aside and use what works when they have the opportunity to do so.
Quick, what’s clickable on this page?
And how do you know?
Hyperlinks are typically underlined within paragraph text. Unless you’ve never been online, you understand that convention. You believe that the icons on this page are clickable. Maybe you double check by hovering a mouse over them to see if the hand changes to a pointer. Speaking of icons, what does the little heart icon at the bottom of this page mean? What about the “speech bubble?” Or the “bookmark?” What do you expect them to do when you click them? If you have some understanding of them and can infer what they do, it’s by convention.
Probably the most understood icon in web development is the search icon. If you have search in your application and you use anything other than a “magnifying glass” icon to represent it, you should probably be fired, no hard feelings.
At CHSI Technologies we have a new rule, “you can only use an icon if a user can infer what it means in the application; else use explicit, concise text.”
So in our 2017 redesign we got rid of standalone icons like these…
…and replaced them with either explicit, concise text or icons paired with text. One of the icons above represents “Prospect,” good luck trying to figure out which one. You’ll never find an icon that says “Prospect” to your users — it’s just not an established convention — so you should probably replace it with the explicit text, “Prospect.”
You can use an abstruse icon if you also pair it with explanatory text. For example, I’ll never be able to come up with an icon that means “Underwriting” to users. But that doesn’t mean I can’t have icons for hard to understand terms or concepts; I can use icons, I just have to help them out with some text.
There are 2 takeaways from this thinking:
- You actually shouldn’t be using standalone icons that much because there just aren’t that many understood standalone icon conventions.
- If you’re going to pair harder-to understand icons with text, you could even skip the icon for a more concise text or button design. With this thinking, icons become a design choice more than a usability choice.
For example, I chose not to use a “plus sign” icon, and instead opted for “Add new” buttons in this redesign of a company listing in our CRM application:
In user tests, users didn’t understand clicking a plus sign would bring up a modal to “add a new thing” — some thought it would expand the list, some thought it would add an entirely new company. They didn’t know what to expect! I had to add text to the plus sign; and at that point the icon was redundant, so I eliminated it entirely and opted for simple and clear “Add new” buttons instead.
For a fun read on how even rockstar companies like Google screw up understandability see: Material Design and the Mystery Meat Navigation Problem.
As a UX Architect, my job may need me to break conventions in the right place for the right reasons.
Looking at the page from our CRM above, I break two established web conventions in favor of usability specific to our application.
- Hyperlinks are not underlined, rather they are bolded and colored.
- Input fields are not bordered, rather they are flat rectangular boxes one shade of gray darker than their background.
I chose to remove the underlines from hyperlinks because our application displays so many links on any given page. In early prototypes, there were underlines on everything and it made the text less readable. So in the spirit of usability, I had to break that convention and replace it.
If you’re not going to use an existing Web convention, you need to be sure that what you’re replacing it with either (a) is so clear and self-explanatory that there’s no learning curve — so it’s as good as a convention, or (b) adds so much value that it’s worth a small learning curve. — Steve Krug
I chose to remove the borders around input fields for a similar reason; early prototypes looked like clunky boxes everywhere and hampered readability. I went with a flat, more open design because of our application’s need for lots of input fields.
But in order to replace these conventions and have users understand it, we have to maintain consistency in the application. All hyperlinks and input fields are styled this way, to help users know what is interactive on the page.
When we establish a replacement convention, users trust us to maintain that convention throughout the application. That way, when a user comes to a new page or modal they haven’t seen before, they know what is a hyperlink and what is a field input. Consistent use of a style allows users’ expectations to be met when working in our application.
Your goal should be for each page to be self-evident, so that just by looking at it, the average user will know what it is and how to use it. — Steve Krug
Don’t be dumb
The pen is dumb because I expect it to do something and it does something else. Don’t let your application be dumb. Use understandability and consistency to meet your users’ expectations.
PS — The pen may be dumb, but it’s got a challenger for World’s Dumbest: