Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

The Un-researched Persona

945 Aufrufe

Veröffentlicht am

Presentation given at the Frontend Conference in Zurich by Nellie LeMonier on September 6th, 2012

Veröffentlicht in: Technologie, Business
  • Hi there! Get Your Professional Job-Winning Resume Here - Check our website! http://bit.ly/resumpro
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

The Un-researched Persona

  1. 1. The Un-researched Persona Nellie LeMonier Perforce Software UX Design
  2. 2. Nellie LeMonierUX research & design at Perforce Software Alameda, California
  3. 3. What is User Experience (UX)?
  4. 4. UX or UI
  5. 5. Engineering & UX
  6. 6. Why this talk?Research is important…don’t make a productwithout it.
  7. 7. Origins of Personas Customer Prints: by Angus Jenkinson for Customer Segmentation / Marketing (~1993) Personas: Alan Cooper for Software Development (~1995)
  8. 8. Why Personas? The Benefits• Shared understanding• Coherent story• Reduce conjecture• Build empathy• Define the “right” requirement• $$$ Save Development Effort
  9. 9. What is a Persona?• Personification of the roles• Role, professional background• Identity and personality• Technical expertise• Goals & cares
  10. 10. An Example
  11. 11. Business Domain• Personas are specific• Don’t believe in library of personas• Define ecosystem
  12. 12. When are Personas Created? • Early • Before you start • As you go
  13. 13. How are Personas created? Hypothesis Stakeholder Research Review Refine Analysis Hypothesis
  14. 14. Research is important…don’t make a productwithout it.
  15. 15. Research
  16. 16. Research
  17. 17. How are Personas Researched? • Contextual inquiry / User observation • Surveys • Phone interviews • Market research • Domain research
  18. 18. Without research…What could possibly go wrong?
  19. 19. Case Study:Content Management System (CMS)• Developers came up with the personas• No research was done to create these
  20. 20. CMS Case Study: Personas without research Larry Moe Curly End User Sys Admin Content Manager The dev team made these up
  21. 21. What was RIGHT with Larry, Moe and Curly?• Comic relief• United the team• Gave them a common conversation• Tasks for personas were defined
  22. 22. What was WRONG with Larry, Moe and Curly ?• No motivating factors defined• No domain expertise defined• Did not reduce conjecture• Curly couldn’t type
  23. 23. CMS Personas – Take 21. 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)
  24. 24. CMS Personas – Take 2Aaron Maya EdFront End Developer Content Editor Site Administrator
  25. 25. Take 2 Conclusions1. Motivations are clear2. Tasks are defined3. Expertise known4. Unifies product team
  26. 26. What was WRONG (PART 2) with Larry, Moe and Curly ?• 1 of the users didn’t exist• 1 marketing persona wasn’t defined(How to sell to these guys?)• No consensus with stakeholders
  27. 27. Case Study:Bridge to Competitive Product (FUSION)• Developer & UX came up with Personas• Research done into domain
  28. 28. Case Study: Fusion Background• Requirements driven by market need• Pressure from lost sales• Internal users of competition• Domain was somewhat known
  29. 29. Case Study: FusionStep 1: Persona Hypothesis Evan Greg System Administrator Git Developer Vera Raina TomP4V Developer Release Engineer Tech Lead
  30. 30. Case Study: Fusion Step 2: Research• Research Plan with Goals• Survey via Twitter, Forums, and Sales Team• Phone Interviews• Site Visits• Remote Screen Sharing
  31. 31. Case Study: Fusion Step 2.5 Share ResearchDoing research is cool, but sharing itis even cooler…
  32. 32. Mental ModelExplanation of someone’s thought process on how something works GOAL MESSAGE EXPECTATION USER
  33. 33. “Paul”
  34. 34. About “Paul” • Huge Perforce fan boy & early Perforce Admin • Becoming a Git/GitHub fan boy • 15 years dev management
  35. 35. Peter: Using GitHub News feed
  36. 36. Peter: Using GitHubReview changes of other developers
  37. 37. Peter: Using GitHubReview changes of other developers
  38. 38. Peter: Using GitHubReview changes of other developers
  39. 39. Peter: Using GitHubCommenting on changes
  40. 40. Peter: Using GitHubCommenting on changes
  41. 41. Peter: Using Perforce• Review Daemon - > P4Web• Code review tool - > set up, not cohesive experience• P4V -> history view more clicks to visually diff
  42. 42. Peter: Using SourceTree
  43. 43. 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
  44. 44. 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
  45. 45. Case Study: FusionStep 4: Refine Hypothesis Tom Evan Tech LeadSystem Administrator Greg Git Developer
  46. 46. Case Study: FusionStep 5: Stakeholder Review
  47. 47. Perforce Git Fusion Product Personas 49
  48. 48. 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 optionWho 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.
  49. 49. Product Persona Evan Enterprise 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 prioritiesWho 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 appreciatesproducts 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 andidle employees. 51
  50. 50. 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
  51. 51. Survey to UX Practitioners
  52. 52. How Many Projects Used Personas?
  53. 53. How Much Do You Know About the Business Domain?
  54. 54. Why Don’t You Take The Time to Research? Enough known Someone elsedid the research Research time not important Research important, no time
  55. 55. 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
  56. 56. How Long Did You Spend Researching Personas?
  57. 57. Share the Personas• Stakeholders – Marketing / Sales• Product Management• Product Team• Keep the Personas Alive
  58. 58. Why Personas? The Benefits• Shared understanding• Coherent story• Reduce conjecture• Build empathy• Define the “right” requirement• $$$ Save development effort
  59. 59. 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
  60. 60. Thank you for listening. Questions? Nellie LeMonier Twitter: @NellieLeMonier or @gmail

×