Gov.uk
Working within the UK government to replace 750 websites with one
Related capabilities
Between 2010 and 2012, the UK government achieved something that most large organizations talk about but rarely accomplish. It took Directgov, Business Link, and the numerous department-level websites that had built up over a decade of digital expansion, and condensed the entire array into a single domain, Gov.uk. I was a senior project manager on that program, working across what became the Government Digital Service (GDS) to define and implement the service design principles that would oversee the new platform.
The mandate
In late 2010, Martha Lane Fox published her review of the government’s digital presence, titled “Directgov 2010 and beyond: revolution not evolution.” The title was not hyperbole. Her core recommendation was to converge Directgov and Business Link into a single domain under a new central team with authority to set standards, commission content, and control the user experience across all of government’s online services. She estimated that shifting 30% of government service delivery to digital channels could save more than £1.3 billion annually, rising to £2.2 billion at 50%.
The response was the creation of GDS in April 2011, and the AlphaGov prototype was launched the following month. The prototype was deliberately rough, designed to demonstrate a principle rather than impress a procurement committee, and the principle proved to be correct. If you design around what users actually need instead of focusing on how government is internally structured, the experience improves dramatically. By August 2011, the project had moved into beta, and by October 2012, Gov.uk went live, officially replacing both Directgov and Business Link.
The challenge
My role as senior project manager sat at the intersection of several moving parts that don’t normally get along. I collaborated with designers, developers, content specialists, policy teams, and departmental stakeholders to define the 10 GDS design principles that would form the framework for the new platform. These principles were published in 2012 and have since been adopted by governments and organizations worldwide.
The principles themselves seem straightforward when you see them on a poster. Consider user needs. Do less. Design with data. Tackle the tough work to make it simple. Iterate, then iterate again. This is for everyone. Understand context. Build digital services, not just websites. Be consistent, not uniform. Make things open.
Getting a sprawling, politically sensitive, multi-departmental program to genuinely follow those principles in practice was the real challenge. This wasn’t an environment where you could simply wave a set of guidelines and expect compliance. Every department had legacy systems, processes, and assumptions about their users—many of which proved to be mistaken when tested against actual behavior. User research consistently showed that people didn’t care which department owned a service. They cared about renewing a driving license, registering a birth, or figuring out how to pay business rates. The organizational chart was invisible to them, and rightly so.
One incident from the migration stays with me more than most. We were transferring business registration guidance from Business Link, and the owning department had created a 14-page replacement that walked users through the process in the same order as the internal casework system, which made perfect sense if you already worked there. In user testing, eight out of ten participants left the page before reaching the section they actually needed because they couldn’t tell which steps applied to them and which didn’t. We held a two-day workshop with the policy team, the content designers, and two business owners who had recently been through the process. We rebuilt the page around three key questions the user needed answered (Do I need to register? How do I register? What happens after I register?) and reduced the page from 14 to four. The completion rates in the next round of testing rose from under 20% to over 70%. The department initially resisted, saying the new version “didn’t reflect the full regulatory picture,” but the data supported our case, just as design principles are meant to do.
My role across the program involved translating those principles into project-level decisions repeatedly, across dozens of service areas. When a department wanted to keep a separate workflow because that was how they had always done it, the conversation shifted from “we prefer it this way” to “show me the user research that supports this.” When content teams wished to publish guidance in the dense, cautious language favored by legal and policy teams, we had to find a middle ground that was both accurate and easy to read. When technical teams proposed architectures that prioritized internal convenience over user experience, we had to push back without alienating the colleagues whose cooperation we relied on daily.
Why this matters for your organization
You do not need to be running a government to recognize the pattern. Most organizations that have been around for more than a few years accumulate digital sprawl in roughly the same way governments do. Different teams launch different tools, different departments commission different websites, and customer-facing systems get bolted onto back-office workflows in ways that make sense to the builder and bewilder the user. Over time, the digital estate becomes a geological record of every decision made by every team that ever had a budget and an opinion, which is all of them.
The lessons from the Gov.uk program transfer directly to the kind of work we do at Better Than Good.
-
Start with what users actually do, not what your organizational chart says they should do. The most impactful thing GDS achieved was reframing every service around user needs rather than departmental structures. When working with organizations, we observe the same pattern on a smaller scale. Client portals built around internal team structures instead of what the client needs to find. Approval workflows designed for how the agency thinks about stages rather than the actual flow of work. Fixing this doesn’t require a revolution, just someone willing to sit down, observe how people actually use the system, and redesign based on evidence.
-
Reduce before you rebuild. Martha Lane Fox’s review revealed large amounts of content on Directgov and Business Link that no one was reading. The instinct in most organizations is to migrate everything when they rebuild a digital product. A better approach is to audit ruthlessly and remove anything that doesn’t serve a documented need. Less content, better maintained, is almost always the right solution.
-
Principles are only useful if you enforce them. The GDS design principles worked because they had institutional support and because the team was willing to have difficult conversations with departments seeking exceptions. Every organization has a style guide or a set of brand guidelines gathering dust somewhere. The difference between guidelines that shape behavior and those that don’t is whether anyone is willing to uphold them when it gets uncomfortable.
-
Ship early and improve continuously. AlphaGov was a prototype, intentionally imperfect, and the team released it, tested it with real users, gathered data, iterated, and then iterated again. The old model of spending two years writing specifications, 18 months building, and discovering on launch day that no one wants to use it was precisely what GDS aimed to dismantle. For agencies managing client work, the principle applies at every level, from a new website to a new internal process.
The BTG connection
The Gov.uk program shaped how I think about every engagement Better Than Good takes on. The core lesson, the one that continually proves itself, is that operational improvement and user experience are the same problem viewed from different perspectives, and you cannot fix one without fixing the other. When we help organizations streamline project delivery, improve communication, or introduce automation that genuinely reduces overhead instead of merely shifting it sideways, we are applying the same discipline that transformed 750 government websites into one that functions effectively.
If your organization is dealing with systems that grew organically, processes that reflect outdated ways rather than optimal ones, or a digital presence that confuses users more than it assists them, that is a problem we have solved before, on a scale most organizations will never have to attempt.
