tags:

views:

1286

answers:

19

What are some key UI design tips that every developer should know?

While there are a number of UI resources for developers (for example, Joel Spolsky's User Interface Design for Programmers), I'm interested in more of a bullet list that can be communicated in 1 to 2 pages.

I'm interested in more tactical, day-to-day UI tips, as opposed to overarching UI design goals that would be covered in a UI design meeting (presumably attended by at least one person with a good UI sense). A collection of these tips might cover about 80% of the cases that an everyday programmer would come across.

+3  A: 
  1. ask the user, don't just make things up
  2. simplify - remove a step, eliminate clicks, etc.
  3. get familiar with the principles of usability
Steven A. Lowe
+9  A: 

When you are about to perform an action that will change or delete information, don't ask 'are you sure' - users will learn to click the button as part of the action. Try to allow for an 'Undo' in the system design.

Alister Bulman
LOL - "are you sure you want to format the hard drive?" vs "undo format hard drive"
Steven A. Lowe
But wouldn't the app be better if one truly could "undo format hard drive"? Doing and then being able to undo is almost always preferable to pop-ups. Obviously, for irrecoverable actions the dialog is necessary. The trick is to not build in irrecoverable actions in the first place.
Bryan Oakley
+22  A: 
  • use a standard menubar (amateur GUI designers seem to like to chart their own course here for some reason). Make sure the first items are File, Edit and View, and the last one is Help
  • don't worry about color themes or skins; stick to a standard look that is consistent with your platform
  • use the default system font
  • use menu accelerators that are consistent with your platform
  • stick to the tried and true layout with a menubar on top, a status bar on the bottom, and if required, a navigation pane on the left
  • never do a system-wide grab
  • If you have a choice, make all windows resizable.
  • use groups of radiobuttons for "choose exactly one"
  • use groups of checkbuttons for "choose zero or more"
  • constrain input if necessary (ie: simple ignore non-digits in a numeric input field) rather than waiting for a user to enter data, submit, then throw up a dialog saying "hey, letters aren't allowed!". If they aren't allowed, don't accept them in the first place.
  • be liberal in what you accept as input. For goodness sake, don't throw a fit for a SSN field if they leave out the hyphens, or put then in when you don't want them. The computer is smart, let it figure out that xxxxxxxxx and xxx xx xxxx and xxx-xx-xxxx are all valid.
  • always allow spaces in long fields such as serial numbers and whatnot. Data quality goes way up if a user is allowed to group numbers in sets of three or four. If your data model can't handle the spaces you can always remove them before saving the data.
  • Avoid pop-up dialogs like the plague. Never display one unless you absolutely must. If you decide you must, stop and rethink your design before continuing. There are times when they are necessary, but those times are considerably less frequent than you might imagine.
  • pay attention to keyboard traversal. Most toolkits make an attempt to get it right, but always double-check.

All of these rules can, of course, be broken. But only break it if you are breaking it for a justifiable reason.

Remember, the software is there to aid the user, it should be doing what they want, rather than making them do what it wants.

Bryan Oakley
I'd add that paying attention to how to use the keyboard with the GUI is usually the mark of whether the software feels amateurish or professional. With a good interface, the user can navigate it entirely in whatever way they want. This often also means thinking carefully about the underlying data model of course…
Donal Fellows
+5  A: 

Always give your user a "way out" from wherever they are that does not require the use of the back button.

The best example:

If an error occurs, give them a link back to where they were (or at least to where they can start over).

Jeffaxe
Yes, but also make it so if they use the back button it doesn't die, because the 'back' button is an approved part of the UI that people *do* tend to use.
Kent Fredric
+1, especially considering JSF has a tendency to just mangle the functionality of the "back" button...
KG
+4  A: 

I think that this link would be a good starting point, from Microsoft's "Windows Vista User Experience Guidelines:
http://msdn.microsoft.com/en-us/library/aa511328.aspx

And this might be very close to the two page bullet point list you are looking for: "Top Violations":
http://msdn.microsoft.com/en-us/library/aa511331.aspx

Very down to earth tips like: "Set a minimum window size if there is a size below which the content is no longer usable."

Corey Trager
+4  A: 

Make the default choice the one most users would be happy with.

Paul Marshall
+4  A: 

Correct tab-stops are a must.

utku_karatas
I don't understand what this means? The vast majority of the apps I use don't have the notion of "tab stops". I think for this to be a valuable answer it needs more detail.
Bryan Oakley
I know this is ancient, but "Tab Stops" are the places that focus will switch to in an application upon pressing Tab. For example, while typing a comment, the next Tab Stop is the "Add Comment" button. Applications that do not take into account Tab Stop order can end up with completely random switching of focus, so that use of the mouse to switch focus is mandatory.
Chris
This is "tab order" or "field order" as far as I know. Tab stops are something a typewriter or possibly word processor has.
calmh
+2  A: 

Do not increase "discoverability" at the cost of basic clarity and usability.

Larsenal
Can you describe what you mean by "discoverability"?
David
discoverability: "The ability of any feature to be found in the context in which it's needed."So in this context, am suggesting you don't go overboard assuming people won't be able to find a feature. Instead, use common conventions so that a user's first (or second) guess will be right.
Larsenal
+5  A: 

Use tool tips as much as possible. It is amazing how these little guys can add a large amount of help to the end user and they are unobtrusive to the application itself.

Dillie-O
But don't create an app with thousands of arbitrary icons that are similar and require tooltips to know what they do ;)
Kent Fredric
+2  A: 

When designing a UI make it as simple as possible, but no simpler.

BoltBait
That's a very nice summary.
fluffels
A: 

If you do use a popup from an editor, make sure to return your insertion point or state to whatever it was before the popup. Too many programs just leave you "hanging" and having to find your way back.

Uri
+1  A: 

Find the thing the user will do the most often, and then make that the easiest thing to do.

For example: I have a long running personal gripe with microwave design.

Many require you to set a clock you never use for anything prior to using the microwave, and it forgets everytime it loses power AND requires 10 key-presses on those hard-to-use button pads to do so.

A simple usability test would realize the most common cook time used on microwaves is the standard 'minute' and multiples thereof. An Ideal microwave should thus be able to cook an product for 1 minute on high power in 3 or less actions.

For times outside a minute, but within 5 minutes of the golden "1" minute, there should be slightly more steps, but not significantly so, and only significant numbers of actions required for cook times > 5 minutes. ( which are rather rare )


2 examples of great microwave design

1. 4 parts. Door, temperature dial, time dial, time-lighting sequence

Temperature dial is analogue and persists from previous setting, with a varying sliding range.

Time dial is digital, but simulated analogue, turning dial clockwise increases clock time( shown by a lighting sequence under the dial). Turning dial counter clockwise decreases clock time. Cooking decreases clock time.

Door being closed and time being on clock starts cooking. Door opening pauses cooking.

standard operation: open door, load, turn time dial, close door ( or optionally, close door first, and cooking starts as soon as >1s is on clock )

2. 6 Parts, Door, Dial, Power Button, Start Button, Clear Button, Digital Time Display

Start button with no time chosen starts cooking for 1 minute on high power.

Start button while cooking adds 1 minute to time.

Time dial persists between sessions. Turning dial causes the time stored on the dials position being copied to the digital timer.

Pressing "power" prior to starting cooking will

  1. in the event the dial has not been turned, copy the current time stored on the dails position to the digital timer.
  2. in the event the dial has been turned, decrements the choice of power level by 1, or if on lowest power level, return to highest.

Pressing power while cooking decrements the power level on the fly.

standard operation: 1 minute high = press start.

1 minute medium high = press start, press power.

2 minutes high = press start twice.

<anytime> on high = turn dial until happy, press start.

<anytime> on <anypower> turn dial until happy, press power until happy, press start.

<previously chosen time> on high = press power, press start

<previously chosen time + 1 minute> on high = press power, press start twice.

As you can see here, adding a small amount of extra buttons, can add a great degree of expressive and functional design.

Any design with a numeric keypad for time specification, tends to fail my criteria for good design.

Its noted that these designs may, for some people have a higher learning curve, but once learned, muscle memory makes it instinctive. As opposed to more ( obvious? ) but overly complicated designs which even a learned user will repeatedly have to spend tedious amounts of time performing tedious arbitrary operations, simply to attain common goals.

Kent Fredric
Sounds like you need a copy of my microwave. The buttons 1-9 when pressed automatically start cooking for that many minutes. 0 adds 30 seconds. If you want to cook a specific amount of time, you must press the Cook button first, before keying in the exact time.
BoltBait
Both my and my parents microwaves trumps that :). But i've encountered evil microwaves all over the place that were less-simple that drove me crazy.
Kent Fredric
I agree, especially with the first design. We used to have one like that :'(
fluffels
A: 

Instead of the arbitrary "OK" and "Cancel" buttons, which, given context, can be ambiguous, and users blindly click one, the buttons should contain a brief description of what they do.

[Ok, Please Cancel my subscription ], [ Please do not cancel my subscription ]

is far better than

Cancel my subscription?
[ OK  ] [ Cancel ]

( these sort of failures often surface on the dailywtf )

Kent Fredric
Hmn... my initial reaction was disagreement. I'll have to think about this one as a general rule/tip. I'd say the applicability of your tip may depend on what action brought up that (presumably) dialog.
Larsenal
Is there really any case where "OK" and "Cancel" are better than naming the buttons for what they're actually going to do when you click them?
Steve Losh
A: 

Do some hallway usability testing (in the same way you would do code reviews).

Even a really quick "Hey! try this" usability test (if you can call it that) with the guy next to you will make a big difference. The main thing is to have somebody other than yourself try the bit of UI you've just built.

It's amazing how many times other people get stuck using your new UI, and it only takes a couple of minutes (usually) to find the biggest problems.

Wilka
A: 
  1. Minimize number of clicks
  2. Uniform look(text size, buttons.. and other controls )
  3. Minimize free edits... (ex: in an address entry... provide states in a dropdown...etc etc)
  4. In a drop down for country list... list the residing country first...(how many of you frustrated with USA being listed at the bottom and you have to scroll down?)
  5. General drop downs can be ordered as the users choice
  6. No Spelling msitake ;) at all
  7. Pay attention to labeling text: for email address (have the caption as email... believe me... i have seen it as e_mail address:)
  8. Currency symbol for amounts. uniform digit display in amount.. ex: $12.15 ==> $12.15 $10.9 ==> $10.90 9.Progress/Status bar
  9. Buddy label to indicate the error field before the user clicks OK/Save button(ex: for an email address if there is no "@" there is no need to wait until user clicks OK then tell them invalid email Address)
  10. Avoid repeated inputs... (ex: remember me option in login screen)
  11. global application option to let the user continue from where left off in the previous instance)
  12. when showing data on a grid... excel style filter options
  13. default values for inputs.

Folks...feel free to flush down any of the point above with the valid reasons!!!

I disagree with point 3. I would much rather be able to type "IL" than search down a list to find it (people in Alaska may disagree :-). Certainly in some cases a dropdown makes sense but I don't think this is a good general rule of thumb. It really depends on the context.
Bryan Oakley
You *can* type in a dropdown. If you click or tab to a dropdown in most modern browsers and start typing "Penn" (for example) it should select "Pennsylvania". Desktop apps should try to do the same.
Steve Losh
@Steve Losh: only sometimes. I've seen cases where dropdowns don't allow typing. Plus, if I tab to a drop-down and type "IL" it sometimes chooses Louisana (ie: it chooses based on the last character typed rather than every character typed).
Bryan Oakley
A: 

Grandmaw Testing.

This is my term for the conceptual question, "Can your grandma, who's never used a computer beyond email and checking www.cutecats.com, use it?(Assuming that she has the real-world knowledge to use that particular app)".

Everything common should be obvious; nothing should be black box magic with side effects. Uncommon things should be accessible in a common format that the user has used before.

Clear labeling, clear route to a help file, clear actions with clear effects.

If Grandma can't use your Paint program, you need to really think about your UI.

Paul Nathan
A: 

My basic rule of UI design is to have each "page" do one task and one task only. It keeps pages simple, which keeps design clean and makes the application more understandable.

This type of design is called Inductive User Interface. Here is a document that Microsoft put out in 2001 on the topic. The text may be a little dated, but the principles are generally pretty good. The only caveat is that there is a balance to be found in designing like this. If you oversimplify too much users will have to navigate all over the place to accomplish simple tasks, and the gains in understandability will be lost to underproductivity.

NigelTufnel
A: 

Some simple tips for daily user interface web design and application design:

  • Use simple static sketches to begin preliminary web app development plans. -Dont allow users too many choices. instead, use cater design to send users down a path they'll benefit from. -Define key user groups and the journeys they made -Practice iterative design as a part of UI to ensure ROI
Alex
A: 

I like to follow these guidlines:

  1. Standard - follow known standards/patterns, reuse ideas from all products you respect
  2. Simple - keep your solutions simple and easy to change (if needed)
  3. Elegant - use less to accomplish more
Zamboni