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.
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
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
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.
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
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