What good usability guidelines should an average developer follow?

I'm not a usability specialist, and I really don't want to be that way.

I just want a small set of rules that I can follow when coding my user interfaces so that my product has decent usability.

At first I thought it would be easy to answer “Use common sense”, but if this is so common among developers, we would not, as a group, have a reputation for our terrible interfaces.

Any suggestions?

+28
usability
Sep 09 '08 at 1:00
source share
17 answers
+24
Sep 09 '08 at 1:15
source share

Read Don't Make Me Think By Steve Krug . This is a great starting point and easy short reading.

EDIT: This is mainly for ease of use on the Internet, but it will still be good, even if you make rich customers.

+12
Sep 09 '08 at 1:03
source share

Only two things:

  • “The user interface is well designed when the program behaves exactly as the user thought it would be” - quoted from Joel Spolsky UI Design for Programmers
  • Put your designs in front of the user. A true end user is best, but for easy and quick feedback, you cannot beat a hallway usability test, that is, capture an employee.

If you remember Joel’s advice and make sure you get feedback on what you are doing and acting on it , that is, iterating, you won’t be mistaken. And I would repeat the recommendation for Steve Do not Make Me Think Circle - this is probably the best work related to the book I read, there is no bar, and it is as applicable to desktop software as websites.

Hope this helps.

+7
Sep 17 '08 at 17:10
source share
  • Do not do the job differently than your users expect (i.e. disable the back button when using Ajax in web forms
  • Follow KISS Director

Indeed, any rules that someone publishes will be a variation on the topic: Don't Think Your Users Think

"Do not Make Me Think" has already been published, see also Design of everyday things and Designing using web standards are also good for reading the usability of light.

+5
Sep 09 '08 at 1:04
source share

The most important piece of advice I would give someone is to work with the user interface first. Pen and paper and all. Thus, you will not subconsciously associate buttons with functions, enter fields in variables, etc.

The best user interface could be a pain in the code, and if your main code is mostly written, it will sabotage your thinking.

In addition, I would point to the Apple Human Interface Guide . Of course, if your platform is not OS X, take the OS X partitions with lots of salt. What works on OS X may not work on Windows. You must use the idioms of your platform.

OS X aside, this document has some good starting points based on.

+4
Sep 09 '08 at 1:07
source share

Avoid modes . This disappoints the user when the input works sometimes, but not others, or does different things at different times.

+4
Sep 09 '08 at 2:21
source share

Here are some simple rules:

  • The fewer clicks, the better.
  • Frequently used functions should be easier to find.
  • Opportunities for advanced users can be harder to find than higher.

Think about the number of mouse clicks / keyboards the user needs to do something.

PS - please do not report this to Microsoft Office 2008 staff; poor little guys will cry to sleep tonight! :)

+4
Sep 17 '08 at 19:55
source share

I posted related questions:

  • What indicators for the convenience of using the GUI do you know?
  • GUI design to enhance user experience
+2
09 Sep '08 at 1:43
source share

Think about the users who will use your application. Why do they use it and in what context?

  • Will most users who know the domain in which the application is used and use the application a lot? Then do not be afraid to add a lot of data to the screens if they are logically set for users (usually this is not in alphabetical order :-). Think of trading screens for alternate fighters or airplane cabs.
  • Are users random users? Keep it simple. Avoid context switches (save every time / as much as necessary data for the task on the screen). Do not break the expectations of how gui widgets usually see. Design for bounce.
  • Anything in between? Allow users to grow in the user interface. Track usage to subsequently determine where users tend to spend more time, so you can improve the most used areas of your application.
  • Test your application for friends and colleagues (test in the hallway) to find out if they can use it effectively.

This is the beginning.

+1
Sep 17 '08 at 7:37
source share

I suggest reading these blog posts from Enso .

Of course, they repeat guides / ideas / tips from books such as: Design of Everyday Things and About Face , but nonetheless, the messages contain quite a lot of information and (IMO) that they read well.

+1
Oct 09 '09 at 12:40
source share

What information do you need, put it on the screen and nothing more. If you cannot determine what the user needs, get another user.

0
Oct. 10 '09 at 2:14
source share

Remember that your application will be one of many to deal with. Do nothing to be different or kewl. Do not come up with unusual graphics, behavior, terminology or interactions. Use standard OS controls, conventions, utilities, and behavior.

Allow your application to interact with other applications; allow cutting and pasting data, save your data in formats that other applications can read, and allow importing data from other applications instead of using the user interface.

If you are creating a desktop application, do not try to take over the user's computer. Leave the user's Documents folder, taskbar and application settings. Do not modify anything that is already installed on the computer. Allow interaction by script or command line.

If you are building a web application, do not try to hijack the browser. Do not attempt to undermine standard menu bars, history, layout, or fonts. Allow the user to modify the page using Javascript.

0
Oct 10 '09 at 2:40
source share

(1) General actions should require as little effort as possible and should be obvious ; on the other hand, actions that are rarely needed can take many steps and can be hidden behind menus and dialogs. To do this, you should always describe what the user wants to do with the application, listing examples of use .

(2) The UI must be self-documenting . The manual should be integrated into application dialogs and menus, as users do not read individual manuals. For example, a keyboard shortcut should appear in a menu item that represents the action with which it is associated.

0
Mar 12 '10 at 9:18
source share

Provide keyboard shortcuts for advanced users (even if it's as simple as hit hit to search)

Do not put too much on the screen right away.

If you pop up as a message, your users usually don’t read it.

0
Mar 12 '10 at 9:25
source share
  • Simple is better than complex
  • Complex is better than complex (exclude "nested ifs")
  • Intuitive (good elements require no explanation)
  • Follow the convention (for example, an underlined link means red means an error, the tab goes to the next field, etc.)
  • Use semantics to apply logic (first heading heading, paragraphs)
  • space is important.
0
Mar 12 2018-10-12T00:
source share

In addition to other recommendations here, I would recommend Jenifer Tidwell's Designing Interfaces as a good way to familiarize yourself with user interface conventions.
In addition, Prisoners manage the shelter. Alan Cooper is great for understanding how to approach design interaction.

0
Mar 12
source share

A Good Approach to Do not Make Me Think Robert Hekman Designing the Obvious . It is more focused on web applications, unlike websites such as Krug's.

0
Mar 12
source share



All Articles