You Are Here:

General usability tips

Register Today

Register with Forum Nokia now and you'll enjoy the full benefits of the Forum Nokia membership.

Register Login
Community Highlights

Wiki article of the week

Zoom and Rotate Gestures in FlashLite for touch-enabled devices

Champion of the month

Jackson Feijó Jackson Feijó
Read more about Jackson on the Champions website.


Forum Nokia Events

Nokia Developer Days in South Africa
December 01, 2009
Johannesburg, South Africa

Forum Nokia Developer Conference ’09, India
December 07, 2009
Bangalore, India

LeWeb
December 09, 2009
Paris

Web Runtime Coding With Aptana WRT Plug-in
December 09, 2009
9am New York | 2pm London | 4pm Helsinki

Web Runtime Coding With Aptana WRT Plug-in
December 09, 2009
9:30am New Delhi, noon Beijing


View all
Group your user interface elements
If you have a lot of elements in your UI, create logical groups from them. Also consider hiding the less used controls if the UI still seems cluttered.

  Do not rely on one sense
User can be in a place where he cannot hear or see or feel the device, or he may be impaired. Combine visual, audio and tactile feedback. This way user is most likely to notice what you’re trying to tell him.

Keep it simple
If your product needs a manual to use it, it's probably too complicated. Most users will not read the manual if they cannot solve the issue. Instead they are more likely to abandon the application entirely.

  Follow the UI style guide – it makes your life easier
  • Using standard components eases compatibility issues backwards and also towards future versions
  • Consistency is one of the key factors affecting usability -> allow user to learn one way of doing things and then apply the way to different cases as well
Test all designs at a very early phase with both your colleagues and target users of the application.
  • To test the language used
  • To test the task flow
  • To get immediate feedback from end users before it is too late
  Allow customization but don’t force it
Users generally appreciate the possibility of customization, but there are a lot of users who could care less about customizing and forcing will just annoy them.

Allow toggling between alternatives
if there are 2 options in a radio-button selection.

  Forms are forms – settings are settings
Avoid opening things to new views as forms should be editable within the view – settings on the other hand may require entering a new view for more complex controls like sliders.

Hide rarely used features in Options menu
Before doing that – make sure they are rarely used by most users!
  Make sure user fills needed information
  • Mark mandatory fields with a star or, alternatively, change the right softkey label to "Done" only after the mandatory fields have been filled.
  • Only mark those fields mandatory that are mandatory for user to define – for others provide suitable default values in case they need to be defined to make things work.
Provide default values
Users often do not have an idea what the setting item or value in a field should be.

  Avoid long forms
Even if form items are not mandatory, many users put time into filling the fields just because they are there – not because they need to.

Be careful with colors, especially red
Colors have culture-dependent meanings, as do icons and graphics. The color red, for example, may be used to represent a warning or an error message, but in another culture it may be used to promote a positive experience.
  Study your target users
Product design must understand who the target users are and what their culture is like right from the start.

Focus the user tests on the most relevant product versions
Don't neglect user studies, even though a vast number of different application versions may make user testing a challenge. On the contrary, more attention should be paid to user studies than in traditional software development.
  Ground rules to make your application usable
Don't be blinded by your own expertise.
Don't use your friends for testing - they are easily affected by your presence or opinions.
Do ask for the user's input.

Know the users and design for them
Having key features clearly visible and working properly is better than having too many technical functions.
  Take users into account in every phase of the application development process
Success in developing usable products requires that usability be designed into the product right from the start.

Make porting easier, don't hardcode the user interface
Porting an application from one device platform to another can be quite challenging. To make it easier, remember the following:
  • The application needs to be designed to be portable right from the start - which is done by carefully separating the abstract functionality from the user interface implementation.
  • The application engine should be flexible, to allow new features to be added.
  • You need to redesign the user interface to fit the conventions of all supported platforms.
  • You need to consider localization issues such as different languages, cultures, and user groups.
  When porting an application, do it for the targeted users
Keep in mind that the goal of porting should be a satisfied user, not just a functioning application.

Porting an application successfully means porting the user experience too
  • Remember that not only are the devices different - the users of the devices are different too.
  • Focus on porting the user experience, instead of simply making the application run on a new platform.
  • When porting, be willing to drop, add, or redesign features if needed.
  • When porting, remember that it is preferable to conduct user tests with advanced users of target devices.


Rate This

Bookmark this page: DeliciousDiggFacebookGoogleYahooStumbleUponRedditDiigoTechnocratiTwitter  Share this page Share this page Print this Page Print this page Invite a friend Invite a friend
RDF Facets: qdcZidentifierQSxhttpE3aE2fE2fwwwE2eforumE2enokiaE2ecomE2fTechnologyE5fTopicsE2fE44esignE5fandE5fUserE5fE45E78perienceE2fUserE5fE45E78perienceE2fUsabilityE5fTipsE2fGeneralE5fusabilityE5ftipsE2eE78htmlX qfnZupdatedQDx2009E2d10E2d05X qdcZtypeQUqfnZE45E78cludedFromGeneralE4CistingsQ qdcZtypeQUqwebZE52esourceQ qdcZtypeQUqwebZInformationE52esourceQ qdcZtypeQUqwebZPageQ qdcZtypeQUqfnTypeZE52esourceQ qdcZtypeQUqfnTypeZWebpageQ qdcZtypeQUqmarsZManagedE52esourceQ qdcZtypeQUqrdfsZE52esourceQ qfnZdistributionQUxhttpE3AE2FE2FforumE2EnokiaE2EcomE2FX qfnZtypeQUqfnTypeZE52esourceQ qfnZtypeQUqfnTypeZWebpageQ qmarsZlanguageQUxhttpE3AE2FE2FswE2EnokiaE2EcomE2FlanguageE2D1E2FenX qrdfZtypeQUqwebZInformationE52esourceQ qrdfZtypeQUqwebZE52esourceQ qrdfZtypeQUqwebZPageQ qrdfZtypeQUqfnTypeZE52esourceQ qrdfZtypeQUqmarsZManagedE52esourceQ qrdfZtypeQUqfnTypeZWebpageQ qrdfZtypeQUqrdfsZE52esourceQ qrdfZtypeQUqfnZE45E78cludedFromGeneralE4CistingsQ