designing with only four people in mind? - a case study of using personas to redesign a...

Centre for HCI Design

Designing with Only Four People in

Mind?

A Case Study of Using Personas to Redesign a Work-Integrated Learning Support System

Amir Dotan, Neil Maiden, Valentina Lichtner

and Lola Germanovich


The Paper

1. A case study illustrating how personas were used in a real world situation to engage project members with user information during a 2-day workshop to redesign APOSDLE (3rd Prototype)

2. The strengths and weaknesses of personas based on our experience

3. The strengths and weaknesses of actively involving stakeholders in creating and using personas


The APOSDLE project www.aposdle.tugraz.at

• Advanced Process- Oriented Self- Directed Learning Environment

• A 48 months R&D integrated project involving 12 organisations from five countries (contract no. IST-027023)

• Aims to support work-integrated learning by providing people working in knowledge-intensive industries the infrastructure needed to acquire, understand and communicate knowledge

Refine resources here

Resources

Learning by doing: Typewriter Requirement Analysis 1 Evaluation Document X

Resources

Learning Events

Expand results

Day 1

C++ in 4 Days

Example of Analysis

How to evaluate

Day 2

Robin Hood Alka Selza Steve Martin Kartoffelpü Reh

Knowledgeable Persons

Refine experts here

PersonsExpand results

APOSDLE Prototype 2

Personalised

(competencies)

and contextual

(activities)

learning support


Why Did We Turn to Personas?

1. A work-based formative evaluation of the 2nd prototype highlighted various usability problems such as:

• Ambiguous terminology (e.g. Learning Events, Knowledge Artefacts, Learning Goals, Context)

• Unclear interaction and processes - (Where to begin? What to do? Where is ‘search’?)

• Individual differences (e.g. The Learning Events did not always fit the users’ needs and objectives)



2. International Multi-Disciplinary Consortium

3. Varying views, perceptions and understanding of APOSDLE’s target audience – Lack of common language to describe end users



4. Information about end users was provided in the early requirements stage by stakeholders representing future clients and empirical studies, but was not visible throughout the project

5. Referring to users as Knowledge Workers, Knowledge Seekers and Knowledgeable Peopledid not provide essential rich information about the target audience and its work environment


Main Criticism of Personas (Chapman and Milham, 2006)

• Methodological weaknesses - Personas are difficult or impossible to verify – Are they realistic representation?

• Practical limitations - It is not always clear how the personas are reconciled with other data and who is responsible for interpreting them


Creating the APOSDLE Personas• Empirical data (interviews, observations)

• Stakeholders representing APOSDLE’s target clients contributing an initial set of personas describing their employees based on a template

• Reason 1 - Validation – Getting the right personas

• Reason 2 - Time constraints


The Four APOSDLE Personas

Rigid work process Flexible work process

Senior employee

Junior employee

Pierre - mechanical engineer Eva – consultant

Paul – Intern (Engineering) Lisa – Project assistant


Redesigning APOSDLE with Personas • 2 Day workshop

• 4 Personas

• 21 participants (None have ever used personas)

Stage 1 – Familiarisation session – Get to know the personas

Stage 2 – Review prototype 2 from the personas’ point of view and consider redesign

solutions if necessary

Paul (the intern) is probably

question driven and requires

detailed knowledge. He carries

out a single task at a time Pierre (the senior engineer) is

probably more set in his ways .

He deals with processes,

simulations and calculations

Persona Familiarisation SessionGeneral comments about each persona


Persona Familiarisation Session• How do the personas perceive APOSDLE Prototype 2?

• “What aspects of APOSDLE is Pierre more likely to appreciate?”

• “What aspects of APOSDLE is Pierre less likely to appreciate?”


Persona Familiarisation Session• Participants extrapolate new Information about the personas and APOSDLE

Eva will not use

APOSDLE’s process

view. Her work is less

about ‘ticking boxes’

Eva would appreciate

being able to locate

experts using

APOSDLE

Redesigning APOSDLETo better suit the needs of the personas

“Interesting idea. Who do you imagine using this feature?

Eva? Paul? Lisa? Pierre?”

“Is this a feature a 48 year old senior engineer

in your company might use?”

Addressing Practical Limitations of Personas

Stakeholders help interpret and use the personas


Rapid Persona-Driven Prototyping During

the Workshop

Viewing the domain

elements could help

Paul get an overview

and explore the

domain

Eva and Pierre

require quick and

unstructured access

to resources

“Will Paul like this kind of thing?

I wonder if people will go through this process.

I can imagine Paul simply pressing ‘ask’ and

bypassing the form.”

Rapid Persona-Driven Prototyping During

the Workshop


Design Outcomes• Learning Events in Prototype 2 could alienate Pierre and Eva

Participant 5 (Programmer): The

Learning Events were created to

facilitate learning. I think we should

reflect on the four personas and see if

they have need for this information. We

are discussing low-level details and

terminology before addressing the

users’ real goals.


Optional explicit learning support for Paul in Prototype 3

Quick access to content for Eva and Pierre

Option to explore domain topics for all four

personas

More obvious search option for Pierre and Eva

Refine resources here

Resources

Learning by doing: Typewriter Requirement Analysis 1 Evaluation Document X

Resources

Learning Events

Expand results

Day 1

C++ in 4 Days

Example of Analysis

How to evaluate

Day 2

Robin Hood Alka Selza Steve Martin Kartoffelpü Reh

Knowledgeable Persons

Refine experts here

PersonsExpand results

Prototype 2 - Before Personas Prototype 3 - After Personas

Design Outcome


Strengths and Weaknesses of Personas

based on our experience

•Short life span – Had a strong impact

during the first few hours of the discussions

and then their impact diminished

•This could be attributed to the

stakeholders’ presence

•Having to constantly ask participants to

link their ideas to a persona became

tedious and potentially annoying

•Focused the discussions on real people

and real working environments

•Helped project members from different

professional background to ‘get to know’

APOSDLE’s target audience

•Ensured redesign ideas targeted end

users and did not merely reflect personal

preferences

Weaknesses Strengths


Stakeholders’ Involvement

•Despite a template and instructions,

the style of the initial personas

provided varied

•After a while, participants seemed

to abandon the personas in favour of

asking the stakeholders directly if an

idea could work or not

•Helped produce more valid

personas that captured the work

routine and goals of real people

•Helped interpret the personas and

resolve disagreements - The

personas had clear owners who

knew the people they represented

NegativesPositives


Conclusions

• There are obvious pros and cons to the persona approach

• In our case we conclude the strengths outweighed the weaknesses

• We found personas to be an effective way to encapsulate and communicate user information so it served as a reminder during discussions


Conclusions

• By combining initial persona descriptions generated by stakeholders with our empirical data we feel we were able to address to some degree methodological weaknesses and practical limitation of the tool expressed in the literature

designing with only four people in mind? - a case study of using personas to redesign a...

Technology

personas stage

weaknesses of personas

hci design redesigning

right personas reason

initial set of personas

personas interesting

aposdle project

aspects of aposdle