The User Is an API

The best interface is no interface. In his Don’t Make Me Click talk, Aza Raskin (the son of famous human-computer interface expert Jef Raskin) eloquently explains that the best shovel is a hole.

Although we still haven’t found a way to make completely invisible apps (hopefully AI will get us there), a good guideline is to only prompt the user as a last resort.

For example, if an application needs access to the user’s location, it should first try to call the location API. Only if that fails, should it prompts the user for manual input. Whenever user input is not absolutely necessary, such as when a drop-down only has one option, it shouldn’t be requested.

Today, building an application that follows the above guideline requires a lot of effort. Most people assume that interacting with an API and interacting with a user are completely different things, and have adopted different tools, strategies and abstractions for dealing with them. But what if they were the same things? What if we started thinking about the user as just another API? What if the code for getting the user’s location was the same, whether it ultimately asks the GPS or the user?

When you start thinking about your entire system as a collection of API calls, and stop thinking about the user as a special case, things become very interesting. You realize that API calls are just functions, and an interesting property of functions is that you can compose them. All you need is the type of inputs and outputs to match, like dominoes.

When you realize that the user is just another API, you notice that a lot of existing API concepts naturally apply to it:

I strongly believe that thinking about the user as an API is the key to the next user interface revolution.

This post was originally published on Medium.