When we interact with everyday objects, we have an expectation of how they are going to work. This is known in design as affordance. For example, if you see a handle on a door, it should be instinctive to you that you should be pulling on the handle; conversely, a flat rectangular piece of metal (called a finger plate) attached to the door implies it should be pushed:

This concept of affordance is universal to all design, including API design. Likewise, an API should be self-explanatory and as obvious as possible.

Users don't want to learn new behaviors. Users don't want to read the documentation in order to use your platform. The best case scenario is that your API is so intuitive that they only need to refer to the documentation once in a while.

On the other hand, if your API is unintuitive, then a user may still try it out, but they may feel the learning curve is too high and use an alternative platform instead.

This also touches on the previous point made about consistency: if it is commonly consistent, then users will feel more familiar with using your API.

Being intuitive simply means making things obvious. We should follow the Principle of Least Astonishment (POLA), which states that "the result of performing some operation should be obvious, consistent, and predictable, based upon the name of the operation and other clues."

Here, we outline a few things we can do to make sure our API is as intuitive as possible.