For a long time, I thought APIs belonged entirely to engineers.

As a UX designer, I understood that APIs existed somewhere behind the interface. I knew they moved data around, connected systems, and made certain features possible. But I did not see them as part of my design work. My responsibility was the user flow, the screen, the interaction, the content, the layout.

That understanding was incomplete.

The more I have worked on complex products — especially products with many roles, permissions, forms, transactions, configurations, and integrations — the more obvious it has become that the interface is only the visible layer of the experience. The real behavior of the product often lives underneath it.

‍

‍

The API is where the system reveals what it actually understands.

It tells you what data exists, what relationships matter, what actions are possible, what states can be created, and what rules the interface depends on. For a UX designer, that is not an engineering detail. It is experience design context.
‍

A button is not just a button if the action behind it can fail silently.
A form is not just a form if the data structure underneath it is inconsistent.
A success message is not really successful if the system did not actually create the expected record.
A workflow is not simple just because the screen looks clean.
‍

This is why I think API literacy is becoming one of the most underrated skills in UX.

Not because every designer needs to become a backend engineer. They do not. But designers do need enough understanding to ask better questions, challenge weak assumptions, and follow the experience beyond the edge of the screen.

‍

A simple way to think about an API is this: it is the contract between the interface and the system.

The interface is downstream of the system

When a user clicks, submits, searches, filters, creates, edits, or deletes something, the interface is usually communicating with an API. The API receives the request, applies rules, returns data, and tells the interface what happened.

That contract shapes the user experience more than we often admit.

If the API does not return the right data, the UI cannot display the right information. If the system allows inconsistent states, the interface has to deal with that inconsistency. If validation only happens after submission, the user experiences the failure late. If the API does not support a certain action, the design may be beautiful but unrealistic.

This is where API literacy changes the way a designer works.

Instead of only asking, “What should this screen look like?” the designer can ask:

What data does this screen depend on?
Where does that data come from?
What happens when the data is missing?
What does the system consider a valid action?
Can the user recover if this fails?
Can this state be verified?
Is the interface showing a real system state, or just giving the appearance of one?

These are UX questions. They just happen to require some technical fluency.

‍

Why UX designers need to own this layer

I have been seeing this clearly while working with Playwright tests.

At first, it is tempting to think of end-to-end testing as a way to automate what a user does: click this, fill that, submit the form, check that something appears on the screen.

That is useful, but it can also become fragile if the test only understands the UI. A test that clicks through everything manually can fail because of timing, loading states, small UI changes, or data that was not properly prepared. It may also verify that something appeared visually without confirming that the system actually processed the action correctly.

This is where the API becomes important.

In some cases, the API can help set up the correct conditions before the test starts. In other cases, it can verify that the result actually exists in the system after the UI action is completed. That does not replace the user experience test. It strengthens it.

The point is not to bypass the UI entirely. The point is to be clear about what is being tested.

If the goal is to test the user flow, then the UI matters.
If the goal is to confirm that a transaction, form entry, connection, or record was actually created, the API may be the more reliable source of truth.

That distinction is extremely relevant to UX.

Because real users do not only experience screens. They experience whether the system behaves consistently. They experience whether their work was saved. They experience whether the next step appears because the previous step actually happened. They experience the consequences of hidden system logic, even when they never see that logic directly.

‍

This is why I do not think API literacy is optional for designers working on complex products.

Again, this does not mean every UX designer needs to write backend code. But a designer should understand enough to have better conversations with engineers, recognize when a problem is structural rather than visual, and design flows that match how the system actually works.

The strongest UX work often happens in the space between the interface and the system.

That is where defaults are defined.
That is where validation happens.
That is where permissions shape what users can do.
That is where automation becomes possible.
That is where consistency is either protected or lost.

A designer who understands that layer can make better decisions.

They can design screens, but they can also design behavior. They can think about flows, but also about states. They can improve usability, but also reduce ambiguity, prevent errors, and make the product more predictable.

The interface is what users touch.

But the system is what users trust.

And APIs are one of the clearest ways for designers to understand that syste

‍

‍