Skip to content
All work

NS-007 · Restaurant Web Experience

Nous Sommes Un

LiveDesign + Build202696 PERF · 100 A11Y/SEO

Outcome

A cinematic, photography-heavy restaurant site that still hits Lighthouse 100 across accessibility, best practices, and SEO — 96 performance on desktop, proving atmosphere and speed aren't a trade-off.

Nous Sommes Un — view 1 of 4
Nous Sommes Un — view 2 of 4
Nous Sommes Un — view 3 of 4
Nous Sommes Un — view 4 of 4

Nous Sommes Un — French for 'we are one' — is a fictional high-end restaurant split across two dining rooms, Paris and Toronto. The brief I set myself: most luxury restaurant sites load like templates, and a five-star room should never feel like one. The site's whole pitch is atmosphere plus speed — cinematic and image-heavy, but instant to load — and that tension drove every decision, from the stack to the animation budget.

A written brief before a single line of code

I treated it like a real client brief, not a portfolio sketch. I researched what current luxury restaurant sites do well and where they fail, wrote a problem statement, and only then started brainstorming the restaurant itself — the name symbolizes unity and strength. Before touching Next.js I built a design spec in Figma: typography, colour, logo, visual language. The must-haves stayed non-negotiable throughout: menu, hours, locations, and reservations findable in seconds, a hamburger nav on mobile with one-tap location/email/social, and full SEO and metadata.

  • Researched competitor luxury-restaurant sites before any design work
  • Figma design spec — typography, palette, logo — preceded the build
  • Hard requirement: menu/hours/location/reservations findable in seconds, mobile-first nav

Directing Claude Code through a Design Intent Interview

Before Claude Code wrote anything, I gave it the full brief and ran it through a structured Design Intent Interview — iterating on UI/UX intent across many rounds of planning before any implementation. That kept the agent's output aimed at a specific feeling (atmosphere, restraint, premium pacing) instead of generic restaurant-template defaults. From there the build ran as a tracked pipeline: scaffold and dependencies, brand and content data, the shell (header, contact dropdown, mobile menu, footer, six routes), then a static home page built from 19 curated photos across five sections.

  • Design Intent Interview with Claude Code before any code was written
  • Tracked pipeline: scaffold → brand/data → shell → home → subpages → reservations → animation → SEO/a11y/perf
  • 19 curated photos across 5 home sections

Framer Motion for UI, GSAP for the scroll choreography that needed it

The stack is Next.js (App Router) + TypeScript + Tailwind, with Framer Motion driving interface motion and GSAP ScrollTrigger brought in specifically for the pinned, scrubbed scroll sequences — Framer's scroll primitives aren't built for that. Next.js's static rendering and image optimization are why a photography-heavy dark site could still hit strong Lighthouse scores, which is exactly where most restaurant sites lose. TypeScript because the code is part of the portfolio and has to be inspectable, not just the finished page.

  • Next.js App Router + TypeScript + Tailwind
  • Framer Motion for UI motion, GSAP ScrollTrigger for pinned/scrubbed scroll sequences
  • Static rendering + image optimization carried the Lighthouse scores

No CMS, no booking backend — on purpose

It would have been easy to over-build this: a CMS for content, a real backend for reservations. I deliberately skipped both. A spec piece doesn't need infrastructure serving an editor that doesn't exist, so the three-step reservation flow — location, then date and time slots, then guest details — runs fully client-side with a frame-draw confirmation, and the whole site ships static with nothing to break in production. The bilingual EN/FR toggle got the same restraint: real content in both languages, not a translation-library stand-in.

  • 3-step reservation flow — location → date/slots → details — with a frame-draw confirmation
  • Fully static: no CMS, no booking backend, nothing to break
  • EN / FR language toggle with real bilingual content, not machine translation

Where the numbers actually landed

After the animation pass — Lenis smooth scroll, parallax, a pinned gallery, a preloader, reduced-motion handling, and cleaning up ghost ScrollTriggers — I ran the SEO, accessibility, and performance pass: JSON-LD, sitemap, OG image, a full keyboard sweep. Lighthouse came back 100 on accessibility, best practices, and SEO, with 96 performance on desktop and roughly 85 on mobile for a dark, image-dense site. Then real refinements — bug fixes, parallax edge cases, the EN/FR toggle — before deploying live on Vercel.

  • Lighthouse: 100 a11y / best-practices / SEO, 96 perf desktop, ~85 mobile
  • Lenis smooth scroll, parallax, pinned gallery, preloader, reduced-motion throughout
  • Deployed live on Vercel — two fictional rooms, Paris and Toronto
Credits
Solo — design & direction
AI
Ran a Design Intent Interview with Claude Code before writing any code, then directed it through scaffolding, animation, and polish — reviewing every diff and making every UX call myself.
Next.jsFramer MotionVisitGitHubCode