Big Wins

User personas have had a falling from grace since 1999, the year Alan Cooper coined the term and popularized user personas as a tool for facilitating user-centered thinking.

As Travis and Hodgson put in Think Like a UX Researcher, "Personas get a mixed reception from development teams, with some questioning their value."

And this is exactly what I started to experience when I began poking around IBM Cloud's personas in early 2022. As I interviewed collaborators about existing personas and started reading externally about this tool, I noticed there were at least 7 common pain-points with personas. I call these the 7 Sins of Problematic Personas:

1. Fluffy - look nice but don't contain relevant insights for teams.

2. Idiosyncratic - no standardization across personas that are part of a set.

3. Innumerable - too many to make sense of.

4. Concrete - one-and-done artifacts that become outdated.

5. Hidden - hard to even find if they do exist.

6. Opaque - black-boxes without any reference to source material/research.

7. Specific - not generalizable, break in scenarios they should lend clarity to.

In addition to these pain points, the Cloud persona landscape itself was disjointed: 8 archetypes, 66 associated job titles, and 23+ cloud-specific personas spread asunder in box folders and local drives. And many had the 7 sins.

It was clear in early 2022 that a revamping — and a rethinking — of user personas was needed.

I approached personas like any other tool or service UXRs help create everyday — I sought to understand the user pain points and find solutions to those pain points in order to make something more useful and usable. I was not beholden to any one method or approach — personas, jobs-to-be-done, mindsets, etc.

During my initial probing, I began presenting my thinking to the Cloud UXR team for feedback. I called out the common pain points and how the current way of thinking about personas — i.e., as fictional characters, using out-of-the-box templates — was broken.

I argued that personas should be thought of, not as fictional characters, but scientific theories. A good persona would possess the same qualities a good scientific theory possesses. Said another way, the 7 Sins of Problematic Personas are the result of not having these qualities. These are the Tenets of Good Personas:

• Empirically based

• Flexible (generalizable)

• Updated over time

• Consistent (with each other and other knowledge)

• Lean (Occam's razor)

• Predictive (of user behavior/attitudes/feelings)

• Documented (sourced)

• Discoverable

• And of course, just built into these tenets are the concepts of being Testable and Falsifiable.

Through these presentations, I was able to convince the Cloud UXR leadership to focus on revamping our personas. A small cadre, or guild, was created with this goal in mind.

Overall, this work took a year to complete, requiring enormous amounts of collaboration and coordination between uxr, design, engineering, and pm.

The guild approached this project with the mindset that personas were theories. We also wanted to detach our understanding of personas from job titles. Job titles mean different things at different companies and don't lend clarity to what someone is doing. We opted instead to see our users through a behavioral lens, similar to jobs-to-be-done.

Armed with the above mindset shift, we went through five phases of person development:

1. Corral collective UXR knowledge about users, pulling out insights related to user behavior (jobs and responsibilities).

2. Created draft personas.

3. Socialized these drafts with cross-functional collaborators for feedback and critique. This was a crucial step. It not only ensured we were creating something of actual value for the users of personas but also fostered a sense of shared ownership — these weren't the UXR teams personas; these were Cloud's personas.

4. Incorporate feedback and publish new personas.

5. Update as new knowledge is gained.

The main deliverable for this work was something called the Persona Framework. This framework is similar to an image on a puzzle box — it shows how all of our cloud platform users relate to one-another.

Within the framework, there are individual, product/service agnostic Archetypes for each domain on the platform. These Archetypes describe what these user types are trying to do on the platform and their core responsibilities (e.g., FinOps Manager: understand cloud cost and manage that spend, etc.).

Each Archetype has tabs on it that contain the research it was based on and any notes related to it (e.g., updates that have occurred to it).

Here are (blurred) images of these deliverables:

Persona Framework and Archetypes

In Think Like a UX Researcher, Travis and Hodgson say:

"Here's a secret many people don't know: You don't need to create personas to be user-centered. Creating personas should never be your goal — understanding users' needs, goals and motivations should be your goal."

To the extent that user personas do that — i.e., increase user empathy and user-centered development — that is the measurement of their success.

The Cloud team did a pre-/post-survey of stakeholder attitudes about users and their usage of personas. This allowed us to measure attitudes related to user understanding/personas, albeit in an imprecise way.

We were also able to see usage metrics for the persona artifacts via site traffic data, Figma insights, and how often they were attached to epics in PM tools.

Anecdotally as well, we began seeing these new personas used as the basis of all workshops and ideation sessions.

Overall Impact

• Increased user-centered thinking/design (personas used in Figma/workshops)

• Increased user-centered development (personas used in epics)

• IBM UXR wide personas thought leader

• Helped UXR teams beyond Cloud build personas