This section lists only the basic requirements for usability testing. For more thorough instructions on planning good usability, see the documents on Forum Nokia, for example:
Good usability is the basis for a good application and a pleasant user experience. If the application’s usability is poor, some users might stop using it. To ensure user satisfaction, you should arrange separate usability tests and start testing the application already in the early phases of application development. It is easier to fix possible usability problems in these earlier stages.
For a positive user experience, it is important that all main functionalities of the application can be accessed easily through the main menu. Ensure that each functionality works properly as described in the application documentation and the Instructions section and that there are no hidden functionalities.
Check also that the terminology is correct and that there are no grammatical mistakes. Do not use difficult terminology or abbreviations.
Make sure that the application gives enough feedback to the user. Typically users do not wait for more than a couple of seconds if the display does not change and seems jammed after they have selected a function. In addition, if the application repeatedly shows certain notifications or questions to the user, it must be possible to turn those off.
Any selection of a different function in the application should be performed within five seconds. There must be a visual indication within one second that the function will be performed. The visual indication can be, for example, prompting for user input, using splash screens or progress bars, or displaying text such as "Please wait..." or "Sending message…". These indications can be enhanced with sounds. Consideration is possible for applications that are subject to Digital Rights Management or other types of verification in the start up. In these cases, the waiting time can be longer.
Check that:
All main functions of the application can easily be accessed through the main menu.
Each functionality works as described in the documentation and in the application’s Instructions section.
Terminology and grammar are correct and no abbreviations are used.
Each screen appears for the length of time that is necessary to read its information.
The consistency of the following features is maintained throughout the application: terms, layout, colors (or reverted colors), softkey labels, vibra, and sounds.
The application gives enough feedback to the user.
Repeated user prompts can be turned off.
Check that menu structures are grouped logically and not too deep. A wide menu hierarchy is preferred over a deep one. The user must not get lost in the menus. Ensure that the Back button is always at hand, on the right softkey. Closing the application must be easy as well.
The order of the items in the menus must be well defined. It is advisable to arrange items by frequency of use, that is, the most frequently used item should be at the top of the menu, and the Exit item should be the last item, at the bottom. In S60 devices, until S60 Platform 2nd Edition Feature Pack 3, the Exit item is automatically on the Options list of the left softkey. Note that this does not happen with Series 40 platforms.
All menu items must be shown as selectable items, and the labels of the items must be descriptive. The user must easily see which screen items can be selected and/or changed, especially if low-level UI components are used as menus. Selectivity is not a problem if high-level UI menu components are used because they are similar to the system menus.
If the application requires completing multiphased forms, the current screen number as well as the total number of the screens must be indicated to the user in, for example, the following format: Page 3/5. The last screen in the form must give the user some informative feedback, for example, a Thank You screen after pressing the Submit button.
Add Help to the main menu of the application. Help must be useful and complete and include at least the purpose of the application, rules, and use of the keys.
The application also needs to contain an About screen that gives information about the developer and other generic information about the application. The About screen should contain developer name, application name and application version number. These values should be the same as defined in the JAD file.
Check that:
Sequences of actions are grouped logically.
Menus are grouped logically and menu structures are not too deep.
The Back or Exit button is always available on the right softkey.
The order of the menu is logical.
Menu items are marked clearly.
The application has a Help section.
Information about the developer and the application is given in an About section.
It is possible to Exit the application from the main menu.
The order of commands and the softkey to which they are assigned depend on the following:
Command type
Command priority
The order in which the commands were added to the UI component
For more information about command mappings and command labels in S60 devices, see S60 Developer Platform 2.0: Specification.
In S60 devices, all UI components, except for the Nokia UI API’s FullCanvas class,
include an Exit or Close command by default. Be careful that UI components
do not end up with two Exit commands, for example if you have added one yourself. Note that these commands are
not automatically added in Series 40 devices.
Check that:
Softkey labels reflect the style of the user interface of the particular Developer Platform.
The label related to the right softkey refers to Back, Quit, Exit, Cancel, Clear, or other “negative/backward functions.”
Ensure that each sound (if sounds are used) in the application is distinctive and has a well-defined meaning. For example, a happy sound should be used for a positive action and a sad sound for a negative action.
Be sure that the current status of the possible sound settings does not affect the playability of the application (for example, whether or not the sound is activated).
All in all, you should be careful when adding sounds because too much sound may make the use of the application annoying. Therefore, add sounds only to places and situations where they give more information or an extra experience for the user. Be sure that sounds can be turned off easily.
Check that:
Each sound has a distinctive meaning.
Sound settings do not affect the playability of the application.
Sounds are not overused in the application.
Sounds can be set on/off in the application and setting is saved on exit.
The backlights and vibra functionalities are supported via the MIDP 2.0 APIs.
The vibra functionality can be used to give extra feedback to the user. Note that it is a wearing functionality, so it should be used only in special circumstances and less frequently than sounds. There should an easy way to set vibra on/off and the setting is saved on exit.
Backlights should always be on if the application is actively used without user interaction (there have been no key presses to keep the backlights automatically on). However, backlights consume quite a lot of battery power, so there should be a setting that allows them to be turned off.
Check that:
Vibra is not used too often.
Vibra can be set on/off.
The user can turn backlights off.
It is advisable to have user settings for the application, for example, settings for sounds. Regardless of the settings it is important that all settings and selections can be cancelled or restored. Also, make sure that the current status of each setting has a clear meaning and that the user can easily understand what changes will occur if a setting is changed. Note that settings must be saved when the application is closed.
Check that:
The user can cancel and/or restore settings and selections.
The current status of each setting is clear.
Settings are saved when the application is closed.
The content in all different views in the application must be available in the application’s target language. It means that e.g. Main menu, Help and About are localized. Text should not contain any spelling errors and it should be clear and readable (e.g. no overlapping or text cut off).
The date format must be handled according to the target country. Verify that date, time, time zone, week start, numeric separators, and currency are formatted according to the conventions of the target country of the implemented language and supported throughout the application.
Data entry fields must accept and properly display national alphabets, for example, ä, ü, and ß. If possible, test that all data entry fields accept and properly display all special character input.
Check that:
All text is available in the application’s target language.
There are no spelling errors and text is not overlapped or cut off.
The language conventions of the target country are followed.
National alphabets are accepted and displayed.
The following guidelines are especially concerned with game MIDlets. It is important that the general view of the game is clear and that the game gives enough feedback and immediately responds to the player.
The rule or function of each element in the game must be clear (for example, how the player and the enemies are represented, and how they interact).
The game must be paused automatically as described earlier (section Pausing a MIDlet) and it is also important that the player can pause the game by him/herself. When the game is paused it must be easily continued.
If the application is closed in the middle of the game, the game status and settings must be saved so that the game can be continued later.
Check that:
The general view and the rules and functions of the game are clear and described in the Instructions.
The game gives enough feedback to the player.
The user can pause and continue the game and the status is saved.
The current status of the settings does not affect the playability of the game (for example, whether or not the sound is on).