PurePerformance - Persona Driven Engineering – The magic of knowing your end users with Barbara Ogris

Episode Date: August 29, 2022

How do you a design a feature if you don’t know for whom it is for? How do you define SLOs (Service Level Objectives) if you don’t know what your users expect from you? How do you design performance tests and workloads if you don’t know which user behavior to simulate?In this episode we have Barbara Ogris, Sr Product Experience Designer at Dynatrace, who walks us through the concept of target personas that she helped establish within Dynatrace. It changes product and observability discussions from “as a user I want …” towards “as Archie I have this need …”. Listen in and learn about design thinking, using empathy maps to define your target persona and how this can be applied to many aspects in software engineering.Barbara on Linkedinhttps://www.linkedin.com/in/barbara-ogris-6a0b6011b/Dynatrace Blog: Terminology matters: how to enhance user experience by aligning names with expectationshttps://www.dynatrace.com/news/blog/terminology-matters-how-to-enhance-user-experience-by-aligning-names-with-expectations/Atlassian persona template: https://www.atlassian.com/software/confluence/templates/personaMIRO persona template: https://miro.com/aq/ps/templates/personas/?utm_source=google&utm_medium=cpc&utm_c[…]aIQobChMI6J7Juqql-QIVCOJ3Ch3jtwWwEAAYASAAEgLxT_D_BwE&loc=9062705Adobe XD: how to define a persona: https://xd.adobe.com/ideas/process/user-research/putting-personas-to-work-in-ux-design/

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. hello everybody to another episode of pure performance as you can hear from my austrian accent i am not brian wilson but i'm andy grabner and unfortunately brian couldn't make it today but he asked me to take the leading role of today's podcast and i'm very happy today well first of all i don't have a joke because brian typically tries to make a joke either of my Austrian heritage or something else that he thinks is funny. Today, no jokes, just pure business. And I am very happy that I have a colleague of mine today, Barbara Ogris, as a guest. Servus, Barbara. Hi. Hi. Thanks for making time. Is this your first podcast? It's my first podcast, yes.

So thanks for having me. Of course. I know it's the first and most likely not the last because I know you're doing some really great things at Dynatrace. And I'm sure also outside of Dynatrace, before you started at Dynatrace, you have a lot of experience. And I'm pretty sure not only my audience, but other audiences can benefit from it.

Now, before, Barbara, I let you introduce yourself and give some background, I want to tell the audience why I have you on the podcast. It was a couple of months ago, and I just looked into the Slack conversation that we had. We were doing some research internally in my team. So we're doing developer relationships and we try to figure out what type of content do we need to create like the

podcast content and the youtube videos to really help our target audience and as the name implies pure performance or my observability clinics it's all about performance engineering, observability, DevOps accessory. And then I stumbled upon your name because you within Dynatrace have started a program or a project. You can probably tell more about this. But you started talking about target personas and using target personas to better drive product innovation, product experience, product development. And that was really fascinating for me because i think what we are doing in general not well as an as an industry and that also includes what i'm doing as content creator i think we don't think well enough in the beginning about who is the target persona what's their pain and how can we help them and this is why i invited

you because i want to first of all learn now more about you who you are your background and then we jump into the topic of target personas and how does this now change the way we develop products and features in Dynatrace and then hopefully I can also extract some of the knowledge and give to the audience that is listening today Barbara, now to you. Who are you? Hi again. My name is Barbara and I'm with Dynatrace now for a bit more than one and a half years. I'm working in the field of application security and I'm a senior product experience designer. And before working here, I was in marketing. So my main focus was lead generation. And there, of course, personas play a big role. So that's kind of helpful for our topic today. And my main focus and my daily work is that I kind of maintain the end-to-end process of our application security

users, guiding them from the alert from invulnerability to all the details, and then in the end to really remediating the problem. So I try to rather focus on user experience than user interface design. And I would say my main focus is always to put the user in the center. That's, first of all, a couple of things. App security, that's a very important topic for those listeners that don't know it but we at dynatrace we have focused over the last year and a half maybe even two years almost i guess on application security as a new solution uh but

what you just said is interesting the differentiation between user experience and user interface, for me, I guess I always thought the user interface is what defines user experience. Or how do you see this differently? I think one doesn't go without the other. So to have a good user experience, you need to have a good UI, so good user interface design. So I think the focus is a bit different. For user interface design, you really focus on how something looks, how the page is structured, how you guide the user through the page with, I don't know, colors, headings, buttons, stuff like that.

For user experience, it's more focusing on the overall journey. So how the user works with the feature, how he or she might interact with it, where, I don't know, just how the experience in the end is when working with our product. But as I said, the one doesn't go without the other. I just wanted to say that my main focus is really on defining those user journeys,

identifying the pains of the users throughout the user journeys, understanding what they need, where they need it, when they need it, how we can fix that for them. Now, years ago, when I was still coding, I remember these user stories that started with as a user i want to do xyz why is this no longer enough and how does the target

persona concept change this so as a user is super generic and it kind of so it that the thing is that when you have as a user then you suggest that you just have one user which is wrong because you normally don't just have one user you have different user groups um so that's the first thing that i would argue against and having a name saying, for example, as Eric, I want to, as Archie, I want to, really helps me to put me in the shoes of this special user. And it also helps me to identify the different needs for one feature. So Eric might have other pains and needs than Archie. So that means the feature that we are developing and the stories and epics that we are generating

need to fulfill different needs for different people. And not just one, so there's not just one value that it should, or that it can deliver for all the users, but yeah, it needs to be different values that come out of a user story for the different user groups that we have. And I think this is especially true for, I mean, obviously we at Dynatrace,

we build a software intelligence platform that has grown over the years. So that means we have many different capabilities in the product, many different features, and obviously they're all targeted towards different user groups. But again, this is another podcast about Dynatrace, so that means anywhere in the world, right,

whatever product you're selling, you are, unless it's a very niche product and it's very clearly defined who your potential user is, I think you always have different user groups, target personas. Yes. And now, how do you

so you said when you started with anachronism roughly about a year and a half ago were you asked to do this did you say you want how does this start so i i got my first task and i was super eager to start and everything and then i i thought okay I don't even know who I really do that for I mean of course I had a person in my head and I'm sure everyone on the team had but I wasn't sure if that is true also because I was kind of new to application security in general so I struggled a bit because I thought okay now I can an assumption, but I don't know if that assumption is true. And then I may create a solution to a pain that doesn't even exist. So my internal trigger was that I just wanted to learn who I built this feature for before

starting to build the feature, actually, and then how the process started. And then, I i mean i would assume right i mean now we live in the software business in the software business creating a product and then pushing it out and then seeing if it's used or not it's probably cheaper quote unquote than let's say building something like building a new car and that's going to be very expensive and if you then figure out damn we didn't think about the target persona and now we don't sell it but we spend millions of euros to develop it but still right even though software is relatively quote-unquote cheap it's actually not cheap because you have a lot of resources that are tied up and then

in the end you only have so much runway in terms of revenue until or money until you can actually then you know you need to sell at some point and therefore it it's it's i guess it makes so much more sense from the beginning we always think about who is your real target persona what's the pain point that you're solving for this particular target persona and uh now coming back to your story, that means you started this whole thinking about who are we actually building this for? What was your approach? Any best practices that you have? Yeah, I think the first thing you or everyone should do is just to sit together with the team

and see if all the assumptions that you have in your head, everyone else also has in their heads. And then just gather everything that's there to have kind of a starting point. I mean, it's also a good idea that if you have data analytics in place that already tell you something of the users to, of course, include that in your first persona draft. But then I think the most important thing was to get people from different roles in one room and just gather everything that was in their heads to kind of start a persona journey. So the design thinking method that we used was empathy maps, where you just take a piece of paper and divide it in four sections and then put what the user says, thinks, does and feels. And the cool thing there is that, so whenever I did that before, is that normally what the user says is not necessarily what he really thinks or feels.

So I like the exercise a lot because people tend to say different things that they maybe think or feel and it helps to kind of identify the real pain behind what the user is maybe saying or the persona is saying. So that's why I really like that exercise. And we did that together and, yeah, then just collected sticky notes, basically. And after that, I put it in a template. And we added some demographic information, some background, for example, education and what the role might be and stuff like that and after that we had an internal workshop trying to get personas from these roles to kind of

um yeah to kind of verify what we came up with and in the end we then had a let's call it proto persona so a proto persona is a persona that is just based on assumptions where we didn't validate anything yet and with that we kind of started then so i'd say then the most important thing is to just get it out show it to your team, tell them that these are now the personas that you're all working with for now. And then, yeah, just work with them. Now you said, because AppSec is a new solution within Dynatrace, which means completely new audience

and which makes it even more natural to actually do these workshops and figure out who do we want to sell this new uh feature to um i guess with other with other existing features it's a little easier because we've been doing this for 15 years and so we have a good understanding but for every new feature for every new you know kind of solution you're building for every new product for a new service this just makes so much sense from the appsec perspective can you give us an example of a persona that you have now come up with and kind of you know shaped and also validated and give us a little bit of the the pains the amp the what what they feel what they want just is yeah so we established uh four personas in total i think four

is a good um amount to start with and um archie i will pick archie our security architect for our main or not main persona but it's the persona that we always have in all of our stories because it it's the persona with the most fundamental and deep knowledge about security, meaning that a lot of people in the company would approach him for help and security insights, which then leads to the first pain that he has because he, of course, is kind of a bottleneck because everyone needs his expertise. And then on the other hand, he has a lot of dependencies and a lot of people to talk with because he's also the most important sparing partner for our chief information security officer,

helping him decide what's the next important thing to add to the feature set is. And when then there's a buying decision, our chief information security officer would also go to Eric, would also go to Archie, sorry, to get insights and to get advice what should be bought next. So I think it's a major player for us in security and a major role where a lot of information is centered,

but then also a lot of dependencies are there. So yeah, I think that's the persona that's most important for our journey and for all of our user stories. Also, because in the product, when there's this, so I mentioned this end-to-end user journey, and Archie would be the persona that really walks from step one to the last step, like the whole user journey, and really uses all of our pages and all of our different features so that also helps because

um we get a lot of understanding of how he uses our product and what he needs and where then there is this point where maybe a developer takes over or someone else takes over and he's kind of out of the process so yeah cool and then that's that's interesting uh so because i mean i know the product um and so basically you say whoever i mean he's a critical role that he needs to be made aware of when there are security problems how how uh what was this severe they are but then there's a clear handoff yes, let's say, the developers. And that's when you have also in the product, I guess, an option where you say, now I want to hand this off to team A, B, C who needs to then take care of it. Because in the end, you then solve a problem for him, right?

You give him an overview of what is critical, but then hand it off to the development team so that they can fix things so that he can focus again on other stuff. Yes, and also you kind of get the answer to where you need to start the new user journey for the next persona and how it should best start. So if you know where the handover happens and if you know how the personas use your product, then you know where the handover is and you can create the smoother handover for the different personas in the end so um yeah when when archie talks to the developers and then says okay from the detail page on where do you really need to fix like a certain um security

issue in the end um when you know where that happens then it can be smoother then you know where that happens, then it can be smoother. Then you know maybe you need to have a tool or an option to create a ticket there or something like that. So it's smoother to hand over from one persona to the other. And that's why I assume, right, you said in the beginning you start with the proto-persona. But then you validate your assumptions with some real people. Now, my question is, who is the real archie so the thing is um we tried to so we first uh validated internally and then we tried of course to validate with customers and i think their sales also comes into place of course because um you you kind of get a recommendation for who you who you who is a good sparing partner

for doing exercises like that. And then the best, so if that is possible, and if the customers take the time, then it's super awesome to do interviews because you talk to them, and by talking to them, you get so much more information out of them than by just sending a survey. I mean, we also did a survey and got a lot of insightful values back. But I would really recommend to do an interview if you have the opportunity. Because then you can also ask questions like,

okay, and now please tell me how is that in your day-to-day work? And they will come up with examples and share insights with you that really help you then in the end. Also, what I learned is there's of course differences in every company. And if you have enough customers to talk to, then you will also get a pattern in the end where you see, okay, bigger companies tend to do it like you see okay bigger companies tend to do it like that smaller companies tend to do it like this stuff like that so for me having those interviews was really like the the best thing to get a feeling for how valid our proto personas are and i mean it doesn't mean that because we had those interviews and we validated those proto personas now that we never reiterate on that so the persona is a concept that is never

done so you always have to validate it you always have to um yeah i think the needs change the product grows the feature set grows so it gets more complicated maybe or so you always have to reiterate on your proto personas or personas to to deliver the best product in the end well it's like a real persona right a real persona doesn't stop to evolve either we if you change every day because we make new experiences and that defines the path we take um i also wanted to say i agree with you that it's so valuable to have one-to-one interactions you call them customers or users or the community i'm also very i always find it very fortunate for me to travel and then being at the sales show right at the conference

and then speaking with 10 50 100 people every day where you can then learn from them who they are my best question when people come to the booth i always typically ask so what do you do and then i ask the question back actually what do you do because i want to figure out what you do and how we can help you and i think that's the that's a it's a really we're really fortunate that we have this opportunity to learn from them and then take this what we learn and bring it back to the product so that we can actually build something that helps these people yes um quick question now you mentioned i mean the interviews are great so you are figuring out what the the real person the target persona is then you build

the product now obviously we are here at pure performance and we talk a lot about performance about monitoring about observability do you then validate your the product um also through monitoring so do you then really know if the people are actually then using the product in the way that you have designed it product in the way that you've designed it and they're using that you've designed the user experience do you have do you look at monitoring data yeah i think um there's two different approaches the one would be user tests before you launch it actually and then afterwards of, as you said, monitoring how users interact with the product. That means having event handlers and stuff like that in place to just figure out where do they click?

How long do they stay on a certain feature? How do they use it? Is it maybe, I don't know, there is an info icon. Do they ever hover over it? Do they ever read that? Do we really need that? So things like that. But as I said, I think user tests are also super, super important beforehand,

before launching it, just to understand how users really click for your prototype. I think so you can validate the stuff that you do a hundred times, but then seeing a user really using it makes such a difference. And I think that, so with that in place beforehand, that can save you a lot of time afterwards because introducing a feature to a customer means that the user needs to learn a new pattern and can do great ux and and it can be super easy for the user but still the user learned this pattern if you then find out

that you did something wrong and that you actually need to change it again it's a pain for the user because the user needs to relearn and needs to adapt to the feature again and stuff like that so um i would really recommend to do user tests beforehand and observe and let the user talk as much as possible and then find out if you really are on the right track or launching yeah and then right if you build something new and you have the ability to do user tests where you have direct interactions that's great at scale you can also do this through even things like feature flagging ab testing i think that's very common techniques right to figure this out exactly so we always try to do that and as you said then after launching of course we have measures in pain to learn from that to see how many people interact with with the feature how they interact

and then we also learn from that data of course so we take that data and then try to iterate on it so of course we're working in an hl team so that means we always want to iterate because we always want to do better of course every iteration should be beneficial for the user so we take that data and then we try to yeah iterate on our user journeys iterate on how the structure of the page is just come up maybe with a with yeah new new ways to to visualize stuff things like that did you and this goes into a topic that brian and i have been discussing quite a bit over the last couple of episodes um we talked a lot about slo service level objectives and kind of also doing business level monitoring so using like a tool like dynatrace to figure out

you know how are users actually working with the software that you're monitoring how many people come how many people use a certain feature and one of the the things the software that you're monitoring, how many people come, how many people use a certain feature. And one of the things, the challenges that I've seen a lot is that people say, ah, yeah, SLOs is a great concept, service-level objectives or business-level objectives, but we don't really know what this means for us. We don't really know what the expectations are. And now the question to you, did you, with developing a new feature like AppSec, did you have expectations on, and did you also then monitor and validate against, like, how many people, how many new users you wanted to onboard to that feature?

How many, did you have expectations on how the features were used? And then did you monitor it and validate it against your expectations? Yes. So we had, of course, expectations and assumptions. And but I so to be truly honest here with a new solution or a new feature, it's always really hard to guess. Of course, you have a gut feeling and you have data in place and that you can base your assumptions on.

But in the end end it's assumptions and i think um as long as you don't have data um that proves your assumptions it's still just assumptions so i think in some fields we were pretty right with our guessing and assumptions but then in others maybe we didn't consider this or didn't consider that. And so they were quite off. But the cool thing is when working HL, that doesn't really, like, it impacts you, of course, but you are so quick with iterating and, yeah, bringing out the better iteration of your last iteration so that it doesn't really hurt. If you're really HL, you should really, like, that's a quick process. You can always bring out the new iteration and the new, yeah, new version that is better than the last. And I think, yeah.

So I think having those assumptions and having those expectations is good to have, like, a base to start from somewhere. somewhere but in the end you need to validate and then iterate yeah and also one thing that i wanted to highlight this is why i was really so intrigued to talk about this topic today and i always try to find the link to some of the other topics we have discussed with our audience in the past um if if you are if you're listening to this and you are trying to define slo service level objectives and from you go to your business and then they say well we don't know what the objectives really are make something up i think this is the wrong thing i think you should now ask the question hey do you have a target persona in mind who are the target persona what do we expect them to do

how many let's say how many how many people of the target personas are in our addressable market and what do they expect right do they expect one second response time when they open up this feature or five seconds uh do we expect five people a day or 50 people an hour and and things like this are better expectations that are now aligned with target personas. Because every target persona, as you also said, like Archie, you're expecting Archie to click through every page while you have developers, different target personas that hit a different page. And I'm pretty sure you have a certain ratio in mind of how many Archies you have and how many developers get in place. And this is all valuable data that helps us to A, define SLOs for production,

but also going back before production because just by the way, you understand Brian and I have a big history in performance testing and performance engineering. So one of the biggest challenges there is always to figure out what is a realistic performance test

and knowing how many different target personas you have and how big this target persona batch is and how many will use the product at a given time frame will help you define and run better performance tests. And this is why I really like that we have this discussion. Because for me, and for you especially, I think it's just common sense to have target personas. But for some of the listeners, maybe it's like, huh, maybe I should ask my company if we have target personas but for some of the listeners maybe it's like huh maybe i should ask my company if we have target personas and if not we should discuss this and if we have then you know give me the details yeah totally true and and yeah as i said i think that the the most

important thing is then to first find out if everyone has the same persona in mind and then if that is true start the whole persona process yeah to not also to not head into different directions actually yeah exactly because organizations are big like ours is big right and we have i mean i started when i approached you we were going down the the track of defining target personas but then we tried to figure out if somebody has already done it and then we stumbled across your name and then we kind of figured out not let's not reinvent the wheel let's make sure we all have the same picture and when we talk about a particular persona yeah and i think it also helps in

discussions i think when doing a new feature or yeah some big new thing um everyone has this vision and sometimes it's just not the same or you have contradicting opinions and stuff and i think it really helps to then have a persona because then it's not about your opinion anymore it's about so putting yourself in the shoes of that persona and then arguing from that uh point and not from your point of view and i think that also makes it easier to define an mvp to um yeah even discuss things together because then it's not your opinion anymore yeah cool yeah so um that means today what's the situation today when you define new features? What has changed when you started a year and a half ago?

Yeah, I think a lot has changed, actually. So, we, of course, established the personas, had a meeting with the whole team and explained to the whole team what we came up with. After that, we included personas in all of our epics and stories, as I mentioned. So whenever we start writing an epic or a story, it always starts with the persona, as a persona I want to. And then what also is really cool is that now when we do presentations or have meetings together, it's easier to tell the story

because you can always start with, now we have our persona Archie, and as you know, Archie is like this or is like that and needs this and that. We came up with that new feature because that helps solving this and that pain point. So I think it also helps in storytelling and being on the same page with new stuff that we have. And then, of course, it helped the team a lot. I think the cool thing that happened in our team is that we really only just take the names now of our personas

and we don't say our users. we really say like Eric or Archie. So it really kind of, it's in our daily lives now. And everyone just talks about those personas from now on. And I think that helps, as I said, in discussions and in our meetings a lot, just being on the same page. Always having the user in mind as a standard yeah all right i like the example in it and as you explained this you always have now let's say archie coming back to to archie as a person if we consider right let's say archie had a bad night

because he was woken up because of a security issue how can we make sure that he will have a happy ending of the day um and what can we do right and so now we need to design features exactly for that persona but also maybe that persona in a certain specific situation exactly and that's exactly what we do so we really try to come up with a story because then it's easier to relate. And one thing we did there is that we have this one day in the life of thing. So that means you really try to sketch a day of the persona from getting up to really going to bed. So that you understand where this persona gets the news from, which channels does that persona like to use to stay informed, what are the touch points and stuff,

and then also what the pain points are throughout the day, what the issues are, where maybe there is stress or yeah. So things like that. And then also to understand when maybe is their person more likely to take a decision or stuff like that. So it really helped, I think, to to try to have a day of Archie or live a day of Archie virtual, of course. But yeah, of course.

Cool. Hey, to Babba Yeah, of course. Cool. Hey, Baba, to conclude, what's next? Are you done? Or what's the next step? So as I said, we're never done. Personas are never done.

We, of course, iterate and always try to improve with how we shape our personas. And then, of course, we want to roll that out in the whole company. So we already started an initiative to do that now. We are at the moment coming up with templates and just to give guidance to all the other teams

that are working on new features. And just roll it out to every other team. What we achieved so far is that we have proto personas now for everyone, but then also give a little bit of guidance on how to validate and how to do those interviews maybe and the service and stuff like that. Very nice. Barbara, thank you so much for, first of all uh agreeing to doing this podcast i know it was your first and you did an awesome job because remember you are the expert

in the topic and that's always what i remind people of that are starting with either public speaking or doing things like this you're the expert in that topic and you are sharing your experience and that's great so thank you so much thanks so much it was an awesome experience thanks for having me again yeah and also um just for the listeners if you have any questions right you will probably hear this on your most favorite podcast app or on youtube or wherever else we publish this if you have questions feel free to drop us a note at pure performance at dynatrace.com or you can also find us on twitter it's pure underscore dt and uh we will definitely make sure to um barbara we typically do a little

write-up of the episodes so if there's any links of additional material that we can publicly link to you just let me know and then we'll add it to the summary okay all right with this i wish all of you a happy good summer because we are taking a short break over the next couple of weeks well i guess when this airs i'm probably already back from vacation barbara what about you have you uh any vacation plans are you done i have of course i'm planning to go from vacation barbara what about you have you uh any vacation plans are you done i have of course i'm planning to go to america and i still hope that works oh good where you go uh going to orlando because i'm a huge universal studio fan ah the florida in the summer that's mean it's going to be boiling, but yeah, worth it. Yeah, very good.

Well, then all then enjoy your trip. And for the rest of the listeners, hopefully you took a couple of notes today. I hope it was inspiring for me. It was a great new topic and I definitely can see how it spans over to what we're typically doing. We talk about DevOps as really3 specifying sls and really in the end we try to help our organizations build software that really solves the pain points of your end users but for that you need to know your end users and i think this is where target personas come in because you then better identify these personas i think you can feel empathy that's also why i like the empathy map so much that that's that's the one thing that I took away with me.

And yeah, that's it. With this, I want to say goodbye. See you next time. Bye-bye.