Don't Underestimate the Power of Coworkers as Usability Participants (feat. Daniel Diener)

Daniel Diener discusses his book chapter "Don't Underestimate the Power of Coworkers as Usability Participants."

Sponsored by Watch City Research
Watch City Research is your trusted UX research partner

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Transcript

Dan Berlin: 0:14

Hi everyone, and welcome to another episode of the 97 UX Things podcast. Dan Berlin here, your host and book editor. I'm joined this week by Daniel Diener, who wrote the chapter "Don't Underestimate the Power of Coworkers as Usability Participants." Welcome, Daniel.

Daniel Diener: 0:29

Hi, Dan, how are you?

Dan Berlin: 0:31

Alright, thanks for joining the podcast.

Daniel Diener: 0:34

Thank you for giving us the opportunity to talk about our chapters.

Dan Berlin: 0:38

Yeah, no problem. Can you tell us a little bit about yourself, please?

Daniel Diener: 0:41

Yes, of course. My name is Daniel. I am living in Germany. I'm now working since five years - No, nine years at Porsche, so the car manufacturer, in different positions. Because our chapters now two years ago, I was remembering that when I was writing - the chapter was building up the UX design operations team at Porcher for digital products. Now, I joined a different position. Now, I'm, for nine months, a product manager for our rental and subscription platform at Porsche. So, we are now giving people the opportunity to experience the thrill of driving a Porsche, our product vision.

Dan Berlin: 1:24

Very nice. Sounds fun.

Daniel Diener: 1:25

Yeah. Oh, yeah. Is it?

Dan Berlin: 1:27

So you mentioned that transition from research to product management within Porsche, but can you tell us your entire UX journey there? How did you discover UX and wind up where you are today, please?

Daniel Diener: 1:40

I kind of stumbled into the topic. At the beginning of my career, I was studying sport management. Then, I worked in the online marketing field for a soccer club in Germany. And one of my first product was the development of the new website for the soccer club. I don't know how and why - but somehow, I was motivated to create a kind of prototype to just explain the agencies, explain to other people how I imagined the website should look. It was the first time that I was using a wireframing tool. It was Zabich back in a time. I'm not sure if it's still available, but it was a nice tool to show other people, our stakeholders, what was my idea? So, this was basically the first time that I somehow got into UX. But I didn't call it, later then, user experience. After the really, really emotional time at Dortmund, at the soccer club, I went to Porsche. There, I had different positions. But at the end, I was part of the marketing communication department. We were responsible for corporate design, to corporate identity. So basically, we approved all the screens that agencies or people were doing. So, we were a kind of the approval. But to be honest, I was more intuitive; what was the thought behind the screen? So, how did people get there? This was more my interest, or I was interested. This was also the idea, also the starting point, where I got into design and also UX. So basically, I'm not sure, but maybe I was one of the first UX designers in the digital-field Porsche and ecommerce store. This was a really nice experience. So, also doing some things for one product. But at the end, I thought it's really nice to do it also for more and more products. This is why also the idea became to build up UX knowledge, build up UX methods for other products at Porsche. This was also our starting point- to develop a new UX design operations team. I designed for five years, and it was an amazing journey. In that time, I also was writing the chapter about that we are talking today.

Dan Berlin: 4:19

Great. Yeah. Thanks for all of that. Do you remember what inspired you to make those wireframes for the football club?

Daniel Diener: 4:27

Sometimes, I was thinking that it's hard to express ideas when you're just talking about that. For me, it was easier to display it and to show it when I was doing the wireframes. When I did it, I was also thinking about, "Okay. Is it really working the way that I'm thinking?" Also, I was first testing some of the first ideas that I had. Also, I was thinking about how to structure the content, how to structure some of the kinds of elements. I didn't call it UX, but it was becoming somehow the first steps in my UX career. I saw that when you're showing something, it's easier for people to understand. It's easier for people to discuss. It's also easier for people to give feedback - what's maybe not working? What's working? It was also nice because I was sitting close to our developers back in the time. So, the discussions were on another level. So, they were more and more detailed than when I was just expressing what I was thinking with words.

Dan Berlin: 5:34

Very nice. Okay. Makes sense. So, you mentioned your chapter - you were building up the UX team while you were writing the chapter "Don't Underestimate the Power of Coworkers as Usability Participants." Tell us about that, please.

Daniel Diener: 5:49

At Porsche, it's really nice because I have lots of nice colleagues. So for me, it was obvious that when I'm doing a product, when I'm doing some kind of prototypes, I'm just asking some of my colleagues to get fast feedback. Because asking or also recruiting customers to talk about wireframes, to talk about ideas, is sometimes difficult. Then, it was also my first experiences when we are creating first digital products, when you're releasing every day or every sprint. So, you need to be really, really fast. I went also in a situation that I said,"Okay, I don't have enough time to test it. Okay, just build it." But it wasn't feeling right, from my point of view. Therefore, I was thinking about different possibilities on how I can do it. Because recruiting customers, getting valuable feedback from them - it's a lot of work to do. You need to be really, really well-prepared. Then, I saw when I'm just talking with colleagues, I really also get valuable feedback. Because they have also good opinion. They also have some domain knowledge out of their work. It was valuable, because they were thinking about things that I didn't see when I was creating my my product. And yet, this was the reason why I was thinking, "Okay, this is a really, really good source for me." It's also fitting perfectly to the way we are creating digital products with this fast and iterative ways, working in two-weeks sprints. In one of my previous projects, then, we started also working two-week sprints. But we recruited colleagues for each sprint to test these kind of ideas. So, it's getting more in a continuous way, in a continuous flow. So, we have always had it on the second Friday. It was a testing date, so I could be prepared. So I was really, really sure at the beginning of my work or at the beginning of my sprint. "Okay, this is the day when I want to test. We, as a team, could be prepared for that." It was also easier for me to prepare or recruit some participants and colleagues, also from different departments like accounting, purchasing, sales, and customer service. With every test, it was really amazing what kind of feedback they gave to me. It was a good source of knowledge. Also for the colleagues - that was really nice, because they thought,"Hey. It's really nice, what you're developing. I can give you some kind of feedback. You're building up this feedback. So maybe the customer won't ask the customer service for this." So, this was the beginning of the way that I was thinking, "Okay, I need to ask my colleagues. Or it's easier, faster for me to ask colleagues before I was testing with customers." Not to say that, please don't test your customer. It's really, really important. It's valuable. From my point of view, it's also one of the most important things. But I'm also saying if your colleagues are not able to use your product, or don't understand your product - then, the customer won't do the same. So, this was the intention also to write in this chapter. Because it was for me a huge, huge way towards getting faster, getting valuable feedback, and creating better products for our customers.

Dan Berlin: 9:41

You made a great point about how sprints are good, in terms of iterating and advancing the design. But the research operations associated with bringing in participants every two weeks and the expense associated with that. We could alleviate that with your coworkers as participants. My question for you there is about bias. Is using coworkers biasing your research? Is there a way to get around that?

Daniel Diener: 10:16

Of course, they are having a bias that you cannot - it's not really easy to get rid of it. But from my point of view, when you're testing for- at least testing usability, there are some points that they can help you. So, I wouldn't use coworkers when you're trying to research some things, like a user needs, some behaviors of your customers. Their coworkers cannot help you, because their bias is really, really big. But all the things when you're testing, or when you want to conduct testings about usability- they are really, really good. They can see almost the same things that customers can also see. Therefore, when you're talking with your colleagues - just keep in mind, do testings and usability testing for that. But never use it for a user-needs evaluations or some other research methods. Don't do it.

Dan Berlin: 11:20

Now that's a great point. Stick to coworkers for usability, but avoid them for generative. How about finding the right coworkers to have as participants? Do you have any tips in terms of finding folks to bring in?

Daniel Diener: 11:35

That's a really important step. So, when I was starting, I built up a database and also huge network. So, it was connecting with other people's at the beginning that I know. After testing, I was also telling them, "Hey. Please. If you know somebody who would like to do or give some feedback, please just let me know. So, the first tip that I can give - start to build up your database, start to build up your knowledge network. Then ,it gets easier for you to recruit people. Because you also don't want to bother them and recruit all the time, the same colleagues, the same people, right? It's work. It's a hard work to build up the network. But it counts, and it's valuable. It will help you to be really fast and efficient. So, you can also use tools that you're using in your company. So for example, if you have a Microsoft team's account, you can start to build up a group where you're posting some invitations for testing. So, you're building up your community. You're sharing the link that they can just join the community and see some new testing. So, there are multiple ways and multiple tools that you can use. But it's work. You need to do it. They won't come to you.

Dan Berlin: 12:59

Right. I always say to folks that recruiting is the worst part of our job as researchers.

Daniel Diener: 13:04

Yeah. But it can also be fun. Because networking, getting to know new people could be also fun. So...

Dan Berlin: 13:12

Great point

Daniel Diener: 13:12

Start to enjoy your recruiting.

Dan Berlin: 13:15

You mentioned tools. What tool are you using to track participants? Are using just a spreadsheet? Are there other tools you're using?

Daniel Diener: 13:25

So on the one hand, you need to take into account data privacy when you're talking with your colleagues. Because at Porsche, you need to really take care of it. Because it's really important for us as a company. So, mostly spreadsheets are helping you to know, "Okay. How often did I contact somebody?" But at the beginning, when I was starting, it's more about feeling you know who was participating. You also conducted the testing. So, you're aware if people are willing to do another testing. Or if it was just a way that they said, "Okay. I want to do it for you, Daniel, because I know you. But not for anybody else." But tools can support you. If you're allowed to use some of the database tools - they can make it really, really efficient for you to build up your network, build up your database. To be honest, this was also one of my advices maybe later on. But there are so many tools online that you can use. So after COVID, people are used to video calls. So beforehand, it was not familar for you. Today, if you're just going into the internet, you can find lots of tools and lots of software that can support you in the entire UX research process, or in the UX design process. You just need to reuse it.

Dan Berlin: 15:04

Do you have some examples there? What software in particular?

Daniel Diener: 15:06

For example, when you're doing analysis you can use Dovetail as a research repository. For example, uploading your videos, analyzing the transcription software, supporting you with tagging, and analyzing the software. From my point of view, one of the most important thing - sharing your insights and sharing your knowledge. So therefore, Dovetail could really help you explain when you want to build up some prototypes - really fast prototypes to have also high fidelity things that your colleagues can test. So, this can also support you. There are many, many more that we are also tried to use- we also encountered at Porsche, within my previous role at the UX design operations team.

Dan Berlin: 16:02

Cool. So, Daniel, what else from your chapter were you hoping to convey here today?

Daniel Diener: 16:07

There are, from my point of view, two points that I would like to mention here. So on the one hand, it's ritualize your research. So, when I was starting with testing my products, it was, more or less, not ritualized. So, it was always stressful because you wanted to get, as fast as you can, some kind of feedback. When I started to realize, "Okay. When I just do it on a Friday, then it's not as stressful as it was before." Because you can prepare. It's also easier for your colleagues, that they can get out and schedule their day. So, they are aware that you can- or they are aware that on Fridays, do some testings. So, your database is already aware of that. So, ritualizing the research is helpful. It was really, really helpful for me to have this organized this way. The second point - it was building up a community event. Because I was doing all the things. I was doing research. But from my point of view, I also wanted to have the possibility- or give other teams the possibility- to get this knowledge and also to have the possibility to test with coworkers. So, it started at Porsche event; it's called Usability Testing Marketplace. So, it was taking place once a quarter. The first two times was a live event. So, teams had their own stands where people could test their product. So we had some laptops, where you can test the digital products. But also somebody brought some Lego stones, where he did a card sorting, for example. Or they printed out some websites and did some A/B testings, or preference tests, and other things. That was really amazing how creatively my colleagues went. We had five teams that participated at this event. Then, we did some advertisement. Or, just get all the floors and said, "Hey, come. You can test your product score from stand-to-stand and see what the what people are doing." From my point of view, this event, on the one hand, helped other teams also to get aware that testing is helpful. Also, testing with colleagues is helpful. It was also a nice event for colleagues. Because instead of doing a coffee break, they could go there and conduct some testing, learn some new products. They also get to know some other colleagues from Porsche. This was nice. During COVID, we did it in a remote way. It also worked, but the atmosphere was not there. So, I'm hoping that now we will also do it in

Dan Berlin: 19:09

Right. face-to-face meetings. Because it was amazing. Yeah, that sounds wonderfully fun. What a great way to get buy-in from your coworkers. To show them what you're working on, and to show them your process. That sounds wonderful.

Daniel Diener: 19:28

I think there's also an online article about it. So, there you can also see some pictures. When you Google my name, then you can find it. Because it was amazing. I really liked the event and I enjoyed it.

Dan Berlin: 19:44

And what was it called again?

Daniel Diener: 19:45

It was Usability Testing Marketplace. When you're searching it with Porsche, you need to find it, or you will find it.

Dan Berlin: 19:52

Great. One question I want to come back to is the matter of incentives. It comes up a lot when we're dealing with participants on the outside. Obviously, we have to incentivize them for their time. Do you ever have to do that with coworkers? Or should you?

Daniel Diener: 20:07

You could, or you should also give them some kind of incentive. So for example, some lanyards or other things that you could. But at the beginning, I didn't. I wasn't thinking about that. It was totally okay for them to spend time together with us. Because one of the incentive for them was also to learn and get to know some kind of product for Porsche. It was already in value for them. And it was amazing. This was the reason why in the first testing sessions, I was never thinking about incentivization. But as we, when we did the Usability Testing Marketplace - we, of course, had some pretzels, some local food, and also some drinks. So, this was incentive enough, and the people enjoyed it.

Dan Berlin: 20:58

Food always brings the people that makes sense.

Daniel Diener: 21:00

Yeah, you're totally right. That was helpful.

Dan Berlin: 21:04

So, Daniel gave us a lot of great information here today. I really appreciate you talking about your chapter. In our final section, we'd like to get a career tip. So, is there a career tip you'd like to convey to people, either breaking into the field or who have been doing this for a while?

Daniel Diener: 21:19

So my career tip is build up your toolbox and tool knowledge. So when I was starting, I was always using some software and some tools that you can find on the internet. I was always looking for tools and for software that can help me to do the entire workflow for creating digital products. So from recruiting people, there are lots of software outside that can help you - also with cheap money, because you can do it really easy, really fast, and cost efficient. If you want to do them for prototyping, for creating some screens, to analyzing - there are so many things outside there that you can use. Then, you are prepared for everything. Because from my point of view, spend most time of your work thinking about problems, thinking about to solve problems, and use tools. This makes it really, really efficient to work. Or, spend your time on work that will solve customer problems or user problems. And not waste too much time and inefficient work. So, as we thought at the beginning of our session, recruiting could be really, really hard. But if you have the right tools, if you have the right software, it can be really fast and also efficient. This is the most important thing.

Dan Berlin: 22:47

Well, thank you for all of that. You gave us a lot of great information here today. My guest today has been Daniel Diener, who wrote the chapter"Don't Underestimate the Power of Coworkers as Usability Participants." Thanks for joining us here today, Daniel.

Daniel Diener: 23:02

Thanks, Dan.

Dan Berlin: 23:03

And thanks for listening everyone. We hope you enjoyed this. You've been listening to the 97 UX Things podcast - companion to the book 97 Things Every UX Practitioner Should Know, published by O'Reilly and available at your local bookshop. All book royalties go to UX nonprofits, as well any funds raised by this podcast. The theme music is"Moisturize the Situation" by Consider the Source. I'm your host and book editor, Dan Berlin. Please remember to find the needs in your community and fill them with your best work. Thanks for listening.