Case study / anonymized
Website design & front-end build
Hospitality · Single venue · UK

A restaurant site built to be
found, read and booked

A full marketing and reservation site for an independent Pakistani restaurant and event venue. The interface below is reconstructed as abstracted blocks — no client name, logo, address or photography appears in this document.

delivered site — home,
above the fold
Region served
Bradford & West Yorkshire
Industry
Restaurant, buffet & event catering
Scope
Full site design + build
Delivery
Version-controlled repo → hosted deploy

Landing surface

Above the fold the page carries one promise, one location cue and two exits: read the menu, or book a table. Everything below is abstracted — bars stand in for set copy, striped panels for photography.

hero photography — venue interior, evening
Eyebrow · positioning
Regional cuisine,
city-centre table
Decision made

Photography carries the room; type stays quiet over it, with a dark scrim so headings hold contrast on any frame.

Two exits only

A filled primary for booking, an outlined secondary for browsing. The same pair repeats site-wide, never a third variant.

Consent, handled

The cookie bar sits inside the design language rather than on top of it, and links to a real policy page.

The visual system

One dark base, one metallic accent, two typefaces. Everything else is a rule about spacing and radius.

Palette
#0B1A2B
Base
#12263C
Surface
#1B3350
Raised
#C9A15E
Accent
#E6D3AC
Accent light
#F0ECE3
Ink on dark
Type pairing
Aa
High-contrast display serif
Headings and pull quotes. Italic reserved for section titles.
Aa
Geometric sans
Body, UI and tracked uppercase labels at small sizes.
scale · 12 / 14 / 16 / 20 / 28 / 42 / 58
radius · 6 / 10 / 22 / pill  ·  grid · 12 col, 24px gutter
Component inventory
nav bar
primary pill
ghost pill
stepper
price card
review card
field
badge
image frame
menu row
progress
footer column

Information architecture

Flat where guests are impatient, nested only where content genuinely divides. Every URL reads as a phrase a guest would say out loud.

URL tree
/
├─ /about
├─ /buffet — dinner + weekend breakfast
├─ /menu
│   ├─ /menu/takeaway
│   └─ /menu/drinks
├─ /gallery
├─ /events
│   ├─ /events/catering
│   └─ /events/event-hall
├─ /order-online — outbound handoff
├─ /book — 5-step reservation
├─ /contact
└─ /cookie-policy
How it scales
What changes
Where it lands
New page?
New dish or price
Menu data, one row
No
New menu category
Section on existing menu page
No
Seasonal buffet
Buffet page, second card
No
New occasion type
Events child route
Yes, templated
Second location
Location segment above the tree
Yes, structural
Booking is a route, not a modal

The reservation flow lives at its own URL, so it can be linked from social, printed on a card, and measured on its own.

Ordering leaves cleanly

Third-party delivery gets one framed handoff page rather than being scattered through the nav.

Search & integrity setup

A local restaurant is found on a phone, near closing time. The setup below is aimed at that moment. Claims here are qualitative by choice — no performance figures are quoted.

01
Technical SEO

Unique titles and descriptions per route, one H1 per page, canonical tags, descriptive alt text, clean internal linking.

02
Sitemap & robots

Generated sitemap covering every public route, robots directives that keep utility pages out of the index, search console verified.

03
Structured data

Restaurant, menu, opening-hours and breadcrumb schema so hours and cuisine can surface directly in results.

04
Local presence

Business profile aligned with the site: same name, hours, categories and service list, with the map and directions reachable from every page.

05
Content architecture

One page per intent — buffet, takeaway, drinks, catering, venue — so each can rank for the phrase people actually search.

06
Core Web Vitals

Sized and compressed imagery, reserved layout space to avoid shift, deferred non-critical work, fonts preconnected.

07
Measurement

Analytics behind consent, with reservation completion, enquiry submission and outbound ordering tracked as distinct events.

08
Accessibility

Contrast checked against the dark base, visible focus states, labelled fields, keyboard-completable booking flow.

Build & delivery

Component-built front end, version-controlled, deployed from the repository. No CMS to babysit, no plugin surface to patch.

Author

Componentised pages, content held as structured data rather than pasted markup.

Commit

Every change is a commit in the repository — the full history of the site is recoverable.

Preview

Each push builds a shareable preview URL, so the owner signs off on the real thing before it goes live.

Ship

Merge deploys to production on managed hosting with HTTPS and a CDN; rollback is one click.

Where submissions go

Reservations and enquiries arrive as formatted email in the business inbox — no dashboard to learn, no second login. Fields are ordered the way front-of-house reads them, so a booking can be actioned from a phone in seconds.

Required fields validated client-side before send
Confirmation state on screen, so guests don't double-submit
Booking rules encoded in the flow, not buried in small print
Inbox format — sample shape
subject: New reservation — [service]
date: ██ / ██ / ████
time: ██:██
guests: ██
name: ████████
phone: ███████████
email: ████████@████.███
notes: ██████████████████
Values redacted for this document.

Further surfaces

The same components, rearranged. Four reconstructions: a pricing surface, a long menu, the reviews module, and the reservation flow on a phone.

Pricing surface
£ ——
ADULTS
£ ——
CHILD
Free
INFANT
Highlights

Two services, one template. Price, window and inclusions in a fixed order so guests can compare at a glance.

Long menu
Category
Category

Two columns on desktop, one on mobile; dietary marks inline. Prices sit on a consistent right rail so the eye can scan cost alone.

Reviews module
source attribution

Guest reviews carried in from the public profile, with sub-ratings and attribution kept intact — quoted, never rewritten.

Booking, mobile
Pick a time

One decision per screen, thumb-reachable targets, progress always visible.

What carries to the next project

Anonymized extract
01
A booking flow that fits the venue's real rules

Cut-off times, advance notice and group handling belong in the flow. Encoding them removes the phone calls that exist only to say no.

02
One page per searched intent

Buffet, takeaway, drinks, catering and venue hire each earn their own URL. It is the cheapest structural decision with a search payoff.

03
A dark palette that survives real photography

Owner-supplied photos vary wildly in exposure. A scrim plus a single warm accent keeps every page legible regardless.

04
Delivery the client can live with alone

Email-in-the-inbox beats a dashboard nobody opens. Content as data means a price change is a one-line edit, not a redesign.

Delivered
Visual system: palette, type scale, component set
Responsive build of every public route
Multi-step reservation flow with validation
Enquiry and catering forms routed to the business inbox
Metadata, structured data, sitemap and robots
Consent banner and policy page
Analytics with conversion events
Repository, deploy pipeline and handover notes

No performance metrics are quoted in this document; every claim above describes work done, not results measured.