Merging eight websites into one

Taking stock of what we have

By the time I joined the project, the website had already been designed, and I was brought in to to refine the homepage navigation. To begin the empathise and define phases, I immersed myself in the eight original websites and the new design prototype, uncovering how users had previously accessed services.

As one of the tasks was looking at the “My account” button, this became my first point of focus. I was briefed that while the county council had multiple “My account” options, only five of the seven districts offered any account functionality at all. To understand the broader landscape, I also reviewed numerous other local authority websites, exploring how they approached account-based services for their residents.

A “My account” button in the top right corner sounds reasonable right?

Optimistically, I proceeded with ideation

Despite these efforts, when I shared the concepts with the product team, the reaction was unanimous—it was still too confusing. Rather than simplifying the experience, we risked sending users in the wrong direction or leading them to frustrating dead ends.

We needed a different approach.

We suggested an (somewhat radical) idea

To create a more user-friendly experience and reduce confusion, we proposed something unexpected: removing the “My account” button and page entirely. It was a bold suggestion—one that surprised stakeholders and was met with hesitation from those who had accepted its presence. But we had the data to back it up.

Google Analytics (GA4) revealed that most users weren’t navigating to their accounts from the homepage. Instead, they were starting their journey with a Google search, landing directly on the specific service page they needed. We considered why someone might need to access their account and how they typically got there.

If a user wanted to report an issue—like a pothole—they weren’t searching for their account first. Instead, they were finding the highways page, launching the report form, and only then logging in. Similarly, if they needed to check the status of a blue badge application, they were first looking for the blue badge information page, then accessing their account from there.

While some users would always prefer to access their account directly, displaying multiple accounts with different functions on a single page created more confusion than clarity. The benefits of removing the button outweighed those of keeping it.

Of course, the only way to be certain was to test. Hold that thought.

The other buttons

Another key area of the homepage navigation I was tasked with was the "Apply," "Book," "Pay," and "Report" buttons. These had been carried over from the original county council website and were intended to direct users to online service forms. My role was to design how the pages behind each button would be structured and presented.

However, when reviewing all eight websites, I uncovered significant inconsistencies. What one district categorized under "Pay," another placed under "Book." If an application required a payment, would users look under "Apply" or "Pay"? These weren’t just inconsistencies across the councils—this was a deeper issue of language ambiguity that likely confused users on the original websites as well.

The problem was clear: the “Apply,” “Book,” “Pay,” and “Report” buttons had low information scent—they didn’t provide enough context for users to confidently choose the right path. This lack of clarity would increase cognitive load and frustration, making it harder for people to find what they needed.

On top of the language inconsistencies, there was another challenge—each district offered different levels of online service access. We weren’t just dealing with hundreds of services; we were dealing with up to eight different ways of delivering each one.

Again, I optimistically proceeded with ideation

But when I presented these ideas to the product team, none felt quite right. We realised that structuring the pages behind these buttons essentially created an entirely new information architecture—one that overlapped with the existing homepage categories.

If users were already on the homepage, they should ideally navigate through the primary categories rather than detour into an "Apply," "Book," "Pay," or "Report" section, only to be faced with another layer of categorisation. However, removing categories entirely wasn’t a solution either—a single, unstructured list would be far too long to scan effectively.

This reinforced the need to rethink whether these buttons were helping or hindering users in their journey.

The (now less radical) idea popped up again

You probably saw this coming—it was time to test removing the “Apply,” “Book,” “Pay,” and “Report” buttons too.

Just like with the “My account” button, analytics data suggested these buttons weren’t heavily used. As long as users could still find what they needed seamlessly, removing them seemed like the logical next step. Now, the question was: Would their absence improve navigation or create new friction? Testing would give us the answer.

Time to test

Two days, 17 participants, and countless insights.

Armed with chocolate biscuits, a colleague and I set up a testing area in one of our local offices. We were fortunate to have 17 enthusiastic volunteers ready to help us test the navigation of the new website. All sessions were in-person and moderated, with me facilitating and my colleague taking notes.

We designed six real-world scenarios, each reflecting a common user task that would have previously relied on the now-removed buttons. Each scenario required participants to either log into an account or complete an action that had once been categorized under "Apply," "Book," "Pay," or "Report" on the original website.

To ensure unbiased results, we framed each scenario in an open-ended way, avoiding leading participants toward a specific path. For example, instead of directly instructing them to log in, we asked them to check the status of a recent secondary school place application for their child. This task naturally required accessing their "parents" account, allowing us to observe how they navigated to it without the crutch of a "My account" button.

In theory, we were confident in the design, but some stakeholders remained sceptical.

The testing results spoke for themselves—users successfully completed their tasks 90% of the time, reinforcing that the removal of the “My Account,” “Apply,” “Book,” “Pay,” and “Report” buttons had no negative impact on navigation.

This was also the first time the new website had been tested with real users. Since our scenarios reflected common user actions, the high success rate was a reassuring sign that we were launching with a website that was intuitive and easy to use from day one.