Usability comes from the word ‘user’ which simply put would mean ‘the ease of use’ for the end user, or in another words ability of the user to employ/interact with the given system/product at hand. See the obvious emphasis on the word user in the earlier sentence to understand how important s/he is to the end result of the product. The offering is as good as the user perceives it to be and not as good as the development/marketing team emphasise it to be. Only if the buyer of the product is able to take full advantage of the application without much hassle and with relative ease and comfort does a product pass the ultimate marketability and usability test.
With technology evolving everyday allowing for more complex systems to be created and the market space for every product being saturated quickly faster, usability becomes even more important. The user is neither bothered about the implementation complexities nor does s/he have the patience to learn how to use the product. They want to be able to use the product immediately and they also want it to respond to their requests immediately, a slow/complex system is often deemed as an unusable/unreliable solution. The essence of a user-friendly application is the efficiency of the system, ease of use from an end user’s perspective and the final satisfaction that the user derives from using the system/product.
Here is a list of general usability issues to keep in mind.
Colors have been an integral part of our lives and over the years we have formed strong opinions about different colors where each of them immediately evokes a certain kind of response/feeling.
Some common colors and their connotations are as follows:-
Most of the colors have their own connotations and meanings given the cultural backdrop and hence you should do a careful analysis of the intended market before using a particular color.
This has to be easily the most important component which drives the usability design process. Without understanding the target users no user friendly product can be developed. The skill sets/capabilities/expectations/usage pattern of the target audiences goes a long way in designing a user interface which is both efficient and easy to use. The first two would help you in understanding how much input/information you should seek from the user in your application and how much of it should be programmed to avoid inconvenience to the user. For instance lot of times the user might not be conversant with the complexities of the internal implementation details like VPN gateway settings, enable/disable of settings etc. While the latter two would help in understanding how to implement the outputs of a particular request and in also writing the help manual/documents.
A nice way to capture the target user’s expectations would be to have one on one with some prospective users, people not in the know how of the development/design process. Sometimes a survey/questionnaire mode to gather datapoints could also be a good idea.
While writing usability test cases, you should always consider the product offerings and the features that are going to go out in the current release version. More emphasis should be placed on testing the features that you percieve the user to be using the most, as those are the bread and butter of the application so to speak. Also the user would want atleast those basic features to be easy and reliable to use. For instance in a dialer application the user would at best expect to dial/receive/hangup calls, even if at times it doesn’t let you edit/delete a number from the dialpad etc. So while writing the test cases you should drill down those functionalities more with more usual/alternate/exceptional flow cases.
Ground rules to make your application usable, do not be fooled/blinded by your own expertise in the development/implementation phase. The end user does/need not know the internal details of the product, all they care for is the ease with which they can use the features developed by you. If the user interface is cumbersome and complicated to understand likely chances are that the user won’t use it too often. As they always say “first impression is the last impression” if the user sees a cluttered home view, with complicated navigation/menu layout etc they would be very irritated with the product and more often then not they wont even bother to check the durability and robustness of the solution.
Another golden adage that holds true is ”looks can be deceptive” and sometimes a product with good look and feel ends up attracting more sales and user satisfaction as compared to another application with lousy UI but strong features. So always ensure that you design keeping in mind the end user sensibilities and requirements. While testing the user experience don’t use your friends for testing, because their opinions/feedback could be colored as they might not want to offend you by passing negative comments about your own. Always ask the end user’s input, they are the best judge of your application’s layout and usability.
Always design for the users and not for yourself. The user is the one who is going to spend his precious dollars in buying your product and they always want the best value for money. How often have you come across a product with bad interface selling well, a well packaged product sells better then a lousy one.
Users are the single most important component of the entire value system from your point of view. If the product doesn’t sell and the company doesn’t make money they wouldn’t be in business which in turn could mean not so good news for you. So always involve and keep in mind the sensibilities and expectations of the user. It would be better if not best to involve an end user in every phase of the development process as they would give you constructive comments which could prove benificial in designing an interface that is usable from their stand point.
While designing/architecting the solution keep in mind the various form factors/specifications and other visual parameters of the devices you are targetting the solution for. This would help in ensuring that while porting from one device family to the other the efforts are minimal. Use a disjoined architecture like MVC which separates the business logic from the UI as much as possible so that the back end code can remain the same while porting and only the UI needs to be customized. It is never a good idea to hardcode the co-ordinates/location etc which drawing/creating the UI as the same co-ordinates wont fit in for all devices.
Porting is nothing but customizing the solution so that it works on the targetted platform/device/language etc. The end user does not know what/how you have created the solution i.e. whether you had first written it for S60 and now you have just changed it for S40 or whatever, for them it’s a new solution for which they have paid money and they want it to work reliably and have a relative ease of use. So don’t think that since you are just porting a solution you can not think about the end user experience, the basics still remain the same even in this case.
From the main view only the core functionality of the application should be available. The navigation model should put more focus on the main tasks hiding the complex and advanced functionality from the beginners.
Make sure that providing input is easy for the users. Application should not be expecting large input from the users, instead of text prefer the other forms of entry like selecting from a list. Also minimize the number of clicks, use default values while taking inputs etc.
At any point of time users should not have a confusion on how to proceed, where to click now. Provide the context sensitive help, and a user guide.
---- Edited by Mayank on 11/06/2009 ----
No related wiki articles found