Developer experience: It’s not just for APIs anymore
As the world moves in a DevOps/API direction, Developer Experience (DX) and API Experience (APX) are becoming real things for the UX/HCI communities to wrestle with. What does a developer audience want? How do we support products with few or no UIs that are within our control?
At Akamai Technologies, we have acknowledged the first aspect by bringing aboard Nick Tran and having him create a team devoted to this work around our own APIs.
Since I’m working with the Rapid/Akamai API Gateway team — which is not just about delivering our APIs, but delivering our APIs to developers so they can better deliver their APIs to their customers — we need to consider this very carefully.
In reading around it, I came across a slideshare deck and an article that came out of them, basically laying out a road map for how to provide a good developer experience (based in very similar process for creating a good user experience). And in reading the article, I realized that we need to be thinking more in terms of DX with regard to our in-progress Arc design system.
A design system is essentially a series of components and guidelines that can be reused in different combinations, often by development teams that may not have access to UX or visual designers (who are often at a premium). Design systems allow you to manage design at scale.
The key point here is that our customers of the design system are not external customers, they are our own developers. We need to make the design system something that they want to adopt and use, and make it easy for them, or they won’t use it.
This is something we were not properly considering under previous leadership and paradigms, and it almost certainly would have led to some public visibility for our efforts, at the cost of abject failure of internal adoption and scaling, which are the real intent of such a system.
Try reading through the following article, and substituting “design system” wherever you see “API” concepts. It’s not 1:1, to be sure, but you should get the idea: there are things we should be providing to our developer customers, which they expect from tools they use, that we might not currently be providing:
http://manfredbo.tumblr.com/post/63457756729/developer-experience-because-developers-are
The first point is particularly salient: “Do I want to use it?” We need to make an early and compelling case that this is something that will save them time and effort if they are willing to get on board with it. Using change management practices can go a long way towards that end: find supporters and partners, make people aware early, get them involved so they feel invested, give them clarity of effort and roadmap and support long before they are required to adopt anything. With some effort you can turn critics into evangelists if you do things well.
Of particular concern to us on the API Gateway is the “How do I get started?” question. Things like API Consoles, referenced in the article, could have a direct correlation in the Arc site if we provide live, dynamic, interactive examples of the components rather than static images. Each component in our system should include a configurator, to be configured and experimented with right on the page, based on either intelligent defaults or customized element by element. This should be paired with guidelines for when and when not to use the component, along with how to customize it and where that is acceptable. The code for whatever has been generated should be easily copyable right out of the UI. Creating our component pages this way will have the additional bonus that, as we update and change each component, it will automatically update live on the site.
This will require some serious development effort on our part as a UX team — and we don’t have any of our own front end developers on the team yet. But if it creates a tool that will save countless hours of design and coding effort going forward and contribute strongly to the goal of consistency across our broad and diverse service and feature ecosystem, it seems like a process win in a big way… and also potentially a serious COGS win.
With Arc we are attempting to “increase the design quality” and provide a tool that will be the best solution for our customers… but as always, we need to make sure we are designing it for the right customers. Following good DX practices is helping us get there more quickly and successfully.
