"Child-Personas: Fact or Fiction?" by Alissa N. Antle and
"Personas: From Theory to Practices" by Chang, Lim, & Stolterman
The Origin of Personas
Alan Cooper "The Inmates are Running the Asylum"
- Personal Goal: "Develop a precise description of our user and what he wishes to accomplish"
- User is a resource, but won't know solutions!
- 'Make up pretend users and design for them"
- Failure = design for broad, abstract groups
- Success = design for a single (archetype) user
- Description of a specific, fictitious person
- Written in the form of a narrative
- Represents gathered info about a group of users with common characteristics (single users too quirky!)
- Usually given both a name and a face
- May contain personal information
- Family members, friends, occupations, possessions
- Makes the persona more 'real'
- Focuses on the goals, needs, and frustration of the persona when using the product being designed
- 3 to 7 personas usually created for a project
- Some advocate using one primary persona
- "Pretend" but not "made up"
- Based on data with users
- interviews
- Ideally completed face to face
- Observations
- try to do this in the environment where program will be used
- ask for comments from users - "What frustrated you?"
- Presented as a story about a believable person
- Project team should refer to the persona by name
- Stop talking about abstract 'users'!
- Focused on enabling effective design decisions
- Should explicitly define the needs, goals, and frustrations of the persona
- Designers should be able to infer what features are needed and how they should be designed
James is 52 years old and works as a mechanic with an organization offering road service to customers when their car breaks down. He has worked in the job for the past 12 years and knows it well. Many of the younger mechanics ask James for advice when they meet up in the depot as he always knows the answer to tricky mechanical problems. James likes sharing his knowledge with the younger guys, as it makes him feel a valued part of the team. James works rolling day and night shifts and spends his shifts attending breakdowns and lockouts (when customers lock their keys in the car). About 20% of the jobs he attends are complex and he occasionally needs to refer to his standard issue manuals. James tries to avoid using the manuals in front of customers as he thinks it gives the impression he doesn’t know what he’s doing.
James has seen many changes over the years with the company and has tried his best to move with the times. James has been told that his van will soon be equipped with a new computer system that will allow him to access job information and records, in addition to browsing the company’s website. He wonders if he will be able to find out what’s going on in the company more easily, especially as customers’ seem to know more about the latest company news than he does when he turns up at a job. This can be embarrassing and has been a source of frustration for James throughout his time with the company. James wonders if he will be able to cope with the new computer system. He doesn’t mind asking his grandchildren for help when he wants to send an email to his brother overseas, but asking the guys at work for help is another story.
- Assisting communication
- Easier to talk about 'James' and his needs
- User is too abstract -> doesn't drive decisions
- Informs design decisions
- What does james need to do with the new system?
- How do you meet James' goals?
- How do you resolve James' frustrations?
- Supports design evaluation
- Where will you trip up James?
- Will he know what to do? How to interact with the system?
- Will he even use the system?
- Bad personas won't help you and can be misleading
- Some consider them too 'artsy' (developers tend to fight against it)
- User interviews can be costly
- Recruiting users
- Conducting interviews
- Transcribing protocols
- Time to analyze data, extract themes
- Some estimates: $47,000 for commercial apps
- Interview potential users. Take good notes
- Identify key observations ("factoids")
- 10-12 per interviewee is typical
- Sort individuals into groups based on observations
- Expert vs novice users
- motivational vs apathetic
- like technology vs. uncomfortable with it
- Cluster key observations from multiple interviewees
- Look for patterns/themes
- what are their common needs
- do they have common lifestyle
- given the use of my system, key themes should relate to what the use of my system is
- (if visual learners doesn't apply to your system, that shouldn't be a commonality)
- Typically, 3-4 characteristics from each person are relevant to the group
- Look for common goals
- Look for common frustrations
- Look for common perspectives, approaches
- Technophile vs. Technophobe?
- How do users interact with existing technology?
- Do they take shortcuts?
- Frustrations? How quickly do they opt-out?
- Do they know how they use things? (people think they know and they really don't)
- Due next week (Feb. 4)
- May work in teams
- May use Capstone project as application
- this is encouraged if it can work
- Identify application/website
- Create & conduct 2+ interviews
- Analyze interviews
- Create persona
No comments:
Post a Comment