Created
March 31, 2014 22:25
-
-
Save cube-drone/9903789 to your computer and use it in GitHub Desktop.
5 Usability Tips
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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