Thoughts About UI Design

8/15/2019 Thoughts About UI Design

http://slidepdf.com/reader/full/thoughts-about-ui-design 1/8

Title: Thoughts about UI design

Author: Oren Cohen Shwartz

Introduction

The importance of designing a good UI is well known in our days. We have madesome progress since the boring console applications.

Now days we are not talking about just an intuitive UI design but about Smartclient applications with extended capabilities.

Designing a good UI application looks like an easy task but in reality it is not.

Meeting with customer needs; surly with hundred 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 better UI application.

Who should read this article?

The article might be useful for UI designer, Product and Project Managers and of course developers.

Disclaimer

The article contains thoughts of my own of 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 it suit most

of Windows UI applications I have used.

Consistency

If the UI is lack of consistency then it sucks. The consistency should be both in

look and usage. If you use Microsoft Outlook you are probably know what I

am talking about. How many times did you use the Ctrl+F shortcut in Outlook andlearn to see that in this program it forwards the email.

This lack of consistency get the bad side of me, and it does so time after timeagain. This is A Bug. It is not only that the fox in Redmond irritate the users





I have used to told him that it is not important how much he hates what Microsoftrepresents, there are still good reasons to use it, and not only for the end userssake.

Copycat Office Toolbars and Menus simplify the development work because weride on Microsoft experience in UI designing. Be rest and sure that company of this caliber

spends a lot of time and money on this issue why spending it again?

Example 2:

In the above example we can see that the menu is missing the ALT shortcut like

File. The icons in each layout look like it was designed by different graphic designer. The export icon is not meaningful. The layout is too loaded.

In places where Windows is not consistent or where your design is simply differ

then you need to write a set of rules that will be applied for your entireapplication(s).

For example if you use Toolbar keep using it in each Form. Don’t decide out of asudden to drop it in one of your Forms. Another example is the use of ContextMenu.

If you have certain common items in a context menu like: Copy, Cut and Past

then you should keep them for each, relevant control, and in the same order.



The usage might be differing and the context menus might have extra specificitems for each control but the common need to stay, for consistency purpose.

It is also important to use the same font family and size and to keep similarWindow layout.

Always think about the end user

This rule could have, humouredly, putted like this: “Hmmm… someone will

actually going to use it some day”. Only there is nothing to laugh about.

This rule is dead serious. 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 use to

be developers) tend to forget about the end user skills.

They think about them self as the end users. In reality most of the end user skills

is much lower than those of the developer.

This rule is not easy to comply to because day after day on the designing and

developing table we get familiar with the defects and bad UI Design begins tomake sense.

It is crucial to detect the type of users that is going to work with the application.Mostly, the best practice is to aim to the lowest common ground and

apply advance and advance of advance capabilities in conceal. It would also begreat to allow each user to customize the UI according to his knowledge,

capabilities and expertise. This customization data must be stored in a persistentmedia 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 thefollowing main questions:

• Do the features and functionalities that I have yearned to have exists and workwell?

• Is it simple, intuitive and easy to use?

• Is it done fast in term of performance?

• Is it stable?

If the user answers those question with Yes answers then we are facing a happyuser that will use the application happily again an again.

Meet the user needs and he will praise your software else he will blameyou for all the miseries exists in the world.



The problem is when there are various types of users with different expectations.In one of the projects that I have participate in, I have notice something very

interesting about the use of UI. The application UI exposes the same functionalityin 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 companyused one of option accordingly. Using this approach makes different type of users

happy.

Another practice that helps to think about the end users during the designing and

developing process is to meet them on regular basis and to gather feedbacks inpre

marketing stages. You should also run surveys between the customers after thebuying or examination processes. Asking for the users for their involvements willteach

them that you are committed to quality and cause them to be much more patient

and cooperative in regards to bugs.

Keep it clean and don’t over estimate users capabilities

Design good UI application is not about thinking how to make a Toolbar but, whatshould be the type of it: Should it be Dockable or not? What to put in it? Does itrequired?

User might ask the following question when working with your application: How to

do it? Where to do it? When to do it?

Make sure that the questions can be answered by the user within short period of

time. As shortest the learning curve is the happier the users are.

• Avoid overwhelmed messages and dialogs controls which requires the user tomake a decisions. At least you should make it as clear as it can be. Users justhate to

read those messages like: “…yada yada ….happened…..” and then after few

frightening lines of this story it requires to answer a question like: “…Do you wantto X?”

The user does not give a damn about this kind of messages so don't load himwith information. It is hard task to decide for your users what they should decideabout

and what not. There is a thin line between annoying and upset them for notletting them know about stuff.

Example 3:



In the above example you can see extensive use of words in Winzip. When yousee this message you are saying to your self “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 aboutthe initials: RTFM (Read The Fucking Manual). It is a crying shame but it is true,users

don’t read it or at least they will do almost everything to avoid it. The moremoney the application cost the more chances that the users will use the manual.

For example, if the application is free and the user does not get along with it, hemight just uninstall it.

The above fact does not mean you can avoid of writing a manual; the customerstill demands it. What you can do, is to make the UI clean, clear and simple towork with.

• Do not make an assumption that the end user is intelligent enough to notcustomizing the UI background to black because this is the color of the font orbecause

it will look ugly.

I am using Murphy’s main law to say that if the application UI allows the user toshoot is leg then he will probably manage to do so. Make sure to protect theapplication

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 an explanatory. Create rich log to send to thecustomer

support instead. Be sure you clear the horror messages like “…Fatal problem…” or “…we should not arrive to this code…” before you ship the application.



Make sure the application stand tall in any circumstances. Catch all the error anddisplay friendly messages only.

• Do not ask what the user can do in order to work better with your applicationand 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 theusers 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 toread the latest news on the web. Of course, I am talking about you.

You are and 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 can be.

Customizability

There is no such thing as exaggeration in customization capabilities. I have never

heard anyone complains about an application that there are too many

configuration options. They might be angry only if those options are not orderedwell. This rule is important for the following reasons: The amount of configuration

options is stand in direct line with the ease of tailoring the application for specificcustomer; a job which is usually contains pain to the Customer/Project teammembers.

The extent of customization options, allows users from different level of expertiseto adapt the application to their needs. The user customizations data should

be, of course, saved for future application runs.

Good customizable application enables the use of it for user with disabilities. Forexample 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 the Toolbar icons you don’t take theusers with max 16 bit color screen into consideration. Another example is thescreen size.

This kind of consideration, if left unhandled, can cause your application to lookpoor.



Take the user machine into consideration

Good UI which complies with all the above rules help firms to sale products.

Sometime a competitive company steals business opertunities from your

company, simply because their UI is better looking. It shines, sparks and makesgood impression. It dose not matter if your application have much richer

functionalities. If it looks ‘low tech’ then there is ‘no take’.

The article describes only a drop in the oeacens of UI tips and rules. There aremany other. I encourge you to read and learn about this topic it is the

only way to write better UI applicaitons.

Bibliography

• User Interface Design For Programmers By Joel Spolsky October 24,

2001

• The Essential Guide to User Interface Design by Wilbert O. Galitz,

2002

• User-Centered Design Principles, MSDN

• Understanding Users, MSDN

• Design Specifications and Guidelines, MSDN

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch02b.asp


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/part3.asp



http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/part3.asp

Documents

Thoughts About UI Design