The case for API-driven Design
Not long ago, around coffee break, I was trying to explain to H. (Bob! Desk’s CEO) what an API is. I started with the obvious, breaking down the acronym. An API is an Application Programming Interface… which sounded clearer in my head.
Next, I stated that it’s the user-facing interface of a system. Didn’t help much, and Google Translate wasn’t going to cut it to translate from engineer to sales rep.
Your coffee maker’s API
Bothered, I then looked down at the coffee maker next to us, and got the idea of explaining him APIs with this analogy: Think of it as the buttons of a coffee maker. Altogether, those represent the API of the coffee maker.
In other words, it represents how you need to interact with a system for it to produce a result. Push the button on the coffee machine to get your coffee, push on the brake pedal for your car to stop, and so on.
Software APIs
The term API comes from software and usually refers (for non-technical people, at least), to the way you should ask a web server holding data to provide you with information (or to perform any other task). For instance, to see how a web server response might look like, check out this dummy to-do list.
To view this very page, your browser is using Substack’s API to ask their servers for the page. When it gets the code for the page, your browser interprets it and renders it onto the screen with all the pretty colors and fonts and images you’re seeing.
If you have a technical background, you already know that the term (I’m already tired to write API) refers to the way you interact with a given piece of code (aka package or library): How you’re supposed to use it so that it can produce what it was designed for.
The trick, though, is to break the concept out of the software industry: You can successfully apply this idea to virtually anything that can be operated by a person.
Product APIs
They’re a useful mental model for designing product interfaces from the user’s perspective. APIs are virtually everywhere, tons of them in desperate need of a revamp, like Microsoft Azure’s portal, Fujifilm cameras’ menu, my microwave’s cryptic buttons, public transportation maps…
If you’re building products, you are creating APIs, and would probably benefit from asking questions like the one below before you design your product (or write code):
How should users interact with the product? Do they bring their own coffee and water to make themselves a cup of coffee?
Should they have more or less control over how it operates? Should they be able to decide how grinded the coffee is, or how long it brews?
Do they care how it works? Is the process of making coffee important to them, or would they rather have a quick coffee so they can get back to work?
Isn’t it better to have users bring their own water and coffee because this is what they wanted to do, not because you didn’t think about it?
API-first design
As tempting as it may be to leave as much control to the user as possible, so “you don’t close the door on yourself”, this lazy-design strategy often results in user frustration.
Don’t make the configuration panel grow too big. Don’t put too many buttons on my microwave that all look the same. Make smart choices for me, please: I don’t have time to read an Encyclopedia every time I use your product !
Leaving as little control to the user as possibly needed usually leads to better design, the user spending less time guessing how they’re supposed to operate or configure your product or system. Good products make it easy to use them right.
Unexpected benefits
Even then, your API might be as simple as could be, you’d still be shocked how creative can people be to come up with new, unexpected ways of using a product.
As an example, Kleenex was initially making disposable towels intended to wipe off make-up. When they learned people were using the towels to blow their noses, they started advertising their product as tissues and doubled their sales.
Unexpected APIs
Users inventing new usages for a product is good news. But unclear APIs are not. Hoping for someone to rise and come up with a good usage for something you didn’t think through is not a winning strategy. It takes time, luck, and people actually willing to use your product.
The magic recipe
To hack your luck, start with API design. Instead of spending time pondering how you’re going to manufacture a product, put yourself in your customer’s shoes and wonder what magic tool you would like to have to solve the problem you’re facing. What buttons would you like to have if you could wish for anything?
Those are the kind of questions that foster change, innovation, and the appearance of tools like linear.
Once you’ve figured out your product’s API, it’s easy to derive solutions from there. All the functions you attach to your API’s entry points act as black boxes for the user, who ends up having to interact only with the parts they actually care about to do just what they intended.
Forget what you want to do, embrace your users’ perspective.
Sometimes that hurts.