UI/UX: The Lego-isation of Developer APIs
By: Clement Vouillon
Tags: SaaS, Developer Tools, API, UX Design, UI Design

In the past couple of years, the evolution of the UI/UX of developer APIs has been stunning: we went from very “rough” products, mainly composed of a text documentation describing an API that developers access through their terminal, to much sleeker and easier to use interfaces.

I currently see more and more developer tools that take the “Lego” approach: on top of their API, they offer modular blocks, ready out of the box, that users can combine the way they want to build what they need much faster.

This “Lego-isation” of developer tools UI/UX is materializing through the functional and visual aspects.

Functional: from a “raw” to a “modular” approach

Instead of providing only a “raw API” consisting of a text documentation listing endpoints that you use in your scripts, this new generation of products go a step further and provide building blocks that are a level of abstraction above. Let me illustrate it with an example.

Voiceflow, a tool that enables you to build your own voice assistant app (such as an Alexa skill), provides a selection of pre-programmed blocks that you can use immediately, without needing to code:

These blocks are often shortcuts to the most popular and useful functions, preventing users from “reinventing the wheel” (which is often the case with raw APIs). However, this modular approach doesn’t sacrifice customization: in most cases, you can edit these blocks to tailor them to your needs (add your own data sources, include your own logic…), or even create your blocks from scratch.

For example, Mason, a front-end as a Service tool (where Point Nine Capital is an investor), offers a library on front-end components that you can combine to build your interface. All these components are customizable, not only from a cosmetic standpoint (color, shape), but also from a functional one (for example you can import your own data sources, or connect the components to external services such as Stripe or Facebook).

What has changed is not only this modular approach, but also how you interact with the API itself.

Visual: from text based to WYSIWYG

As I mentioned in the intro, the main way of interacting with an API was to write code in your IDE and run scripts in your terminal to test it.

Many of these new tools offer visual interfaces enabling users to create what they need directly in their browser. And sometimes even with WYSIWYG (What You See Is What You Get) interfaces where you drag and drop the components you need and customize them on the spot.

Both Mason and Voiceflow have WYSIWYG type of interfaces:

On Mason you can drag and drop components and see live the result of what you build.

The future of developer APIs?

I believe this “Lego approach” is the future of many developer tools:

Faster and easier to use. This hybrid approach enables users to build much faster and more easily what they want. At the same time, if they have specific needs, they can always customize these modules, or even develop their own. The key aspect, for the API providers, is to provide the right “blocks”. How you “modularize” your API can be challenging.

Wider user base. A huge limitation with the “raw API” approach is that it speaks to developers only. By providing a modular approach with easier to use interfaces, you clearly broaden the user base. You’ll have people with no coding (or limited) experience be able to use these products. At the same time, experienced developers can also find what they want. Voiceflow has an interesting onboarding screen that illustrates it: