This blog was originally written for, and published on the Fusion Company’s website. Check out the original post here.
What a User Persona Typically Is:
Most User Personas are created by making a description of one or more “users”. They tend to be filled with quirky personality details and made up information. Throw in a name, a fake picture and voila! You have (as an incredibly simple example):
“Hugh Sampson a 47 year old father of three from Brooklyn, NY who pretends to like craft beer to appear ‘hip’ but honestly just prefers Old Milwaukee. He is technologically proficient but still relies on his children to fix his computer when he accidentally downloads a virus”
If you’re lucky, Hugh Sampson will live forgotten on a server until someone remembers him, pulls him out, and rewrites him to sound more relevant to the developed product. If you’re unlucky he’ll be in the forefront of every conversation – questions like “but what would Hugh Sampson do” or “how would Hugh Sampson feel about that” plaguing every decision.
I know what you’re most likely thinking right now – “but isn’t that the point of a user persona?”
Why a Typical User Persona is Bad:
The danger with using these persons is that they are built on fiction rather than fact. They’re static and rarely change, while real users are much more complex. Teams who grow attached to this over personified version of a faux user often suffer short sightedness into their real user’s actual needs. Personas create a false sense of security, are easy to project one’s own assumptions and opinions onto, and make it hard to accept when the persona fails (and yes, it will fail).
How to Write a Good Persona:
Persona’s should focus less on the “who” (who is this person, where are they from, what do they do for fun, etc) and more on the “why”, (why does this type of user need this product, what are they trying to accomplish, etc). Neither should they stand alone, but rather be developed in tandem with focus grouping and user research to help spot and represent key patterns identified across target audiences.
Take this version of Hugh Sampson instead:
“User Group A: Is technologically proficient but not confident. Does not like learning new technologies and won’t stay around on a website if they can’t easily accomplish their tasks. Will be likely to utilize a customer support chat or help forum as long it is readily available.”
This new version focuses more on the factors that would cause a certain type of user (in this case a group that likes learning new technology but isn’t willing to work to figure things out) to bounce. Done properly, it should delineate clear pain points based on real user information and insights derived in testing, that can be referenced throughout the product development cycle.
How to Use a Good Persona:
Don’t forget that personas should evolve. Just like users don’t stay the same, neither should your qualitative representations of what they need. Good personas should be used to keep track of user types, build use cases for those persona types, and ensure an interface is properly built with its variety of users in mind. By basing personas off of user types rather than personalities they can be sorted into primary, secondary, and tertiary groups – helping the product’s primary focus be the primary user’s issues and needs. As your users grow and evolve, their personas should see changes and restructuring to ensure they remain an accurate representation. When you have a fluid evolving set of persona’s they can excel at the area they’re truly great for – user segmentation and role based personalization in everything from marketing, to testing, to product development.