Developer Experience 101
When I ask engineers which companies treat their technical user base best, they tend to say Stripe with little hesitation.
Sure, there are plenty of great companies out there building tools that solve payments for your product, but Stripe has built up an evangelical user base of engineers who’ll recommend it as the payments product of choice when they walk into their next company. How?
It starts with Developer Experience.
Developer Experience 101
What is DX?
Over the past 5 years or so we’ve seen developer-focused companies come into the mainstream: Twilio, Stripe, etc. As a result, the phrase ‘developer experience’ has sprung into existence. Simply put, it can be thought of the ‘user experience of developer tools’. Naturally we can infer a very broad persona: Developer.
How is it different to UX?
For consumer-facing products it’s easy for a designer or team to hypothesise personas and make assumptions rooted in common sense. In a consumer context, it’s quite a lot easier to imagine you are the user.
Reducing friction is typically seen as a good thing across the board…. Developer tools do not share that trait.
For engineers ‘reducing friction’ can mean the difference between a £1000 AWS bill and a £10,000 one, and a simplistic GUI may be counterintuitive to the power an engineer might expect when deep in flow.
Pillars of DX
But of course there’s a pyramid for it
This pyramid (or a version of it) has been floating around the web for a couple of years now. Consider it a hierarchy of needs for building good developer tools. I’ve taken some liberties from the original based off what I’ve learnt working in developer-first companies:
Foundations
For obvious reasons function and predictability fall into the control of developers. Function is of course paramount.
Predictability is a word I’ve dropped in as opposed to the original’s ‘reliability’. I feel the term is a better catch all for what can broadly be thought of as the consistency of the experience of a product — this could mean stability of software (lack of bugs) or it could mean uptime of a service. It needs to work 24/7/365.
A developer is obviously the best person to start designing a developer tool, but they may fall into the trap of designing this just for themselves. To get that ease of use up to scratch, they’ll need a few more people — namely technical writers and designers.
Accessibility
By mere virtue of being developer tools, expect a lot of complexity. Turning new mental models into concrete through great documentation and working code examples can often be a huge piece of work — but remember that if nobody can understand and learn your product, nobody will buy it.
Remember that great design is not achieved by a single kind of person. It requires teamwork and input from a team of stakeholders. Developers alone don’t make great developer tools.
1. Make terminology a first-class citizen
I’ve been fortunate to work with great technical writers, and what made them incredible to work with is that they didn’t just write docs with new feature releases or API updates. They worked with engineers to define company-wide terminology for technical concepts.
Technical or not, having a shared terminology across your products is a good idea. The difference in a developer context becomes: share that internal terminology. Being intentional and careful with the words you use across your CLI tools, APIs and documentation will pay dividends in terms of developer experience.
2. Understand workflows as deeply as possible
In the same way I might build a user journey for the users of my product, I can do the same for understanding developer workflows and context. Early on in Ultima’s validation phase we used this diagram to probe around the problem space:
You can use these kinds of maps as a means to understand specific problem sites, or even as a discussion point around the usage of your product. If you’re a company like Stripe, you probably have many of these for each product, and all of your larger user stories. Imagine something like this for the ‘integrating payments’ block — how many forks in the road could there be? You are perhaps adopting more of a Service Design mentality here.
Don’t be afraid to put these in front of (other) . These can be a terrific starting point for research conversations that can help refine the user journeys of your developer tooling.
3. If you need a UI, don’t make it suck
While we place UI considerations as the least important on the pyramid, there is no excuse for shipping things like this:
I love raising the AWS Console as an example of how it’s done badly, and I’m not the only one. Market dominance is no excuse for a shitty user experience. Let’s circle back to Stripe here for a bit of comparison:
Stripe has made clear the distinction between analytical and operational features of their web dashboard without overloading users. Developer-specific stories are placed in a Developer-specific part of their dashboard, leaving the operational dashboard and payments analytics to the people to whom they matter the most.
A direct comparison between the world’s largest cloud hosting and a payments API is of course simplistic — but the difference between the UX of web tools isn’t. Developers are beginning to care more and more about the user experience of the tools they use, and don’t expect that to go away.
So, what now?
With all of the above in mind, focus on the accessibility of your tools. Decide upon a shared language for your teams and make sure your products receive feedback that isn’t just from your own engineering teams.
If you’re looking for some homework, there are a handful of companies that have great DX that you can evaluate: Stripe, Twilio, Spotify and Twitter (until Cambridge Analytica ruined it for everyone).
If you’re eager to see who’s going to be taking the crown from Stripe, though… well, that’d be Ultima.
Until next time. ✌🏽
