Making simple, elegant solutions is HARD and often invisible. These are some of the most common things I hear come out of people’s mouths when heading for a bad UX decision.

1. 13 Signs
Your UX Needs an Exorcism
Crystal Beasley . @skinny

2. This is a one-oh-one.
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.

3. things people say
Making simple, elegant solutions is HARD and often invisible. These are some of the most
common things I hear come out of people’s mouths when heading for a bad UX decision.

4. 1
“ I've got this really great idea
for a site.”
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 insight into where peoples' needs and frustrations lie.

5. 2
“I've got this really great idea
for a feature.”
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, you should still maybe build them but 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.

6. UI complexity
feature set
Each feature you build adds UI complexity. There are successful sites all along the orange
line. The degree to which you can add features without adding UI complexity, rising above
the orange line, is the degree to which your site feels like magic.

7. Low # of features, low UI complexity. http://whatthefuckshouldimakefordinner.com barely
has buttons. There’s only one page. There are no user accounts. You can use it by just
refreshing the page. Yet, people love it. It was so successful it spawned its own book!

8. High # of features, high UI complexity. NYTimes employs the best in the business to tweak
every dial of this UI. The algorithms that determine where articles are placed have to be nuts.
Be aware that every step feature you add means exponentially more UI complexity. It can
certainly be done, but know what you’re committing to.

9. 3
“Let's put a sentence under
the button to explain.”
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...

10. 4
“ What we're doing here is
so novel.”
Reuse existing UI 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.

11. Yahoo’s design pattern library is a great place to get the common UI building blocks. Even if
you are making something from outer space, you’ll still need to make use of most of these.

12. 5
“ I think the button should be
on the right.”
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.

13. 6
“ I don't want the user to do
the thing they want to do.”
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.

14. What do you think the most clicked element on this page is?

15. Trick question, because it’s not even above the fold. The tiny light grey link down in the
footer “contacting us” received thousands of clicks and generated hundreds of email every
day.

16. To their credit, they’re moving sites over to a contact us box in the right sidebar.

17. 7
“ Maybe we need a FAQ.”
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.

18. FAQs are an admission of defeat.

19. 8
“ Can't we just pop up a
confirm dialog?”
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.

20. What kills me is that they know the correct answer. It says so right in the dialog. “Deleting a
survey task cannot be UNDONE.” Again, supporting undo would be the correct choice here.

21. 9
“Let's split this up into
different steps so it
seems smaller.”
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.

23. This new version puts the content right up front, allowing the users to immediately
understand the purpose of the site, grab what they want and go.

24. 10
“ Make it red so it will really
stand out.”
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.

25. Chrome’s visual design is pretty and I suspect it hits the target customer’s aesthetic, but the
UX is poor. They’re using red for everything because it’s the brand color. If you MUST do so,
reserve yellow for errors.

26. How many errors are there on this page?

27. How many errors did
you see?

28. Double highlighting will call attention to the error fields so users can quickly complete their
task.

29. You’re not saying nearly
enough about this stuff.

30. 11 navigation
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.

31. 12
copy

32. Add-ons, extensions, plugins... Who can tell the difference? I’m sure there’s an
implementation level reason for these names, but users can’t be expected to parse that. To
know what your users call things, you have to ask them. Those card sorts sound stupid easy,
right? So go do it.

33. from Jakob Nielsen
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.

34. 13
login

35. Give users a way to gradually engage with your site. Do you really need login or can you do
the same thing with a cookie? Delay it until absolutely necessary even if so. They won't make
an account until they understand the value.

36. 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.

37. That’s it!
@skinny

38. Resources
Steve Krug Don’t Make Me Think
Lou Rosenfeld Information Architecture for the WWW
Luke Wroblewski Web Form Design
Jakob Nielsen useit.com
these slides and more at skinnywhitegirl.com