user modelling teppo räisänen teraisan/ [email protected]
TRANSCRIPT
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’
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