The London Design Festival website wasn’t broken. It was doing exactly what it had been built to do, which was to let partners publish most of the site themselves. Around 90% of the content came through the Partner Dashboard, the custom event and content management system we built over five years ago, so a constantly changing programme could go live without landing on the internal team.
What changed was everything around it. Every September the festival launches a new identity, designed by Domenic Lippa and his team at Pentagram, who’ve had the creative direction since 2007. The red stays but almost everything else is redrawn, and the site has to reflect it. When a new visual language can only land through a development project, the identity ends up shaped by what the build allows. That is a strange constraint for a design festival.
The programme keeps moving as well, bringing new work, venues and formats that didn’t exist twelve months earlier. The Global Design Forum, the festival’s talks and ideas programme, had grown into something needing a structure of its own, and marketing wanted to promote different events through the year without needing to ask anyone. The dates and locations are fixed, but very little else is, and the site had been built as though it all were.
When simple changes stop being simple
The first thing we noticed when we started pulling the platform apart wasn’t technical. It was a workflow problem.
Take the navigation. During the festival it points people at what’s happening that week, and for the other eleven months it needs to do something else.
Landing pages were much the same, as was presenting content in a new way. Work that looked small from the outside kept reaching into the codebase.
That wasn’t a flaw in the original build. It had been designed around a different set of priorities, and the gap between those priorities and the team’s current ones widened every year.
The problem wasn’t Rails
When people hear about a project like this, the assumption is often that the technology was outdated, but Ruby on Rails served LDF well and still runs important parts of the platform today.
The real issue was how tightly everything was connected. The dashboard, the content management and the front end were bound together closely enough that a change in one surfaced in another, so small changes took more effort than expected and new ideas were hard to try without pushing complexity elsewhere. It also meant the work sat with a few people who knew both the platform and Rails deeply, which is a fragile place for any organisation to be in.
Separating what manages content from what presents it
Very little was thrown away, and the Partner Dashboard stayed on Rails doing the job it was built for. The front end was rebuilt in Next.js and React, with new blocks in Storyblok giving editors control over pages, navigation and content modules that used to need a developer.
An API sits between the two, so the dashboard can focus on managing content while the website focuses on presenting it, and more of the development team can work across both.
Our Chief Digital Officer Guang wrote recently about choosing the right tech stack. The choices mattered, but for what they make possible rather than for their own sake.
The brief will change again
Successful systems don’t usually fail all at once. More often they slowly become less suited to the needs they were built to meet.
The original platform was right for the problem it was designed to solve, and it solved it well for five years. Then design moved on, the way people find and read things moved on, and LDF moved with them. So the question at the start of a project is less about what it needs to do now, and more about how much change it will need to absorb before anyone looks at it again.
