UX is ignoring developer experience
Research shows designers need to leave their comfort zone.
Throughout the first half of 2024, I ran extensive user research across multiple organisations to understand the needs and challenges faced by developers.
I spent dozens of hours interviewing, mapping and workshopping. And what I learned shocked me. I’d never been taught how to truly see developers as users.
Developer experience, not developer tooling
As someone who codes, I always felt comfortable working closely with developers as part of a product trio or in workshops. It has helped me to move quickly on technical projects. Yet I had never noticed the hypocrisy of how we treat developers when we do product design.
And I’m not here to critique VS Code or GitHub. I’m talking about our approach to APIs, integrations and documentation (or the lack thereof). And perhaps a little about company culture. We backlog developer experience (DevEx)as a ‘could have’.
Skip ahead
How we did DevEx research
So I kicked off 2024 by joining a developer experience-focused set of teams. As part of a push to fundamentally enhance our integration offering to developers, I was tasked with leading a significant piece of user research.
We kicked off using value proposition canvases to collaboratively gather any existing knowledge, then expanded our knowledge using Jobs to be Done interviews.
We then produced detailed service maps with internal & external developers, capturing crucial pain points. Sessions were recorded and tagged on Dovetail, to aggregate themes.
Insights were discussed and plotted on Opportunity Solution Trees with product teams, before we then pursued high priority areas.
What did we learn?
The needs and concerns of developers using our data products fitted into four main goals for our team:
- enable added value
- remove obstacles to success
- provide valuable, discoverable guidance
- enhance ways of working
I can’t go into proprietary specifics on this research, but I can offer up some themes under each of these goals. And refer to my experiences developing a side project, matchboxxr.
1) Enable added value
Developers can iterate and innovate faster if they are powered up by some pretty simple enablers.
All the fields, all the functions
Developers want access to as much information as possible from endpoints. And they would like to do as much as possible with the information at these endpoints, via diverse functions.
Flexibility with responses
Sorting, filtering and other ways of mutating response data is hugely beneficial to developers. This way teams don’t have to heavily process data after receiving it.
This approach allows developers to use fewer requests, simply tweaking the parameters of a single template for various needs (GraphQL being great for this). Which also means any changes they need to make are made to fewer functions, reducing toil.
Self serve and control
Whether it’s configuring permissions, setting team access or migrating versions — teams can innovate faster when they don’t need regular help from the owners of a given endpoint.
2) Remove obstacles to success
The below might not sound like UX problems — but these issues can be easily missed if a team designs a backend service to only fulfil one specific requirement while neglecting to investigate how this effects other areas. It is developers who pick up the pieces.
Easy testing
Deployment of changes is slow when teams can’t easily produce test data or access a stable, readily available test environment.
One thing I have found easy to test with was the Google Docs API. It was straightforward to test from localhost or in the API Explorer.
Google provide a flexible API Explorer in the Google Developer Console. Things like auth tokens and the request body can be auto-filled with suggestions, helping to avoid mistakes and discover features. Figma’s Rest API docs also auto-generate access tokens.
Tasks that play nicely with each other
Idempotency isn’t always a good thing. Some tasks can occur twice but should only be done once, causing errors. Imaging charging a credit twice for a single transaction.
Atomisation should be properly applied to mutually dependent tasks. If not, complex batches of functions can fail in some areas but not others. Imagine mortgage payments coming out of your account, but failing to be registered by your lender.
This sounds technical, but if you’re part of a team building these systems, it is ultimately up to you to roll up your sleeves and get stuck in. Don’t leave it to the tech lead to decide alone.
3) Provide valuable, discoverable guidance
Make getting started a breeze
Any developers reading this will be familiar with the ‘Getting started’ section of documentation (or the anxiety if it isn’t there). The quality of these can vary wildly. Ideally, guidance should be clear and apply to multiple difference scenarios, not a single use case.
Liveblocks provide an SDK for easily incorporating websockets into your front-end. I used it for getting started with Matchboxxr. The Liveblocks docs have plenty of detailed, interactive examples. They’re easy to use, I was a beginner to websockets and their docs helped me learn by doing with minimal mistakes.
Clear & well-communicated changes
Change logs and release notes should be accurate, regularly updated and consistently written. Changes should be shared well in advance, ideally in a targeted way where teams can opt into hearing about relevant changes only.
I had an issue where Miro changed how their cursored responses work and I didn’t know. It took a feature breaking for me to realise something was wrong. If there is a way to hear about changes, it wasn’t made clear to me. Their customer support team are very responsive, however.
Usable documentation architecture
The information architecture of documentation needs to be designed with the user’s behaviour in mind. Where do new users start? Do they find fields via site search or the nav? What are typical user journeys?
Figma’s Rest API docs are very simple to read and easy to navigate. There were some details missing at times. But it was easy to find your place. Not just when getting started either. You could return to the docs to read a specific detail in the middle of an integration and find what you need. Hashed/anchor links are great, as you can use the back/forward browser buttons to cycle through various parts of the same page.
Meanwhile, the Google Docs API documentation was absolutely awful for this. I had more success finding specific fields or functions from comments in Stackoverflow than using the docs. The naming conventions felt inconsistent, as did the contents of each endpoint. There was no top-level index to find the right thing.
The silver lining was how fantastic Google’s customer support is. They reply to your emails within a couple of days. This allowed me to liaise with them asynchronously.
Optimised customer support
Developers love to self-serve, but if they have to ask for help they want to ask the right person quickly. Effective triaging is a must.
Thorough detail
Although nobody wants to spend forever reading instructions, it is daunting to build a feature or function with uncertainty of how it works.
Whether it be field descriptions, error messages, example snippets… developers like the certainty and confidence that they are building requests correctly.
Interactive tooling
An excellent way to help developers self-serve and move quickly is to help them with query builders and copy-able example snippets. Miro’s docs are ace at this. You can build perfect queries in multiple languages without writing any code, to be easily copied. Figma also provides interactive query building.
4) Enhance ways of working
Predictable communication cadences
Regular meetings, updates and release change-sets are a solid way to build routine around changes that teams can prepare for.
Documentation prioritised internally
Internal teams need to consider documentation when they make changes. Such as updating legacy pages and writing high quality change logs.
Partnership between owners and users
Ideally, your users should be treated as your partners. Conduct regular research and share ideas with them for feedback. Consider developer experience metrics to benchmark and track developer satisfaction.
Where design comes into developer experience
What can be done about the above? Here are some starters.
Stop designing unequally
Let’s be honest, we tend to micro-analyse interaction design for user experience (think eye-tracking), but gloss over developer experience.
Next time you build a page or a feature, consider setting aside time for the changes to system behaviour. When are requests being made? What changes must we make? Could this effect the developers of another product or service?
This detail should be considered, workshopped and mapped like other aspects of a design.
User research for ambiguity
Don’t understand something? Group blind spots into research questions and start interviewing. Co-design maps or artefacts with users. Ask for help.
Apply a UX lens to data products
The world of APIs and data products is currently starved of attention from design-thinking. So consider forming an opinion on what a ‘good’ data product looks like. I created the Data Delivery Checklist for just this, although there are other API Design frameworks.
Drop your buzzword
We can sometimes get too attached to what type of designer we think we are. UX, UI, Service, Systems… The product space is becoming less clearly defined, everyone can benefit from dabbling in multiple areas, regardless of platform or technique.
We work in an integration economy
Artificial intelligence may lead to an explosion of integrated systems, beyond what we’ve already seen. Pair this with the various tools simplifying traditional design and it looks to me like UX is shifting towards a closer alignment with engineering. We can’t ignore the iffy, technical bits forever.
