The web feels direct. You click Save, the button changes, and your work is there when you return tomorrow.

Underneath that moment is a conversation between computers. The browser turns code into an interface. A server applies the product's rules. A database keeps what should survive after the tab closes. The internet carries messages between them.

You do not need to become an engineer to design for this system. You do need a rough map of it. The map helps explain why a screen loads in pieces, why a form can fail after submission, and why a seemingly small feature can require a change to the data model.

The whole journey

Imagine someone opens a project page:

Person → Browser → Internet → Server → Database
                                      ↓
Person ← Interface ← Response ← Server

Here is what happens:

1. The person enters a URL or follows a link.
2. The browser finds the right server and sends it an HTTP request.
3. The server checks the request, runs application logic, and may ask a database for data.
4. The server sends back a response.
5. The browser turns that response into pixels and behavior.

The trip may take a fraction of a second, but it is still a trip. The network may be slow. The server may reject the request. The database may return nothing. Good interface design makes each of those moments understandable.

The browser

The browser is the app running on someone's device. Chrome, Safari, and Firefox are browsers. A browser reads three main languages:

• HTML describes the content and its structure.
• CSS controls presentation and layout.
• JavaScript adds behavior and changes the page after it loads.

You can think of HTML as the layer names, CSS as the properties panel, and JavaScript as the prototype logic. The analogy is imperfect because code must account for live data, screen sizes, input methods, accessibility settings, and failure.

The browser is also called the client. A phone app and a desktop app can be clients too. “Client” means the part of the system that asks another computer for something.

Rendering

Rendering is the process of turning code and data into the interface someone sees. The browser:

1. Reads the HTML into a tree of elements.
2. Reads the CSS and calculates the layout.
3. Paints text, borders, images, and other pixels.
4. Runs JavaScript that may update the page.

This work is why large pages can feel slow even after their data has arrived. Downloading is only part of loading; the device still has to parse, lay out, and paint the result.

The server

A server is a computer running software that responds to requests. Its location matters less than its role: it owns the rules the client should not be trusted to enforce.

Suppose a person clicks Delete workspace. The client can open the confirmation dialog and send the request. The server must still check:

• Is this person signed in?
• Do they belong to this workspace?
• Are they allowed to delete it?
• What other records must change with it?

Client-side checks make an interface feel responsive. Server-side checks make the product correct. Anything sent from a browser can be altered, so the server must treat it as untrusted input.

The server usually handles authentication, permissions, payments, email, database access, and other product logic. This collection of server-side code is often called the backend. The interface code in the client is the frontend.

Requests, responses, and APIs

The client and server communicate through requests and responses. On the web, they usually use HTTP.

A request says:

POST /projects

{ "name": "New portfolio" }

The method describes the intended action:

• GET reads something.
• POST creates something.
• PATCH changes part of something.
• DELETE removes something.

The server answers with a status and, often, data:

201 Created

{ "id": 184, "name": "New portfolio" }

Common status codes include:

• 200 means the request succeeded.
• 201 means something was created.
• 400 means the request was invalid.
• 401 means the person is not signed in.
• 403 means they are signed in but not allowed to do this.
• 404 means the requested thing was not found.
• 500 means the server failed unexpectedly.

An API is the agreed shape of these requests and responses. It is a contract between pieces of software. If the API returns a project with a name, owner, and updatedAt, the interface can decide how to present those fields. If the interface needs a collaborator's avatar but the API does not return one, design and engineering have found a contract that needs to change.

Client and server are a conversation

Consider a save action:

1. Person clicks Save
2. Client shows progress and sends a request
3. Server validates and stores the change
4. Server returns success or an error
5. Client updates the interface

The client can wait for confirmation before changing the UI. This is safe but may feel slow.

It can also update immediately and assume the request will succeed. This is called optimistic UI. Liking a post is a common example: the heart fills at once, while the request finishes in the background.

Optimistic UI still needs a recovery path. If the request fails, the interface must undo the change or explain what happened. Instant feedback does not remove uncertainty; it chooses how to represent it.

The database

A database is durable product memory. It stores information that should remain after a request ends or a device turns off: accounts, projects, messages, permissions, and purchases.

Many web products use a relational database. It organizes data into tables. A simplified projects table might look like this:

The parts have familiar spreadsheet-like names:

• A table holds one kind of thing, such as projects.
• A row is one project.
• A column is one property, such as its name.
• A primary key is a stable ID for a row.
• A foreign key points to a row in another table.

Here, owner_id can point to the person with id = 42 in a users table. That connection is a relationship.

The comparison with a spreadsheet only goes so far. A database enforces types, constraints, and relationships. It is built to let many people read and change connected data without corrupting it.

The data model shapes the interface

Suppose a project starts with one owner. Later, the team wants co-owners.

This is not only a matter of adding another avatar to the UI. The current owner_id column can represent one owner, not many. Engineering may need a new relationship table that connects many people to many projects. The API must return the new shape. Permissions must account for it. The interface must cover invitations, removal, and what happens when the last owner leaves.

A useful question in early design reviews is: what must the system remember for this interface to be true?

SQL

SQL, usually pronounced “sequel” or “S-Q-L,” is a language for working with relational databases.

This product question:

Show Flora's three newest projects.

Could become:

SELECT *
FROM projects
WHERE owner_id = 42
ORDER BY created_at DESC
LIMIT 3;

The statement reads almost like instructions:

• SELECT chooses what to return.
• FROM names the table.
• WHERE filters rows.
• ORDER BY sorts the result.
• LIMIT caps how many rows come back.

SQL also creates, updates, and deletes data. These four operations are often shortened to CRUD: create, read, update, delete.

You rarely need to write SQL as a designer. It is useful to recognize what a query does because product questions often become data questions. “Can we sort by most active?” means the system needs a definition of activity, stored events to measure it, and a query that can calculate it fast enough.

State: where does the truth live?

State is information that can change. A selected tab, an unfinished form, the current account, and a saved project are all state.

State can live in different places:

• Local UI state lives in the client. It may disappear when the page refreshes.
• URL state lives in the address, such as a search query or selected item. It can be shared and revisited.
• Server state lives behind the API and often comes from a database. It survives across devices and sessions.
• Cached state is a temporary copy kept nearby so repeated reads are faster.

Where state lives changes what people expect. A filter encoded in the URL can survive refresh and be shared. A draft kept only in browser memory disappears when the tab closes. A preference stored on the server can follow someone to another device.

When a design calls for persistence, sync, undo, or collaboration, it is making a technical claim about state.

Build time and runtime

Build time and runtime answer when work happens.

Build time

Build time happens before a version of the site is deployed. A build process might:

• Turn TypeScript into JavaScript.
• Convert Markdown into page content.
• Bundle and compress files.
• Optimize images.
• Generate pages that are the same for everyone.

This site processes its MDX files at build time. The expensive content parsing is done before a visitor opens a page.

Build-time work is useful when the answer is stable. A portfolio page, documentation site, or article can be prepared once and served many times. Visitors get a fast result, but publishing a change usually requires another build.

Runtime

Runtime is when the deployed product is running and someone is using it. Runtime work might:

• Load a person's inbox.
• Check whether they can access a workspace.
• Calculate the current cart total.
• Save a comment.
• Return live search results.

Runtime work is necessary when the answer depends on who is asking or what just happened.

A useful test is: could every visitor receive the same answer? If yes, the work may fit at build time. If the answer depends on the person, the request, or live data, it belongs at runtime.

Two axes, not one

Client versus server and build time versus runtime describe different things:

Client vs. server   = where does the code run?
Build vs. runtime   = when does the work happen?

They can combine. A server may generate an article at build time, check permissions at runtime, and send JavaScript that later runs on the client. “Server-side” does not automatically mean “build time,” and “client-side” does not mean “runtime only.”

This distinction clears up a lot of technical conversation. Ask where? and when? as separate questions.

What the network means for design

Every client-server interaction crosses a boundary. The request can be delayed, duplicated, rejected, or interrupted. The interface needs to account for more than the happy path.

For any data-dependent surface, consider:

• Initial: nothing has happened yet.
• Loading: the request is in progress.
• Empty: the request succeeded, but there is no data.
• Success: the expected data or action is available.
• Error: the request failed or was rejected.
• Stale: old data is visible while a fresh copy loads.
• Offline: the client cannot reach the server.

These are not edge cases added after the main design. They are states of the product.

Latency also changes interaction choices. A 100-millisecond action may need no visible progress. A two-second action needs feedback. A ten-minute export should survive navigation and notify the person later. The duration of the underlying work belongs in the interaction model.

A designer's checklist

When a screen talks to a server or database, ask:

• What starts the request?
• What feedback appears while it runs?
• What can fail, and can the person recover?
• What happens when the result is empty?
• Which actions require permission?
• What should survive a refresh or device change?
• Can two people change the same thing at once?
• Is the UI showing current data or a cached copy?
• What must the database remember for this feature to work?

You do not need to prescribe the implementation. These questions make the behavior visible. They also give design and engineering a shared vocabulary for the parts of the product that a static mockup cannot show.