Good design is critical to a good product but it’s often just viewed as a pretty add-on, says Google’s Melissa Powel. The challenges and benefits of embedding design into your developer relations strategy are outlined in her talk from DevXCon San Francisco 2018.

Transcript

My name is Melissa Powel, and I work in Google’s Developer Relations team specifically within the Google Developers Experts programs, which actually, the number is not 450, it’s now 600 designers and developers external to Google who work around the world in a variety of Google technologies. I’m also passionate specifically about IOT and work with the Android Things platform. And I also strongly believe that if we help product creators understand design principles, not just inside about how we can hire or apply UX principles to our own APIs and developer tools, but also externally to help developers improve what it is they’re building, that we can create a better tomorrow. So…and another thing you should know about me is I’m an adrenaline junkie. I love the introductions where they talk about their professional careers, but this is me climbing in ice caves in Alaska, and I’m gonna be climbing Kilimanjaro at the beginning of next year, so if you have any questions about that as well you can ask me.

The definition of design

A couple of things that I’d like you to take home today is to broaden your concept of what design is. And also, I’ll provide a lot of examples of ways that at Google we’ve been incorporating design into our developer relations strategy and ways that we can make it less painful. So, the first thing is I’ve heard the pushback. First, design’s easy. You don’t know how many people I’ve seen get it wrong, not understand how to ask non-leading questions when they’re trying to talk some of their users. Or you’ve got folks who, perhaps, don’t have bandwidth. I’ve got teammates who spend 222 days on the road, so adding extra work or extra advocacy into what they’re already doing is really difficult. And sometimes people say design’s important but that will come later. I’m gonna… I need to focus on educating this specific technology, but I’m hopefully gonna help you understand why design is not only important, it’s critical to what we’re doing in developer relations. And what I found is that also, some people don’t quite understand what the definition of design is. Design can encompass, from what we’ve seen, everything from UX of developer tools, to typography, to brand, to communication design, to voice interfaces. The definition is extremely broad, so let’s just start off by defining exactly what design is.

So, I looked up what design is according to the Merriam Webster dictionary, and it is, “To create fashion, execute, or construct according to plan.” Scrolling down just a little bit further, you’ll see that this is how design is used in a sentence. By definition, engineering requires design. This is executing a plan. But, again, design is a very broad term, so let’s focus on a couple of other terms that we use in relation to what we’re doing with dev rel. For example, product design. This should sound very similar to some things that you’re working on now. “The process of creating or improving a product by learning what consumers want and examining similar products that are already available.” And again, graphic design. “Graphic design is the process of visual communication and problem-solving using one or more of typography, photography, and illustration.” So, to put that all together, design is a process for problem-solving by listening to what consumers want in order to build a plan of execution. And if that doesn’t sound like what it is that we do, then I think that we might be in different fields.

So, design is not a single thing. It’s everything that we do within developer relations. It’s creative, it’s analytical, it’s artistic, and it’s useful, and it’s so dynamic. We’ve created a series called Design Is. So this is the first example of a source where you can look to find ways to incorporate design into your strategy. It’s on Medium, and it’s on YouTube. And it covers the wide variety of what design encompasses from machine learning for self-driving cars, to graphical user interfaces. So, when somebody tells me that they don’t see the value in design in their dev rel strategy, I think that they just haven’t understood exactly what the term means. And while we’re defining terms, let’s define what it is that developer relations does. So, I’m not sure if anybody’s had the experience of trying to explain to a non-DevRel-er what dev rel does, the single thing that we do. But I’ve had a lot of fun, to say the least, coming up with different titles make sense to people.

Design and developer relations

And, in general, at Google, dev rel’s mission is to help developers be successful everywhere. That is broad. So, I’ve tried on a couple of different titles to help explain to folks outside of our community. And the first thing that I tried was startup consultant, mostly because I liked how that sounded, but that didn’t quite cover what it was that we were doing. So, then I have this one friend who only believes that there exists traditional roles in the world: education, law, medicine. So I told her I’m an apptologist. The same way that a doctor might help diagnose and treat your foot disease, I help diagnose and treat your app disease. Unfortunately, that one stuck. Now she introduces me to other people as an apptologist, but at least I think she gets it.

Even within Google, I take out a scatterplot graph of all of the initiatives, programs, and activities that we run within developer relations to help them understand tangibly what it is that we’re doing. And here, this is actually a simplified version of a scatterplot graph that I share. We have partnership outreach, we’ve got ecosystem where we’re speaking to developers at large, and that’s the team that I work in, we have developer advocacy, and we have documentation. And I believe that many people have a similar structure as well. But the term that I found that I personally identify with most is an educational marketplace, where ideas and knowledge are the greatest currency. And we’re all exchanging these ideas and knowledge with the goal of improving products to improve somebody’s life, whether that’s the developer or the end user. And whenever you wanna call us, I think we have the best job in the world. Kinda speaking to the room here. I think we might all feel this way.

And we talked a little bit today from the past speakers about who our users are. Obviously, they’re developers, which might come in the form of entrepreneurs, students, teachers, a variety of different professions. But, what we’re all working to do is to help developers be successful. And developers are building for somebody else. So, what we’re all concerned about is the end user. And at the end of the day, our job is not only to help educate developers to use our products better through educational outreach, or to help talk to our product teams to make products so that developers love them through feedback loops, but also to help developers be successful and be better problem-solvers for what it is that they’re actually trying to build.

Integrating design in three simple steps

So, in order for developer relations to be successful, developers have to be successful. And in order for developers to be successful, they have to understand how to effectively problem-solve. They have to understand design. All right. So, let’s assume everybody’s nodding. “Yes, okay, I’m on board. I get it. Okay, just tell me, what do I do?” Well, it’s hard because if you’re like my team, you’re already working weekends, evenings, you’re putting in everything into just advocating for the technology and your product and if you add something else to this bandwidth, you’re not gonna sleep. You’re not gonna eat, you’re not gonna have a family. Forget about it. So, what you have to do is you have to think of ways that you can integrate design seamlessly into what it is that your current initiatives encompass. And just like a great infomercial, it’s as easy as these three simple steps. So first, explore what’s out there, which is what you’re doing right now. Second, make sure that it aligns with your company goals, because you’re gonna be working upstream if you don’t. And finally, measure your impact, understand what matters to your team. And if you find what matters to them, you’ll be able to show whether or not your initiative was successful and adjust and change it accordingly. Sounds easy, right? It is. It doesn’t have to be hard. And if you commit to making this happen, you can make it seamless and integrated into your current initiatives.

So, let’s dive a little bit deeper into what each step means. First thing is you need to understand the right approach, so talk to folks within your team. If you have a design team, talk to them, what keeps them up at night, what are they excited about? You can also look at forums, online blogs. Go. Do your research. But I’ve also got a couple of ideas that have worked within Google that you can try. So, as I mentioned before, I’m on the Google Developers Experts program, and I run the Sprint Master Academy, which is a training program that’s based on GV’s design sprint methodology. I teach this to about 40 members of our 600-person community every year, and this last cohort that we taught was about 75% technical and 25% design, which means that we had senior consultants, CTOs, technical consultants, and developer agencies coming to learn design thinking methods to apply to either their product or to their customer’s product so that they can be more successful in what they’re doing.

After the academy, one of the machine learning experts came up to me and said how he was adapting the design sprint methodology, which is generally spread over the course of 5 days, into a 20-day model where he was able to test and iterate on his machine learning models to improve the effectiveness of what he was building for his clients. So, what I recommend is that if you have any technical trainings that you’re already doing, incorporate some designing-thinking methodologies and see what people come up with. It’s an effective problem-solving tool and you’ll be surprised with the creativity that people have. The next suggestion is to go analog. Have people shut their computer for just a second and think through what it is that they’re trying to build. 2015, Google I/O, I ran a sketching and paper prototyping workshop where we paired developers with senior designers at Google and we helped them think through their navigation and interaction before they started coding, and ask a lot of questions about what makes effective app navigation.

By the middle of the morning, we had so many people lining up that we had to switch our model from one-on-one sessions to 10-to-1 sessions. And I had one developer come up to me afterwards who had spent the past six months…he had a look of sheer frustration and joy. I’ve never seen something like it before, because he had spent this past six months developing, deleting, coding, uncoding an app and couldn’t figure out why it wasn’t working with his users. And after a 60-minute session with a designer, thinking through the navigation from start to finish, he had a feature roadmap that he could build in six weeks instead of six months, and quickly test and iterate whether or not this was going to work. So, a stitch in time saves nine. And I recommend that you try adding a sketching or paper prototyping or some sort of planning exercise before a hackathon, a meetup, before a technical conference to help get people thinking about what it is that they’re trying to build.

Creating and testing useable design

Finally…this is actually a good example. Having design at a developer event. I was just sharing to tell that we have World Usability Day activities happening and a lot of people ask whether or not if you incorporate design into your developer conference, whether you should have separate tracks. Like we have today, I recommend that you have separate tracks. And then have some sort of collaborative workshop or networking happy hour that can encourage some sort of collaboration. But you wanna be able to satisfy people’s needs to go deep into their area of expertise while also encouraging that dialogue happening between people. But you don’t wanna force this engagement if it doesn’t make sense, if that content is not what they’re interested in learning about.

There are so many other examples of ways that we’ve incorporated user research, design thinking, visual design, best practices into our dev rel strategy and it hasn’t been extra work. So, one of them is usability testing, you can get people to go out rough and dirty. We ran a workshop with FinTech startups in New York and all of the startups were from Malaysia. We made them go out into the streets of New York and interview restauranteurs to get feedback about their app. And even though it was a different market, the experience of talking to people got them out of their shells. You can also be at the forefront of helping create this dialogue by creating UX tooling like we’ve done with the material components. There’s a lot of other people who have created that transitional content that helps you go from prototyping, digital prototyping into coding really quickly. And then you can create rubrics, the sort of standardize accessibility or standardize what good design or good usability can be. The progressive web app Lighthouse score is a good example of that.

Second piece is to align with your company so that you aren’t fighting an uphill battle. And if you don’t have any OKRs, or objectives, and key results that are tied to design, I recommend that you make it your goal to get them added by the end of next year. Because for example, at I/O earlier this year, Sundar announced that, “Digital wellbeing is part of our company’s OKRs.” Because we all have a critical responsibility to ensure the wellness of developers using our products. But, if you’re changing, so, say you have your objectives, you have your guidance, your sort of north star, now you’re gonna go to your team and tell them, “Okay, we’ve got this command and you now have to change everything that you’re doing,” that’s also not gonna work. So, you wanna have a bottom-up approach. Talk to your team, figure out what keeps them up at night. Figure out what features, what technologies, what products they’re most passionate about and align whatever design outreach strategy you have with the bandwidth, talents, and priorities of your team so it becomes seamless and people don’t even feel that they’re doing something different.

Design doesn’t have to be difficult

Finally, getting them to do it once, getting your team to change what their initiatives are one time is easy. But in order to have this be continued success, you need to measure quantitative and qualitative success, and also make sure that you understand what the rest of success means to both your executive teams and to the rest of your dev rel team. For example, World Usability Day. It was the first time Google’s participating in this global initiative. It’s not something Google started, and we participated in 10 different countries reaching 1,000 developers and with 1,000 hours of content and 72 sessions. We had a lot of feedback about what works and what doesn’t work for our developer community to find out what we need to do to improve for 2018. We also emphasized a couple of critical points like, “The understanding of the problem you’re trying to solve is the secret to unlocking the success of your product, which is at the heart of human-centered design.” We also left…we did a train the trainer program, so we taught a workshop and then we left resources with folks on the ground who can then continue the education and continue that advocacy for design excellence after we leave. We’ve already started planning for 2018 and we’ve got a lot of teams that are coming up to us hoping that they can get involved because this is not only an issue for designers, this is a huge issue for developers to be successful.

So, design should not be a separate activity, it should not be an afterthought. It should be something that’s seamlessly integrated into everything that you do. And it doesn’t have to be hard. Remember, all you gotta do is start exploring the options, listen to your team, find out what works, integrate with what your priorities are, and measure your impact. And a little secret, design’s super fun. This is us prototyping a new robot. I don’t know what it was exactly that we were working on, but it also feels really good having human-centered design and helping your developers understand problem-solving better feels really good because you’re making people’s lives better.

So, being in developer relations means that we help developers be successful and we do this by helping them create incredible user experiences for their products. Thank you.