Developer experience is user experience

Transcript

Speaker 1: I am from, Robots and Pencils. I'm actually the CTO of Robots and Pencils, and we're an agency. We also build products. One of those products is called BeepBoop which is a developer platform for building and deploying Slack integrations. But today we're gonna talk about developer experience.

Speaker 1: And so when we consider developer relations and we talk about the purpose of developer relations and we've heard about this today like the functions of developer relations pushing back influencing the platform and product as well as pushing out to developers and working with developer community. I really like I borrowed this from Ray O'Meyer on his blog post. He's a dev for Google Android team. But basically, if you look at this graph, the interface into the virtuous cycle, right, which is that developers build better apps that build you know, lead to better user experience, lead to more successful apps, and a more successful ecosystem that then feed into better apps. The way then to fuel that is to just pour more and more fuel onto building better developer experience and I really think that's the job for the most part of developer relations at least as it pertains to making developers successful and I think at least in my mind and my full time role isn't DevRel which is kind of interesting but when I look at DevRel especially as a developer and having you know almost twenty years experience as a developer I would say that developer relations program should be measured by developer success and when we talk about developer success and what makes them successful it's very similar to user experience And so Don Norman who's sort of one of the founders he was actually the first person who had user experience in his title when he was at Apple in the nineties.

Speaker 1: And what he said of user experience was that it encompasses all aspects of the end user's interaction with the company, its services, and its products. So much broader than a lot of times what we come to think about user experience as. When we say you're a user experience designer a lot of times that means that you design user interfaces but it's much broader than that. And so I didn't have another picture to put here but to the template so I guess I said this, I don't know I just replaced some of his words but basically I would say a developer experience encompasses all aspects of the developer's interaction with the company, its services, and its products. And so a lot of times we think of DevRel and we put developers sort of in a box and we think of them only in relationship to our API docs or APIs but it really encompasses everything including your product not just the platform.

Speaker 1: When we think about what is the developer's experience, what's the relationship with that product? And so I think we could borrow some tools from user experience research to sort of help shape our DevRel strategy. And one of those is personas. This was mentioned in the last talk of basically, don't just assume that your developer is one thing. Developers are diverse.

Speaker 1: You could they could be academic in school. They could be hobbyists. They could be at large enterprises, at start ups. Identify and design personas around what developers you're you're targeting and in ways that describe and personify them to better understand who your target audience even is. In addition to that there's a thing called journey maps which basically tracks major life cycles through your product.

Speaker 1: This could be sign up, this could be getting through your first getting started guide, but basically what you're doing is you're tracking throughout that process how the developer feels. Are they happy and delighted or are they angry and anxious and displeased? And so this this helps you kind of visualize some of the key journeys in your product. And then third is really just watch, ask, listen. To your developers, actually listen to what they say And then I'll show you some ways to do that.

Speaker 1: Number one is just care about how your developers feel. Because how they feel is really what their developer experience is. And a lot of times we don't really empathize as much with developers. We empathize with users and we talk about that a lot. But I think there's a big lack of empathy.

Speaker 1: Irony of the Amazon Alexa example is Amazon is the one that says we are the customer service company. That's their that's their goal and their mantra. But what we hear today is that it's not it's not that simple. And I think, though you can say those words, I I think they could do better. So how do we measure how developers feel?

Speaker 1: I'd like to share with you perspective from professor Noriyako Kano who in 1980s in Japan he was really looking at quality and the impact that quality had on customer satisfaction and basically said that he didn't find a linear relation between quality and customer satisfaction and that if you make a product better it doesn't necessarily mean the customer is gonna be more satisfied. Makes sense, right? And so he developed this model. I think it's a model that we could use for a lot of things. It's used in user experience design and I think it can certainly be used in developing our strategy around developer relations and developer tooling, API docs, developer support, all those things.

Speaker 1: So let's just walk through this. So basically there's two axis here, two dimensional. This horizontal axis is quality. So this is basically if it's nothing garbage crap or not done at all all the way towards done sort of to perfection and completion with a high amount of investment. And then on the Y axis all the way down here is sort of your most area of despair and disgust as a developer or as a user and all way up here is delight like full complete elated delight.

Speaker 1: Right? And then so what we can do is look at several categories that the Kano model describes to help us think about certain features, certain services and the first one is called baseline expectations and so these are the things that if you look at a category of products you would say the product must have this or actually your users or your developers would say it must have this. However there's something interesting about this category. Like if you look at over here, so if you if if you basically invest poorly or don't do it at all people are extremely unhappy. But the more you invest in it you get to this point where they're happy enough.

Speaker 1: They're basically you know content. But no matter what you can do you can never make them happy. They'll never be delighted that that exists. So API documentation for example and I mean Stripe everybody uses as the example, it's great. And I think people appreciate that but and we say that especially we appreciate it right as developers and as a DevRel community.

Speaker 1: However, most people won't say I love Stripe because of the documentation. Say Stripe they they love Stripe because of the actual experience of using the product and how easy it is and how easy it to collect payments. If the payments bit was horrible and the documentation was great you'd think that they were upside down completely. In addition if there no document if no documentation or it's just complete rubbish then people will be very unhappy. So these are the things that you have to gauge you have to do them they're expected but you have to be careful how many resources you pour into them because you get marginal returns in the long run.

Speaker 1: The second category are called linear satisfiers or sometimes they call these performance and basically what these are is the more you put in the more you get out of it. So the more you you invest in it the more satisfaction you get out of it. And this people usually use price as an example or let's say even credits, like free developer credits. So the more you give developers free credits, the more they use and the happier they are. Right?

Speaker 1: These are things that are very linear. And the third category are delighters. And so these are the things that if you survey your users and ask them what they want of a product, let's say your developer experience, they usually would never would never think of typically. Right? They would they would usually not request this thing but when they get it they're delighted.

Speaker 1: They're happy, they're amazed, they're pleasantly surprised. And so and even just by if you look at where this sits on this graph even just their existence or almost the that you made an attempt makes them happy and delighted and the more you put that in makes them, very excited and happy to use your product. And so here's an example of that from a sort of developer relations perspective. So, who's here, familiar with Clearbit and Alex McCall? Okay.

Speaker 1: So Clearbit is they offer an API for company data. Really interesting. But so I signed up for their API and I got this email from Alex and I knew of him at least. And this is just a form email that goes out to anybody that signs up for their program. He's the founder and CEO, but he says I'm a developer and founder of Clearbit, and I just wanted to say hi.

Speaker 1: And basically if you're local let's go grab coffee or we could pair together and that's the thing that really stood out for me. So he's like totally making himself available. I didn't take him up on this but I've shared this over and over and over again. Delighters are those kinds of things that when people are delighted with your product those are the things they tend to share with people and I've had a positive sort of view of Clearbit even though I barely even use the API but if I need an API for that type of thing I'll go back to it. So perfect example of a delighter.

Speaker 1: There's another sort of category of product that's called indifference. And these are the things that you really wanna stay away from. So what this basically is that no matter what you do, whether you do it or not, or you do it to the best of its ability people just don't care. They don't care enough to be dissatisfied and they don't care enough to be satisfied. And you'd be surprised how many of these things we do on a day to day basis.

Speaker 1: If your intent is to drive developer satisfaction and emphasize how they feel look at the things that you do on a day to day basis and how you actually impact developers and I guarantee you'll find things that have nothing to do with how they feel and they wouldn't really care one way or another whether you do that. And so if we look at all these together it gives us this model sort of categorizing different features and where we should focus. And again the important thing to to mention here is with baseline expectations these are the things that you have to do in your product. If you don't all these other things don't matter but the key thing is you don't have to do them extremely well you just have to do them. So the Kano Motto is really a framework for prioritizing developer satisfaction and delight.

Speaker 1: Andy Piper was here, might he be here, I don't know. There he is, Andy. So this is basically my story of my perception of Twitter as someone who started using Twitter in 2007 and sort of went through the cycle of what Andy described. And don't get me wrong, I love Twitter. I love developing for Twitter but I wanted to describe basically having empathy for a developer and this is my perspective, sort of what this looks like.

Speaker 1: And so Twitter launched their API in November 2006 about six months after sort of the first tweet. Was very early on even at that point the sort of ecosystem of Twitter was exploding. It was amazing. It was actually it was really the first social API ever at the time where you had just a massive amount of data from all over the world all sorts of people that you weren't even connected to, and that you had geolocation information. You had lots of interesting intersections of data, and it just exploded.

Speaker 1: So all these apps up here you see were created by the developer community. It's the thing everybody wants. You open up this API, even before they opened the API and people were scraping their web API, it just exploded. Awesome successful story with Twitter. Then Twitter got to a point where trying to really needed to be able to monetize the product and needed to be able to control the user experience more.

Speaker 1: And this is kind of how I think of it is like you have this amazing powerful thing that you kind of lost control of and then you've got to figure out well now what do I do? And so along came some of those reactions. Was oathcalypse, that's a really hard thing to say, should all try to say that, which was the restriction of authentication. In the beginning you barely had to authenticate for anything and then when you did use basic auth and it was basically wide open. It just threw open the doors in the beginning and gave everybody access to it and just saw what they did and they did amazing things.

Speaker 1: Then there was what I call the Clone Wars, here's my Star Wars reference, which was basically the battle of Twitter battling people that competed with the core features of its product trying to diminish those. And then there was just like lots of sort of angst around the developer community as Twitter kept removing sort of these features that people expected. That's kind of the key thing there. And then as Andy described at flight I think this is 2014 and we shared the same slide they announced all these developer tools geared at mobile developers and the reaction was sort of one of consternation from the developer community at the time. Know which is, you know, if you're familiar with the sort of Peanuts, scene here which every time Charlie Brown tries to kick the ball Lucy pulls it away, right?

Speaker 1: And then tries to convince him to do it again. Know, it's like fool me once, shame on you, fool me twice shame on me. And so all the way to the point in I think it's 2015 when Jack Dorsey took over again as CEO and stood up and basically apologized to the developer community and said we're gonna reboot the whole thing. We're sorry that we and this was like they owned it. We're sorry we created the confusion.

Speaker 1: We wanna make sure that we are learning, listening, and then we're gonna reboot the community. And it's awesome to see that but it's like any relationship takes time to heal. So if we plot out this journey map and this again is like my Twitter developer journey as someone that developed for Twitter very early on. This is how I felt about it. Early on it was amazing even before there was no API people were doing things with it.

Speaker 1: They were scraping the web API and then when they launched the API it just blew up and people and just you you had the first iPhone app for Twitter mobile app wasn't by Twitter TweetDeck obviously wasn't by Twitter even though they acquired them. All these things the first social content search wasn't by Twitter. Like the community exploded But then here after sort of the honeymoon and then, well, thought about clips, I can't say that, and the Clone Wars and then tools from over developers, how I describe this is initially there was some pain but then people got over it because it was just off. But then once Twitter started to limit your API usage limitations, terms of services got more strict it was very sort of discouraging and there's again lots of consternation. But we're kind of back at this point where it's like over time heals all wounds and you're sort of back level set.

Speaker 1: I think it's like the perfect time as this reboot continues for Twitter for them to pick that up. And this isn't a cut on Twitter. This is like this is what people would describe as a good problem to have. This happened in the first place. This doesn't happen barely to anybody at that scale, amazing.

Speaker 1: And so if I break this down and you look at these two sections I was delighted as hell up here. So we look at the categories of features Twitter launched it was like an API of its kind had never been launched with that type of data. People were blown away doing all sorts of things, had nothing but great things to say about Twitter. I think that's what really produced this delight. Down here was actually directly influenced by what happened up here and this is where I talked about basic expectations.

Speaker 1: Basic expectations are not necessarily things that you expect it's what developers expect and and they sometimes they're in your control and sometimes they're out of your control. In this case it was very much in Twitter's control, my hindsight being twentytwenty when they launched this API threw the doors open and see what to see what people would do with it they did amazing things. However I think what really drove at least again this is from my perspective here what wasn't met is this basic expectation of what I got up here which was like full unbridled open access to tweet data Right? Which then that got taken away from me. Then even as this optimization when flight happened I was kinda disappointed because even though they launched a whole bunch of new tools that I could get excited about I feel like I still my basic core expectations weren't being met.

Speaker 1: And so it's another interesting thing about how Kano described this model is basically that there's a natural decay of delight into expected features and so the delighters that you launch today become expected soon after. A perfect example this is is Wi Fi on an airplane Right, if you ever seen the Louis CK video where he talks about he talks about that happening much much faster but in general like when we first had WiFi on an airplane you were just happy to connect and be like, oh it's working, get them in a plane, know. But then now you go on a plane and you're just like this is bullshit right? There's no WiFi or it doesn't work or it's slow and it's not meeting our basic expectations of flight in general. Really how do you do this?

Speaker 1: How do you execute on the Kano model? It's a good thing to look and say well that's how you quantify different features or services but Kano maps out a pretty easy process of actually collecting this information and what you do is it's it's a survey and for each feature that you want a survey on you ask two questions. How do you feel if you had it? And then how do you feel if you didn't have it? And based on that you answer with the most positive is I like it and the most negative is I dislike it and the middle is I'm neutral.

Speaker 1: And the others are I expect it to be there don't necessarily like it or I can tolerate it but don't necessarily dislike it. And so then with that information you categorize those features on a chart and there's some here that are a little bit confusing like everything here marked reverse is basically someone said I love it if it was there I love it if it wasn't there right so those are kind of the reverse and that that either tells you that your survey is confusing or that people really don't care like they just are like love it love it love it CC CC on the test whatever but for simplicity we'll remove those and then indifferent all these things here that's basically what we described as those are the things you want to stay away from people are basically indifferent of whether they're there or not And so the ones that really care about are these delighters, the linear satisfiers, and baseline. Linear satisfiers are great if you can get them but again it's based on how much you pour in is what you get in a linear way whereas the delighter can be sort of exponential in nature.

Speaker 1: Again basic expectations are everything that you need to do. So with basic expectations if you actually look over here and up top is this is where you plot out if the feature was absent and someone said I would dislike that. So if you said API docs, that was my example before. If you ask someone how would you feel if there were no API docs for the service? And they said well I would dislike it no matter what I would dislike that.

Speaker 1: But if you said how would you feel if there were API docs? And they go I would expect them to be there, I really don't care, I could live without them. So people answer things differently when you say like I could live without it but they'd say what if you didn't have it? They say I didn't like that. Those are the things that are basic expectations and that's how you look at this.

Speaker 1: And so just in review I would encourage you to look at and when you consider developer experience think about how developers feel, empathize with them, and then borrow these tools that have been around now for decades for how we measure products and services around how people feel. These things, personas journey maps and more specifically like the Kano model and just designing for delight and satisfaction. That's all I had so thank you.