Creating a positive emotional experience for the developers who use our products is the job of everyone across the company.
In this talk filmed at DevXcon 2018 in San Francisco, user experience and design executive Peter Merholz explains why everybody should be responsible for empathy.
Tamao: I wanna ask, how many people have heard of Peter Merholz? Okay.
Peter: A few. That’s good.
Tamao: So, one of the reasons I wanted to bring Peter here just overall, right? We don’t want to be navel-gazing. We don’t want to be swirling in our own similar faces and people we know in the conversations we had, because there are obviously other fields, departments where maybe they’ve been thinking about a lot of our problems, maybe even decades before we are.
And just because it’s for different audiences, or there’s a slight change or maybe a major change, there’s still so much that we can learn. So I was very thankful that Peter is willing to come out here and have me accost him with a bunch of questions and hopefully we’ll have time for you to ask them as well. So I thought I’d just kick off. So we had a good number of hands, but for people who haven’t heard of you as you are kind of different from our field. When you started Adaptive Path… Yeah. Well, it was a long time ago. What were the challenges and gaps…
Peter: Origin story?
Tamao: What was the challenges and gaps that you said, Okay, I’m gonna address this and I’m gonna address this with a company?
Peter: Yeah. So for those who don’t know, Adaptive Path was possibly the first firm dedicated to user experience, not usability and UI design, but a kind of the broader notion of user experience. And we started it in 2001. And we were coming out of the first web boom and bust. And at that time, user experience had grown thanks to the boom but it had also not necessarily stuck. The bust had demonstrated, at least to some folks, that maybe this whole whether its user experience thing or web thing is not where you wanna kind of put your effort behind. So the task we had in front of us was demonstrating the value of user experience as a practice. We developed many practices for user experience and we were very public and writing and speaking about it and trying to kind of develop a community of, of user experience folks.
And also, you know, looking at subjects like in our second or third year, we researched the ROI of user experience because again there was doubt that this was even a valuable approach to building software or delivering, you know, delivering experiences to customers. So, that’s where we were in 2001. Most companies did not have internal design teams. Some of the bigger ones did but most didn’t. So when we would get hired in it would be because they had a marketing team or an IT team who we have to build something on this website and we need designers for it. We don’t have any so can you do it? You know, that’s probably the single biggest change in the last 20, 17 years is every company now has an internal design team. So those are the kinds of things that we were addressing.
Tamao: Excellent. So a couple more questions I have, but we’ll start off with two establishing positions that you have. One is my question. Is there such a thing as UI designed specifically for technical developer audiences?
Tamao: So that’s Peter’s answer.
Peter: Yeah. The approach to doing user interface, user experience design, the basic methods and approaches are going to be the same regardless of the audience, right? It’s understanding the people that you’re designing for, usually through some form of observation, taking those insights in, developing new experiences based on that and then doing some form of iterative design and prototyping to see if you’ve hit that mark. The specifics of where the UI lives likely changes, right? I have never worked on a command line interface, right? My audiences are usually either consumer or kind of business-oriented, right? Not as technical. I, it’s probably worth noting. I’ve never really worked in developer experience specifically.
And so, you know, my experience has been when developing UIs, it’s it’s usually a graphical user interface, originally software then web, now mobile kind of desktop software, then mobile. That said, the same principles apply whether you’re doing something that’s GUI or a command line interface. The same basic principles apply in terms of how to solve those problems. In fact, it’s the ways that user experience developed came out of software development in like the ’70s and ’80s. A lot of what we do, usability, testing and all that stuff was still rooted in command line interfaces from way back.
So, you know, the same approaches should apply, regardless of the audience. It’s going to be the final experiences, those artifacts, the places in which those experiences are realized. That’s gonna be where the difference is.
Tamao: So as I mentioned, we have a track that will be covering some of these topics and so I’m really excited to have the nuances of the different perspectives of how we might think about that. So the other thing that I thought was fun to bring up is, I did ask, well, you have kind of skimmed and had opportunities potentially to do developer experience and why have you not chosen them?
Peter: Yeah, so and I was chatting with Erin a little bit beforehand about this as well because I worked for two months at IBM. It didn’t take. No fault of IBM’s as a company, it’s a massive company and the different teams are going to be on are going to be wildly different. But one of the reasons it didn’t take and one of the reasons I didn’t persist was I had never worked in an environment where developers were my audience. And I realized that’s not where my passion is, honestly. And this is not to suggest that it’s not right for other people’s passion but my juices kind of flow when I’m working with… So at Snagajob, right? Helping 16, 17,18-year-olds get their first job, or helping a small business employer deal with the hiring process so that they can get back to doing the thing that they love and not spending all their time recruiting and hiring right.
There’s things that we find that we gravitate towards, and I just have not gravitated towards developer experience. I don’t have that kind of technical bent, I’m not as interested in serving technical audiences I guess as I am in serving kind of more either general interest audiences or people in areas that I find can be somewhat at in experiencing some challenge, right 17-year-old trying to find their first job, how do they show themselves or again small business people who don’t actually know how to run a business and they got into being in small business because they had a passion and then they realize most of their time is spent not engaging in the passion and trying to figure out how to just keep the lights on.
Tamao: And I was really excited that you know, we could share this through the conversation with Peter because I thought it would be very important for us to at least always think about grounding ourselves like, you know, what is it hopefully you are doing this because you’re very passionate or like as Mano said last night you know,” Are we in this for that sweet, sweet DevRel money?” Right? A lot of us aren’t, right? Where a lot of us into this because we’re very passionate and, you know, they’re different areas in which we know we’re serving, you know, our developer communities but I think there’s something to be said to keep grounding ourselves and checking in. Because we were just talking about a client in healthcare and every Friday, the entire company comes together and they gather and they actually talk about lives that they have saved based on the work that they do, or connected to the work that they do.
And I mean, I’m very excited by my job, I’m very excited by what I do, but I, you know, really led me to think like, you know, are there ways in which I could be in technologies where, you know, we could be thinking about more directly what the impact is. And clearly, you know, Peter likes to have that greater impact of working with individuals who, you know, have labor challenges or have business, small business challenges, right? A lot of people who might get stuck in a wrong path and need help. So I think that’s a valuable thing.
So with that, I wanted to kind of come back to…so right now, like, you know, you’ve had different jobs. So again, I don’t know if everybody is deep in the world of UX, but like when people hire you for companies and you’ve been at so many different kinds, what are they looking for? What do you come to do? Whether it’s sometimes you’ve consulted other times you’ve worked? What is it that they’re looking for when they, you know…?
Peter: Yeah, I mean, at this stage of my career, I’m mostly leading teams of designers. So I’m coming in, there’s usually a design team that has grown to a certain point, and whomever was leading that team is now out of their depth. Or it was being led by a head of product or head of engineering and they now need to bring someone in who’s focused on it, because it’s time to firm it up and, and continue to grow the team. So that’s typically what I’m brought in to do.
What I end up also doing, listening to some of the stuff that you were talking about before we came on stage is to, I end up trying to work to broaden the understanding of what experience and design means. I thought it was interesting, you know, the DevRel to DevEx to who are we, what are we? You know, how, where does somebody else’s job end and mine begin? We face the same challenges in the world of design and user experience. In fact, I tried to avoid calling my teams user experience teams because I think that user experience is a whole organization’s responsibility. I run a design team that contributes to the user experience, but product, engineering, developer relations, marketing, all of these teams contribute to those user experiences. And what’s important is figuring out how all these teams working together can deliver on that.
And so one of the tools that I end up using and I was happy to hear about Erin speaking about user research yesterday, I think it all begins with user research. With that authentic, honest, empathetic, you mentioned empathy, who owns empathy? Everybody fucking owns empathy, okay? Like you can’t let people get away with not owning empathy. If they’re not if they’re not interested in helping the people that they are building products for, do away with them.
And if that’s the case in understanding the experiences that the people you are serving have, whether you call them customers, developers, etc., research is a great tool for understanding it. One of the tools that I end up bringing into the companies that I work with is this idea of the customer journey. And I don’t know if folks are familiar with it, it’s emerged out of kind of service design, and now customer experience thinking, but it essentially recognizes that someone has a kind of a journey, a narrative that they are going on when interacting with your company. And it becomes a helpful model and a helpful anchor for thinking about the nature of the experience you are delivering.
And so for, for a developer audience, right? What does that developer’s journey? How did they first become aware of what it is that you have to offer them? How do they learn about it? How do they then start adopting it? How do they adopt it in small ways, and then maybe in bigger ways? What role do you play in trying to bring them along on that journey? How do they then maybe get other people excited about that technology, right? That journey is going to touch a lot of different teams within your organization. Developer relations, developer experience might be a lead team or a coordinating team.
But it’s gonna, you know, it’s going to hit your marketing team. It’s going to hit your sales team, it’s going to hit your product team, right? All those teams need to understand their role in delivering on that developer’s experience on that developer’s journey. And that’s so it’s bringing kind of models like that that help folks get out of their blinkered, siloed, specifically, functionally minded orientation and recognizing that in order to do right by our customers, by our audience, we have to work we have to figure out new ways of working together to deliver that experience.
Tamao: So I wanted to end with something that Peter had shared and please, please do come up to me if you are already doing this in your organizations because it actually was fairly new to me. So we chatted about the emotional journey and a lot of emotional pitfalls that a user can experience when they’re discovering or onboarding and all that. And you guys have worked on doing in your particular use case, not in DevRel but I think we could use someone taking like an emotional journal, right, through their experience and then if we have time you had knowledge of what Airbnb has done as well because you know someone experiencing Airbnb for the first time could have a lot of places where they have like emotional stress and then it just, you know, they’re off it right they leave off so I love to have you share what you guys did.
Peter: Sure I’ll relate the Airbnb story it’s pretty quick if you’re not familiar with it. Airbnb did a lot of research with their both guests and hosts trying to understand their journeys. And one of the things that they saw was that there were these moments of anxiety particularly earlier on in the development of the service because it’s weird. You’re staying in somebody’s house, right? That’s not something that we until recently considered at all normal but not somebody house, a stranger’s house.
And they identified these key moments where anxiety was high. The one that was where its highest is that moment when the guest is about to approach the front door of the place they’re staying and just wondering, is this gonna work? Will there be someone there? Will the key code work? Like that’s a period of very high anxiety. And so they’ve spent a lot of time and energy and resources, trying to manage that part of the experience so that people felt comfortable.
I, again, I’m not familiar with Developer Relations, I’m sure you have similar periods of high anxiety with your audiences that probably warrant greater focus and understanding. Because in the old days, we would like thinking back into the ’90s we sometimes call these “Moments of truth.” What are the moments of truth that people have with your company, with your brand that you want to make sure that you’re delivering on? That if you if you succeed, you win and if you fail, you lose regardless of kind of what happens elsewhere in the experience. There’s these key parts of the of the journey that need to be particularly addressed.
A tool in particular that we use… So at Snagajob, we did…we had never done a deep research on our job seekers. These again 17 to 24-year-olds trying to find a job and what that experience was like. We had a lot of data, but we didn’t really have that empathetic emotional understanding. So we conducted a two-week diary study, we ended up using a tool called dscout, it’s a meant for mobile devices where every day someone you gave you give them tasks or little missions, and every day they answer a few questions and upload a 30 second video about, for us, it was where they were in this process of this job seeker journey. Applying for jobs, going to resume workshops, the occasional highs of ‘they called me back’ and then the inevitable lows of ‘I didn’t get the job’ or ‘no one’s responding to me’ and just really understanding that emotional kind of cadence and valence was hugely powerful and helping us better understand and empathize for those customers and how we can better serve them.
So I love diary studies and there’s now a set of tools that make it very low effort for the participant and you learn a lot. Snapshots, just talking to someone for an hour is valuable but getting someone, engaging with them over time over a couple weeks if you can is even more valuable just because day by day, you know, that experience changes, right? So your snapshot will be very specific to where they were at that moment but over a couple of weeks, you’ll learn kind of how typical or atypical that was.
Tamao: And one last question. Did you guys offer anything to these people who volunteered to put two weeks of their time?
Peter: Oh, yeah, yeah. So any user research we pay participants. I don’t remember what we offered them over the course of a couple of weeks, something like that. Probably a couple hundred dollars, right, to take part in something like this to keep them honest, maybe a little less, maybe 150 bucks. For a professional audience, you might need to offer more. But you can also be clever, right? You might be able to offer them access or subscriptions or whatever that your company provides that they would be happy to take in lieu of money and doesn’t cost you anything. So yes, you should expect to compensate your participants.
Tamao: Excellent. Well, thank you so much.
Peter: Sure thing.
Tamao: And I hope you found this useful. We are told that we’re at time but I think you’re gonna be here a little bit for the break. So if you have any questions, please talk to Peter. So thank you so much.
Peter: My pleasure. Thank you.
Can you make good release notes by collating your commit messages? Eva Parish argues not.
Can negative feedback from customer satisfaction surveys have a positive impact on your developer experience?