Skip to content

Instantly share code, notes, and snippets.

@cube-drone
Created March 31, 2014 22:25
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save cube-drone/9903789 to your computer and use it in GitHub Desktop.
Save cube-drone/9903789 to your computer and use it in GitHub Desktop.
5 Usability Tips
5 Usability Tips for App Designers
----------------------------------
Hey, everyone. I'm a guest speaker, and I'm here to share some very simple
usability guidelines with you for application development.
Make clickable links obviously clickable.
Or touchable if you're designing for a phone or a tablet or something.
Modern app development style is becoming very flat and minimalistic -
which, I'm not going to lie, I like a lot -
but one of the reasons that buttons with that pop-out gradient effect
were so popular was because it was always REALLY EASY to tell that
"hey, you can CLICK this thing".
When you're designing for mobile devices? Avoid links in favour of buttons.
And pay attention to how big those buttons are!
Touch screens do not have the pixel-level accuracy that mice do -
your buttons should be at the very minimum the size of a chubby finger.
If you have a web-style link, it's important that the link stands out.
The colour of your links should be different than the colour of your text.
If possible - blue.
That really ugly blue colour that just screams "this is a
clickable link, you should click this thing."
That brings me to my second point. The reason that blue links are easier
to use than red links or green links is because we expect that links are
blue. It's a convention.
Be conventional.
I know that, when you design things, there's a really strong desire to
be unique, to be clever.
It's hard to say 'don't be unique and clever' with a straight face -
but I can at least say 'don't be too unique if you don't have to'.
There's a wonderful design library out there, composed of every
website and application that your users use every day.
When things look and act familiar, your users
can become conversant with your software much more quickly.
When you're using a mobile application and you pull the content down
to refresh? That's a convention.
Give Bing a try. I'm not a Microsoft shill, I don't want you to use
Bing or anything. But look at how closely they modeled their
search interface on Google's. Now try a Yahoo search. Yep, it looks
just like a Google search. Google has clearly hit on a really effective
user interface for searching, and this convention is spreading.
There are other conventions that users find really useful.
Like the back button.
Don't break the back button.
This is a wide generalization, but so be it: most users don't read everything
on a page before they decide on what to click. Users who are looking for
something quickly scan the page and click the first thing that looks even
vaguely like what they want.
Part of the reason that this sort of behavior works for users is that the
cost of visiting the wrong page is so low - the 'back' button supports
a quick exit from anywhere you might visit.
And the 'back' button isn't unique to the browser. It's reached the point
where this ubiquitous button is appearing again and again in iOS applications.
Most Android devices have a 'back' button built right in.
And yet with all of this support for the 'Back' button, some tools break
this functionality.
Lots of banking applications and older Java applications
have serious trouble handling the back button.
Single-page javascript applications have to be extra careful about this -
a user could intend to leave a window that you've taken them to, only to
leave your application entirely.
Modern frameworks have implemented back-button support -
look for a 'router' class - but this sort of stuff only really works
if you're designing for it for the get-go.
Designing it _from_ the get-go.
Designing with it in mind from the beginning?
Oh, that reminds me of my next point:
Proofread & edit.
You wouldn't think of this as a usability tip, but it absolutely is.
If your application has text in it - and most applications do - go over
that text with a fine-toothed comb. Make sure it's clear, and make sure
it's concise.
# commented out
#Keep your marketing, sales, and legal teams well away from any copy that
#ends up in your software - you want simplicity and readability, not reams
#of self-congratulatory SEO horseshit.
It's as simple as going through your wording line-by-line and, for each
line, asking yourself: is this necessary? Could I make this clearer?
If you're just a soul whose intentions are good, you have to read your text
and ask: how could this be misunderstood?
Why does this button read 'submit'?
Which takes me to my last point:
Sometimes you should discard conventions that don't work.
For some reason, one of the most common bits of text you'll find on a button,
is the word 'submit'.
'Submit' as in 'submit this to the server', not like
'SUBMIT TO MY WILL, FOOLISH MORTALS'.
It's almost always a valid thing to put on a button -
'send this to the server' is often what you're doing, but it's just so
general.
The thing is, though, a lot of times 'send this to the server' is just a
step in the process. Stop for a second to think of the end result of
clicking on the 'submit' button. Will this create a user? Then the text
on the button should read 'create user' or 'create'.
Will this send an email?
Then the text on the button should read 'send email' or 'send.'
Okay, that's a wrap. Remember to like and subscribe, and thanks for watching!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment