Best Practices & Principles for GUI design [closed]

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago .
  1. KISS.
  2. Be clear and specific in what an option will achieve: for example, use verbs that indicate the action that will follow on a choice (see: Impl. 1).
  3. Use obvious default actions appropriate to what the user needs/wants to achieve.
  4. Fit the appearance and behavior of the UI to the environment/process/audience: stand-alone application, web-page, portable, scientific analysis, flash-game, professionals/children, .
  5. Reduce the learning curve of a new user.
  6. Rather than disabling or hiding options, consider giving a helpful message where the user can have alternatives, but only where those alternatives exist. If no alternatives are available, its better to disable the option - which visually then states that the option is not available - do not hide the unavailable options, rather explain in a mouse-over popup why it is disabled.
  7. Stay consistent and conform to practices, and placement of controls, as is implemented in widely-used successful applications.
  8. Lead the expectations of the user and let your program behave according to those expectations.
  9. Stick to the vocabulary and knowledge of the user and do not use programmer/implementation terminology.
  10. Follow basic design principles: contrast (obviousness), repetition (consistency), alignment (appearance), and proximity (grouping).
  1. (See answer by paiNie) "Try to use verbs in your dialog boxes."
  2. Allow/implement undo and redo.
  1. Windows Vista User Experience Guidelines [http://msdn.microsoft.com/en-us/library/aa511258.aspx]
  2. Dutch websites - "Drempelvrij" guidelines [http://www.drempelvrij.nl/richtlijnen]
  3. Web Content Accessibility Guidelines (WCAG 1.0) [http://www.w3.org/TR/WCAG10/]
  4. Consistence [http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746]
  5. Don't make me Think [http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758/ref=pdbbssr_1?ie=UTF8&s=books&qid=1221726383&sr=8-1]
  6. Be powerful and simple [http://msdn.microsoft.com/en-us/library/aa511332.aspx]
  7. Gestalt design laws [http://www.squidoo.com/gestaltlaws]
community wiki Related question: stackoverflow.com/questions/51050/… Commented Sep 18, 2008 at 7:59

It's a rather all-encompassing question. zone in a little bit more.. I posted MVP first.. thinking you're interested in UI design alternatives.

Commented Sep 18, 2008 at 8:01

My aim is in the end to glean what are used in the field - not the text-book academic views, but practices that actually makes things really useful.

Commented Sep 18, 2008 at 9:31 Related: What are some good usability guidelines an average developer should follow? Commented Feb 3, 2012 at 12:09

19 Answers 19

I test my GUI against my grandma.

community wiki this answer made my day. :) Commented Sep 23, 2013 at 9:24

Try to use verbs in your dialog boxes.

alt text

alt text

131 9 9 bronze badges answered Sep 18, 2008 at 8:15 5,365 3 3 gold badges 31 31 silver badges 36 36 bronze badges I like this too, but I noticed you'll get allot of discussion from older developers. Commented Sep 18, 2008 at 8:25

Yeah u are right about ingoring text! But - users dont read title and text, they read button captions!

Commented Sep 19, 2008 at 10:05

Instead of 3 words on second dialog ("Save changes to") there are 22 on first one - nobody will read this. However, captions on first one are so much better!

Commented Oct 24, 2008 at 12:55

i also find yes/no/cancel much more logical then save/cancel/no save . i.e. yes/opposite/cancel instead of yes/cancel/opposite of yes .

Commented Dec 10, 2009 at 17:56

Most people just read the button text - something like Yes/No/cancel could be referring to anything, but Save/Don't Save is very clear what you are doing. It is fine to have additional text above the buttons, because if someone sees Save/Don't Save and was expecting something else (say about printing), then they will stop and read the text. You just can't expect the normal use-case to be the user reading all the text in your dialog.

Commented Dec 9, 2010 at 15:24

Follow basic design principles

answered Sep 19, 2008 at 1:44 Craig Pickering Craig Pickering 1,184 1 1 gold badge 13 13 silver badges 17 17 bronze badges

Robin Williams "The Non-Designer's Design Book: Design and Typographic Principles for the Visual Novice" covers these principles in a great way! goo.gl/qoG0Q

Commented Jun 29, 2011 at 23:45 Like the acronym. When you're finished, do you say it looks like CRAP :p ? Commented Mar 23, 2013 at 5:35 @Chris There's now a newer (4th, 2014) edition of the Williams book. Commented Jun 23, 2016 at 0:12

Never ask "Are you sure?". Just allow unlimited, reliable undo/redo.

answered Sep 18, 2008 at 11:45 Jörg W Mittag Jörg W Mittag 368k 79 79 gold badges 451 451 silver badges 659 659 bronze badges

You're right, but I don't think this is realistic. Implementing a rollback often require a lot of effort.

Commented Mar 12, 2010 at 8:13

@Dimitri C.: Not nearly as much if you build it into the design from day -1. In a text editor, for example, you could just create a hidden directory and use Mercurial/Git/whatever to keep track of potentially destructive operations. The Command Software Design Pattern is also helpful. Google Mail is a nice example: have noticed that if you delete a thread there is no dialog box? Instead, there is a small notification bar which says something like: "You just moved a thread to the trashcan. [More Information] [Undo]"

Commented Mar 12, 2010 at 14:00

Try to think about what your user wants to achieve instead of what the requirements are.

The user will enter your system and use it to achieve a goal. When you open up calc you need to make a simple fast calculation 90% of the time so that's why by default it is set to simple mode.

So don't think about what the application must do but think about the user which will be doing it, probably bored, and try to design based on what his intentions are, try to make his life easier.

answered Sep 18, 2008 at 8:31 Jorge Córdoba Jorge Córdoba 51.9k 11 11 gold badges 82 82 silver badges 130 130 bronze badges

If you're doing anything for the web, or any front-facing software application for that matter, you really owe it to yourself to read.

answered Sep 18, 2008 at 8:27 4,787 4 4 gold badges 32 32 silver badges 35 35 bronze badges

Breadcrumbs in webapps:
Tell -> The -> User -> Where -> She -> Is in the system

This is pretty hard to do in "dynamic" systems with multiple paths to the same data, but it often helps navigate the system.

answered Sep 18, 2008 at 8:44 11.6k 7 7 gold badges 33 33 silver badges 37 37 bronze badges

Jared Spool did some user testing on this and learned that only coputer savvy people use breadcrumbs. Normal visitors don't get this concept.

Commented Jun 2, 2009 at 9:48

It might be so. But a quick read on Spool's article uie.com/brainsparks/2005/09/26/value-of-breadcrumbs gives me the impression that he thinks that breadcrumbs are just a navigational tool for the user. In my opinion they're also a good "page heading". Also, Spool's article is far from scientific.

Commented Jun 3, 2009 at 6:00 I think these would actually be pretty good in some desktop apps too! Commented Feb 6, 2013 at 19:59

I try to adapt to the environment.

When developing for an Windows application, I use the Windows Vista User Experience Guidelines but when I'm developing an web application I use the appropriate guidelines, because I develop Dutch websites I use the "Drempelvrij" guidelines which are based on the Web Content Accessibility Guidelines (WCAG 1.0) by the World Wide Web Consortium (W3C).

The reason I do this is to reduce the learning curve of a new user.

answered Sep 18, 2008 at 8:02 Davy Landman Davy Landman 15.3k 6 6 gold badges 52 52 silver badges 76 76 bronze badges

I would recommend to get a good solid understanding of GUI design by reading the book The Design of Everyday Things. Although the main printable is a comment from Joel Spolsky: When the behavior of the application differs to what the user expects to happen then you have a problem with your graphical user interface.

The best example is, when somebody swaps around the OK and Cancel button on some web sites. The user expects the OK button to be on the left, and the Cancel button to be on the right. So in short, when the application behavior differs to what the user expects what to happen then you have a user interface design problem.

Although, the best advice, in no matter what design or design pattern you follow, is to keep the design and conventions consistent throughout the application.

31.6k 22 22 gold badges 109 109 silver badges 132 132 bronze badges answered Sep 18, 2008 at 8:03 2,968 3 3 gold badges 27 27 silver badges 40 40 bronze badges

Avoid asking the user to make choices whenever you can (i.e. don't create a fork with a configuration dialog!)

For every option and every message box, ask yourself: can I instead come up with some reasonable default behavior that

I can use my Palm handheld as an example: the settings are really minimalistic, and I'm quite happy with that. The basic applications are well designed enough that I can simply use them without feeling the need for tweaking. Ok, there are some things I can't do, and in fact I sort of had to adapt myself to the tool (instead of the opposite), but in the end this really makes my life easier.

This website is another example: you can't configure anything, and yet I find it really nice to use.

Reasonable defaults can be hard to figure out, and simple usability tests can provide a lot of clues to help you with that.

answered Sep 18, 2008 at 8:57 Carl Seleborg Carl Seleborg 13.2k 11 11 gold badges 59 59 silver badges 70 70 bronze badges

Show the interface to a sample of users. Ask them to perform a typical task. Watch for their mistakes. Listen to their comments. Make changes and repeat.

answered Sep 18, 2008 at 9:06 8,419 4 4 gold badges 34 34 silver badges 39 39 bronze badges

Make sure it's a representative sample of your customers. We use an intern for this and we have to give them special instructions to include the over 30 crowd.

Commented Nov 22, 2008 at 22:27

The Design of Everyday Things - Donald Norman

A canon of design lore and the basis of many HCI courses at universities around the world. You won't design a great GUI in five minutes with a few comments from a web forum, but some principles will get your thinking pointed the right way.

answered Sep 18, 2008 at 8:39 Michael Carden Michael Carden I would add that his Emotional Design is also very worth a read. Commented Nov 8, 2013 at 20:49

When constructing error messages make the error message be the answers to these 3 questions (in that order):

  1. What happened?
  2. Why did it happen?
  3. What can be done about it?

This is from "Human Interface Guidelines: The Apple Desktop Interface" (1987, ISBN 0-201-17753-6), but it can be used for any error message anywhere. There is an updated version for Mac OS X. The Microsoft page User Interface Messages says the same thing: ". in the case of an error message, you should include the issue, the cause, and the user action to correct the problem."

Also include any information that is known by the program, not just some fixed string. E.g. for the "Why did it happen" part of the error message use "Raw spectrum file L:\refDataForMascotParser\TripleEncoding\Q1LCMS190203_01Doub leArg.wiff does not exist" instead of just "File does not exist".

Contrast this with the infamous error message: "An error happend.".

community wiki

(Stolen from Joel :o) )

Don't disable/remove options - rather give a helpful message when the user click/select it.

answered Sep 18, 2008 at 7:59 7,097 9 9 gold badges 56 56 silver badges 80 80 bronze badges

I also read that article, but think it works for most of the time, but not always. In some scenario you have to hide/disable menu options. Think about this: you have the Paste menupoint always visible and enabled and when you click on it, it will show a message: You have nothing to paste. :-)

Commented Sep 18, 2008 at 8:03

One of the rare occasions where I completely disagree with Joel: Disabling menu options gives a direct feedback - 'not available now'. Save the user the action (and the disappointment) of having to click on a menu to find out. Hiding menu options is bad, though

Commented Oct 4, 2008 at 7:59

As my data structure professor pointed today: Give instructions on how your program works to the average user. We programmers often think we're pretty logical with our programs, but the average user probably won't know what to do.

31.6k 22 22 gold badges 109 109 silver badges 132 132 bronze badges answered Sep 18, 2008 at 8:03 marioBonales marioBonales 91 2 2 silver badges 6 6 bronze badges
  1. Use discreet/simple animated features to create seamless transitions from one section the the other. This helps the user to create a mental map of navigation/structure.
  2. Use short (one word if possible) titles on the buttons that describe clearly the essence of the action.
  3. Use semantic zooming where possible (a good example is how zooming works on Google/Bing maps, where more information is visible when you focus on an area).
  4. Create at least two ways to navigate: Vertical and horizontal. Vertical when you navigate between different sections and horizontal when you navigate within the contents of the section or subsection.
  5. Always keep the main options nodes of your structure visible (where the size of the screen and the type of device allows it).
  6. When you go deep into the structure always keep a visible hint (i.e. such as in the form of a path) indicating where you are.
  7. Hide elements when you want the user to focus on data (such as reading an article or viewing a project). - however beware of point #5 and #4.
community wiki

Oh, and hire a designer / learn design skills. :)

answered Sep 18, 2008 at 9:50 12.6k 8 8 gold badges 43 43 silver badges 43 43 bronze badges

With GUIs, standards are kind of platform specific. E.g. While developing GUI in Eclipse this link provides decent guideline.

community wiki

I've read most of the above and one thing that I'm not seeing mentioned:

If users are meant to use the interface ONCE, showing only what they need to use if possible is great.

If the user interface is going to be used repeatedly by the same user, but maybe not very often, disabling controls is better than hiding them: the user interface changing and hidden features not being obvious (or remembered) by an occasional user is frustrating to the user.

If the user interface is going to be used VERY REGULARLY by the same user (and there is not a lot of turnover in the job i.e. not a lot of new users coming online all the time) disabling controls is absolutely helpful and the user will become accustomed to the reasons why things happen but preventing them from using controls accidentally in improper contexts appreciated and prevents errors.

Just my opinion, but it all goes back to understanding your user profile, not just what a single user session might entail.