Rebuilding a City Website That Residents Can Actually Use

The email that forced me to take our municipal site seriously didn’t come from a citizen, or a mayor, or a department head. It came from the front desk:

“People keep calling about the same things. They say the website is confusing.”

If you maintain a city website (or anything close to it—district services, public works announcements, local permits), you learn quickly that “confusing” is rarely about visuals. It’s about finding the right answer under pressure. The people calling aren’t browsing. They’re trying to solve a problem: pay a bill, find office hours, check a road closure, confirm trash pickup, figure out a permit step, locate an emergency notice. They’re often on a phone. They often have low patience, and sometimes low connectivity. And they assume the website is the official source of truth.

Our old site wasn’t broken. It just behaved like a collection of pages rather than a public service interface. Information existed, but it was buried. Updates were inconsistent across departments. Some pages felt current, others felt abandoned. Alerts were posted in multiple places, sometimes in different wording. And worst of all, every small change felt risky—because the site had grown organically, with shortcuts layered on top of shortcuts.

I rebuilt the structure using Mayorx – Municipal City Government WordPress Theme. I’m not going to turn this into a sales pitch or a checklist of features. What I’m writing is closer to a maintenance diary: what problems I was trying to solve, the decision logic I followed, and what changed after the site lived through real weeks—bad weather, schedule changes, service interruptions, and the normal churn of municipal operations.

The real goal wasn’t “a better website” — it was fewer phone calls for basic answers

City websites have a harsh truth: if the site fails, people don’t just bounce. They call. They show up. They complain. They file tickets. They demand staff time.

Every call that starts with “I couldn’t find…” is a hidden cost. It eats front-desk capacity. It delays responses to more complex needs. It increases frustration for both residents and staff. And it often points to the same root cause: the site’s structure doesn’t match how residents think.

So I framed the rebuild around one metric that everyone understood: reduce avoidable contact.

Not eliminate contact—people will always need help. But reduce the calls that are really just “the website didn’t route me correctly.”

I stopped thinking like a web designer and started thinking like a city resident

The most helpful exercise I did was acting like a resident with a small problem and no time. I didn’t do this once. I did it repeatedly, with different scenarios:

• I need to know whether city hall is open today.
• I need to pay a bill or find a payment link.
• I need to confirm trash pickup after a holiday.
• I need to know whether a road closure affects my route.
• I need to report a pothole.
• I need to find a permit form or a process.
• I need to find emergency updates during an incident.

Then I asked: “If I land on the homepage, how quickly do I find the correct path?” And more importantly: “If I land on a random page from Google, can I orient myself and continue?”

The answers weren’t flattering. Some paths required multiple clicks through pages that looked official but weren’t helpful. Some pages had duplicate titles but different content. Some department pages were basically archives with no clear “current information” zone.

Once I saw the site through the resident’s eyes, a lot of my previous “nice-to-have” ideas felt irrelevant. Residents don’t care about decorative consistency. They care about predictability.

The first structural choice: define “resident tasks” as the top layer

Municipal websites often organize navigation by department. That makes sense internally—Public Works, Parks & Recreation, Finance, Police, Planning, etc. But residents don’t always know which department owns which task.

They know their task. They want an answer.

So I created a top layer based on task categories rather than department categories:

• Payments & Bills
• Services (trash, water, street maintenance)
• Permits & Forms
• Notices & Alerts
• Meetings & Public Records
• Contact & Report an Issue

Departments still exist on the site, but as supporting structure, not the primary mental model.

This changed the site’s feel immediately. It became a place you use, not a place you browse.

The second choice: “alerts” needed a single source of truth

This was one of the most operationally painful problems on the old site. Alerts were posted:

• on the homepage banner
• in the news feed
• on department pages
• sometimes in PDFs
• sometimes as a social embed

And when a situation changed (time updates, road reopens, office closure changes), not all locations were updated. That created contradictions.

Contradictions are dangerous for government sites. People treat them as official statements. If your site contradicts itself, residents lose trust—and then they rely on rumor, social posts, or phone calls. All of those increase chaos.

So I enforced a rule: alerts come from one place. Not one person, but one canonical location on the site.

Everything else references it. The homepage can highlight the latest alert, but it should not become a separate alert feed. Department pages can show relevant alerts, but they should pull from the same source.

This is an information architecture choice, not a design choice. It’s also the foundation of maintenance sanity.

I rebuilt the homepage as a “front desk,” not a billboard

Old municipal homepages often try to do too much: announcements, mayor photos, department links, banners, news carousels, program promos, social feeds, event calendars, and calls-to-action.

The result is a homepage that looks busy but is not helpful. A resident can scroll for a full minute and still not find “pay bill” or “trash schedule.”

So I made the homepage act like a front desk:

1. Clear access to resident tasks
2. A visible alerts area (current and official)
3. Quick access to “report an issue”
4. A short set of links to high-frequency pages (hours, meeting agendas, contact)

Everything else moved to dedicated pages.

This is not about minimalism. It’s about functional prioritization. If the homepage fails, the whole site fails.

The “forms and permits” area: stop treating PDFs as the interface

One of the most common failure modes in municipal sites is relying too heavily on PDFs as the main interface.

PDFs are sometimes necessary, but they’re a poor primary experience:

• On mobile, they’re frustrating.
• They often lack context.
• They drift out of date.
• Residents don’t know which PDF is the right one.

So I changed the way forms were presented:

• Each permit/form got a simple page that explains what it is, what you need, and where to submit.
• The PDF (if needed) became an attachment, not the whole experience.
• The page became the stable reference point (and could be updated without replacing the PDF every time).

This reduced confusion and reduced “which form do I use?” calls.

It also improved internal workflow: staff could update instructions without needing a new PDF version immediately.

A practical misconception I corrected: “department pages should be comprehensive”

In a perfect world, every department page is a complete portal. In reality, comprehensive pages are hard to maintain, and maintenance is the bottleneck.

So I redefined department pages as:

• a short description
• core contact information
• hours (if relevant)
• the top few services or links
• a clear path into the resident-task navigation for everything else

This keeps department pages accurate and prevents them from becoming stale encyclopedias.

Residents still find what they need, but the maintenance burden stays manageable.

The admin perspective: I optimized for edit safety

The hardest part of municipal sites isn’t building them. It’s keeping them accurate while multiple people make changes.

Edit safety means:

• consistent page layouts so editors know where to put updates
• fewer “special blocks” that break when text changes
• predictable headings (so pages don’t become unscannable)
• a clear rule for where updates go and where they don’t

I also avoided overly complex visual components. Fancy layouts look nice until an editor adds one extra sentence and the entire section becomes awkward on mobile.

Municipal sites are updated by humans in real life, often under time pressure. The site must tolerate imperfect edits gracefully.

User behavior I watched after launch

I didn’t need complicated analytics to judge whether things improved. I watched for simple operational signals:

1) Did front desk calls change in nature?

The best sign was that calls became less about “where is the information” and more about “how do I proceed.” That shift suggests the site is helping with orientation, and staff time is being used on real assistance rather than navigation.

2) Did residents stop asking repetitive questions during alerts?

During a service interruption, repeated questions indicate the alert system isn’t clear. Once the alerts had a single source of truth, the repetition dropped.

3) Did mobile visitors find the basics faster?

You can test this yourself: open the site on a phone, pretend you have one minute, and try to pay a bill or find a closure notice. If you can do it calmly, the structure is working.

A “quiet” design decision: consistency beats novelty

Government sites often oscillate between two extremes:

• overly plain and outdated
• overly modern but confusing

I tried to avoid both by focusing on consistency: consistent headings, consistent layouts, consistent placement of key actions.

Consistency is a form of public trust. When the site feels consistent, it feels maintained. When it feels maintained, residents trust it.

Light technical thinking: performance and resilience without overengineering

Municipal sites have to work in imperfect conditions: older devices, slower connections, spotty rural coverage, sometimes heavy traffic during emergencies.

So I kept the technical approach conservative:

• avoid heavy animations
• avoid unnecessary third-party embeds on critical pages
• keep pages readable even if some nonessential elements load slowly
• prioritize the top tasks and alerts for fast access

Performance here isn’t about scoring a benchmark. It’s about reducing resident frustration.

Common mistakes I see in municipal sites (and tried to avoid)

Mistake 1: Using internal language

Residents don’t think in “Public Works Division.” They think in “pothole” and “trash.” Use resident language as navigation labels.

Mistake 2: Announcements everywhere

If you post the same update in five places, it will eventually conflict. Use one canonical location.

Mistake 3: PDFs as the only explanation

PDFs should support pages, not replace them. Pages provide context and remain searchable.

Mistake 4: Hiding contact paths

Some sites hide contact info to reduce spam. That often backfires, because residents then call the general line. Give clear contact routes and structured issue reporting.

Decision log: the order that prevented chaos

I rebuilt in an order that avoided rework:

1. Define resident tasks (top navigation)
2. Implement alerts as a single source
3. Simplify the homepage as a front desk
4. Rebuild permits/forms as pages with attachments
5. Refactor department pages into lightweight directories
6. Only then refine wording and polish layouts

If you start with polish, you’re decorating confusion.

A catalog mindset that helped me keep discipline

This might sound unrelated, but looking at well-organized catalogs helps me maintain discipline in information systems. A clean collection of WooCommerce Themes isn’t relevant to municipal services, but the underlying idea is: consistent items, predictable layout, clear navigation, minimal surprises.

Municipal sites benefit from the same principles. Residents should feel like the site is orderly. Order reduces anxiety. Reduced anxiety reduces calls.

What I would do differently next time

Even though the rebuild improved things, there are two adjustments I would make earlier:

1) Create a clearer “resident quick answers” page

Some residents want an FAQ-style landing page: trash, payments, closures, hours. A single “Start Here” page could reduce friction further.

2) Establish editing rules with departments sooner

Structure alone isn’t enough if departments keep posting updates in random places. I would implement a short editing guide early: where alerts go, how to title pages, how to update forms, how to avoid duplication.

Closing: a municipal site is a service interface, not a content archive

The biggest mindset shift for me was treating the website as part of public service delivery. It’s not a marketing channel. It’s not a scrapbook. It’s a tool residents depend on when something goes wrong or when they need to act quickly.

The rebuild didn’t magically solve every communication issue. But it changed the baseline: residents could find answers faster, alerts became more reliable, and updates became less stressful for me and for staff.

If there’s one takeaway, it’s this: design for maintenance. Municipal sites are never “finished.” They evolve with services, staff, and community needs. A structure that supports accurate updates is more valuable than any design trend.

Once the structure is stable, the site becomes quieter—in the best way. Fewer calls. Fewer confused emails. Fewer contradictory notices. And more time for the real work that happens beyond the website.