The City Website Rebuild That Wasn’t About Design

I didn’t start this rebuild because someone wanted a “fresh look.” I started it because the city website kept producing the same failure modes, week after week, and those failures were turning into operational work: extra calls, repeated emails, duplicate requests, and staff time spent explaining what the site should have made obvious.

I ended up rebuilding the site on Towngov – City Government WordPress Theme, but this isn’t a list of theme features or a promotional walkthrough. It’s closer to the notes I leave for future me: what problems showed up in a municipal-style site, how I decided what to change first, what I watched for after launch, and what I would avoid if I had to do it again.

I’m writing this for the person who has to keep the site running—someone who cares about stability, clarity, and not getting dragged into endless “quick fixes” that never end.

The real problem: the site was acting like a bulletin board, not a service surface

City websites tend to drift into one of two extremes:

1. A bulletin board: lots of posts, lots of PDFs, lots of “news,” but no real flow for residents who just want to do something quickly.
2. A portal: too complex, too many categories, too many half-finished sections, and nobody remembers where anything is.

Our old site leaned bulletin board. It had content, but residents couldn’t reliably answer basic questions in under a minute:

• Where do I pay / apply / report?
• What’s happening today that affects me?
• How do I contact the right department without guessing?
• What’s the schedule for services in my neighborhood?
• Is this announcement current or archived?

When those answers are hard to find, the site doesn’t just “look bad”—it creates work for the organization. And that’s the point: a city website is not primarily a brand asset. It’s a workload shaper.

So I framed the rebuild around one question:

Which parts of the website, if clarified, would reduce operational noise the most?

That question kept me grounded. It also prevented the usual trap of spending half the project on aesthetics and then rushing information architecture at the end.

The decision sequence I used (because “start with the homepage” is a trap)

I used to start with the homepage. Now I rarely do, especially for government-style sites, because the homepage becomes a dumping ground for every stakeholder’s priorities. That doesn’t end in clarity; it ends in a long page that nobody can scan.

Instead, I rebuilt in this order:

1. Identify the top resident intents (what people are trying to do)
2. Define a small set of “service lanes” (navigation that matches those intents)
3. Build a content model for announcements (how items are created, expired, archived)
4. Fix the department contact flow (reduce “wrong inbox” messages)
5. Standardize page structure (so every page feels familiar)
6. Validate mobile scanning and performance basics
7. Only then: refine the homepage layout

This order has a social benefit: it makes it easier to say “no” to random homepage requests. When someone asks, “Can we add this banner on top?”, I can respond with, “What resident task does it support, and where does it belong in the service lanes?” That changes the conversation.

Step 1: mapping resident intent without pretending I know everything

I didn’t run a complex research program. I did a practical version:

• I reviewed the last month of common emails and calls
• I checked the top searched phrases in the site search (even if the tool was basic, patterns still show up)
• I asked front-desk staff what questions they repeat daily
• I looked at the pages with highest bounce and asked why someone would leave immediately

The output wasn’t a perfect taxonomy. It was a short list of resident intents that happen constantly:

• Pay / bill / fees
• Apply / permit / register
• Report / issue / complaint
• Get updates (alerts, closures, notices)
• Find services (trash, utilities, parking, public works)
• Contact the right department
• Attend or watch meetings (agenda, minutes, schedules)

I also noticed something subtle: residents often arrive anxious. They don’t want to explore. They want confirmation fast. That means the site needs to provide “answers first” and let the deeper context follow.

Step 2: defining service lanes that don’t collapse into mega menus

My rule was: if a resident can’t guess where to click, I’ve already failed.

I limited the main navigation to a few lanes and made sure each lane had a clear internal structure. The lanes I used were variations of:

• Services
• Government / Departments
• Residents (practical actions)
• News & Alerts
• Meetings & Documents
• Contact

The exact labels can vary by municipality, but the principle stays: keep top-level choices small, and keep substructure consistent.

The first structure mistake I corrected: mixing “news” with “tasks”

A common failure is placing urgent alerts next to general news and events, then expecting residents to interpret the difference. Residents don’t interpret; they scan.

So I separated:

• alerts and service disruptions (time-sensitive)
• announcements and updates (informational)
• events (optional attention)

That separation reduced confusion immediately, even before redesign.

Step 3: treating announcements like records with a lifecycle, not “posts”

The old site used posts as a catch-all. That created two problems:

1. Old announcements stayed visible and looked current.
2. Staff didn’t know whether to create a page, a post, or upload a PDF.

The rebuild goal wasn’t “more content.” It was predictable content behavior.

So I implemented a simple lifecycle discipline:

• Every alert/notice has: publish date, “valid until” date (even if approximate), and a clear status indicator.
• Once expired, it moves into an archive view that is still searchable but not mixed with current notices.
• Pages that serve as evergreen references are separated from notices.

I’m not describing tools or features here; I’m describing a governance habit. Most municipal site problems aren’t technical—they’re governance problems. The site becomes messy when content is created without a lifecycle.

The “archive honesty” test

I applied a test to every notice page:

If a resident lands here from search three months later, will they clearly understand whether the information is still valid?

If the answer wasn’t a confident yes, I rewrote the intro to include context and date cues. Not hype, not fluff—just clarity.

Step 4: department contact flow, and why “Contact Us” pages fail

The old contact page was a list. Lists are easy to publish and hard to use.

Residents don’t think in organizational charts. They think in problems:

• “Streetlight out”
• “Permit question”
• “Noise complaint”
• “Garbage pickup missed”
• “Parking issue”

If the contact page asks them to pick a department first, many will pick wrong. Then staff time gets spent rerouting.

So I rebuilt contact around routing-by-intent:

• Start with problem categories residents understand
• Provide short “this is for…” descriptions
• Offer a consistent contact method per category
• Include escalation guidance (what to do if no response)

I also added a quiet boundary: what not to send through certain channels. Not as a scolding warning—just a practical note to reduce misuse.

A common misconception I corrected internally

Some stakeholders assume that adding more contact methods increases service quality. In practice, it increases fragmentation.

I tried to make contact options consistent and limited, because consistency reduces error. The more different patterns residents see (different forms, different emails, different phone formats), the less confident they feel.

Step 5: page structure standardization as an accessibility and trust tool

A city website is more trusted when it behaves consistently. Consistency helps everyone:

• residents scanning on mobile
• older visitors who are less patient with surprises
• staff who publish updates under time pressure
• screen-reader users who rely on predictable structure

So I standardized:

• a clear page title that matches the navigation label
• a short “what this page is for” intro sentence
• a visible “last updated” cue for evergreen pages
• consistent placement of service actions (apply, pay, report)
• consistent “related links” pattern (kept short)

This wasn’t a design flourish. It was operational discipline. When staff publish, they shouldn’t have to invent structure every time.

The quiet technical checks I run for municipal sites

I avoid turning these posts into a performance lecture, but a few checks are worth mentioning because city sites often accumulate heavy assets and inconsistent pages.

Mobile scanning rhythm

If a page has:

• huge headings,
• dense blocks,
• tiny tap targets,
• long lists without grouping,

…it becomes tiring. Tired visitors don’t convert into successful tasks; they convert into phone calls.

So I did a “thumb test” on key pages:

• services landing pages
• notice pages
• department pages
• meeting pages
• contact flow

I looked for:

• accidental horizontal scroll
• inconsistent spacing
• text that becomes unreadable in bright conditions
• CTA placement that forces excessive scrolling

“Time-to-answer” checks

For the top resident intents, I measured:

How many taps from the homepage until the resident can either:

• complete the task, or
• clearly understand the next step?

If it took more than 3–4 taps for a common task, I treated it as a structural issue, not a content issue.

Content drift detection

Municipal content drifts quietly. It’s not dramatic; it’s slow.

I created a habit: once a month, review:

• top 10 evergreen pages
• the current alerts list
• the most accessed service pages

I’m not expecting perfection. I’m expecting “not misleading.”

What I learned about “homepage politics” inside organizations

The homepage becomes a battlefield because every department wants visibility. The solution is not to fight harder. The solution is to define a homepage job.

I wrote a simple homepage job statement:

• Provide fast access to essential resident actions
• Show current alerts clearly
• Give a short path to departments and contact
• Offer a calm snapshot of what matters today

Then I aligned homepage sections to that job.

When someone wanted to add something, I asked:

• Does it support a core resident action?
• Is it time-sensitive?
• Is it already available in a service lane?

If the answer was no, it went elsewhere.

This isn’t about controlling stakeholders; it’s about preventing the website from becoming a permanent meeting outcome.

The rebuild logs I keep (so future me doesn’t suffer)

I document municipal site rebuilds more than other sites because staff turnover is real, and institutional memory fades.

I keep a short “operator’s log” with:

• content types and their intended use (notice vs evergreen page)
• how to expire and archive announcements
• where to update key data (office hours, phone numbers)
• the navigation logic (why it’s arranged this way)
• a list of “do not do this” patterns (like uploading critical info only as PDFs)

This log prevents the site from drifting back into chaos.

Post-launch observations after a few weeks

I’m careful about declaring victory. City sites have seasonal cycles. But after launch, I noticed a few early signals:

Fewer “Where do I…” emails about basic services

We still got them, but the frequency dropped for the most common issues.

More people arrived on the correct page from search

This happened because the structure and intros were clearer, not because of any clever trick.

Staff published with fewer layout accidents

A consistent page pattern reduces “accidental formatting” problems. Staff don’t have to guess where things belong.

Residents scrolled less on key pages

This surprised me. Shorter pages aren’t always better, but clearer grouping reduces unnecessary scrolling.

Common mistakes I corrected that I expect others to hit

Mistake: turning “Services” into a duplicate of the navigation

If your services page simply mirrors the menu, it doesn’t help residents. It adds a step.

Instead, services should be task-based and grouped by how people think. Departments can exist, but residents shouldn’t be forced into org charts.

Mistake: letting PDFs become the only source of truth

PDFs are fine as records, but the website should still provide a plain-language summary:

• what the document is,
• why it matters,
• the effective date,
• what residents should do next

If the PDF is the only explanation, residents will call.

Mistake: mixing emergency alerts with general announcements

This trains residents to ignore alerts because they look like “just another post.”

Mistake: publishing without “valid until” thinking

A notice that lingers without context becomes misinformation.

Mistake: assuming accessibility is a one-time checkbox

Accessibility is sustained by consistent structure and publishing habits. You don’t “finish” it.

How I decide on a theme foundation when the site must be maintained

For municipal-style sites, my selection criteria are conservative:

• Can the layout support clear hierarchies without custom hacks?
• Does the structure feel predictable across pages?
• Does it behave well on mobile without constant intervention?
• Can staff publish without breaking layout?
• Does it encourage “service lanes” rather than endless posts?

When I’m looking through collections like WooCommerce Themes, I’m not looking for novelty. I’m looking for something that won’t create maintenance debt. “Maintenance debt” is the hidden budget killer in government sites.

Closing notes: what I’d tell the next admin inheriting this site

If you inherit a city website, the job is rarely to “make it look modern.” The job is to reduce confusion at scale.

Here’s the mindset that helped me:

• Treat the site as a service layer, not a newsroom
• Design around resident intent, not internal structure
• Give announcements a lifecycle so they don’t become misleading
• Make contact routing match how residents describe problems
• Standardize page structure so publishing stays stable
• Validate mobile scanning because that’s how many residents browse
• Resist homepage clutter; define its job and protect it

The result I wanted wasn’t excitement. It was calm reliability. When a resident finds the right answer quickly, nobody praises the site. They just move on with their day. For municipal work, that’s the right outcome.