A public events portal and the application behind it — two products, two audiences, one design system.
01
The public portal has to be fast, scannable and good at one job: finding something to go to. The organiser application has to be dense, precise and good at a dozen jobs.
Built separately they would have drifted within two releases, and the team maintaining them is small.
02
One token set, two densities. The same colour, type and spacing primitives drive both surfaces; the application simply runs at a tighter spacing scale and a smaller base size.
Listing and filtering were designed once and reused, which is where most of the duplicated effort would otherwise have gone.
03
A shared component layer with the application-specific pieces — tables, forms, bulk actions — layered on top rather than forked from it.
Front-end delivery inside the agency's process, with the component library handed over documented.
Indicative figures — replaced with the client’s own analytics once supplied.
We subcontract design and build to him regularly. Briefs come back done, on time, and our clients never know a second party was involved.
