Jason Irwin dot Net

Designing the Best UI

January 18, 2009 Technology

There comes a time in everybody’s career when they decide that the current position just isn’t rewarding enough and they begin to look for something better.  Occasionally this means finding employment at another company, but it doesn’t have to be this way.  In my case, I’ve been working pretty hard at a job that doesn’t quite match who I am.  However, considering the numerous limitations facing me outside of my current employer, any career change will most likely need to occur within the company.  For these reasons, I’ve been working on an application that should save quite a bit of time and money for the same people that sign my pay slip.

But can a person from North America really design software for a Japanese company?

I certainly hope so, as it will be a long time before I truly understand why software written in this country has to make use of such complex and seemingly unintuitive interfaces (I’m looking at you, Sony) for things that should be relatively simple.  That said, there are 13 rules that I’ve always tried to abide by whenever developing the front-end of an application, as this is where people make their decision to love or hate the software.

Luckily, I had learned these 13 rules from one of the strictest instructors while in college: Mr. Mann.  With a name like this, you know he means business.  So, before we were even allowed to crack open our 486-based notebooks (yes, college was that long ago for me), Mann’s Commandments had to be known inside and out.

Mann’s Commandments

1. Consistency is Key – Any application that has more than one form must follow the same rules in each.  If double-clicking a grid with customer information in one place will perform a function, it only makes sense (from a user’s perspective) that the software will react the same way somewhere else.  In addition, buttons should always be in the same general area and react the same ways.  Standard non-serriffed fonts should be used, and messages should all use the same type of language.  Consistency lets people build a mental map of how the software will work on each screen,which gives them more confidence in the system.
2. Set Standards – The only way to ensure consistency is met is to set some standards and not let anyone, for any reason, change “just one thing”.  Following Agile Modelling’s standards and practices is recommended, but not 100% necessary if standards are set and adhered to by everyone in an organization.
3. Explain – Communication is key, and people need to know how to use the software that was built with them in mind.  When an application works consistently, it means that you should only need to explain the rules once.  This is a heck of a lot easier than explaining each an every function on each and every screen.
4. Navigation Without Maps – If it’s difficult to get from one part of the application to another, then users will quickly become frustrated and label your software as everything from “cumbersome” to “worse than Vista”.  When the flow between screens matches a person’s understanding of their job, then the application will make sense.  That said, people work differently from each other, so the User Interface and underlying code should be flexible enough to support various approaches.
5. Navigation By Instinct - In Western-based societies, people read from left to right, top to bottom.  Because people are accustomed to this, UIs should follow the same principle.  Screens should be designed with the target audience in mind.
6. KISS Labels – The text on the screen is the primary source of information for the users.  If the text is poorly worded, we can expect the users to become confused.  Using full words and sentences rather than abbreviations and codes makes the software easier to understand.  Messages should always be worded positively, even when something is incomplete, to give people the illusion of control and to provide the insight necessary to use the application as it was designed to be used.
7. Learn What Works – There’s nothing wrong with looking at other UI designs to get a little help when building an application, but we can’t just copy something verbatim.  Unless it’s known that an application has been designed to follow the UI guidelines of the organization, don’t assume that the program offers the best way to solve a problem.
8. Use Color Sparingly – There are just some things that should not be over-used in an application, and color is one of them.  If color is necessary, then a secondary color must also be included to act as an indicator.  The problem that many developers forget, though, is that many people are color blind and cannot differentiate light colors from the white of the screen.  If colors are used, they also need to be used consistently throughout the application.  A grid that highlights green on one screen should not use purple on another.
9. Obey Contrasts – If color is going to be used, the screens need to remain readable.  The best way to do this is to ensure proper contrasts between colors; light text on dark backgrounds, and dark backgrounds on light backgrounds.  Using red letters on a green background does not have as much contrast as red letters on a white background.
10. Align Those Fields – On data entry screens, numbers are almost always right justified and text left justified.  While this may not be an abolute truth in all cases, applications should follow the same rules on each screen.
11. Expect Mistakes – How often do you find yourself using an application and you make a mistake?  Is it easy to undo what you just did?  Every application should have some form of “Undo” function, even if it’s just a very basic one.  We’re all human, and we all make mistakes.
12. Avoid Busy Forms – Crowded screens are difficult to understand, use, and comprehend.  Forms should have between 40-50% of empty space (total) in order to maintain an easily readable screen.
13. Keep It Intuitive – An intuitive screen can be used quickly by a rookie after just a few quick glances and five minutes of trial-and-error.  Even if the guesses are wrong, the system should provide useful feedback in such a way that the new user quickly learns how to use the system.

And there we have it … 13 rules to live by when developing applications, regardless of the platform.  As you can see, there is an awful lot of talk about consistency in these rules, and that seems to be the underlying foundation of the principles.  I’ve tried to follow these rules in all of my applications and, in the few times that I didn’t, it became quickly apparent just how important these 13 commandments really are.

Do you follow these rules when you are designing an application?  Are there any that you would add to the list?

Tags: design, rules, software, UI