This document discusses the importance of user research in developing effective personas for software projects. It provides examples of personas created both with and without research to highlight the benefits of research. Personas developed without research for a content management system lacked defining details and motivations. In contrast, personas created for a competitive product were improved through domain research, strengthening requirements and relationships with users. The document advocates spending time on research and sharing personas to realize benefits like a shared understanding, building empathy, and defining the right requirements to save development effort.
1 of 62
Downloaded 21 times
More Related Content
The Un-researched Persona
1. The Un-researched
Persona
Nellie LeMonier
Perforce Software
UX Design
7. Origins of Personas
Customer Prints: by Angus Jenkinson
for Customer Segmentation /
Marketing (~1993)
Personas: Alan Cooper for Software
Development (~1995)
8. Why Personas?
The Benefits
Shared understanding
Coherent story
Reduce conjecture
Build empathy
Define the right requirement
$$$ Save Development Effort
9. What is a Persona?
Personification of the roles
Role, professional background
Identity and personality
Technical expertise
Goals & cares
22. CMS Case Study: Personas without research
Larry Moe Curly
End User Sys Admin Content Manager
The dev team made these up
23. What was RIGHT with Larry,
Moe and Curly?
Comic relief
United the team
Gave them a common conversation
Tasks for personas were defined
24. What was WRONG with Larry,
Moe and Curly ?
No motivating factors defined
No domain expertise defined
Did not reduce conjecture
Curly couldnt type
25. CMS Personas Take 2
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)
26. CMS Personas Take 2
Aaron Maya Ed
Front End Developer Content Editor Site Administrator
27. Take 2
Conclusions
1. Motivations are
clear
2. Tasks are defined
3. Expertise known
4. Unifies product
team
28. What was WRONG (PART 2)
with Larry, Moe and Curly ?
1 of the users didnt exist
1 marketing persona wasnt defined
(How to sell to these guys?)
No consensus with stakeholders
29. Case Study:
Bridge to Competitive
Product (FUSION)
Developer & UX came up with Personas
Research done into domain
30. Case Study: Fusion
Background
Requirements driven by market need
Pressure from lost sales
Internal users of competition
Domain was somewhat known
31. Case Study: Fusion
Step 1: Persona Hypothesis
Evan Greg
System Administrator Git Developer
Vera Raina Tom
P4V Developer Release Engineer Tech Lead
32. Case Study: Fusion
Step 2: Research
Research Plan with Goals
Survey via Twitter, Forums, and Sales Team
Phone Interviews
Site Visits
Remote Screen Sharing
33. Case Study: Fusion
Step 2.5 Share Research
Doing research is cool, but sharing it
is even cooler
43. Peter: Using Perforce
Review Daemon - > P4Web
Code review tool - > set up, not
cohesive experience
P4V -> history view more clicks to
visually diff
45. 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
46. Case Study: Fusion
Step 3: Analysis
Hypothesis is a little wrong
Secondary persona is really primary
Primary persona is really secondary
Other requirements and influencers
47. Case Study: Fusion
Step 4: Refine Hypothesis
Tom
Evan
Tech Lead
System Administrator
Greg
Git Developer
50. Product Persona
Tom
Release 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 Engineering
Education: Masters in Computer Engineering, UC Berkeley, 2001
Age: 38
Home 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 hes 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.
51. Product Persona
Evan
Enterprise Version Management System Administrator
My job is to protect my companys 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 Department
Education: BS Mechanical Engineering, University of Illinois, 1980
Age: 54
Home 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. 51
52. Case Study: Fusion
Research Benefits
Business domain more defined
Requirements for other products
Persona accuracy
Strengthen relationships with users
Build the product customers want to buy
55. How Much Do You Know About
the Business Domain?
56. Why Dont You Take The
Time to Research?
Enough known
Someone else
did the research
Research time
not important
Research important,
no time
57. 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
59. Share the Personas
Stakeholders Marketing / Sales
Product Management
Product Team
Keep the Personas Alive
60. Why Personas?
The Benefits
Shared understanding
Coherent story
Reduce conjecture
Build empathy
Define the right requirement
$$$ Save development effort
61. The (OTHER) Benefits
of Research
Build trust with your users
Build a relationship
Usability testers ready
Expand stakeholders
Learn of Other opportunities
Make MORE $$$
Make a better product
62. Thank you for listening.
Questions?
Nellie LeMonier
Twitter: @NellieLeMonier
or @gmail
Editor's Notes
#9: infer what a real person might need. Such inference may assist with Brainstorming, Defining use case, and Defining features From personas we can learn how to market and sell our product