Why Developer Experience Needs Service Design

via doteveryoneuk

Notes on advocacy, design, and building better developer products and services. 

I’ll say this up front — I’m not a developer, I’m a design researcher. But Developer Experience is totally a thing now, and I, for one, am stoked. I was fortunate to get invited to some awesome conferences during the month of May, and I’m just now slowly catching my breath, digesting all the intersections of UX, design, development, and what we’re now calling “developer experience”.

I’m excited about all of this because I’ve worked on developer solutions on and off for the past few years, and I personally love the collision of complexity, engineering, systems, and humans to be found within them. Like Anil Dash said, at some point someone realized that I could talk to engineers, and I realized that I enjoyed it. 

I’m also a total geek about learning, and Developer Experiences are almost always learning experiences, and social ones — despite the popular characterization of development as a lonely solo process. We have a lot of new developers entering the scene, in part due to the fact that there are more ways to learn to code than ever. Like Jenn Schiffer pointed out, every developer tool is a de facto learning tool — a potential we’re all too quick to write off.

But how do we work together in this realm? How can we build better, more robust, more open and accessible solutions for developers? As I said before, we can see building, documenting, and supporting usable tools for developers as an act of care. But, if we’re going to be successful, we’re going to need to think beyond tooling, to services. Like in Healthcare, consumer products, and government, we have much to gain by thoughtfully designing services to align products, tools, and human work.

UX? DevX? 

“User experience” might be a term we first heard at the turn of the last century, but ergonomics, “man-machine interaction”, and the roots of usability and accessibility have much longer history. Some of the problems we face when building developer tools are unique, but many of them are not. So how do we adopt a more human-centered approach in Developer Experience?

To make this all the more complex, we all have a far more sophisticated awareness of user experience and design than ever before. We are more comfortable with automation and abstraction if it gives us a break, and more of us are inclined to think that we write applications that are “user-friendly” (or the word I hate to hear, “intuitive”). What’s more, I’ll hypothesize, is that many folks working on and with Developer tools are skeptical of the promises of “design thinking”.

But still, in hearing folks like Alex Salazar, Cristiano Betta, and Jono Bacon speak on building great developer experiences, I heard some very familiar language. Salazar spoke to the value of understanding particular user segments, and in developing personas and journey maps. (Not mentioned was how one developed these, but obviously this is a subject I’m very opinionated about.) Developer Experience, it turns out, can get a lot of value from classic User Experience tactics.

One thing does stand out about Developer Experience, though. There’s no doubt, within this community, to the value of IRL human interaction. “Human interaction is the only thing that’s proven to work in selling to developers”, I heard someone say, “So we have advocates and evangelists.” With other products, UX gets set in opposition to an IRL, hands-on, long-game approach to growing products — “a usable product doesn’t need evangelists”, one might say. But I’d like to look past this thinking.

In the process of designing for developers, advocates and evangelists are amazing allies. After all, they spend their days and nights with end users, and as I’ve said, holding products together with duct tape and emotional labor. They build relationships with end-users, and gather rich data about them. 

Is this a substitute for user research? Nope, but it’s a great asset to it. Design and research teams need to build close alliances with advocates and evangelists, building better feedback loops. Yet, it’s most often the case that these are distinct silos. Developer Advocacy has a demonstrated ROI, as does UX design and user research. How much more value could we add by working together?

The Os Gemeos silo murals in Vancouver, an apt metaphor

Designing Developer Services

This brings me to my end point: to build great Developer Experiences, we need to look beyond these product/advocacy boundaries, and instead, combine our efforts for a Service Design approach. A more thoughtful, high-level design approach for developer experiences is possible, when we integrate products, support, services, and data from the interactions that surround them. Bringing advocacy, design, and development together allows us to integrate the wealth of data we have, and frame the user needs and workflows of developers in rich context.

What is Service Design, exactly, and what would that look like for Developer Experience? I’ll point here to cases of Service Design for healthcare and bikes.

But rather than give a complete illustration of something I’ve never seen in practice, I’ll offer the five principles of Service Design that Stickdorn and Schneider outline, and that I’ve adapted -

1. User Centered — centering design and development of services and products around the end-users and stakeholders, rather than technical specifications or business requirements. (Though those are important considerations as well)
2. Co-Creative- meaning that it’s not a single designer or developer in charge of developing a product or service, but that the design process draws on the insights and participation of those who will use it. Meaning, we bring developers and developer advocates into the room with us. 
3. Sequencing- We visualize sequences and journeys, allowing us to better understand the impact of design decisions throughout the process of use
4. Evidencing- we draw on data and context to see elements of a service
5. Holistic- We take into account the entire experience of a service or product, each before, during, and after.

What does this look like for Developer Experience? I can tell you how it’s played out in projects I’ve worked on, but that’s a small representation. What’s more, I’d argue, is that we’ve got a lot of work to do in order to do this purposefully. Let’s work together to do better in building the next generation of developer experience.