Introduction
The importance of designing a good UI is well known in our days. We have made some progress since the boring console applications. Nowadays, we are not talking about just an intuitive UI design but about Smart Client applications with extended capabilities. Designing a good UI application looks like an easy task, but in reality, it is not. Meeting with customer needs, surely with hundreds of them, is a hard task.
This article describes several UI design rules; complying with them, so I believe, will be a good start for a better UI application.
Who should read this article?
The article might be useful for UI designers, Product and Project Managers, and of course, developers.
Disclaimer
This article contains thoughts of my own on how to approach UI design. I assume that some of the readers will disagree with some of the rules, and that is just fine. After all, the extent of the UI quality is in the eye of the beholder. Nevertheless, this article sees the light because I think the rules described in it suits most of the Windows UI applications I have used.
Consistency
If a UI lacks consistency, then it sucks. Consistency should be in both looks and usage. If you use Microsoft Outlook, you probably know what I am talking about. How many times have you used the Ctrl+F shortcut in Outlook and learned that in this program it forwards an email. This lack of consistency gets the bad side of me, and it does so time after time again. This is a bug. It is not only that the fox in Redmond irritates the users, it also puts Microsoft in bad reputation. Since the emerging of Windows OS, Microsoft has tried to encourage developers to write Windows applications with a consistent UI.
The use of WinAPI was, and still is, free of charge (as opposed to that in MAC); they have developed frameworks like MFC, VB, ATL and tools. Moreover, Microsoft wanted developers to keep consistency in terms of Windows UI usage but failed to do so in Outlook.
Example 1:
In the above example, the Nero UI Designer has decided to innovate by designing a non-traditional window. While it looks sharp, it is still confusing because the Close button is not in the upper right side of the window but in the bottom. The Close icon is, for some reason, similar to the XP shutdown icon.
In order to accomplish UI consistency, we must follow the common Windows application behaviors. My application of choice would be any of the Office package applications. I always turn to the Office package application for reference, and for the following reasons: first, the UI design of this package is well debugged. Second, users of my application use them intensively. Third, Microsoft put money, thoughts, and effort in this design.
One of my colleagues hates the fact that he needs to develop Office like applications. He used to complain about his own creativity going down the drain. I used to tell him that it is not important how much he hates what Microsoft Office UI represents, there are still good reasons to use it, and not only for the end user's sake. Copycat Office Toolbars and Menus simplify the development work because we ride on the Microsoft experience in UI designing. If company of this caliber spends a lot of time and money on this issue, why re-spend them again?
Example 2:
In the above example, we can see that the menu is missing the ALT shortcut like in the File menu. The icons in each layout look like it was designed by different graphic designers. The export icon is not meaningful. The layout is too loaded.
In places where Windows is not consistent or where your design is simply different, you need to write a set of rules that will be applied for your entire application(s). For example, if you use a custom Toolbar, keep using it in each form. Don't decide out of a sudden to drop it in one of your forms. Another example is the use of context menus. If you have certain common items in a context menu like: Copy, Cut, and Paste, then you should keep them for each, relevant control, and in the same order. The usage might be different and the context menus might have extra specific items for each control, but the common items need to stay, for consistency purpose. It is also important to use the same font family and size and to keep a similar window layout.
Always think about the end user
This rule could, humouredly, be put like this: "Hmmm� will someone actually use it some day". The only thing is, there is nothing to laugh about.
This rule is an important one. If you don't think about the user in each step of the UI design and in the development stages, then no customer, certainly not a happy one, will use your application. Developers and UI designers (who used to be developers) tend to forget about the end user skills.
They think about themselves as the end user. In reality, most of the end users have skills much lesser than those of developers.
This rule is not easy to comply with because day after day, on the designing and developing table, we get familiar with the defects, and bad UI design begins to make sense.
It is crucial to detect the type of users who are going to work with an application. Mostly, the best practice is to aim at the lowest common ground, and apply advanced capabilities in conceal. It would also be great to allow each user to customize the UI according to his knowledge, capabilities, and expertise. This customization data must be stored in a persistent media for each user for future application runs, and need to stay intact after application updates.
The quality of the user experience is determined, in my humble opinion, by the following main criteria:
- Do the features and functionalities that I wanted, exist and work well?
- Is the application simple, intuitive, and easy to use?
- Is the application fast in terms of performance?
- Is the application stable?
If the user answers those questions with Yes, then we are facing a happy user who will use the application happily again and again.
Meet the user needs and he will praise your software, else he will blame you for all the miseries existing in the world.
The main problem is when there are various types of users with different expectations. In one of the projects that I participated in, I noticed something very interesting about the use of UI. The application UI exposed the same functionality in three different places: Menu, Toolbar, and Context Menu. At first, it looked like a redundancy issue, but soon I saw that three different people in my company used one of options according to their preference. Using this approach makes different types of users happy. Another practice that helps to think about the end users during the designing and developing process is to meet them on a regular basis and to gather feedback in pre-marketing stages. You should also run surveys among the customers after the buying or examination process. Asking for the users for their opinion will make them feel that you are committed to quality, and will make them much more patient and cooperative in regards to bugs.
Keep it clean and don't over estimate user capabilities
Designing good UI in applications is not about thinking how to make a Toolbar but, determining what type it should be: Should it be dockable or not? What to put in it? Is it required?
A user might ask the following questions when working with your application: how to do a task? where to do it? when to do it?
Make sure that the questions can be answered by the user within a short period of time. The shorter the learning curve is, the happier the users are.
- Avoid overwhelming messages and dialogs controls which require the user to make a decision. At least, you should make it as clear as it can be. Users just hate to read messages like: "�yada yada �.happened�..", and then after few frightening lines of this story, it requires them to answer a question like: "�Do you want to do X?"
The user does not give a damn about this kind of messages so don't load him with information. It is a hard task for your users what they should decide about and what not. There is a thin line between annoying and upsetting them and not letting them know about stuff.
In the above example, you can see an extensive use of words in the WinZip interface. When you see this message, you are saying to yourself "Oh boy, do I have 15 minutes to read all this stuff?"
- Do not depend on your manual and help files. You have probably heard about the initials: RTFM (Read The F***ing Manual). It is a crying shame but it is true, users don't read them or at least they will do almost everything to avoid them. The more the application costs, the more chances are that the users will use the manual.
For example, if the application is free and the user does not get along with it, he might just uninstall it. The above fact does not mean you can avoid writing a manual; the customer still demands it. What you can do, is make the UI clean, clear, and simple to work with.
- Do not make an assumption that the end user is intelligent enough to not customize the UI background to black because this is the color of the font or because it will look ugly.
I am using Murphy's main law to say that if the application UI allows the user to shoot his leg, then he will probably manage to do so. Make sure to protect the application against stupid users else you will be dealing with stupid company blames.
- Do not burden the user with error messages that he can not digest. Keep UI information messages short and explanatory. Create rich logs to send to the customer support instead. Be sure you clear horror messages like "�Fatal problem�" or "�we should not arrive to this code�" before you ship the application.
Make sure the application stands tall under all circumstances. Catch all errors and display friendly messages only.
- Do not ask what the user can do in order to work better with your application and get the most of it. Do ask what the application can do for the users.
End users are lazy. If you can ease their work, they will appreciate it. Give users the tools to create semi or fully automatic processes so they won't have to repeat doing the same stuff over and over again and have some free time to read the latest news on the web. Of course, I am talking about you.
You are an exception :-) I am talking about Dilbert and Homer Simpson.
If you don't have the resources to make each part of your application simple, at least make sure that the mainstream, frequent actions are as simple as they can be.
Customizability
There is no such thing as exaggeration in customization capabilities. I have never heard anyone complain about an application that there are too many configuration options. They might be angry only if those options are not ordered well. This rule is important for the following reasons: the amount of configuration options that an application can have stand in direct line with the ease of tailoring the application for a specific customer: a job which usually is a pain to the Customer/Project team members.
A greater extend of customization options allows users from different levels of expertise to adapt an application to their needs. User customizations data should be, of course, saved for future application runs.
Good customizable applications enable the use of it for users with disabilities. For example, some of the end users might be color blind. In this case, the option of changing the application colors is mandatory.
Take the user machine into consideration
When you decide on 32 bit color quality for Toolbar icons, you don't take into consideration those users with a max. 16 bit color screen. Another factor is the screen size. These kind of considerations, if left unhandled, can cause your application to look poor.
A good UI which complies with all of the above rules helps firms to sell products. Sometimes, a competitive company steals business opportunities from your company, simply because their UI is better looking. A good UI shines, and makes a good impression. It does not matter if your application has richer functionalities. If it looks 'low tech' then there is 'no take'.
This article describes only a drop in the ocean of UI tips and rules. I encourage you to read and learn about this topic, it is the only way to write better UI applications.
Bibliography
