Event and festival websites · Redesign and migration
Your schedule is data,not a page.
An event website is judged on a handful of days a year. We model the lineup, venues and times as structured content first, plan the peak backwards, and hand over a site your own team can run without an agency on call.
An architect reads your situation and replies in writing, usually inside 24 hours. No calendar to juggle.
Content model first, peak planned backwards, and a handover that leaves your team in control.
What we keep finding
Six patterns show up in almost every event website we are asked to rescue.
None of them are design problems. They are the reasons a redesign either lasts a decade or has to be redone the first time the lineup changes.
The schedule lives in a page
Artists, stages, times and venues are typed into a layout, so nobody can ask the site what is on Saturday evening near the north gate.
Every change needs the page builder
A start time moves and someone has to open a builder, find the right row and hope the layout survives. On event weekend that is too slow.
Design locked into content
A builder theme fuses the words to the layout, so a refresh means retyping the site rather than restyling it.
Untested for the one weekend that counts
Traffic is flat for months, then arrives all at once with a sold-out notice attached. The stack has never met that day.
Accessibility left to the theme
Contrast, focus order, alt text and keyboard navigation are inherited from whatever the template shipped with, and never checked.
No plan for the year after launch
The project ends at handover. Nobody wrote down how the site is fed, who can publish, or what happens when the volunteer who knew changes roles.
The design decision is usually the easy part. The hard part is whether your own team can change a start time at seven in the morning.
Structure
Your schedule is data, not a page
Model artists, attractions, venues and times as content types once, before anything is designed. Then a single source feeds a filterable mobile schedule, a what is on now view, a printable program, a sponsor listing and next year's site.
This is the decision the rest of the project inherits. Get it right and adding a stage is a two-minute edit. Skip it and the redesign has to be redone the first time the lineup changes.
- One content model for lineup, venues, times and attractions
- Every visitor view generated from the same data
- Information architecture drawn from what visitors actually search on site
Peak risk
The whole year lands in four days
An event site is quiet for most of the year and then carries everything at once: gate times, parking changes, a weather call, a stage swap, a sold-out notice. That is when an untested cache, a builder theme and one shared login become the problem.
So we plan the peak backwards. What has to be publishable from a phone in two minutes, what has to survive the spike, and who is allowed to press publish at seven in the morning when the gate plan changes.
- Load and cache behavior proven before the event, not during it
- Urgent notices publishable from a phone, by more than one person
- Roles and review states that match how the weekend actually runs
Editorial autonomy
The upside is not needing us next year
The best outcome of an event website project is that nobody has to call an agency to change a start time. That means an authoring experience someone can use on the first try, content blocks that cannot be broken, and a handover written down rather than delivered once.
The operational metric we hold ourselves to is time from decision to published, by someone who has never seen the admin before. It runs off the critical path, so it can be proven early rather than promised at the end.
- Authoring a volunteer or small staff team can use unaided
- Approved blocks only, so speed costs no consistency
- Recorded training and written handover you keep
How we frame the work
Experience, Data, Activation, Optimization. Run as a loop, not a ladder.
We move the operational metrics inside each layer. Which of those matter to the organization stays your hypothesis, not our claim.
Experience
The core of the workA mobile-first schedule that answers real visitor questions, clear paths to tickets, directions and gate information, and accessibility built into the component set rather than audited after launch.
Data
StructuralLineup, venues, times, attractions, vendors and sponsors modeled as structured content, not as pages. Migration of existing content mapped into that model, with redirects for everything that ranked.
Activation
OperationalRoles, review states and urgent publishing paths defined with the people who work the event. Ticketing, email and social handoffs wired so a change is entered once and appears everywhere.
Optimization
Continuous, event to eventMeasure what visitors search for on site, where they drop before tickets, and how long a content change takes. Each event cycle leaves evidence for the next one instead of opinions.
Credentials
Not new to this, and not selling you a platform.
Teams whose audience arrives all at once
Proof · Work of the same shape
A lot depends on a short window, and the content owners are not engineers.
IRONMAN
Race weekend, where the content cannot fail
A global endurance brand with event-day traffic spikes and content that has to be right the first time. Platform, performance and publishing built around the days that matter most.
PADI
A worldwide membership and its local centers
One platform serving a global member audience and thousands of local operators, with the content owners in control rather than queued behind engineering.
OHCHR, United Nations
Publishing at volume, by non-engineers
High-volume multilingual publishing with accessibility as a requirement rather than an afterthought, run day to day by editorial teams.
How the work is sequenced
Model first, build against it, rehearse the peak.
Content model and information architecture
We settle the content model for lineup, venues, times and attractions, and the navigation visitors actually need. Design starts after this, not before it.
Weeks 1 to 3 · Foundation
Design, build and migration together
A component set built against the model, existing content migrated into it with redirects preserved, and accessibility checked as components land rather than at the end.
Weeks 4 to 10 · Build
Peak rehearsal and handover
Load behavior proven, urgent publishing rehearsed with the people who work the event, then written handover and recorded training so the site is yours to run.
Before launch · Evidence
Our thinking on this problem shape
Written from sites we already moved.
How we choose a platform honestly, how structured content changes what a site can do, and what a performance audit finds before the day you cannot afford a failure.
Open a brief
Tell us about the event and the site in front of it.
An architect reads it, not an SDR. You get a written response, usually inside 24 hours, with how we would sequence the work, where the peak risk sits, and what we would leave alone. If we are not the right team, we will say so and point you to one we trust.
- Written assessment, no calendar bookings
- We will tell you what is not worth doing yet
- No sales sequences, unsubscribe anytime