March summary – deeper dive edition
If you missed it, here’s the moment the new Luton Council website launched: ‘We are live!‘
After months of planning, content sprints, SME workshops and a lot of ‘work backwards from the date’ energy, our new council website is now live — built on LocalGov Drupal (LGD) and shaped by feedback from residents, staff and frontline services.
This post is a deeper dive than usual into:
- what actually happened in the final stretch
- what we learned during launch week
- what we’re focusing on next as we shift from delivery mode into continuous improvement
Grab a refreshment and hope you enjoy this read…
🌍 Why this launch mattered
The headline is simple: a quicker, clearer and easier to use luton.gov.uk.
However, the deeper effect of this change has been felt internally, across the entire council.
This project strengthens a culture shift towards user‑centred design and a more agile, collaborative way of working. Not as a theory, but as something we’ve had to practise in real time with real trade‑offs.
LGD matters because it gives us a foundation that’s designed to improve over time — not a one‑off rebuild. That means we can keep:
- iterating our digital front door experience for users
- improving key UX principles such as findability and discoverability
🧩 What changed on the website (in practical terms)
Have you heard someone say, ‘the website has a new look and feel’ – what does that actually mean? Often, I’m guilty of saying this too.
I can understand the look part, but feel… what is that? How do you feel a website, right?
It’s hard to define it, but here’s my take. It’s the change in how the website behaves, shape shifts all because of a simple tap or click. It could be felt in various ways:
- using structured patterns and plain English
- navigation and menus changes
- faster and clearer search results
- quick links to keep common tasks easy to reach
- adapts easily to your digital accessibility needs
🛠️ Behind the scenes
Go‑live coordination
We ran a dedicated virtual ‘War Room’ via Teams on launch day, with regular stand‑ups and clear escalation routes so that:
- decisions could be made quickly
- issues could be triaged without noise
Content design
The final push included:
- completing publishing across key content types, including guides, service pages, directories and news
- tidy‑ups that were safe to do immediately
We had a temporary content freeze in the lead up to launch so we could focus on ‘lifting and shifting’ to meet our deadline.
This was important as it helped established a clear, hard line that helped us separate ‘live fixes’ from ‘post-launch backlog’. With our Digital Service Request (DSR) workflow, we knew our next sprint straight after launch would be jam packed and it certainly was.
We got through 84 DSRs compared to our monthly average of 54.
One vital action we performed was to create a legacy site archive. This can only be accessed on the internal network and is ‘offline’ so, post launch, we can collaborate with SMEs on referencing historic content safely and easily.
Technical
The launch did have some hiccups that we were able to stay close to and monitor. However, we were able to execute our key actions well:
- redirects monitored and actioned
- slight delay to Google Analytics switchover
- cookiebot implemented smoothly
There were no major incidents reported and no P1 or P2 incidents post‑launch. Some P3 issues were raised via DSRs, and we knew this would happen. We’ve just moved house so there’s bound to be some things in the wrong place or missing.
Regarding our comms approach, we kept Customer Services and Comms team closely informed before and after launch. We had several internal and external comms updates go out and daily checks of our website feedback forms.
🔍 The ‘real world’ things we’re working on now
404s
Our biggest source of noise is predictable and that is broken links. Now, to fix them might be considered the unglamorous work, but to me it’s not, it’s essential as because every negative experience erodes trust.
Our goal is to reduce friction fast, prioritising the most‑hit legacy routes first. We use the ‘Fix 404 pages’ action in LocalGov Drupal to monitor daily counts and reduce the list.
Search
One of our key priorities was the search experience. Now that we have live behaviour, we can do what we couldn’t fully do in pre‑launch:
- refine search based on what people actually type
- what results they get
Our search is flat, so no filter, no tags, no ‘did you mean’. We use Search API Solr to power this experience and more updates are planned.
We updated our Google Analytics 4 reporting to capture those in-site search terms and use the ‘best bet’ feature to build user journeys to common tasks cleanly.
Our top three search topics are:
- Council Tax
- rent
- Blue Badge
🧭 Project timelines
Even though the website is live, our project is still classed as ‘open’ internally. What’s left is:
- agreeing best way to share project learnings such as wash up meeting
- confirming decommissioning of previous technologies used
- move to full BAU support across Service Desk and DSt
💬 Tell us what you think
The new website is designed to keep improving — and that only happens if people tell us what’s working and what isn’t.
We’re continuing to use our feedback form so users can share what they came to do and whether they managed to do it.
If you spot something confusing, broken or hard to find, please let us know. Every comment helps us shape what comes next.
⚙️ Final thoughts
March was the milestone — but not the destination. It marked the shift from planning and preparation into real‑world use. Getting to go‑live took focus, trust and a lot of people pulling in the same direction. Now the site is live, the work changes shape.
What comes next is about learning from how it’s actually used, prioritising with evidence, and steadily improving the experience for users — one informed change at a time.
Progress doesn’t end at delivery — it starts with what we learn next
Like
Love
Haha
