Synonyms: application programming interface, endpoint, web service, interface (technical sense)
Do not index
Definition
An API (application programming interface) is a set of rules that lets two pieces of software talk to each other. It defines what one system can ask another for and what comes back.
For designers and PMs, this matters because the API decides what data and actions are even possible on screen, and for developer-facing products, the API itself is the thing you're designing.
Use cases
Design without knowing the API and you'll draw screens the product can't actually serve.
Data that doesn't exist: A dashboard mockup shows a field the API never returns. The design looks great, then can't ship without backend work nobody scoped.
Mockups that ignore reality: A perfect screen built on fake data breaks the moment the API returns nulls, 10,000 rows, or a server error. The team finds out in QA, not design.
A list the API can't feed: An "infinite scroll" design collides with pagination and rate limits, so it stutters or fails under real load.
How it's used in practice
Read the API first: Before designing, learn what data, fields, and limits exist, by checking the docs or asking backend. It bounds what you can build.
Design the unhappy paths: Sketch loading, empty, partial, error, and rate-limited states, not just the perfect case.
Plan for latency: Decide what shows while data loads (skeletons, optimistic UI) so slow responses don't leave a blank screen.
Treat developer experience as UX: For API products, the docs, naming, and error messages are the interface. Write them like design work.
🪄
Pro-tip: Design with a real API response, not invented JSON. Ask for a sample early, then build the empty, error, and partial states straight from it. You'll skip the whole round of "the backend can't do that." And for API-first products, remember the error message is UI copy, so write it like it.
Challenges & limitations
Hidden ceilings: Backend constraints, like what's stored and how often you can call it, quietly cap the experience you can build.
Invisible UX: For API products, bad docs and confusing error messages sink adoption, and there's no obvious "screen" to point at when it fails.
Commonly Used Standards & Tools:
REST — the most common API style, organized around resources and URLs. Best for straightforward web and mobile apps.
GraphQL — lets clients request exactly the fields they need in one call. Best for complex UIs that pull varied data.
OpenAPI / Swagger — a standard way to describe and document an API. Best for keeping design, docs, and code in sync.
