The Un-researched Persona

Nellie LeMonierPerforce Software

UX Design

Nellie LeMonier

UX research & design at Perforce Software

Alameda, California

What is User Experience (UX)?

UX or UI

Engineering & UX

Why this talk?

Research is important…

don’t make a product without it.

Origins of Personas

Personas: Alan Cooper for Software Development (~1995)

Customer Prints: by Angus Jenkinson for Customer Segmentation / Marketing (~1993)

Why Personas? The Benefits

•Shared understanding

•Coherent story

•Reduce conjecture

•Build empathy

•Define the “right” requirement

•$$$ Save Development Effort

What is a Persona?

•Personification of the roles

•Role, professional background

•Identity and personality

•Technical expertise

•Goals & cares

An Example

Business Domain

•Personas are specific

•Don’t believe in library of personas

•Define ecosystem

When are Personas Created?

•Early

•Before you start

•As you go

How are Personas created?

Hypothesis

Research

AnalysisRefine

Hypothesis

Stakeholder Review

Research is important…

don’t make a product without it.

Research

Research

How are Personas Researched? •Contextual inquiry / User

observation

•Surveys

•Phone interviews

•Market research

•Domain research

Without research…

What could possibly go wrong?

Case Study: Content

Management System (CMS)•Developers came up with the

personas

•No research was done to create these

CMS Case Study: Personas without research

LarryEnd User

The dev team made these up

MoeSys Admin

CurlyContent Manager

•Comic relief

•United the team

•Gave them a common conversation

•Tasks for personas were defined

What was RIGHT with Larry, Moe and Curly?

•No motivating factors defined

•No domain expertise defined

•Did not reduce conjecture

•Curly couldn’t type

What was WRONG with Larry, Moe and Curly ?

1. Larry, Moe and Curly were retired (RIP)

2. Research domain: internal interviews (1 day)

3. Research specific roles through interviews (1 week)

4. Synthesize new Personas (1 week)

CMS Personas – Take 2

CMS Personas – Take 2

AaronFront End Developer

MayaContent Editor

EdSite Administrator

Take 2 Conclusions

1. Motivations are clear

2. Tasks are defined

3. Expertise known

4. Unifies product team

•1 of the users didn’t exist

•1 marketing persona wasn’t defined

(How to sell to these guys?)

•No consensus with stakeholders

What was WRONG (PART 2) with Larry, Moe and Curly ?

Case Study: Bridge to

Competitive Product (FUSION)

•Developer & UX came up with Personas

•Research done into domain

Case Study: FusionBackground

•Requirements driven by market need

•Pressure from lost sales

•Internal users of competition

•Domain was somewhat known

Case Study: FusionStep 1: Persona

Hypothesis

Greg Git Developer

Evan System Administrator

VeraP4V Developer

RainaRelease Engineer

TomTech Lead

Case Study: FusionStep 2: Research

•Research Plan with Goals

•Survey via Twitter, Forums, and Sales Team

•Phone Interviews

•Site Visits

•Remote Screen Sharing

Case Study: Fusion Step 2.5 Share Research

Doing research is cool, but sharing it

is even cooler…

Mental ModelExplanation of someone’s thought

process on how something works

GOAL MESSAGE EXPECTATION

USER

“Paul”

About “Paul”

•Huge Perforce fan boy

& early Perforce Admin

•Becoming a Git/GitHub fan boy

•15 years dev management

Peter: Using GitHubNews feed

Peter: Using GitHubReview changes of other developers

Peter: Using GitHub

Review changes of other developers

Peter: Using GitHubReview changes of other developers

Peter: Using GitHubCommenting on changes

Peter: Using GitHubCommenting on changes

Peter: Using Perforce

•Review Daemon - > P4Web

•Code review tool - > set up, not cohesive experience

•P4V -> history view more clicks to visually diff

Peter: Using SourceTree

Why are users choosing these tools?

•Align with mental model of needs

•Effectiveness of access

•Remove barrier to information

•Make development more effective

•Effective development means making more awesome software faster

Case Study: FusionStep 3: Analysis

•Hypothesis is a little wrong

•Secondary persona is really primary

•Primary persona is really secondary

•Other requirements and influencers

Case Study: FusionStep 4: Refine Hypothesis

Greg Git Developer

Evan System Administrator

TomTech Lead

Case Study: FusionStep 5: Stakeholder

Review

49

Perforce Git Fusion

Product Personas

TomRelease Engineering Manager

“The devil is in the details”

•Extensive experience delivering solutions that use diverse technologies•Adept at meeting strict deadlines•Wants to be the hero, failure is not an option

Who he is: Profession: Director of Release EngineeringEducation: Masters in Computer Engineering, UC Berkeley, 2001Age: 38Home Life: Married with 3 children. Volunteers with his church 2 weekends a month.Personality: Dynamic leader who loves thinking on a large scale.Technical expertise:Has deep understanding in development and configuration processes and strategies. Expert in Gerrit, Git, ClearQuest, OracleDB, and mySQL which he’s used to create and automate the ALM processes and his company.Goals: •Allow users to re-use code.•Ensure that everything is tested by automation.•Bugs can easily be traced and fixed.•Configure new modules.•Organize who has access to what.•Ensure users can easily follow a workflow strategy.•Understand how product dependencies work.•Provide solution that scales to 700 users.What he cares about:•Solutions that he deploys meet business needs on a global scale.•Development strategies align with release management strategies to maximize the company’s ability to streamline delivery of products.•Tools he deploys must not get in the way of developers need to succeed.

Product Persona

51

EvanEnterprise Version Management System Administrator

“My job is to protect my company’s crown jewels”

•Extensive experience in development and source control•First adopter of new technology•The security, reliability and performance of the site are his first priorities

Who he is: Profession: System Admin in IT DepartmentEducation: BS Mechanical Engineering, University of Illinois, 1980Age: 54Home Life: Single. Rides motorcycles in his spare time. Into gaming.Personality: Not afraid of new technology, likes a challenge and solving problems but also appreciates products that just work as their supposed to.Technical expertise:Has experience administrating Perforce, ClearCase, and SVN. Also has experience coding in Perl and Python.Goals: •Easily set up and configure a Git Fusion server.•Create and manage user access to Perforce, GF and Gerritt.•Ensure that systems are backed up, secure, auditable, and highly available.•Full access, when he needs it, to all systems he maintains.•Enforce SOX compliance requirements through systems he maintains.What he cares about:•Wants Perforce up and running, responsive with no down or slow time. Downtime means complaints and idle employees. •To be known as someone who cares about giving his customers the tools that they need to succeed at their job.•Likes to automate the tasks involved in maintaining the tools for which he’s responsible. The less he has to do manually the better.•Have logs available to help him trouble-shoot what went wrong.

Product Persona

Case Study: FusionResearch Benefits

•Business domain more defined

•Requirements for other products

•Persona accuracy

•Strengthen relationships with users

•Build the product customers want to buy

Survey to UX Practitioners

How Many Projects Used Personas?

How Much Do You Know About the Business Domain?

Why Don’t You Take The Time to Research?

Enough known

Research time not important

Research important, no time

Someone else did the research

Other Reasons For No Research:

•Lack of interest from stakeholders

•Lack of budget for any research

•Out of scope

•Organization does not value research

•Does not believe there are changes to the domain, research was done years ago

How Long Did You Spend Researching Personas?

Share the Personas

•Stakeholders – Marketing / Sales

•Product Management

•Product Team

•Keep the Personas Alive

Why Personas? The Benefits

•Shared understanding

•Coherent story

•Reduce conjecture

•Build empathy

•Define the “right” requirement

•$$$ Save development effort

The (OTHER) Benefitsof Research

•Build trust with your users

•Build a relationship

•Usability testers ready

•Expand stakeholders

•Learn of “Other” opportunities

•Make MORE $$$

•Make a better product

Thank you for listening.

Questions?

Nellie LeMonier

Twitter: @NellieLeMonieror @gmail