Scaling empathy with personas
Report
Share
•
6 likes•3,912 views
What I have learned over the last few years is that personas don’t have to be fake windsurfing grandma’s. They can transform big data into easy to understand composite customers that will allow you to scale your understanding of the customer across the design team and a growing company.
Scaling empathy with personas
•
6 likes•3,912 views
Report
Share
What I have learned over the last few years is that personas don’t have to be fake windsurfing grandma’s. They can transform big data into easy to understand composite customers that will allow you to scale your understanding of the customer across the design team and a growing company.
More Related Content
Viewers also liked
Viewers also liked (8)
Similar to Scaling empathy with personas
Similar to Scaling empathy with personas (20)
Recently uploaded
Recently uploaded (20)
Scaling empathy with personas
- 1. Scaling empathy with personas
- 2. All characters appearing in this work are, fictitious. Any resemblance to real persons,, living or dead, is purely coincidental.,
- 3. A persona is a compelling profile for a, significant segment of your customers or users,
- 5. Personal relationships don’t scale Understanding of the customer was on the decline ● Feedback from an increasingly small customer segment ● Feedback driven by exception cases ● Employee onboarding was slowing Product decisions were increasingly harder and less clear ● New features were delivering increasingly less value ● Product was becoming increasingly complex ● Slowing design and development
- 6. CustomerPrintsSegmentation Personas Use cases & UML Agile & user stories A simplified history (1986) (1993) (1995)(1950) (2001)
- 7. Persona benefits Creates an understanding of users in a way that is compelling and understandable ● Presents complex data in an easily understandable profile format ● Summarizes their behaviors ● Communicates the goals and motivations of the users ● Builds empathy for users People make better and faster decisions in designing and delivering product ● Gets research out of the lab and into the organization ● Grounds company decisions in research ● Focus designs on a single concrete user with minimal exception cases ● Allows for shared customer understanding across the organization
- 8. Segmentation Consolidate user data Derive hypotheses Collect additional data Initial segmentation Gather and review existing user data sources Employee survey Customer support tickets UserVoice Identify the attributes and variables that differentiate our users Technical skills Demographics Business characteristics Personality traits Use one or more items for each of the attributes and variables Survey ~600 users Demographic data (What is your age?) Psychographic data (Being efficient is important to me) Qualitative data (What makes a good work day?) Identify 5-8 statistically significant segments Perform cluster analysis Run multiple models to look for significant attributes Finalize significant attributes 6 clusters identified
- 9. Persona development Examine qualitative data Conduct interviews Finalize segmentation Gather and review qualitative data Customer survey UserVoice suggestions Interview user by segment for richer user context ~20 interviews Describe your work environment Typical daily processes and task Points of frustration Personal and work priorities Segment with qualitative and quantitative data Group and process all qualitative data Review the initial segmentation against interviews Fill out quantitative segmentation with the interview data Create personas Transform the data into an understandable profile Draft a profile for each segment Highlight key characteristics and data Provide detailed and summary view
- 10. Primary goals Key data attributes Research details Snapshot statements Representativeness scale
- 11. Key questions Factoids Company characteristics Link to research Summary statement Environment Detailed goals and behavior
- 12. Usage
- 13. Incorporating personas User goals for discovering solutions User activities for communicating solution experiences User stories for development tracking
- 14. User goal Alice - Knowing I am able to reach a real person makes me confident that I am able to get my questions answered when I run into problems. Who What Want
- 15. User activity Alice - I noticed a problem with the transactions on a lease and I need help fixing it Alice is busy reviewing a customer's lease ledger and sees an confusing credit that she does not understand and is unsure if she can delete it. She starts looking around for help and sees the “Support and help” menu in the top right of the screen. Clicking on the navigation opens up the menu to show a list of support options and help options for her to use. This time Alice prefers to call and sees that Buildium has a phone number she can call and is happy that she can see what hours the support folks are available and that she can call in immediately.
- 16. Pulling it all together
- 17. Delivery (agile y’all) Features become epics and are given a feature flag User activities are broken down into user stories and estimated Stories are linked to personas and use the persona in the standard user story format
- 18. Broader company culture Driving customer understanding ● Provides framework for internal discussions about customers ● Common touch point and understanding across departments Speeds employee onboarding; helps them understand our customers ● Sets a base of understanding for all new employees ● Provides work context Personas provide important context to drive sales and marketing conversations ● Sets messages and language ● Provides context for marketing and sales programs
- 19. Future
- 20. Push out and into the business Personas are mostly limited to product and customer conversations No way to know how different personas impact our business performance Limited ways to leverage our knowledge during customer support, marketing, and sales
- 21. Automatic detection and integration Refine the persona model to (semi) automate detection Push personas into core business systems Drive application personalization
- 22. Acquisition marketing survey Ask five groups of questions Generates a custom recommendation about the product fit Records the data entered for usage by marketing and sales Tara Connelly UX Designer
Editor's Notes
- Hello, My name is Coryndon Luxmoore I am VP of User Experience at Buildium and a reformed persona hater. I want to tell you a bit about my journey from hating to loving personas. So I am going to talk a bit about how we created our personas how we use them in our product process, and how we are evolving them to support our entire organization. So starting from the beginning. I spent years working at agencies where I saw an endless stream of personas of windsurfing grandmas who just happen to not be able to operate an iPhone. These projects were busy building personas based on poor research or opinions of the project sponsors. Alternatively, you might get a bunch of cold hard, to process market research that tells you that 33% of your users are female and you are left trying to figure out what features appeal to 33% of women in the market.
- What I have learned over the last few years is that personas don’t have to be fake windsurfing grandma’s or hard to interpret market data attributes. They can be an effective blend of both if you take the time to build invest in and build them into something that can be used over and over again. So for the purposes of my talk here today I want to share my current definition of a persona: A persona is a compelling profile for a significant segment of your customers or users. Compelling in that your team and company can make real decisions about what to do and not to do Segment in that they are built purely on data not a fictitious grandma
- I came back to personas thanks to Dr. Tomasz Miaskiewicz He has a PhD in personas (information systems) from University of Colorado Boulder - Leeds School of Business and joined us as a UX designer. His passion for personas drove our efforts and tied into our quest to build knowledge and empathy for our customers A great example of hiring T shaped people for skilled positions
- We were facing a problem at Buildium. We were losing touch with our customers. There were many reasons for this but key to them was how fast we were growing. When I joined the company we were supporting about 2000 customers and had 20-30 employees. Most of the staff had a decent tenure and there were clearly defined reference customers along with a stream of feedback from our customers from support calls. As we started to approach 4000 customers and we expanded our staffing we realized that the understanding of the customer was falling and was not consistent across the organization. It was also becoming clear that we were not hearing from all of our customers and users. The product was also becoming more mature and product decisions which were blindingly obvious before were becoming less and less clear. This was impacting the speed at which we could make decisions and slowing down design and development with opinions and arguments.
- Here is a simplified history of how design and engineering have sought to incorporate customer understanding into the product development process. 1950 Market segmentation A way of understanding the mass-market for marketing and product design Traditionally leverages data based on demographics Evolved to include psychographic and behavioral characteristics 1986 Use cases and Unified Modeling Language Created by Ivar Jacobson A list of steps an actor takes in the system Drives functional requirements 1993 CustomerPrints - Customer segments with a coherent identity Created by Angus Jenkinson Focused on improving marketing and sales Adopted by OgilvyOne Personas defined by Alan Cooper Popularized in 1999 by the book “The Inmates are Running the Asylum” Used to drive and focus software design around a single target user “Agile” and user stories Tries to empower the engineer with the information necessary to make smart development decisions "As a <role>, I want <goal/desire> so that <benefit>"
- We saw personas as the solution to our dilemma as a growing product organization. They would allow us to scale and create a common customer understanding in a way that pure data and individual research could not and they could help us make our product process more efficient and customer focused. Personas work because of empathy We are taught from birth to understand people and their motivations We can easily make decisions about their potential behavior Faster and smarter delivery Enables growth without losing sight of the customer with a shareable artifact Scope creep is reduced by having a concrete understanding of the target customer A strong common understanding of the customer speeds decision making
- Historically creation of the personas was based on organizational knowledge of the customer validated with qualitative research Recent trend shifts the process to include more quantitative data and segmentation techniques. So when we went to build our personas we tackled them with this blended approach. We started with segmentation using data we had, an extensive survey, culminating with a series of statistically significant clusters.
- We used those clusters to form the basis of the more traditional persona development process. The clusters and their significant attributes drove the recruitment for the qualitative interviews and provided important data to incorporate into the drafting of the personas.
- So coming out of this work we had 6 well developed personas that were compelling and backed with real data to minimize resistance across the organization. This is the summary view of all of our personas. They are arranged in order of representativeness from left to right with Alice here being the most common. Each have the significant attributes highlighted along with a summary and their goals.
- Each of the personas are fully detailed out in a profile with each word and attribute chosen based on either the quantative or qualitative research results. You can also see here that we are organizing our ongoing research into cross linked folder for each persona so if a team member is seeking more examples and raw data for the personas they can.
- So great we have these elaborate personas. We have shared them and educated our staff on them to provide a common understanding of the customer. How do we ensure that the personas are not forgotten about as you go about designing and delivering your product solutions?
- We incorporate personas deeply into our process three ways: User goals for discovering solutions User activities for communicating solution experiences User stories for development tracking I am going to talk a bit about each of these tools we use across product discovery and delivery.
- User goals are used to identify the outcomes that are valuable for our customers and users, much like the outcomes that the business might be giving you at the start of a project. It defines the problem space and gives you to measure the effectiveness of any solution from the customer's perspective. There are three components to the user goal Who (your persona) What (what your persona is doing) Want (your persona’s desired outcome) Drafting goals is an art not a true science but there are a few common attributes or behaviors of a successful user goal: Clearly identifies the user in detail. If you don’t have personas a short character description can be helpful Independent of solution: You should embrace and enforce solution ambiguity. If you cannot imagine multiple solutions for a user goal it is too constrictive and is probably a user task or development user story. Describes an emotional state for the person once the goal is achieved Keep in mind personas (even detailed ones) have a limited fidelity and you may need to rewrite the user goals based on new data uncovered during user testing.
- User activities seek to describe the solution experience it is the story of the "what" in the user goal and it is what we evaluate to see how well the solution delivers the outcome we want for the user. These activities get prototyped and tested throughout the discovery process.
- So we pull this all together in what we call a feature document. A feature at Buildium is the smallest meaningful piece of functionality we build to meet one or more user goals. It contains the user goals, user activities and links to our screens and prototypes. This document forms the basis for the delivery teams planning and estimation, longer term it supports the QA and Marketing teams with a description of what they can expect when the feature is complete.
- So even further down in the process as we start development we use the personas to track and shape the user stories. Our features get development flags and the activities are broken down into user stories. Each story is tagged with a persona and they are written to incorporate them into the story descriptions and the results for each story.
- I have mostly been focused on how we are using the personas in helping the product organization scale empathy but we face the same problem across the entire organization
- So now that we have talked about how awesome personas are and how much we use them let me tell you about how we fucked up as well. Personas were focused on current customer usage No data on the buying process and triggers Degrading accuracy as they age Over sampling of account holders caused us to potentially miss a segment of users So we have set out to try and address these shortcomings and I want to share two projects we currently have underway.
- We wanted to be able to dynamically keep our persona analysis up to date and get the persona data out and into our core business systems to be able to start doing business analysis for each of the personas. These systems span the business and include integration with Sales and lead management (Salesforce, Hubspot) Integration with customer support (ZenDesk) Business metrics and revenue reporting systems (Domo, ZoHo) So that we could do this we needed to see if we could refine the persona model to automate detection. We first gathered all of our system generated user attributes like system actiins, support tickets, etc. to see if that would be enough to associate each of our users a persona. What we found was with some minor tweaks to the cluster analysis we could detect the personas if they had completed 1000 actions in the system. This means that about 40% of our user base could be assigned personas. During this process we largely validated our personas but we did uncover one problem. One of our personas was a significantly larger group then we had seen in our original work. This looks like we had oversampled account holder in our original survey and that we may have missed a persona. The next question is how do we detect personas for a greater percentage of our user base and ensure that people who are new to the system are detected earlier? Solving this problem requires knowledge of attributes that we cannot detect. So we looked to see what survey questions would help us lower the number of actions required. We are now running a short survey for all of our users to gather this information and see if we can do just that. If it works we will add these questions into our on boarding process more elegantly and start the integration process with external business, marketing, and support systems.
- We use a simple form for sign up and a pre-populated trial to acquire most of our customers. This works well but we essentially don’t know anything about the people who sign up to kick the tires of our software. We wanted to see if we could pre-qualify and help our customers while they were shopping for our software. So we had this idea of of actually adding a quiz or survey to gather more information about our customers and tailor the sell sheet based on their answers. Essentially adding complexity to the trial process and potentially lowering our visitor to trial conversion rates. We used the personas as the starting point for this work including: defining the questions being asked and the data we wanted to gather using the number one goal question as the basis for tailoring the language on the results in addition to items like pricing, relevant features So we ran an A/B test where we replaced the main trial call to action on the homepage with a survey button to see how things would work Survey had up to an +5.14% lift in our trial sign ups when joined with our navigation containing a free trial button Survey takers were 8x more likely to sign up for a trial Initial evidence that the data helps the sales team close deals by allowing them to tailor sales conversations So what is next for this? We are in the process of moving this from being a test into being part of our normal sales cycle. Automating the process of capturing the data in Salesforce Looking to see if we can tie this as input for the semi automated persona model Longer term it may also be an opportunity for us to do additional analysis to see if we can expand our personas with buying behaviors and activity
- So first a brief history before we get into how and why we created personas at Buildium. Then we will discuss a bit on how we ended up using them and our plans for the future.
- So now that we have talked about how awesome personas are and how much we use them let me tell you about how we fucked up as well. Personas were focused on current customer usage No data on the buying process and triggers Degrading accuracy as they age Over sampling of account holders caused us to potentially miss a segment of users