A local government website is often the starting point for getting something done: reporting a missed collection, finding a meeting agenda, applying for a permit, or checking which office can help. A useful redesign starts with those tasks.

At DIH Systems, we work primarily with local government organizations to create tailored, modern technology solutions. Our starting point is user experience: what residents need to do, what staff need to manage, and where the current journey becomes confusing.

Here is a practical way to turn that focus into a website brief.

Start with services, not the organization chart

Residents should not need to know which department owns a service before they can find it. Gather common questions from front-desk teams, phone inquiries, website searches, and service requests. Use those questions to identify the tasks the website needs to support.

Write each task as a clear sentence: “I need to report a damaged street sign” is more useful than “Public Works content.” It describes a person’s goal and gives the project a specific journey to improve.

For each priority task, document:

  • Who needs to complete it, including occasional visitors and returning users.
  • What information they need before starting.
  • Which steps happen online, by phone, or in person.
  • What a successful outcome looks like.
  • Which team owns the next action.

Review the whole journey

A new homepage will not solve a confusing form or an unclear handoff. Follow a request from the first search through submission, acknowledgement, staff review, and completion.

Consider a resident reporting a streetlight problem. Can they describe the location without knowing an asset number? Does the confirmation explain what happens next? Can they follow up without submitting the same report again?

These questions reveal requirements that a list of pages can miss. They also help separate a content problem from a software problem. Sometimes a clear explanation is the right change; sometimes a service needs a better workflow.

Make content part of the project

Before moving old pages into a new design, decide which information is still useful, who maintains it, and when it should be reviewed. Give each important page a named owner within the organization.

Use descriptive page titles and direct labels. “Apply for a parking permit” tells someone more than “Online solutions.” Explain fees, required documents, eligibility, and next steps where the person needs them. Avoid asking residents to download a document simply to discover whether a service is relevant.

A content inventory can be small: page, resident task, owner, proposed action, and review date. Its purpose is to support decisions rather than preserve every existing page.

Build accessibility into the working process

Include accessibility in design reviews and acceptance criteria from the beginning. Review keyboard navigation, readable contrast, form labels, error messages, heading structure, and how pages behave when text is enlarged.

Test key journeys on a narrow screen and with assistive technology. Automated checks can identify some issues, but observation and manual review are also needed to understand whether a person can finish the task. Agree on the applicable accessibility requirements with the organization before implementation.

Define a focused first release

Choose a manageable group of services and write down what must work before launch. For a service request, that might include a clear entry point, a usable form, an acknowledgement, and a staff handoff that has been tested from end to end.

Agree on how the team will evaluate the result. Useful signals may include completed requests, abandonment during a form, repeated questions, and staff time spent correcting submissions. Establish a baseline where data is available, then compare the same journey after launch.

A good website brief connects the design to an actual service. If the work also needs new internal tools, our guide to custom software versus an existing platform can help define that decision. If the main problem is repetitive handling, start with choosing a local government automation project.