Persona Driven Engineering: The magic of knowing your end users

Personas reveal how your users really use your product

If you’ve worked in software development long enough, you’re probably already well-acquainted with this formula:

As a user, I want to *…* so that I can*…*

But, have you ever stopped to think: who is this “user” we’re referring to?

Barbara Ogris, Senior Product Experience Designer at Dynatrace, found an answer to this question with the help of her background in marketing. A couple of months ago, she started an internal project at Dynatrace to create personas to use in software development in her domain of Application Security and give a name (or multiple names) to the anonymous “user.” Currently, the team is working on making these personas be applied throughout the whole company.

We invited Barbara to join us on the PurePerformance podcast and share the design process behind creating personas and how to use them in practice. However, I’d like to summarize some key points in this blog post.

If you’d like to, you can listen to the full episode here: Persona Driven Engineering: The magic of knowing your end users

Why personas?

As already mentioned, it’s common to use the formulaic “user” when creating user stories and epics for new features in software development. Sometimes, this may be replaced by more specific roles, like “admin.” However, terms like “admin” are still very generic and give little insight into the background and needs of the person using your product.

The truth is that there’s no one “user.”

Different groups of users use your product to achieve different goals. Your product doesn’t deliver the same type of value to all your customers.

Furthermore, we often misestimate the value we’re adding to the product. We tend to forget that what we’re adding is not what the persona needs. Even if we have “the user” in mind, this user might be split into two different personas. The added value might be good for one persona, but for the other, it might not be, or you won’t know if it does.

You may be making wrong assumptions and implementing a solution to a pain that doesn’t exist or just plainly implementing the wrong thing. And finding that out earliest when it’s already in production.

How do you create personas?

To create the personas for the Application Security team, Barbara gathered all product managers, product owners, developers, and UX specialists to collect as much information as possible about the people using this feature. She also consulted the marketing team to check which personas they already had.

Marketing (buyer) personas differ from product personas, but they can help learn more about the users. For example, who has purchasing power? And how does this persona rely on input from another persona, like Archie?

Then, they structured the collected information with the help of empathy maps, which show what the person thinks, says, feels, and does. Thus, they created proto-personas, which are personas based solely on assumptions — with no validation yet.

Naturally, then, the next step is to validate these proto-personas. To do this, the UX team consulted with internal and external people by conducting surveys and interviews to gather as much insight as possible to perfect the personas. It’s important to note that the most valuable information came directly from Dynatrace customers, who have the best insight into their job and how they use the product daily.

Here’s an example of a persona that was created by Barbara’s team:

It’s important to note that once you create a persona, you’re never actually done. You need to constantly update and validate it to keep up with the times. The needs change, the product changes — you constantly must reiterate the personas to deliver the best product experience.

How do you use personas in software engineering?

If you look at the “Archie” mentioned above, you can see that he is an excellent example of a persona that goes through the whole user journey with Dynatrace. From him, you can deepen your understanding of how he uses the product and what he needs from it. You can also learn where he would hand over to a different persona. This, for example, can teach you how to design the product at this exact point of the user journey to ensure a smooth handover.

When Archie talks to the developers and hands over the issue so they can fix it, you know on which page of Dynatrace that happens, and you can make sure to design it as a smooth transition. I.e., a specific tool to create tickets could be helpful at this point.

In a more general sense, having a deeper understanding of the motivations of your user and the value they get from your product can help you create better features. When writing new epics and new user stories, product managers, designers, and owners can ask themselves: “how can we design a feature that would make life easier for Archie/Eric/Anne?”

It also helps to picture a typical day in your persona's life: from morning to night. What would be Eric's first thing when he sits at his desk? Who is the first person he talks to? What kind of information would he need today from Dynatrace to do his work?

Although the teams do their best to develop features aligned with the personas’ needs, user testing is still very useful to tell if something has been done correctly. And the benefit of having a persona is that you know whom to ask to test these features since they are based on real people. You can constantly improve a feature in the next iteration based on their feedback and the data you gather from how it’s being used.

Thanks again, Barbara, for joining me on PurePerformance and sharing your story! It was great to learn how personas have impacted how software engineering is done at Dynatrace.

Persona Driven Engineering: The magic of knowing your end users was originally published in Dynatrace Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.