How a website works
What your customer sees in the browser is part of the picture. Explore what happens behind a contact form, a booking and a customer portal.
A visitor sends an enquiry. This example uses an email service without a separate customer database.
Drag to rotate. Select a layer to bring it forward. On mobile, enable touch interaction first.
01 / 6 · BROWSER / UI
The part your customers see. Content, layout and navigation help them understand your offer and know what to do next.
A simple website can be a set of static pages. Add a form, CMS or other features only when they serve a purpose.
Illustration only. No information is sent and no real booking or sign-in takes place.
The model groups areas of work into a simplified journey. These are not necessarily separate systems. A real request can involve several areas at once.
A website does not need every layer. A standard platform or a link to an existing tool can be the right choice. Additional technology needs a reason to be there.
The part your customers see. Content, layout and navigation help them understand your offer and know what to do next.
The behaviour between clicks. A form responds to input, a calendar presents choices and the interface keeps track of progress.
Pages and requests need to reach their destination. Hosting makes the site available; optimisation reduces unnecessary waiting.
The server checks information and permissions. Browser checks help people complete a task, but do not establish trust.
Stored information needs a clear structure and the right access rules. A straightforward brochure site may need no database of its own.
A website can connect to email, booking and other tools. Those connections also need a plan for an unavailable service.
Define the audience, purpose, pages and customer action before choosing the features.
Responsive layouts, accessibility and performance need to work alongside the agreed features. Testing includes the paths where something fails.
Deployment, HTTPS and handover prepare the site for use. Hosting, maintenance and future changes are agreed as part of the scope.
A visitor sends an enquiry. This example uses an email service without a separate customer database.
Clear content and an accessible form make getting in touch straightforward on a phone or with a keyboard.
The browser checks fields and indicates progress. The server will still need to validate the request independently.
HTTPS protects the information in transit to the function handling the form.
Field validation and request checks happen before the email service is contacted.
The service accepts the message for delivery. That does not prove it has already reached the recipient's inbox.
The website confirms what it knows: the enquiry has been accepted for processing.
The server rejects the field. The form explains what to change while keeping the rest of the message intact.
The page cannot promise success without confirmation. An uncertain delivery needs reconciliation before a retry could create duplicate messages.
An interrupted request should not leave a spinner running indefinitely. The interface preserves the text and explains the problem.
A customer chooses an appointment. This example has its own booking rules and stored reservations.
The calendar shows availability retrieved from the system. A visible slot is not yet a confirmed booking.
The customer can review the service and time before confirming, with a clear indication of progress.
The browser sends the selection to the server over HTTPS.
The server validates the details and booking constraints. Availability shown earlier may now be out of date.
An atomic write and a suitable database constraint prevent two customers from taking the same slot. Another availability lookup alone would not prevent the race.
The email service is notified after the reservation is saved. An email failure does not undo the booking.
The page displays the saved reservation, so the customer does not have to wait for an email to know it worked.
The database rejects the competing reservation. The customer can choose another appointment instead of being double-booked.
The reservation and email have separate outcomes. The system retains the booking and can retry the notification without reserving a second appointment.
From signing in to the correct document. Knowing who the customer is and checking what they can access are separate responsibilities.
A clear sign-in screen leads to the customer overview. This example uses no real account details.
The interface makes the next action easy to find. Hiding a link does not protect the file behind it.
The browser connects over HTTPS. Private responses must not be reused through a public cache.
The server validates the session, then checks permission for this particular document. Being signed in does not grant access to every file.
The data model links the customer to the correct case and file. Queries and file access must enforce matching permissions.
Protected file storage delivers the permitted content, with access still restricted to the intended customer.
The document is available without another email exchange. No real file is downloaded in this example.
The server stops the request before sending private information. Interface and API permissions need to agree.
A moved or deleted file needs a useful explanation. The response must not reveal information about another customer's documents.
Tell me about the business and what customers need to do. We can then work out which parts the solution actually needs.
Discuss your project