Making simple, elegant solutions is HARD and often invisible. These are some of the most common things I hear when heading for a bad UX decision.
And before any veteran designers go ripping me a new one, these are rules of thumb intended for a 101 audience. They do not apply in every circumstance. However, you must know the rules to know when to break them, and that requires varsity-level skills.
I’ve seen entire sites built to do something no one wants, and it’s more common than you would believe. How, you may ask, does this happen? You start with a solution and then go find a problem it solves as justification. We get ourselves into this situation because of a lack of research into where peoples’ needs and frustrations lie.
Developing new features is most often at odds with making an interface that’s easy to use. Features have a technical cost, but the UX cost is much higher. Make the happy path supremely happy by rigorously pruning off features from the UI that are wanted by only 2% of users. For features 20% of users will need, it’s ok to make that flow a bit more lengthy. You’re optimizing for the sweet spot of tasks 80% of users will need. I’m sure you have never been guilty of having a pet feature. I’m sure everyone will want to use it. Avoid long fights on where in the 80/20/2 scheme the feature falls by employing a/b metrics and user testing. Otherwise, the loudest or HIPO (highest paid opinion) in the room will likely prevail.
You can’t document your way out of a confusing UI. Remove half the words. Then remove another half. Kinks in the UI can usually be resolved by the next bullet point…
Reuse existing paradigms. People don’t want to read unless required, so use patterns to make reading mostly unnecessary. The user must recognize which mental model is in use or else be able to quickly and correctly learn the model. Breaking a paradigm is serious, varsity-level stuff. Find someone who’s trained if you are convinced you need a novel pattern.
It’s not about opinion. Here’s how you make design decisions. Step 1. Adhere to patterns in your designs. Ahem, we just covered that. Step 2. Test. Users are weirder and more interesting than you can imagine. Step 3. Go back to step 1 and refine with what your learned. Even pros (especially pros) test their designs. You can’t afford not to validate your assumptions. You MUST test with real people to escape your biases. Additionally, when you make a decision independent of data, you have a process that is vulnerable to organizational politics and maneuverings.
If your users want to do something you don’t want, it’s time to closely examine why. Fix the root cause. Chances are this is damn hard or you would’ve already done it. Still, there’s no better solution. Fighting your users is never a winning strategy.
Only put the information where/when the users will need to use it. In a flow, there should be a clear path for the user to take (either a CTA or a clear choice). The most important information on each page should be OBVIOUS. Think of every page a user would likely land on from search as a mini-homepage. Your site should have a purpose, and it should be clear to the user. Users should have enough context to know where they are within the structure of the site and what other related info is available.
Confirm dialogs are of the devil. Prevent errors. Support undo. Again, don’t document that something is dangerous if you can fix the danger. Instead of putting a sign up saying there’s a giant hole in the road, repair the hole or let the driver hit the magic button to fix the muffler that fell off.
Don’t lie to users. Set expectations appropriately. Wizards are usually not the answer. Make the flow smaller. Every field you ask from users reduces conversions. Also related “This thing is taking a long time, can we add a spinner?” No, make it faster.
There comes a time in every designer’s life where they have to learn about the birds and bees. Red is a very wonderful color in the palette. It’s saved for that special person, i.e. error text, critical system warnings. If you must use red because you’re a fire department or Ohio State University, use yellow for errors.
Your site should be organized in the way your users think about it. If your nav mirrors your org chart, you didn’t make the decision with data. I guarantee users don’t think of your product the way you do. To escape your own bias, you’ll need metrics and analytics to understand what the most common tasks your users are trying to solve. Then, card sorts and tree testing can distill that into the correct, mutually-exclusive taxonomy with jargon-free labels.
Did I say jargon-free? To know what your users call things, you have to ask them. Those card sorts sound stupid easy, right? So go do it. Jakob Nielsen has great guidelines for writing for the web. In short, keep it short. Users scan in a F shape, so keep keywords toward the beginning of the line and especially in the headers. This is no place for cutesy language.
Do you really need login or can you do the same thing with a cookie? Delay it until absolutely necessary even if so. Give users a way to gradually engage with your site. They won’t make an account until they understand the value. A registered user is like gold, so treat them as such. Nothing will destroy your engagement of returning users faster than forgetting who they are, so persist user sessions FOREVER. Go assign yourself that bug to make links from your emails automatically log them in.
Steve Krug, Don’t Make Me Think
It’s Complex To Make A Product Simple
Photo credit Some rights reserved by ahp00k