UI Guideline Resources

Every good development team creates guideline for the implementation of the user interface, so that the implementation is consistent.  A consistent meaning helps users to understand more easily what is meant by a particular arrangement of UI elements.  

Don’t create your own!

Many people have been down this road before, and millions have been spent developing such guidelines.  Many of these are readily available.  So use them.  Here are some resources:

Books:

• Don’t Make The User Think – Steven Krug’s well-reasoned instant classic.
  
• Designing Interfaces: Patterns for Effective Interaction Design – Jennifer Tidwell
• A Pattern Language: Towns, Buildings, Construction – Christopher Alexander, from architecture, but it applied to good design in any domain.
• The Timeless Way of Building – Christopher Alexander, another classic from architecture.
• The Design of Sites: Patterns for Creating Winning Web Sites – van Duyne, Landay, & Hong
• Web Style Guide: Basic Design Principles for Creating Web Sites – Patrick J. Lynch, Sarah Horton

Online Resources

The Monster List of UI Guidelines lists 57 different resources (however many are broken).  I have copied the good ones here (in case that link is broken at some point in the future) and updated with some additional ones I found:

• ACDSee Brand Style Guide
• Adobe UI Gripes – a helpful blog
• Ameritech Graphical User Interface Standards and Design Guidelines (This one is from the Internet Archive)
• Android User Interface Guidelines
• Apple Human Interface Guidelines
• Apple iOS Human Interface Guidelines
• BBC Future Media Standards & Guidelines
• BBC Global Experience Language (GEL)
• Blackberry and RIM wireless handheld UI Developers Guide (PDF, 1.3 mb)
• ELMER 2– User Interface Guidelines for Government Web Forms (PDF, 1.2 mb) from Norway
• Eclipse User Interface Guidelines
• Gnome Human Interface Guidelines
• iPhone Human Interface Guidelines
• Microsoft Inductive User Interface Guidelines
• Microsoft Surface User Experience Guidelines
• MITRE- Guidelines for designing user interface software
• Nokia Design and User Experience Library
• Oracle Technology Network Guidelines
• Palm User Interface & Human Interface Guidelines
• SAP Interaction Design Guide for Internet Application Components
• SAP Design Guild
• SAP User Interface guidelines
• Silicon Graphics Indigo Magic User Interface Guidelines
• University of Maryland UI Guidelines
• Windows User Experience
• Windows User Experience Guidelines
• Windows User Experience Interaction Guidelines
• Windows XP Visual Guidelines (There’s a download section to the right to download WindowsXP DesignGuidelines)
• Yahoo! Design Pattern Library

Organizations Dedicated To This

• The User Experience Professionals Association

Does this Guarantee Good UI?

No.

UI design guidelines are necessary to help communicate the intended meaning between particular UI patterns that are being used.  The user experience professional will get together and agree that they will attempt to communicate certain things with certain visual patterns.  Thus, a “question mark” may be used to mean a button to get to a “help page” and it might even define what counts as a help page, and what is not.  The UI guidelines function as a kind of “dictionary” of traditional meanings.

However, have a complete set of UI design guidelines will never assure that you have a good user interface.  This is the same as saying that a good dictionary does not guarantee that you are a good writer.  There is a skill to writing, and while a dictionary is critical to assure that you use the same words in the same way, it is also true that a good writer will violate rules, and use words in unusual ways all the time.  A writer describing a particular subject faces a challenge that possibly nobody has ever had to face before, and in any case they face problems not anticipated by the dictionary writer.   The skill lies in knowing what communicates to the user, and the acceptable language is based purely on whether it communicates and not whether it agrees with the dictionary.  The same is true in a user interface: the designer is facing a situation that possible nobody has ever had to face before, and therefor something that had not been anticipated by the people putting the Ui guideline together.

Making a good user interface is every developer’s responsibility.  It must be judged as a whole, purely based on whether the user finds it comfortable to use or not.  The guideline can help, but not guarantee, that.  Conversely, if you have bad UI, blaming this on the bad guidelines is like blaming a bad book on a bad dictionary.  There is a  UI design skill that is needed independent of the guidelines.

So don’t expect too much from the guidelines.