What a backend developer actually does
You've been working in the frontend — the part of the product users can see and touch. The backend is everything that makes the data work: the servers, the databases, and the business logic that runs on them.
A backend developer builds: the server (a computer program that listens for requests and responds to them), the database (where all the permanent data lives — user accounts, posts, orders, products), and the logic that ties them together (what happens when someone signs up, buys something, or deletes their account).
As a designer, you're not building this. But you're designing for it — and your designs have to account for what the backend can and can't do. The moment you start asking the right questions and designing for real data, you become a fundamentally more valuable collaborator.
APIs — the door between frontend and backend
API stands for Application Programming Interface. That sounds intimidating but the idea is simple: an API is how two systems talk to each other.
The frontend (your website/app) doesn't have direct access to the database. Instead, it talks to the backend through the API. The frontend sends a request: "give me the user's recent orders." The API receives that request, asks the database, and sends back the data.
An everyday analogy: when you go to a restaurant, you don't walk into the kitchen and grab food. You tell the waiter what you want. The waiter (the API) goes to the kitchen (the backend) and comes back with your order. You never see the kitchen. The API is the waiter.
/api/users might return a list of users. /api/users/123 might return the user with ID 123. You request these endpoints and get data back. You don't need to build REST APIs — you need to design around them.JSON — how data travels
When the backend sends data to the frontend, it's usually formatted as JSON. JSON (JavaScript Object Notation — jargon for "a way to write structured data") looks like a labeled list. If the backend is sending you a user's information, it might look like this:
{
"user": {
"id": 1042,
"name": "Rohan Boda",
"email": "rohan@example.com",
"avatar_url": "https://example.com/avatars/1042.jpg",
"plan": "pro",
"joined_at": "2024-03-15",
"posts_count": 47
}
}Everything has a key (in quotes on the left) and a value (on the right). This is the data your frontend has to work with. As a designer, when you design a user profile, this is the data you're designing around. Your design needs to handle:
- What if
avatar_urlis missing? (The user never uploaded a photo) → You need a default avatar or initials - What if
nameis "Konstantinos Papadopoulos-Alexandridis"? (Very long name) → Your layout needs to handle it - What if
posts_countis 0? → You need an empty state design
Status codes — what the server is saying
Every time the frontend talks to a backend API, the server responds with a status code — a number that tells you whether things went well or not. You'll see these in DevTools when you watch network requests. More importantly: your UI needs to handle every possible response.
- 200 OK — success, here's your data. Your UI shows the data.
- 201 Created — success, we created the thing you sent (like a new post or account)
- 400 Bad Request — you sent something wrong (a form with invalid data, a missing required field). UI shows a validation error.
- 401 Unauthorized — the user isn't logged in. UI redirects to login.
- 403 Forbidden — the user is logged in but doesn't have permission. UI shows a "you can't do that" message.
- 404 Not Found — the thing doesn't exist. UI shows a "page not found" or "item deleted" state.
- 500 Internal Server Error — the server broke. Not the user's fault. UI shows a generic "something went wrong, try again later."
How to talk to backend developers
Knowing the vocabulary changes how developers perceive you. These are real questions you can ask in any meeting — and asking them will make people notice that you think differently from other designers.
- "What does the API response look like for this?" — You're asking for the JSON structure, so you can design around real field names and real data shapes.
- "What's the field name for the user's display name?" — You want to label your designs correctly, using the actual field name from the API (not an invented one that doesn't match).
- "Is this list paginated?" — Will the API return 20 items at a time? 50? Does it have infinite scroll or a "load more" button? Your design depends on this.
- "What are the character limits on these fields?" — How long can a username be? A post title? A bio? Your design needs to handle the maximum (without breaking) and the minimum (including empty).
- "What are the possible error states for this action?" — Everything you can imagine going wrong needs a designed response in the UI.
-
1Open Chrome and go to jsonplaceholder.typicode.com — this is a free, fake API designed for practicing exactly this. Open DevTools (
Cmd + Option + I) and click the Console tab. -
2Type this exactly in the Console and press Enter:
fetch('https://jsonplaceholder.typicode.com/users/1').then(r => r.json()).then(console.log). You'll see a JSON object appear — a fake user with name, email, address, phone, company, and more. -
3Look at the data structure. What fields are there? What might be missing in a real scenario? Note the nested objects (like
address.cityorcompany.name). -
4In Figma, design a user profile card that displays: the user's name, email, company name, and city. Design two versions: Version A — all data present and well-formatted. Version B — the avatar is missing (show initials instead), and the name is unusually long.
-
5Reflect: Notice how designing around real JSON data shapes every decision — what to show, what to hide, how to handle missing or extreme values. This is what "designing for real data" means.