際際滷

際際滷Share a Scribd company logo
The Un-researched
    Persona


             Nellie LeMonier
              Perforce 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
dont make a product
without it.
Origins of Personas
 Customer Prints: by Angus Jenkinson
 for Customer Segmentation /
 Marketing (~1993)

 Personas: Alan Cooper for Software
 Development (~1995)
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
The Un-researched Persona
The Un-researched Persona
Business Domain

 Personas are specific
 Dont believe in library of personas
 Define ecosystem
When are Personas Created?

   Early
   Before you start
   As you go
How are Personas created?

                        Hypothesis




    Stakeholder
                                           Research
      Review




             Refine
                                     Analysis
           Hypothesis
Research is important
dont 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




  Larry          Moe                Curly
  End User       Sys Admin          Content Manager



       The dev team made these up
What was RIGHT with Larry,
          Moe and Curly?


 Comic relief
 United the team
 Gave them a common conversation
 Tasks for personas were defined
What was WRONG with Larry,
            Moe and Curly ?



 No motivating factors defined
 No domain expertise defined
 Did not reduce conjecture
 Curly couldnt type
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)
CMS Personas  Take 2




Aaron                 Maya             Ed
Front End Developer   Content Editor   Site Administrator
Take 2
      Conclusions


1. Motivations are
   clear
2. Tasks are defined
3. Expertise known
4. Unifies product
   team
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
Case Study:
Bridge to Competitive
 Product (FUSION)
 Developer & UX came up with Personas
 Research done into domain
Case Study: Fusion
          Background
 Requirements driven by market need
 Pressure from lost sales
 Internal users of competition
 Domain was somewhat known
Case Study: Fusion
Step 1: Persona Hypothesis



        Evan                                   Greg
 System Administrator                      Git Developer




    Vera                     Raina                     Tom
P4V Developer           Release Engineer             Tech Lead
Case Study: Fusion
           Step 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 Model
Explanation of someones thought process
  on how something works




     GOAL      MESSAGE    EXPECTATION




                                        USER
P温顎鉛
About P温顎鉛
    Huge Perforce fan boy
    & early Perforce Admin
    Becoming a Git/GitHub fan
     boy
    15 years dev management
Peter: Using GitHub
  News feed
Peter: Using GitHub
Review changes of other developers
Peter: Using GitHub
Review changes of other developers
Peter: Using GitHub
Review changes of other developers
Peter: Using GitHub
Commenting on changes
Peter: Using GitHub
Commenting 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: Fusion
       Step 3: Analysis

 Hypothesis is a little wrong
 Secondary persona is really primary
 Primary persona is really secondary
 Other requirements and influencers
Case Study: Fusion
Step 4: Refine Hypothesis



                                         Tom
       Evan
                                       Tech Lead
System Administrator




                           Greg
                       Git Developer
Case Study: Fusion
Step 5: Stakeholder Review
Perforce Git Fusion
   Product Personas




                      49
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.
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
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
Survey to UX Practitioners
How Many Projects Used Personas?
How Much Do You Know About
   the Business Domain?
Why Dont You Take The
    Time to Research?
                       Enough known
 Someone else
did the research



                            Research time
                            not important


 Research important,
       no time
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) 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
Thank you for listening.

      Questions?

               Nellie LeMonier

      Twitter: @NellieLeMonier
                     or @gmail

More Related Content

The Un-researched Persona

  • 1. The Un-researched Persona Nellie LeMonier Perforce Software UX Design
  • 2. Nellie LeMonier UX research & design at Perforce Software Alameda, California
  • 3. What is User Experience (UX)?
  • 6. Why this talk? Research is important dont make a product without it.
  • 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
  • 13. Business Domain Personas are specific Dont believe in library of personas Define ecosystem
  • 14. When are Personas Created? Early Before you start As you go
  • 15. How are Personas created? Hypothesis Stakeholder Research Review Refine Analysis Hypothesis
  • 16. Research is important dont make a product without it.
  • 19. How are Personas Researched? Contextual inquiry / User observation Surveys Phone interviews Market research Domain research
  • 20. Without research What could possibly go wrong?
  • 21. Case Study: Content Management System (CMS) Developers came up with the personas No research was done to create these
  • 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
  • 34. Mental Model Explanation of someones thought process on how something works GOAL MESSAGE EXPECTATION USER
  • 36. About P温顎鉛 Huge Perforce fan boy & early Perforce Admin Becoming a Git/GitHub fan boy 15 years dev management
  • 37. Peter: Using GitHub News feed
  • 38. Peter: Using GitHub Review changes of other developers
  • 39. Peter: Using GitHub Review changes of other developers
  • 40. Peter: Using GitHub Review changes of other developers
  • 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
  • 48. Case Study: Fusion Step 5: Stakeholder Review
  • 49. Perforce Git Fusion Product Personas 49
  • 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
  • 53. Survey to UX Practitioners
  • 54. How Many Projects Used Personas?
  • 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
  • 58. How Long Did You Spend Researching Personas?
  • 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