Alex OS homepage journey engine
The CMS-driven journey + orbit engine powering the public homepage.
The problem
One static homepage cannot serve visitors with different intents — evaluating the work, exploring the systems, or reading the ideas behind them.
My role
Design + build
Alex OS homepage journey engine
The engine behind the journey homepage: journeys and per-journey sections live as CMS records, and the frontend assembles the experience from them. Picking a journey re-prioritises the content, swaps the headings, and hands the assistant a journey-specific brief — all without a deploy.
Key decisions
Journeys and their sections are CMS records; the TypeScript defaults exist only as a fallback for when the database is unreachable. That distinction earned its keep more than once — the live configuration was in the database, so editing the code defaults would have changed nothing on the site.
The orbit spheres were part of the original design and are now switched off: the redesigned hero does the same job with less machinery, and the orbit records stay in the database rather than being deleted, so the decision is reversible.
Outcome
The homepage reorganises around a chosen journey — hero, headings, sections and assistant prompts are all CMS-configured.
- 2 visible journeys
- Sections, headings and prompts all CMS records
Limitations
A journey is only as good as the content placed in its sections — a section pointing at a content type with nothing publishable renders as nothing at all, which is exactly what happened to the evidence section before its entries carried a method.