By Muhammad Faraz · 3 min read
Separate presentation from decisions
The interface displays information and collects input. The backend can handle trusted operations such as checking access, updating stored records and coordinating integrations. The exact division depends on the product. A static portfolio may need very little server behavior; a multi-user operations platform needs much more.
Source: MDN: server-side website programming ↗Think in complete requests
For a booking action, consider the whole sequence: input validation, availability, authorization, record creation and a response. Define what happens when something changes during the request. A successful screen design does not automatically answer those questions. They should be part of the discussion between design and development.
Expect imperfect connections
Requests can fail, arrive late or be repeated. Give the interface meaningful loading, error and retry behavior. Preserve user input when recovery is possible. For important actions, the team should agree on how the system avoids duplicate effects and how it communicates the final state to the user.
Scope the operating work
Discuss hosting, access management, backups, monitoring and who responds to failures. These responsibilities affect the product beyond its first release. A useful development proposal names the required integrations and the assumptions around them. This helps the client distinguish a visual prototype from a functioning service with ongoing responsibilities.
Example: reserving an appointment
A visitor chooses an available time and submits a booking request. The backend needs to confirm that the time is still available before storing the reservation. It should return a result the interface can explain, such as confirmed or no longer available. Two people may request the same slot close together. Planning this situation helps the team avoid a design that assumes every visible option remains available indefinitely.
Define the contract between teams
Agree on the information sent with a request and the possible responses. Describe required fields, validation errors and permission failures in a way both frontend and backend developers can use. Include example responses when useful. A clear contract allows the interface to handle expected states before the integration is finished and makes it easier to identify whether an issue comes from the client, the service or the data.
Keep trusted decisions on the trusted side
A browser can display a price or hide an action, but those interface choices do not establish authorization. The backend should check the rules relevant to the operation. Discuss ownership of records and access between different customers early. A polished admin page can still be incomplete if the corresponding service accepts actions from people who should not be able to perform them.
Ask useful handoff questions
Who maintains the service, how are configuration changes managed and what happens when an integration is unavailable? What information helps support investigate a failed request? Which responsibilities belong to the client and which belong to the developer? These questions make an estimate more concrete. They also help distinguish a clickable demonstration, a test deployment and a service prepared for real users.
