Made by
Made by
When it comes to user research, are you asking the right people the right questions and doing the right thing with their answers? In this talk from DevXCon San Francisco 2018, Wordnik founder and IBM developer advocate Erin McKean looks at how user research can inform your developer relations.
So I’m gonna be talking a little bit about user research in dev rel and…but before I talk about that, I want to talk for one brief second about Call for Code which is a new initiative from IBM and the United Nations and the International Red Cross Red Crescent to get developers active in working to write code that helps people suffering from natural disasters. There are flyers in your bag. There are flyers on the back sticker table. The URL is developer.ibm.com/callforcode. I really encourage you all to check it out. It’s a great cause and it should be great code.
So, hi, I’m a developer advocate for the San Francisco City team and for IBM. If the last slide didn’t tip you off, I do work for IBM. I also run a nonprofit called Wordnik, which is the world’s largest dictionary by number of words because if there’s anything that my time running a venture-backed startup told me is that you only release the metrics you can game. So, we do have actually 10 times as many words, real legitimate English words as the next biggest dictionary. So if at any point during this presentation you feel like, “Oh my goodness, I must tweet this,” that’s my Twitter handle, emckean.
And so, I also will mention a couple of things during this talk and to keep you from having to scramble for a pen or take out your phone or laptop to write things down, I’ve got it all at this URL. And if you would like to reserve judgment and not take down this URL until you hear what I have to say, that’s perfectly okay, I will show this to you again at the end. But I just wanted to let you know ahead of time you know, to fend off the scrambling. So a lot of you here are very seasoned speakers, you’ve given a lot of talks so I know that you know that there are two kinds of talks. There are the talks where you are an expert and you’re just sharing your knowledge. And there’s also the talks where you really wanted to learn about something and you also needed a deadline to get you to learn about it. This is that kind of talk.
So why should we do user research as dev rel people? There’re a lot of reasons why you might be told to do user research. Your boss might tell you to do it. You might have some budget towards end of the year that you have to spend. You might be a super nosy person and you just like asking people questions. But I think the main reason that people in dev rel should do user research is because it’s right there in the title, Developer Relations, we have to relate to developers and it’s very hard to relate to people that you don’t understand.
You do not wanna be the real-life version of hello fellow kids meme, right? You need to know who you’re talking to and you need to understand what they care about and what they want. And if you don’t understand who the developers are that you care about and you want to reach, then you run a very real risk of doing the wrong things in the wrong places for people that really only exist in your imagination. And worse yet…
Audience member one: Best people
Erin: What?
Audience member one: Best people.
Erin: Best people, imaginary people are the best people. But if you’re doing those wrong things, the worst thing that you can do is actually bore people. I don’t know if you’ve found this but I have found that developers have a very low tolerance for boredom. You might have a different experience, anyone notice that developers really love to be bored?
Audience member one: Yeah, generally, low tolerance.
Erin: Yes, developers have a generally low tolerance for anything. In fact, when I first started…just in general, they’re intolerant people. But they’re mostly intolerant of you wasting their time. And when I first started learning how to code with Perl, long may it live in our hearts and memories. But I started coding with the Larry Wall Perl book and in the preface to that book he said, “We want you to develop the three virtues of the programmer: laziness, impatience, and hubris.” And I thought this was awesome and I actually photocopied it and blew it up to like a 120% and put it on the wall of my cubicle and this did not go over well at the educational publisher I was working for and they asked me to take it down. But you really don’t want to not understand who you’re talking to and you really don’t wanna bore them.
So if we agreed on the why, we should also talk about the other question words, right? And in 30 minutes or a little bit less. I don’t really have a lot of time to talk about the ‘how’ but I do wanna say that if you only take away one thing from this talk, it should be that you should read this book by Erika Hall.
She has a company here in San Francisco called Mule Design, you’ve probably heard of it. They are wonderful people to work with. They are great people to follow in all of the different things that you can follow people on these days. And it really tells you all about not just the why but the how and with a lot of really practical detail.
So you might think that the answer, “So we know why and this will tell you how,” but you might think that the answer to the ‘who’ question is really obvious, right? Who do I wanna talk to? I wanna talk to developers. And maybe somebody has handed you a set of developer personas, you know, “Hey, we’d like to talk to 22-year-old API developers who live in the western world and have very strong opinions about MacBooks,” right?
Like that’s a developer persona and this is the kind of data that you might get handed by the marketing team or the product team and they say, “Hey, we want you to go out and talk to these people because they are the users of our product. And that’s all fine. You know, that’s all fine and dandy but those are product personas and as a dev rel person, you wanna talk to the people who are using your content, what you do, because the product people and the users of your content, the users of your product and the users of your content are not necessarily the same folks.
And you want to talk to the people who you’re making content for whether or not they use your product because if they don’t use your product, maybe your content will get them to use your product. And if they do use your product, maybe they’re not the customers of your content. They might be more beginner, they might be more expert, they might have a totally left field use case that you have no conception of and you won’t know unless you talk to them. And the number one thing to remember about who your developers are is that they’re not you. You are not your developer and that’s really hard to remember in dev rel because a lot of people get into dev rel because they do love the product and they do love talking to developers and they love reading blog posts and going to talks, and you know, watching webinars, everybody loves watching webinars, right? But it’s hard to remember that you’re not the user of your content. And personally, that’s really hard for me sometimes because before I started talking to people about how they liked to learn things, I loathe video. I don’t like watching it. I don’t like being in it. I think too many years spent working on reference books just totally merged my brain into some other direction. But the people I talked to love video, they love learning from it, they love watching it so I’m gonna make more video because I talked to people, did some user research, found out what they wanted in terms of content and this is totally product agnostic. I should be doing more video across everything I talk about. I’m still gonna loathe it but I’m gonna do it anyway because I learned.
And so sometimes I think that as dev rel people, our superpower is also our greatest weakness. So we’re very lucky as dev rel folks that we get to go to conferences where lots of users are and we can talk to them. And in that way, we can have a lot of access to users that people who are stuck back at the office who are doing product user research or marketing user research, they might actually you know, commit serious physical violence for. But the problem is we’re often at these events to talk and not to listen and that’s the weakness of being in dev rel, is that if you’re at an event to talk about how great you know, whatever thing you are that you talk about is, then you actually have to step back and make time to listen.
And the other weakness I think of being in dev rel is that we have a tendency to forget about the developers who aren’t in the room because we’re talking to so many people all the time. We have to actually consciously stop and say, “Oh, okay, who’s not in the places that I go to? Who’s not coming to our events? Who’s not at our lunch and learns? Who’s not signing into our webinar? Who’s not coming to our blogs? How do we get out and talk to those people who are invisible to us right now?” And if you only talk to the people who show up to talk to you, you’re gonna miss out on a lot of insights. You are gonna have to go somewhere else.
I really love this. This is a bar so that you have plausible deniability so if somebody asks you, “Hey, were you in the bar?” You could say, “No, I was somewhere else.” There’s another bar in Chicago that’s called The Office for the same reason. Where were you so late? Oh, I was at The Office.
So now I know that paradoxically a lot of people in dev rel are actually introverts who just dress up in extrovert costumes and it can be hard to talk to people outside of the framework of a talk or a tutorial or a demo. But that’s totally normal, it’s hard to talk to strangers. People, you know, they shy away from it. So you can do what researchers have done for centuries. You can bribe them with stickers. As we’ve heard earlier today, stickers are the number one incentive for people. And I don’t just give away Semicolon Appreciation Society stickers because I love and respect the semicolon, I give them away because it gives people an excuse to come up and talk to me and ask for one. This is completely, you know, disassociated from the products and the services and the technology that I talk about, you know, except for JavaScript. But this gives people who wouldn’t normally come over and ask me a product or a technology question, an excuse to come up and ask me for a sticker. And that breaks the ice and then I can ask them questions. Why are you here at this conference? What are you interested in? What do you like to do? What’s a big problem for you?
Because once you’re at an event, it can be really hard to switch off from like evangelist mode to listening mode. And this gives me like a physical remembrance, a trigger that says, “Oh, I’m gonna give this person a sticker and then I’m gonna ask them a question.” And usually, they just got something so they’re super happy to be asked a question as long as it’s a normal human question. Because don’t ask them questions like this. Don’t ask people, “What do you want?” Because if they want you to like them, they will tell you something to make you like them and if they hate you, they will tell you something to make you go away and you will get no good data, no insights, no knowledge from this question at all. Instead, be curious, ask them what they do every day, ask them what their last commit message was, ask them what their last bug was. There’s so many questions that you can ask people that are not like, “Tell me what your API management solution is and how do you feel about it on a scale from 1 to 10?” Don’t be a human survey. Be a human being. Be curious about other people. It is fun. And don’t solutionize, right? They tell you about something, what their latest bug was, they tell you about a tool that they love but it has this problem, literally, stand in front of a mirror and practice your oh wow face. “Oh, wow, that’s really interesting. Tell me more about that.” Do not jump straight into that, “Oh, you know what you should do?”
That is hard to do at dev rel because a lot of us are in dev rel because we have opinions and we like to share them with people, especially about technical things. Now, to be fair, if someone tells you something and it makes you make that horrified oh my God, you have a huge security hole face, that is when your oh wow can go straight into you should. I mean, I’m not saying that for the sake of your data, you should avoid telling people how to solve really serious problems that you find out about in the course of discussing it with them, but your first instinct should not be to solve their problem. We just wanna hear about what they like, what they don’t like, what they’re into, what their lives as developers are like. And don’t rush to fill that silence with answers except if it’s a giant, massive, screaming security violation.
But try to dig for greater understanding so you can say, “Oh, okay, I hear that you’re saying that you like to use the open API spec for generating documentation but you don’t use it to generate client code. Oh, that’s really interesting, tell me more about that.” Instead of being like, “Why wouldn’t you use it for client code? It’s awesome for client code.” You just want to elicit instead of prescribe and because your goal is not answers, your goal is not answers from them, your goal is not answers to them. Your goal is to find new and interesting questions because when you first start hearing from developers or users or probably you’re already doing this now, the instinct to take what you’ve just learned and run straight back to your laptop with it and turn it into something tangible like a blog post or a demo or, you know, a strongly worded email to the product team, that incentive is really strong.
But I would say, “Wait, stop.” Try to set some quantitative goals for how much user research that you do. Maybe it’s a certain amount of time that you spend at every event or every week. Maybe you wanna have a goal of talking to a certain number of people, although try to make that like a human scale goal because obviously if you move robotically from one person to another because your goal is to talk to 25 people of an event, that is more on the human survey side and less on the human being side. But if you’re going to a lot of events, see if you can block out time in your schedule not just to be at the booth or not just to give your talk or your demo, but time to just be in the hallway and talk to people.
If you can’t get out of the office in a particular week, try and do some virtual user research, maybe hang out on Slack, ask questions of the board people who are there, maybe do a little skimming of stack overflow and eavesdrop on people’s problems. And when you’ve got this information from users, write it down. This is your excuse to use every single color of sticky note that there is and I know you want to. And also there’s an obligatory rule that any talk about user research has to have a slide of sticky note so I would like the auditor in the back to check that I’ve met this requirement. Awesome, thank you.
And don’t be in a rush to try to make sense out of this information. Just let it kind of congeal naturally. If you do feel the need to start grouping immediately, I find that one group that I really like is to try to group all the different tidbits of information that you’ve gotten by the name of the person at your company who would really be excited to hear about these things. If you cannot think of anyone at your company who would be really excited to hear about these things, that is also user research but of a different kind and it may drive different decisions on your part.
But once you’ve got this information kind of written down don’t, feel like you have to be a stenographer when you talk to people, right? Maybe when you get back to your hotel room or get back to your office, write down little snippets like, “Oh, I talked to Sarah. She is a JavaScript developer. She’s really interested in frameworks for API and she loves testing.” Think about what you’ve heard from people and if they have anything else to tell you, write that down as well. Because if you’re patient, what you will get is more interesting, more exciting, more leading questions that will take you to where you feel like you need to go. And sometimes like when I’m thinking about grouping things, I group them by what new questions does this piece of information generate. So if I’ve got a whole bunch of things that all seem to be about the same thing and they all make me wanna ask the same question, then I put those together like that.
But at the same time, you really don’t have to think about, “Oh, if I’m gonna do user research, man, it’s gonna have to turn into like a 10-page written paper or an hour-long death by PowerPoint meeting with a whole bunch of managers,” or some other like “deliverable” that makes you just not wanna talk to people at all because you don’t want the eventual work that might come out at the other end. But the nice thing is that you don’t need to do it for any of those reasons. You can just do it for you. You can talk to people to learn more about things that will make your own work better. Aside from the product, aside from the technology, but how can you make your own talks better, your own blog posts better, your own demos better, just through the stuff that you learn by talking to people. Now, talking to people as you know, as I mentioned, it can be scary. Sometimes that scariness depends on the person you’re talking to but after a while, you’ll get a good feeling from people who are scary to talk to or people who are not scary to talk to. But it can also be scary for other reasons like when you’re giving a talk or a demo, that’s a very different power differential than one on one conversation and it might be hard to let go of that, to stop being seen as the expert, right, and instead have a more human connection, maybe a less technical connection to people, that’s very different from being up on stage.
And sometimes, you might hear things that you don’t like. Not just that I’m not super thrilled that people love video, like, “What are you thinking, people? Text, is so awesome.” But you might hear stuff that just like personally makes you feel bad. I once asked someone after a big conference like, “Oh, so was there anything that you like found distracting about the speakers?” I was totally sure that they were gonna mention the guy who had his shoe untied the whole talk, which I found completely distracting and very hard to watch, and she said, “No, like I really don’t like it when speakers have wacky glasses,” and I was wearing bright green glasses at the time and I was like, “Oh, I can see how that might be distracting.” So yeah, it’s scary. You might find out things that you don’t wanna find out, but I do think that you’ll find out a lot of things that will make you happier, that will make you a better dev rel person and that will make it easier to talk to more people because every time you talk to someone and you learn something and you make a connection, it makes you more excited and more interested in the next person that comes along. It helps you make more connections, better relations with your developers.
So, if you wanna find me on the internets, I am emckean at just about every place where I wanna be found and as I promised, here is the link to the resources I mentioned which is basically Erika’s book and a bunch of other interesting blog posts.
Oh and this also reminds me to say a big thank you to all the people on Flickr who let me use their creative comments licensed images in ways that they never thought were useful. And so this presentation is also CC license so if you would like all these slides to give a different talk using all these images in the same order, just let me know. I’m happy to share them with you. But here’s the link to the resources and why we’re all here, it would be awesome if you signed up for a completely free IBM cloud account. No salesman will call. And if you’re interested in what our actual code patterns look like, the kind of content that the IBM team creates, this is a loopback pattern that I really like and you could find a whole bunch more IBM stuff, unsurprisingly, at developer.ibm.com/code.