User involvement and use modeling is a key success factor for systems at both proposal stage and those undergoing on-going development. A major challenge however for any system of moderate size is that the active involvement of all users is quite simply infeasible. Productive user involvement is difficult to attain at any stage in the development life cycle. A practical enabling strategy is to choose a subset of users and involve them in the process. Another strategy is to model both archetypical and atypical users, using "personas". Model users termed personas are used to construct and direct the development effort (Cooper et al., 2007).
Model users called 'personas'. They are used to construct a cast of synthetic characters complete with values, personal histories, needs and goals. Personas are not average demographic 'types', they are individual characters whose biographical detail allows designers to 'imagine' the persona's individual aspirations, choices and behaviour as realistic, plausible, meaningful. It is simply another way for designers to generate empathy with their users. It enables them to build up a cast of characters, socialised and known among the design team, in order to focus the team's design attention, to enable and contain design ideation, development action, testing, user acceptance, etc.
A persona is employed as a shared sense making device, a fictional 'identity' or a character who is imagined in putative roles wherein some future version of the product is employed. These design strategies occupy the conceptual boundary between the design-world and the use-world. Each persona can be used to...
“Develop a precise description of our user and what he wishes to accomplish.” (Cooper, 2004)
“Personas are not real people, but they are based on the behaviours and motivations of real people we have observed and represent them throughout the design process. They are composite archetypes based on behavioural data gathered from the many actual users encountered in ethnographic interviews.” (Cooper et al., 2007)By modelling users, through personas and goals, systems developers establish a conceptual instrument for judging the validity and quality of the system and its detailed use-behaviour. Each persona (many may be constructed) has something to say about the system, its requirements and on-going evaluation. A persona may even be produced to explore non-use of the system.
The idea of a persona as an instrument and method has broad application and impacts the whole systems development lifecycle. In particular good use of a persona ensures that goal, feature, and functionality decisions will moderate and balance design decisions driven by the technology itself. Technology (or technologist) driven ‘user’ design decisions fall into three categories: the elastic user, self-referential design, and edge cases. All three categories distort the decision making process in favour of systems development rather than actual users. The creation and use of goal directed personas goes some way to overcoming the in-built biases of the development process.
Human-Centred Learning Techniques
IDEO’s ‘Learn’ cards suggest human-centred techniques and methods to analyze, interpret, present and judge the information gathered from ethnographic and other interpretive field studies. These methods and tools may also be applied to some kinds of quantitative data gathering.
Table: IDEO 'Learn' techniques (IDEO, 2003)
LEARN
| Research Method | Description |
|---|---|
| Activity Analysis | A description of project relevant dynamics: actions, interactions, tasks, and objects of achieving goals. |
| Affinity Diagrams | Represent or diagram clustering of design elements with activities, goals, obstacles. Proximity, dependence and relationships |
| Anthropometric Analysis | Human factors or ergonomics to assess project relevant use factors. |
| Character Profiles | Personas. Archetypes of real people with real goals, lifestyle, behaviour, identities. |
| Cognitive Task Analysis | List, summary of all available sensory inputs decision points and actions. |
| Competitive Product Survey | Collect, compare, and conduct evaluations of extant and competitive products. |
| Cross-Cultural Comparisons | Personal accounts of differences in situations, behaviour and artefacts in different national or cultural settings. |
| Error Analysis | Capturing the things that actually go wrong in the project relevant setting. |
| Flow Analysis | The flow of information in existing and/or new system. |
| Historical Analysis | Identify trends and cycles of product use, customer behaviour, market, and practice. Relate to timeless goals |
| Long-Range Forecasts | Narratives of future scenarios complete with social and technological trends to predict behaviours. |
| Secondary Research | Summary analysis of existing sources and 3rd party data on project relevant areas. |
A cast of personas can be gradually built up during the process of field study and gathering requirements. Afterwards as the data is analyzed and interpreted we construct personas that appear relevant to the project context. The cast of personas grows initially but will gradually be whittled down as duplicates and distinctive behaviour patterns are identified. Cooper et al. (2007) suggest differentiating user personas based on their different goals (motivations) and their behavioural attributes (Table below).
Table: Identify behavioural variables (Cooper et al. 2007)
Identify behavioural variables (Cooper et al. 2007)
| Behavioural variable | Description |
|---|---|
| Activities | What the user does; frequency and volume. |
| Attitudes | How the user thinks about the product domain and technology. |
| Aptitudes | What education and training the user has; capability to learn. |
| Motivationss | Why the user is engaged in the product domain. |
| Skills | User capabilities related to the product domain and technology.. |
Cooper provides an example of how personas become part of the evaluation and decision making process of system design. The following discussion between the product owner (interaction designer) and the programmer deals with a persona named ‘Rosemary.’
Programmer: “What if the user wants to print this out?”
Interaction designer: “Rosemary isn’t interested in printing things out.”
Programmer: “But someone might want to print it.”
Interaction designer: “But we are designing for Rosemary, not for ‘someone.’”
(Cooper et al., 2007)
EXAMPLES: The following examples are from a number of personas developed for a project to develop a training product for a Telco billing system.
Telco systems administrator persona
Persona – Dave Taurus: Network Engineer
Industry Mobile Operator, Telco
Description
Network engineer - five years experience with Ericsson AXE and IN platforms
Responsible for configuration and maintenance of network elements
Switch database maintenance
Switch database interface guru
Hardware focused, resents the IT guys who are always sticking their noses in his switch database.
Skills
C, Sybase
Goals
1. Ensure 100% switch uptime.
2. Avoid anything that interferes with 1.
Tasks
Interface with switch manufacturer
Interface with internal business development people
Provide switch data definitions to the business/IT people
Provide access to switch data (FTP, file dumps)
Rollout new services
Occasional manual provisioning. Troubleshooting of provisioning problems.
Does not use any operational aspect of EPlus.
Will need to review event collection docs to check data transfer etc.
Telco billing consultant persona
Persona – Stephanie Billings: Background
Stephanie is 26, single and an occasional (when not travelling for work) member of the company soccer team. A bit of a lad when it comes to 'football', she's a die-hard ‘Latics’ supporter since the age of 6 when her dad started bringing her to matches. Doesn't give a toss for the Premier league - or won't until Oldham claw there way from 2nd division to 1st division to Premier...
Stephanie works as a consultant Java programmer for Accenture and is based in the Redding office. She calls the projects she works on 'gigs' and has a long list of humorous project disaster stories (though no companies are ever identified directly).
As a contractor all of Stephanie's time is accounted for, she has a personal revenue target and charges in detail down to the minute for every project she works on (even if she's back in the office doing internal stuff and not on a gig). She is a competent hardworking professional but is NOT interested in doing massive overtime (overtime is charged at time and a half, weekend work is double time).
She uses the Incode time tracker from OYOY on her Nokia 9210 Communicator to keep track of what she's doing and for billing clients.
Stef (as she is known to her friends) is passionate about JAVA and J2EE, considers herself a pretty hot JAVA programmer, highlight of her professional career to date was doing a joint presentation with Kari Kukkoaho (head of development, operations support at Nokia Networks OY) JAVAONE in San Francisco last year on OSS JAVA 3G Business Models for 3G Wireless Network. Has some product ideas about embedded JAVA and MIDP and might go off and do something about them some day.
GoalsStefanie was 'volunteered' to attend a 4 day programmer training course in the Dublin office to become a ‘certified mobile billing consultant’ because Accenture is getting primed for a project for client side implementation and integration of the EPlus billing service for a ‘major’ finance house in London.
Stefanie needs to fully understand any technology she is working on, expects all training to be an intense burst of information overload and will do a huge amount of preparation prior to the training, so wants access to all the information NOW (e.g. would like it presented like the JAVA Training Trails).
She wants to be perceived as the expert – has nightmares about not being able to answer a question, and in turn expects to be able to find answers quickly.
Training needs
Personalize training needs, expressed by questions like:
“where do I start?”
“how do I...?”
“where do I find...?”
“what do I do when...?”
“my work integrates with the rest of the team by...”
REFERENCES
