Case study 04 · Self-directed · AI + code · 2026
World Cup 2026 — Building the experience I designed.
An interactive World Cup explorer built on SYX with GSAP, Three.js and Leaflet. The brief, the limits and the acceptance criteria were written before the first line of code and published alongside it — which is the part of a self-directed project you normally have to take on trust.
In 30 seconds
- The tension
- SYX could only show itself. Nothing proved it could carry an editorial project with real visual ambition.
- My call
- Write the brief, the limits and the acceptance criteria before the first line of code, and publish them next to the result.
- The evidence
- 11 specifications, 28 acceptance criteria and 8 screens shipped on GSAP, Three.js and Leaflet. Counted on 22 August 2026.
- What changed
- A closed piece that answers how far past the hand-off I go. The review I never scheduled is the part I would change.
- Role
- Product Designer · builder
- Base
- SYX
- Interaction
- GSAP · Three.js · Leaflet
- Mode
- AI-assisted development
Why I built it
SYX could only show itself, and that proves nothing.
The system had documentation, a token showcase and a page explaining its own architecture — all of it about SYX. A design system is not proved by describing itself. It is proved by carrying a product where it is the means and not the subject. What I wanted to find out was whether SYX could hold an editorial project with more visual ambition than anything it had carried before.
Live product evidence
The deliverable is the running experience.
This preview renders the published World Cup 2026 explorer directly inside the case study. It gives immediate visual context while keeping the full experience one click away.
SYX / INTERACTIVE EXPLORER
2026Product idea → interaction → AI-assisted code → working experience
Before any code
Eleven documents before the first line.
Scope, screens, data layer, motion and 3D guidelines, theming, build rules — and two that mattered more than the rest: the boundaries and the acceptance criteria. They live in the repository, dated, and anyone can open them. That is the whole point of publishing them. On a self-directed project nobody can tell whether the brief came before the result or after it, unless the brief is public.
- 00-project-overviewWhat the product is and who it is for
- 01-strategy-and-boundariesWhat the project must be, and what it must never be
- 02-syx-architecture-mandatory-rulesThe architecture rules the build is not allowed to break
- 03-design-system-applicationHow SYX maps onto this particular product
- 04-product-scope-and-screensThe MVP views and the purpose of each one
- 05-data-sources-and-data-layerPublic feeds, and the normalisation layer between them and the interface
- 06-storytelling-motion-and-3d-guidelinesHow far motion and 3D are allowed to go
- 07-multitheming-specHow a theme changes without rewriting components
- 08-file-structure-and-deliverablesWhat gets delivered and where it lives
- 09-build-rules-and-local-developmentHow it builds and how it runs locally
- 10-quality-checklistTwenty-eight criteria to validate the result against the brief
The line I had to draw
I work in sports media. I was building a World Cup product on my own time.
That is a conflict waiting to be misread, so the rules went in writing before anything else did.
- What the project had to be
- A public-data editorial explorer and a showcase for the design system, running on legitimate open feeds. Editorial in tone, exploratory in structure, and open about being a portfolio piece.
- What it could not be, under any reading
- No betting, no porra, no predictor, no fantasy, no leaderboards. No naming that resembles a newsroom product label, no internal or private data, and no implication of insider strategy of any kind.
The build
The work was coordinating three libraries, not adding them.
GSAP for motion, Leaflet for the map, Three.js as a focused accent layer, across eight screens on Vite and Sass. Dropping any one of the three into a page is easy. Making them share a single interaction language across eight screens, inside the token and component rules SYX already imposes, is where the project actually was. There was no team on this one: the eleven documents were the only thing keeping me honest. AI accelerated the implementation — the intent, the limits and the system were already written down.
The bar, and what I did with it
I wrote twenty-eight acceptance criteria and never went back to them.
The checklist covers eight areas: architecture, how visible SYX is in the result, product framing, the data layer, motion, multitheming, delivery, and a final pass. I wrote it as part of the brief and I never ran it as a closing review. It did deliver something — while I was building, it kept deciding what the project was allowed to be. What it did not deliver is the thing it was designed for. A checklist with no date in the calendar is documentation, not control.
- Specifications
- 11
- Acceptance criteria
- 28
- Screens shipped
- 8
What happened after
A closed piece, and the one I open when someone asks how far I go.
The repository has not moved since March and does not need to: this is a finished piece, not a product with a roadmap. What it does now is answer one question faster than any description of it — how far past the hand-off this actually goes. That is the job it has.
Takeaway
The system holds at a higher visual register than its own documentation.
What I set out to check was whether SYX could serve an editorial project with real visual ambition — motion, 3D, mapping, several themes — without the architecture giving way underneath it. It could, and that is the answer I keep. What I would change is the part I already know about: the criteria were written and the review was never scheduled, so the project was governed at the start and ungoverned at the end.