Day 2 Session 6 Case Study # 5 UK Government Digital Service
Day 2 Session 6 Case Study # 5 UK Government Digital Service
0
August 18, 2017
Bracken was preparing to meet with Tom Loosemore, Deputy Director at GDS and fellow veteran of
the tech industry, to discuss their strategic plan. As Bracken waited, he reflected on their progress to
date. Bracken and his team at GDS had significant successes of which they were proud. GDS had already
helped save billions of pounds with better information technology systems, and had centralized the
government’s web presence into a single domain (called GOV.UK) where citizens could do everything
from schedule a driving test to register for government benefits.2 Rohan Silva, a policy advisor at the
Prime Minister’s office, had praised GDS as the “centre ground of public service reform in the UK
today,”3 and Tim O’Reilly, the famous technology writer and founder of O’Reilly Media, had tweeted
that GDS’s action plan and design principles were “the most significant since Apple’s.”4 Bracken felt that
his team’s success had, for the first time, collected significant political capital within government.
This recognition was especially important to Bracken because it gave credence to his
unconventional—and often controversial—beliefs about how government should operate. To him, the
UK civil service was overly focused on creating complex policy and too little concerned with the low-
glamor work of implementation. Bracken’s approach, which he dubbed “the strategy is delivery,” was
based on the idea that by simply implementing improvements to government services (even if they
were imperfect), he could learn from users, save money, and provide improved services with significant
speed.
Despite the success of GOV.UK, Bracken knew that he had more work to do to realize his vision of a
civil service that was oriented toward implementation, focused on users, and fluent with providing
digital services. After all, GOV.UK was only a website. Underneath GDS’s good press, there was also
This case was written by Lecturer David Eaves and Daniel Goldberg (Harvard MPP & MBA, 2019) at the Harvard Kennedy
School (HKS). Partial funding provided by the Joseph B. Tompkins, Jr. Fund for Case Study and Research. HKS cases are
developed solely as the basis for class discussion. Cases are not intended to serve as endorsements, sources of primary data, or
illustrations of effective or ineffective management. KS1241
Copyright © 2017 President and Fellows of Harvard College. No part of this publication may be reproduced, revised, translated,
stored in a retrieval system, used in a spreadsheet, or transmitted in any form or by any means without the express written
consent of the Case Program. For orders and copyright permission information, please visit our website at case.harvard.edu or
send a written request to Case Program, John F. Kennedy School of Government, Harvard University, 79 John F. Kennedy Street,
Cambridge, MA 02138.
brewing discontent among some civil servants: to them, GDS was naïve and inexperienced, and their
ideas represented a dangerous break from the status quo. Large government IT contractors, in
particular, were beginning to push back against GDS’s growing influence.
To Bracken, these criticisms underscored both the challenge and the opportunity GDS faced. As
Loosemore arrived at the café for their meeting, he wondered: how would they leverage their success to
remake government to be more efficient and user-centered? He knew they’d have to act quickly, before
their political capital disappeared and the inertia of the status quo took hold again.
Background
The early 2000s was a time of enormous technology innovation in the UK and across the world.
During those years, large technology companies such as Facebook and Google grew rapidly, while new
websites, applications, and online services proliferated. However, during that same period, the pace of
innovation within the UK government was much slower. According to Bracken, this was at least partly
because the UK government typically procured digital tools in multi-year cycles, which were too long to
keep pace with innovation in the private sector. The gap between the level of service citizens expected
when working with private companies and when working with the government widened dramatically.
Traditionally, government IT in the UK had been treated similar to a policy issue, with technology
procurement following the same patterns as policy development. IT procurement involved a long
legislative process, in which IT requirements were often determined. After the law had been passed, the
relevant department typically continued to plan the required technology, before ultimately rolling it out.
After roll-out, it was relatively uncommon for either the policy or technology requirements to be
modified significantly.
Because most civil servants were knowledgeable in policy but not experts in technology, almost all
technology development was outsourced to a small number of contractors known as systems
integrators (or SIs), which included companies such as Accenture, HP, Microsoft, Capgemini, and others.
The number of typical government contractors was small: a report commissioned by the House of
Commons found that “government is currently over-reliant on a small ‘oligopoly’ of large suppliers,
which some [experts] referred to as a ‘cartel’. Whether or not this constitutes a cartel in legal terms,
current arrangements have led to a perverse situation in which governments have wasted an obscene
amount of public money.”5 In all, the process of drafting legislation, requirements, and contracts
required between several months and several years of planning and implementation.
This traditional process for IT procurement had many advocates within government. Lara Sampson,
a civil servant in the Department for Work and Pensions, noted that this project management approach
had some significant successes, both in IT and elsewhere, such as the successful launch of several
hundred offices by the Department for Work and Pensions. The system was particularly successful for
However, this traditional process also had many detractors, particularly when it was applied to more
complex problems where the solution was not well known in advance, such as in technology. As
Sampson recalled, while this process could be used for IT procurement, “Nine times out of ten the thing
delivered was not the thing originally conceived of, and having taken longer and cost more than
originally intended.”6 Not only were overruns on cost and time common, but the process was also slow
to adapt to changing needs of citizens. Frequent news stories about botched IT projects had left the
public with little confidence in government’s ability to deliver digital services.7
In response to this challenge, there had been a short history of efforts to “modernize” the
government’s approach to providing digital services, dating back to the early 1990s. Most of the early
efforts centered on creating a central government website. Early attempts, such as open.gov.uk and UK
Online, were essentially directories of other departments’ websites. Visitors could search for
information and be directed to the relevant departments’ information portal. A small number of services
had been digitized, such as the ability to apply for a passport or register to vote online, but were only
available on the individual departments’ website. In 2004, the UK government launched Directgov and
its business-centered counterpart, Business Link, meant to further centralize the government’s internet
presence. However in practice, the vast majority of transactions still went through hundreds of separate
websites for individual department and agencies. Although Directgov received millions of unique hits
each month, it also received criticism from technology bloggers who argued that the website could be
improved by replacing it with a custom Google search for a fraction of the cost.8,9
By 2010, a series of factors had converged to raise the profile of technology reform within the UK
government. “I felt there were a number of forces acting on government in the UK at the time that had
never been in sync in my lifetime,” said Bracken. Among those factors were several high-profile IT
failures, “a groundswell of people from industry with digital skills in the UK,” and the presence of a
coalition government between major conservative and liberal parties, “which meant that it was much
likelier to get cross-party support because you had two of the three main parties in power,” said
Bracken.
Perhaps the most immediate impetus for change was an acute financial crisis that was compelling
the government to seek dramatic spending cuts from the civil service. As Francis Maude, the Minister of
the Cabinet Office, recalled, “We had a budget deficit of 11% of GDP. We had half of Europe in sovereign
debt crisis, and we were about to be there. So, we needed to show that we were doing something
differently.”10 The Conservative party campaigned on a promise to reduce the size of government, and
upon taking power in a coalition government with the Liberal Democrats, committed to broad spending
cuts. As Mike Bracken analyzed, the Conservative Party (of which Maude was a part) “wanted money
out of the system, and would have happily privatised services if that was possible, but the combination
of having the Liberal Democrats in a coalition and that the big stuff (utilities, telecoms) had already been
With these goals in mind, Maude commissioned a report to review the government’s web presence
by Martha Lane Fox, an internet entrepreneur who had been appointed the government’s “Digital
Champion.” In the resulting report (titled, “Directgov 2010 and Beyond: Revolution not Evolution”), Fox
recommended reforms not only to Directgov but to the government’s entire approach toward digital
service delivery. Fox wrote: “There has been a reinvention of the Internet and the behaviour of users in
the last few years. Digital services are now more agile, open and cheaper. To take advantage of these
changes, government needs to move to a ‘service culture.’”11 Fox recommended significantly
strengthening and centralizing the government’s digital presence, as well as appointing a “Digital CEO”
for the government. (See Exhibit 1 for full list of Martha Lane Fox’s recommendations.)
Maude took Fox’s recommendations to heart, and within a few months created a new team labeled
“Government Digital Service.” He appointed Chris Chant to serve as the interim Executive Director, and
Tom Loosemore as his deputy.12 Shortly thereafter, Mike Bracken was appointed as the government’s
permanent Executive Director for Digital.13
Even before Mike Bracken joined Tom Loosemore at GDS, the two had led broadly similar careers,
leading digital transformation efforts across both the public and private sectors. (See Exhibit 3 for
resumes of key GDS leaders.)
Bracken began his career as a technology writer and editor at several publications including The
Guardian and EMAP, a publisher targeted to businesses. Over time, Bracken migrated from writing
about technology to leading technology efforts at several media companies. At a time when newspapers
were struggling to adapt to a digital world, Bracken led digital transformation efforts at Chello (from
1999 to 2003) and at The Guardian (from 2008 to 2011). At The Guardian, he was responsible for
managing all the newspaper’s websites, apps, and other digital products.14 In between roles at
newspapers, Bracken also was a director at several major IT companies (including Wavex and Chello),
focusing on service delivery.
During the same timeframe, Tom Loosemore had a parallel career as a writer and editor for several
technology publications, including Wired Magazine. Following that, Loosemore led several technology
transformations at major publishing companies including the BBC, Ofcom, and Channel 4.15
Since 2002, Bracken and Loosemore worked together to explore how digital technology could
By the time Bracken and Loosemore were together again at GDS, they had a long history of working
together and a small team who had followed them from project to project. As Loosemore remarked,
“We had all been on a journey together over 15 years and we were quite a tight clan.”16
Founding GDS
Francis Maude located GDS at the center of the Government, as part of the Cabinet Office (of which
Maude was minister). Acting as the corporate headquarters for government, the Cabinet Office supports
the Prime Minister and ensures the effective running of government. At that time, it also included an
Efficiency and Reform Group created by Maude to drive transformation throughout government.
From the start, GDS was unlike most other government agencies. Although GDS had a staff of
approximately 200, most of them had never worked in the civil service before. GDS’ office was a set of
large open spaces, decorated with ribbons and flags, filled with screens, and walls covered in post-it
notes. Sheila Bennett, a public civil servant who was recruited to work at GDS, described her reaction
when she first entered the office: “I had looked up GDS before and liked what I saw, but nothing
prepared me for actually walking into the offices, which was quite unlike any public service office I’d
ever worked in. It had a rather stereotypically hipster techie look, with the jeans, the beards, the post-
its.” For Bennett, the feel of GDS was new, energizing, and exciting.17
To Bracken and other GDS leaders, recruiting non-traditional civil servants was a conscious strategy.
Their goal was to develop digital literacy throughout the civil service, enabling government to better
manage IT contractors, develop technology in-house, and to provide a fresh set of perspectives on
common problems. However, to critics, the non-traditional civil servants GDS recruited were
inexperienced in the difficult challenges of working in government and providing public services. This
inexperience was not only true for GDS staff, but also for its leadership: Kathy Settle, an early GDS
employee and experienced civil servant, described her role in GDS as largely consisting of coaching
Bracken and Loosemore about “everything from how you go about a meeting with senior people, the
sorts of language and tone you use, approval processes you have to go through—essentially, all the
basic stuff about working in this organization they just didn’t understand.”18 Moreover, critics disliked
that so much digital talent was centralized in one government agency, preferring instead to distribute
the digital expertise within departments, which they reasoned had a better understanding of the needs
and challenges of their constituents.
Because reducing government spending was a major priority of the coalition government in 2010,
and indeed one of the primary reasons for founding GDS, identifying cost savings became one of GDS’s
first and most important challenges. However, Bracken successfully convinced Francis Maude that unlike
many other governments, GDS should not be given an explicit target for cost savings. As Bracken
recalled, his argument to Maude was: “You’re going to get more money out of this if our motivation is to
make great services. If we do the right thing, the money will pour out the other end. If we go into it
looking for money, our incentives will be all wrong.” Maude acquiesced, even though he notes that
“GDS was always very frustrating to my data people because they wouldn’t say what they were going to
deliver…Because I trusted Mike and knew he would deliver big savings, I let him get away with that as a
little bit of an indulgence.” Bracken believed that focusing the work on service improvement rather than
cost savings was crucial not only to give his staff the right incentives, but also because it made GDS
appear far less threatening to the departments it would need to work with.
Bracken’s intuition that identifying savings would be easy turned out to be well-founded. In the early
years, savings primarily came from spending controls: Maude instituted a rule that he would personally
need to approve any IT purchase above £1 million, and used GDS as a key advisor. (Estimates placed the
total annual government spending on IT services as high as £20 billion.19) Bracken recalled one meeting
where a department “had gotten all the way to the procurement stage, ready to spend £200 million on
an identity service technology,a even though we had one that we’d already spent a year and a half
creating and was perfectly good.” The vendor-produced technology was ultimately not approved for
purchase. Another tactic that Bracken employed was to ask software engineers, employed by GDS, to sit
in meetings with major IT contractors. Unlike most procurement officers, the engineer could push back
on contractors when discussing why a change would cost so much or take so long. In general, Bracken
recalled that finding major cost savings was hardly a challenge at all: as he puts it, “It wasn’t like fish in a
barrel; it was just like fish everywhere. It was easy. You just couldn’t miss.” GDS estimated that there
was approximately £1.8 billion in available savings from digitizing services.20 (See Exhibit 4 for overview
of estimated savings from shifting to digital.)
GDS’s use of spending controls did lead to some friction with other government departments. As
Lara Sampson, an employee of the Department for Work and Pensions, remembered, “That amount of
power definitely made GDS unpopular. There was a feeling that not only did they have a great deal of
power, but the situation didn’t warrant it. They didn’t have the experience of complicated, end-to-end
transactional delivery that justified them having it.” Nonetheless, GDS was popular with Francis Maude
and several other senior politicians, who provided political cover when GDS received push-back.
Another big reason identifying early savings was crucial to GDS was because it put the organization
itself on firm financial footing. Loosemore recalled that much of GDS’s early funding came directly from
a
An “identity service technology” is a system of tools and procedures to verify the identity of somebody making an
online transaction.
Along with instituting spending controls, GDS was to build a new web-presence for the UK
government. This came directly out of Martha Lane Fox’s report, which recommended the creation of a
“front end [website] for all departments’ transactional online services to citizens and businesses.”21 GDS
decided to replace the existing central government websites, Directgov and its business-centered
counterpart Business Link, with a single website known as GOV.UK.
Bracken had at least two overarching goals with the creation of GOV.UK. The first was to align the
government’s web presence with the needs of users. “GOV.UK puts user needs above all else,” Bracken
wrote.22 This not only meant that services should be online (and therefore accessible whenever was
most convenient for users), but also that users should not need to know which department (or
departments) was responsible for any particular service in order to find it online. As Loosemore
tweeted, “Every superfluous page we create is one more dead end for an angry, frustrated, confused
user.”23 GOV.UK would be built with user needs, rather than department boundaries, as the organizing
principle.
A second goal of GOV.UK was financial. Because government services were so rarely digitized, every
time a user interacted with government—via an in-person visit, submission of paper forms, or phone
call—it was expensive. Every year, the government received millions of calls from citizens for answers to
questions or for help with services that could have been completed online. According to Maude, “online
transactions can be 20 times cheaper than by phone, 30 times cheaper than face-to-face, and up to 50
times cheaper than by post.”24,b By moving more government services online, Bracken felt that he could
not only improve services, but also save money in the process.
Once GDS began building GOV.UK, the process was a lesson for many civil servants in what it meant
to operate like a technology company. GDS set several rules for itself in the process, including “Start
with User Needs” and “Iterate. Then iterate again.” (See Exhibit 5 for the full list of GDS design
principles.) For many civil servants, the notion of constantly iterating (an approach to technology
development known as an “agile” approach), was a difficult change in workstyle, compared to their
previous approach of meticulous planning followed by a dedicated roll-out. However, the GDS team
firmly believed that the agile approach increased the likelihood of success of an IT project, as it allowed
engineers, designers, and policymakers to quickly determine user needs and adapt to them in nearly
real-time.
b
Cost estimates of each transaction varied. One estimate suggested that the average cost of a transaction
completed via post was £6.62, the average cost for transactions via phone was £4.11, and the average cost per
digital transaction was £0.22. Other estimates placed the cost of a transaction via post as high as £8.62.
The prototype was a space to try a variety of different designs for each of the hundreds of user
needs. Trials often began as hand-drawn sketches of what a web page may look like, based on
interviews with users.26 For some services, the prototype involved a decision tree, while for others it
involved an answer page, how-to guide, calculator, or other service.27 Unusually for a tech company, this
prototype was open to the public (housed at the website alpha.gov.uk), to gain as much feedback from
real users as possible. There were over 100,000 visits to alpha.gov.uk, with nearly 1,000 people leaving
direct feedback.28
The website was launched in 12 weeks, and for £261,000.29 Although Bracken and Loosemore,
veterans of agile internet development processes, were confident of its success, even strong advocates
like Francis Maude were slightly apprehensive. As Maude remembered, “I didn’t know much about this
territory. I’m not technical. I’d been persuaded that this was the right way to go, but there had been lots
of people who’d launched things in government with lots of fine talk that didn’t turn out.” However,
when the website launched and Maude saw how much it improved the status quo, he became a fierce
advocate. When other departments expressed skepticism, Maude was among the first to champion
GOV.UK: “There were plenty of niggles from different departments about GOV.UK. People said the
search doesn’t work, or something. And we had to explain: ‘This is a work in progress. We’re not in the
old world of contracting to a big systems integrator, and any change will cost tons of money. It’s going to
be constantly iterated and constantly improved based on the user experience.’” While some veterans
immediately understood the new process, others required more active coaching and re-training.
The launch of GOV.UK was the first major introduction of GDS to the rest of Britain, and it was met
with wide applause. Particularly within the technology industry, reporters lauded GOV.UK’s clean
design, streamlined user experience, and simple architecture. (See Exhibit 6 for screenshots of GOV.UK
beta.) Onlookers hoped that the website would be a harbinger of even deeper improvements in the
government’s approach to IT.30 Within the tech community, GDS was particularly praised for its focus on
the user: Tim O’Reilly commented that “this is the revolution we are seeing here – this strategy is the
new bible for government systems.”31
One group of public stakeholders had a much frostier reception to GOV.UK: major IT contractors.
Because of GDS, the UK government was for the first time directly employing hundreds of software
developers, significantly diminishing the need to contract out major IT work, and increasing pressure on
contractors when it did. Moreover, the government had begun a concerted effort to shift contracts
Initial reactions to GDS from within the civil service were even more varied than those from outside
government. While many were energized by GDS and their user-centered approach to working, others
were confused, skeptical, or outright opposed.
One of the surprising findings to many early GDS employees was how enthusiastically so many
government employees greeted the changes that GDS brought. As Andrew Greenway, an early GDS
employee who had previously worked elsewhere in the civil service, remembered:
One thing I found quite striking was just how many people in departments knew
perfectly well how to do proper user research, the need to build services inclusively,
who recognized how broken the procurement market was, and so on. They didn’t need
that explained to them; what they needed from GDS was essentially the top cover and
the permission to get past the blockers in their own departments. So the strongest
supporters of GDS were in fact career civil servants who had been quietly fuming about
what was going on in their departments and had never had a powerful backer and the
mandate to get on and fix it…We didn’t need to create allies in a sense, we just needed
to find them.33
Sheila Bennett, another early GDS employee who came from elsewhere in the public service,
remembered her feeling upon joining the GDS team: “It did feel like a liberation to be encouraged to
work in that way.” Many civil servants were more slowly convinced that they needed GDS’s help, often
encouraged by the reality of major spending cuts, which GDS promised to help them navigate without
sacrificing the quality of their service.
While some staff felt liberated by GDS’s approach, significant numbers of more senior staff took a
hostile approach toward GDS. Neil Williams, who in 2010 was the head of digital communications for the
Department of Business, Innovation & Skills, remembered his initial reaction to Martha Lane Fox’s
As Sheila Bennett, a civil servant recruited to be part of GDS, summarized her take on the resistance
to GDS: “The people we had more trouble with were senior people and people who had a background in
technology. For them, we were far more of a threat. Because effectively they perceived us as saying that
the way you personally have been doing things isn’t good enough and we’re going to tell you how to do
it better. And if our solution worked, it meant maybe they or their team could be out of a job.”
Often, this resistance was born out of loyalty to different government departments. As Neil Williams
remembered, “It was kind of my job to write [my] thoughts down and say why [GOV.UK] shouldn’t
happen. It wasn’t in the organization’s [i.e. department’s] interests, and as the head of digital
communications for that organization my job involved writing briefings…about why that shouldn’t
happen.”36 Among career civil servants, such loyalty to departments’ interests was widespread, even
though it was considered provincial by some political figures: Francis Maude remembered discovering a
document, written around 2008, about what to look for when hiring Permanent Secretaries: “One of the
criteria it specified was you need to be able to balance the needs of the department against the wishes
of ministers. Well I found that deeply, deeply shocking. What that was basically saying was you have
carte blanche not to do what ministers want if you think it’s not in the interest of the department.”
Throughout every department, a variety of rules and norms encouraged civil servants to resist changes
to department processes that had been long established, and had proven successful in the past. The
result, according to Maude, was that “At every stage, people were trying to find failure with GDS.”
More broadly, GDS leaders felt they were swimming against a strong cultural current which required
deep re-education of nearly everybody in government. Simple habits, like the desire to tell Ministers
when they could expect to see a digital service, became impossible when employing a more agile
approach. When civil servants tried to explain that they could not provide certainty because it was a
falsehood, they were labelled “hippies” or incompetent. Likewise, when department leaders supported
GDS’s work, they often offered to loan GDS more staff, even though GDS leaders far preferred fewer
staff who were more empowered to make quick decisions. At every stage, GDS staff felt that minor
misunderstandings like these constantly reinforced the status quo, and made even simple collaborations
difficult.
Despite the early successes of GDS, Bracken and Loosemore felt they had only barely begun the
digital transformation of government. Their vision, first articulated by the technology writer Tim O’Reilly
and commonly called “government as a platform,” was for a government that did far more to empower
people inside and outside government to innovate.37 Through tools such as open data, common services
that cut across departments, procurement reform, and recruiting digital talent into government,
Bracken and Loosemore hoped to create a radically simplified, more efficient, and more user-focused
form of government. They saw GOV.UK as only the beginning of “a new approach to digital delivery of
public services in the UK. It is the start of a new approach to all things digital in central government.”38
In many ways, the work of creating GOV.UK only illustrated exactly how much more work Bracken
and Loosemore felt there was to do. Making cosmetic improvements to the website laid bare how
rudimentary the back-end IT of government services often was. For instance, one service that was
digitized on GOV.UK was the ability to book a visit to see someone in prison. Bracken and Loosemore
hoped that making it easier to visit friends in prison would help rehabilitate inmates and reduce
recidivism rates. However, they learned that behind the scenes prison staff were forced to manually
copy bookings from the new digital service into their old software. These back-end IT services, too, they
realized, would need to be updated.
The deeper into the bureaucracy that GDS attempted to influence, the stronger the pushback often
was. As Lara Sampson, civil servant from the Department for Work and Pensions, recalled, “A very
common phrase across government leveled at GDS was: ‘They built a good website. Who are they to
know how difficult the rest of this is?’”
Changes to deeper IT systems also reinforced the same political difficulties that GDS first
encountered when building GOV.UK. For instance, each department traditionally maintained its own set
of basic IT services, even for functions that were common across almost every department like identity
verification, payments, address lookup, and so on. This led to enormous and duplicative IT expenses;
Bracken hoped to develop common platforms for these shared services as a more cost-effective
solution. However, to many departments, this was anathema: they had already spent millions (if not
hundreds of millions) of pounds developing a customized system that they knew worked for their own
particular needs. Loosemore recalled some of the pushback he received from other departments.
“Departments might say: We went through a lot of effort to make sure our systems plug in together. It’s
clunky, but it’s working. It took a lot of pain to get it working. And you want us to carry all the risk of
performing open heart surgery on our service that’s working at the moment just to save 20%? You’ve
got to be kidding.” In addition to worrying about the implications for their service, some department
leaders also feared that if GDS controlled basic services like payments and identity verification, it could,
in effect, control what the department could and could not do by regulating access to these essential
services.
While the idea of developing common platforms was threatening to many departments, it felt like
Next Steps
With the warm reception of GOV.UK, and with the political goodwill that GDS had won through
successfully reducing IT costs, Bracken and Loosemore felt that they had a rare window of opportunity
to advance their vision of “government as a platform.” Their power over IT spending and the steadfast
political support from Francis Maude also gave them enough leverage to potentially make major
changes. However, given the strong resistance that was already forming within the civil service and from
established industry, they also knew that they would have to be careful in how they chose to do so.
As Bracken and Loosemore sat down at the café for their meeting about strategy, there were a
number of questions on both of their minds. GOV.UK was still an unfinished work: although they had
transferred content from 25 major department websites (focusing on the largest user needs), there
were still hundreds of agencies worth of content to bring onto GOV.UK, totally approximately 150,000
new web pages that would each need to be migrated, updated, and made consistent with the new
GOV.UK style. Beyond GOV.UK, Bracken and Loosemore had been considering several different courses
of action, including embedding themselves in departments to help digitize transactions, building
common services themselves that could be shared by departments (such as identity verification and
payments), developing more stringent spending controls, tracking key performance indicators across
each of the transactions on GOV.UK, training department leaders in digital service delivery, and other
avenues.
In addition to working with departments, Bracken and Loosemore also knew that they would need
to find some ways to gain favor with the political leaders of government. Despite the tremendous
support that Francis Maude provided to them, Bracken and Loosemore knew that it was possible that
these leaders would be removed with the next election. The duo wondered whether they should be
lobbying political leaders within government, as well as other institutional powerbrokers such as the
Treasury.
All of these different projects and approaches had the same goal: a digitally-native civil service that
focused on user needs and on delivery. However, Bracken and Loosemore knew that no one approach
would ever go far enough to transform government the way they wanted to. With so many efforts
underway, they would need to decide: which approaches should be prioritized? How should they ensure
1. Make Directgov the government front end for all departments' transactional online services
to citizens and businesses, with the teeth to mandate cross government solutions, set
standards and force departments to improve citizens' experience of key transactions.
2. Make Directgov a wholesaler as well as the retail shop front for government services &
content by mandating the development and opening up of Application Programme
Interfaces (APls) to third parties.
3. Change the model of government online publishing, by putting a new central team in
Cabinet Office in absolute control of the overall user experience across all digital channels,
commissioning all government online information from other departments.
4. Appoint a new CEO for Digital in the Cabinet Office with absolute authority over the user
experience across all government online services (websites and APls) and the power to
direct all government online spending.
Source: Martha Lane, “Directgov 2010 and beyond: revolution not evolution,”
https://www.gov.uk/government/publications/directgov-2010-and-beyond-revolution-not-evolution-a-report-by-martha-lane-
fox.
Source: LinkedIn
“The Driving Standards Agency started offering an online channel for booking practical driving
tests in 2003. More than three-quarters of almost 2 million transactions are now digital, with
only 23% of people still booking via phone. As people have migrated to digital, costs have fallen.
The principal sources of savings have been reductions in employee numbers and
accommodation costs. One of 2 dedicated contact centres closed in 2008, while the total
number of employees working on the transaction has fallen from 400 in 2003 to 75 in 2012.
Stationery and postage costs have also been removed from the digital channel.”
“HMRC first offered online tax return filing in 2000, with the pace of take-up accelerating
following the Carter Review in 2006. Last year, digital take-up across all 4 main business taxes
(Self Assessment, PAYE, Corporation Tax and VAT) was over 80%, equivalent to tens of millions
of transactions. Dramatically reduced volumes of paper applications has meant fewer people
are required to process them (resulting in a full-time equivalent (FTE) reduction of over 2,700
over the last 5 years), a corresponding reduction in the need for their accommodation, less
space to store the paper forms (cumulative savings of almost £5 million), less stationery
(cumulative savings of £34 million) and a smaller spend on postage.”
1. Start with user needs: Service design starts with identifying user needs. If you don’t know what
the user needs are, you won’t build the right thing. Do research, analyse data, talk to users.
Don’t make assumptions. Have empathy for users, and remember that what they ask for isn't
always what they need.
2. Do less: Government should only do what only government can do. If we’ve found a way of
doing something that works, we should make it reusable and shareable instead of reinventing
the wheel every time. This means building platforms and registers others can build upon,
providing resources (like APIs) that others can use, and linking to the work of others. We should
concentrate on the irreducible core.
3. Design with data: In most cases, we can learn from real world behaviour by looking at how
existing services are used. Let data drive decision-making, not hunches or guesswork. Keep
doing that after taking your service live, prototyping and testing with users then iterating in
response. Analytics should be built-in, always on and easy to read. They’re an essential tool.
4. Do the hard work to make it simple: Making something look simple is easy. Making something
simple to use is much harder—especially when the underlying systems are complex—but that’s
what we should be doing. Don’t take “It’s always been that way” for an answer. It’s usually more
and harder work to make things simple, but it’s the right thing to do.
5. Iterate. Then iterate again: The best way to build good services is to start small and iterate
wildly. Release Minimum Viable Products early, test them with actual users, move from Alpha to
Beta to Live adding features, deleting things that don’t work and making refinements based on
feedback. Iteration reduces risk. It makes big failures unlikely and turns small failures into
lessons. If a prototype isn’t working, don’t be afraid to scrap it and start again.
6. This is for everyone: Accessible design is good design. Everything we build should be as
inclusive, legible and readable as possible. If we have to sacrifice elegance — so be it. We’re
building for needs, not audiences. We’re designing for the whole country, not just the ones who
are used to using the web. The people who most need our services are often the people who
find them hardest to use. Let’s think about those people from the start.
7. Understand context: We’re not designing for a screen, we’re designing for people. We need to
think hard about the context in which they’re using our services. Are they in a library? Are they
on a phone? Are they only really familiar with Facebook? Have they never used the web before?
8. Build digital services, not websites: A service is something that helps people to do something.
Our job is to uncover user needs, and build the service that meets those needs. Of course much
of that will be pages on the web, but we’re not here to build websites. The digital world has to
connect to the real world, so we have to think about all aspects of a service, and make sure they
add up to something that meets user needs.
9. Be consistent, not uniform: We should use the same language and the same design patterns
wherever possible. This helps people get familiar with our services, but when this isn’t possible
we should make sure our approach is consistent. This isn’t a straitjacket or a rule book. Every
10. Make things open: it makes things better: We should share what we’re doing whenever we
can. With colleagues, with users, with the world. Share code, share designs, share ideas, share
intentions, share failures. The more eyes there are on a service the better it gets — howlers are
spotted, better alternatives are pointed out, the bar is raised. Much of what we’re doing is only
possible because of open source code and the generosity of the web design community. We
should pay that back.