views:

679

answers:

17

I'm not a usability specialist, and I really don't care to be one.

I just want a small set of rules of thumb that I can follow while coding my User Interfaces so that my product has decent usability.

At first I thought that this question would be easy to answer "Use your common sense", but if it's so common among us developers we wouldn't, as a group, have a reputation for our horrible interfaces.

Any Suggestions?

+11  A: 

Read Don't Make Me Think by Steve Krug. It is a great starting point, and an easy short read.

EDIT: This is mainly for web usability though, but it would still be a good read even if you are doing rich clients.

Mike Stone
Thank you. Read.
Allain Lalonde
+5  A: 
  • Don't make things work in a different way than your users are expecting (i.e. breaking the "back" button when using Ajax in web forms
  • Follow the K.I.S.S principal

Really, any rules someone posts will be a variation on the theme: Don't Make Your Users Think

"Don't Make Me Think" has already been posted, see also Design of Everyday Things and Designing with Web Standards which are also great for light usability reading.

Rob Allen
+4  A: 

The single most important piece of advice I'd give someone is to work on the UI first. Pen and paper and all. That way, you won't subconsciously couple buttons to functions, input fields to variables, etc.

The best UI might be a pain to code, and if your backend code is mostly written, it will sabotage your thinking.

Other than that, I'd point to Apple's Human Interface Guidelines. Of course, if your platform is not OSX, take the OSX sections with a lot of salt. What works in OSX might not work on Windows. You should embrace your platform's idioms.

OSX stuff aside, that document has some pretty good starting points on the fundamentals.

Jordi Bunster
+20  A: 
Marcio Aguiar
This doesn't actually answer the question.
Allain Lalonde
Yeah, I'm sorry. But you can get some lessons from it: try to make it simple - or as others say, make it Zen. Like Steve Krug said in his book: Don't make me think!
Marcio Aguiar
Now I feel guilty that it's on the top. haha :)
Marcio Aguiar
I think it's a pretty good answer. Make it as simple and intuitive as you possibly can, particularly for parts of the interface that users will interact with dozens of times per day. Save the scary forms for the administrators and the "once in a blue moon" functions.
CMPalmer
Actually, this answers the question very well. The point of the pictures is to say "Look at Apple and Google, who have very successfull products. Now look at the simplicity of their user interfaces and compare that with your own business application." Just because it's a line of business application doesn't mean it should have a simple, clean, easy-to-use interface. No, this answer doesn't give a set of rules to follow, other than "keep it simple", but it is still a good answer.
Scott Dorman
+2  A: 

I've posted related questions:

aku
+4  A: 

Avoid modes. It's frustrating to a user when input works sometimes but not others, or does different things at different times.

Patrick McElhaney
+1  A: 

Think about the users that will use your app. Why are they using it and in which context?

  • Will the majority be pro users that know the domain in which the application is used and use the app a lot? Then don't be afraid of adding a lot of data to the screens as long as it arranged logically for users (normally that is not in alphabetical order :-). Think trade screens for stock borkers or airplane cockpits.
  • Are users occassional users? Keep it simple. Avoid context switches (keep all/as much as possible of necessary data for a task on the screen at each time). Don't break expectations of how gui widgets normally work. Design for failures.
  • Anything in between? Allow users to grow in the UI. Track usage so you can later determine where users seem to spend the most time so you can improve the most used areas of your app.
  • Test your app on friends and colleagues (the corridor test) to see if they are able to use it efficiently.

That's a start.

Mingus Rude
+7  A: 

Just two things, really:

  1. "A user interface is well-designed when the program behaves exactly how the user thought it would" - quoted from Joel Spolsky's User Interface Design For Programmers
  2. Put your designs in front of a user. A real end-user is best, but for lightweight, rapid feedback, you can't beat hallway usability testing i.e. grab a co-worker.

If you remember Joel's advice and make sure you get feedback on whatever you do and act on it i.e. iterate, you'll not go too far wrong. And I would echo the recommendation for Steve Krug's Don't Make Me Think - it's probably the best work-related book I've read, bar none, and is just as applicable to desktop software as websites.

Hope this helps.

Mal Ross
+4  A: 

Here are some simple rules:

  • less clicks is better
  • frequently used features should be easier to find
  • features for "advanced" users can be harder to find than the ones above

Think about the number of mouse/keyboard clicks it takes a user to get to something.

PS - please don't tell the Office 2008 people about this, poor little guys would cry themselves to sleep tonight! :)

brooks hollar
+1  A: 

I suggest to read these blog posts from the Enso creators.

Of course they repeat guides/ideas/advices from books such as
The Design of Everyday Things and About Face, but nevertheless, the posts contain quite a few insights and (IMO) they are a good read.

Nick D
A: 

What information does your user need, put that on the screen and nothing else. If you cannot define what the user needs - get another user.

Nicholas Jordan
A: 

Remember that your application will be one of many the user will have to deal with. Don't do things just to be different or kewl. Don't come up with unusual graphics, behaviors, terminology, or interactions. Use the standard OS controls, conventions, utilities, and behaviors.

Let your app interoperate with other apps; allow cutting and pasting of data, save your data in formats other apps can read, and allow importing data from other apps instead of using your UI.

If you are making a desktop app, do not try to take over the user's computer. Leave the user's Documents folder, task bar, and application preferences alone. Don't change anything already installed on the computer. Allow scripted or command-line interactions.

If you're making a web app, do not try to take over the browser. Do not try to subvert the standard menu bars, history, layout, or fonts. Allow the user to change the page using Javascript.

Dour High Arch
A: 

(1) Common actions should require as little effort as possible and should be obvious; on the other hand, actions that are rarely needed can be require a lot of steps and can be hidden behind menus and dialogs. To be able to do so, you should always describe what the user will want to do with the application by listing use cases.

(2) A UI should be selfdocumenting. The manual should be integrated in the application's dialogs and menu's, as users don't read separate manuals. For example, the keyboard shortcut should be shown in the menu item representing the action it is associated with.

Dimitri C.
A: 

Provide keyboard shortcuts for power users (even if it is as simple as "hit enter to search")

Don't put too much on screen at once.

If you pop up a messagebox, your users generally won't ever read it.

Jamie
A: 
  • simple is better than complex
  • complex is better than complicated (eliminate 'nested ifs')
  • intuitive (good elements needs no explanation)
  • follow the convention (e.g. underlined means link, red means error, tab goes to next field etc.)
  • use semantics to apply the logic (Header reads first, paragraphs next)

  • whitespace is important

takeshin
A: 

In addition to the other recommendations here, I'd recommend Designing Interfaces by Jenifer Tidwell as a good way of becoming familiar with UI conventions.
Also, The inmates are running the asylum By Alan Cooper is excellent for providing an insight into how to approach interaction design.

Matt Lacey
A: 

A good follow on to Don't Make Me Think is Robert Hoekman's Designing the Obvious. It's more focused on web applications, as opposed to web sites like in Krug's.

roryf