User Modelling Teppo Räisänen

General Information For achieving high degree of usability the target user must be analyzed There are plenty of techniques available for user modelling The least one can do is to visit users work environment and gather information

General Information When user is well known, it is possible to tailor UI according to users needs In practice, however, perfect modelling of user is impossible Often modelling is also difficult and costly It is still well advised to model user

General Information In the next part some of modelling techniques available are presented Techniques presented are lightweighted and should be easily adadpted It should be noted, that techniques are based on different worlds of ideas and may seem contradictory

Who Is the User? The one who is using the application? Actually, also many interest groups E.g. flight booking application Personnel of airport Flight personnel Customers attending to flights Customers’ families (?)

Who Is the User? CUSTOM: 3 user types Primary user uses the application Secondary user does not use the application, but gets feedback from the system Tertiary users are other interest groups, to which the system’s activity/inactivity has an effect

Who Is the User? E.g. ADP support application Users call/visit ADP support Member of support staff enters notice of defect into system Member of tehnicians recieves the notice trough system Member of tehnicians repairs the faulty computer Who is the user? How would you improve the system?

All Users Can Not Be Pleased Traditionally products have been designed so, that a product is good enough for all of the target users The most difficult cases are mass products It should often be considered, if a limited user group whould be better choice than designing for masses

All Users Can Not Be Pleased Mass customization is commonly utilized among other fields of industry E.g. car production The same components are used in sports cars and vans Specialized products are designed for different kinds of user groups

All Users Can Not Be Pleased MCV (Model Controller View) Enables use of the same application engine Different UIs for different needs Used in Java GUI technology and Symbian applications The goal is that applications, not users, must be flexible

User Personalites Traditionally users were defined using roles It is argued, that use of blurred roles leads into, at its best, medicore applications instead, accurate user profiles should be used

User Personalites Example of user profile John Smith 29 years old Computer technician, system analys Hobbies: travelling, roller-skating Lives in high-rise building Very conscious of products’ quality

User Personalites When profiles are used, the designers don’t have to think of groups Instead a designer can ask, if the person would, for example, be able to commit a spesific task User profiles are not actual but imaginary persons Actual persons can even have ’multiple personalities’’multiple personalities’

Etnographic Research The goal is to investigate foreign cultures Researchers live among the people of target culture Everyday life of target people is observed

Etnographic Research E.R. is seldom used in actual product development Instead it can be used to, for example, gather information about ways of users’ interacting The downside of E.R. is that it is costly and time-consuming

USTM/CUSTOM USTM = Matching User’s Skill and Task The goal is to thoroughly understand and to be able to document user’s requirements CUSTOM is a lighter USTM-based technique aimed for small organizations’ systems

USTM/CUSTOM CUSTOM divides users into three categories (see slide #6) In addition to the users systems have faciliating persons, who are responsible of designing and maintaining systems CUSTOM is based on 6 steps, which include questions to be answered

USTM/CUSTOM 1. Describe products use context and context organization’s goals and values 2. Recognize and describe interested parties. Locate them under one of the four user categories

USTM/CUSTOM 3. Recognize and describe groups of workers + their positions in the organization 4. Recognize and describe tasks and objects Tasks are things that need to be done Objects are either means or targets of tasks

USTM/CUSTOM 5. Recognize the needs of interested parties Desribe things described during steps 2 – 4, when Existing system is used New system would be used Needs are described as differences between existing and new version of system

USTM/CUSTOM 6. Prepare a summary of the requirements. Compare the summary against earlier defined requirements

Use Cases takes a narrow view compared to aforementioned techniques is a lightweight cost-effective technique Knowledge of system’s context might not be as complete as with using heavier methods Use cases are individual tasks leading to the completion of a spesific goal

Use Cases E.g. sending a SMS message could be a single use case Use cases can be divided into substeps UML notification is often used, but also textual descriptions are possible Use cases can be prioritized, e.g. emergency call over SMS messages

Conclusion There does not exist an universal method suitable for all situations Plenty of other methods in addition to those described here are available Traditional methods are still widely used, but especially use cases are becoming more utilzed