Skip to main content

How we designed the GOV.UK accounts trial

Create a GOV.UK account button

We’ve just launched our first trial of a GOV.UK account. We blogged about it recently, and it’s a big part of the GOV.UK strategy for the future. We want users to experience a government that is more proactive and tailored to their needs, and we think accounts could help us do that.

The trial account is attached to the Brexit transition checker. It lets users save their results and sign up for notifications about changes that impact them. This is the first service that the account is attached to.

During the trial period we want to understand the response to the account - and how we might iterate and improve it. We’re going to use performance data, user research and user feedback to help us make accounts more useful in the future.

Why the Brexit transition checker

We chose to add an account to the Brexit transition checker because it addresses what we call a ‘whole problem’ on GOV.UK. A whole problem normally affects users over a long period of time. It’s not a fixed, standalone transaction with government. It’s made up of a series of complex transactions and pieces of guidance from lots of different parts of government.

The Brexit transition checker isn’t the only place we do this on GOV.UK. We’ve already done a lot of work to bring together journeys from different services that are owned by different departments. The (award-winning!) step-by-step pattern is a way to curate end-to-end journeys that involve multiple transactions, for example importing and exporting from the UK, or starting a limited company.

The difference with the Brexit transition checker, though, is that the checker gives:

  • users a personalised results page
  • us some knowledge of the context and characteristics of a user in a way that isn’t limited to a single topic area

And that’s just the start. If we know the context and intention of the user and persist that through an account, it could help us solve other problems that cut across multiple areas of someone’s life, for example starting a new business, the early years of having a child, or dealing with the coronavirus pandemic.

Where we started

As Leanne Cummings, Head of Product for GOV.UK, mentioned in her recent blog post, we started by thinking broadly about how we could help users if we remembered their context and intent when they return to GOV.UK. We talked to users about how they use GOV.UK when dealing with complex events. And we prototyped a lot of things - some of them won’t happen for ages and some of them won’t happen at all. It was helpful to explore these ideas with real users before we narrowed our scope and chose a smaller thing to test and put live.

How we approached the problem

When we’d done enough research and the product manager identified the scope of our first trial, it was time to move from ‘thinking’ to ‘doing’. We still had a lot of questions to iron out, but our initial research helped to guide us in certain directions.

When to let users create an account

One decision we had to make early on was to determine at what point in a user's journey they would be able to create an account. Because we were planning on doing something small as a first iteration, we believed the account might fall short of what some users expected of it. So we had a hypothesis which said:

'From user research, we observed that users have certain expectations of something called a ‘GOV.UK account’ which we are not always going to meet.
If we introduce accounts as a discrete tool that can help users with the thing they’re doing
Then users are more likely to sign up and use their account
Because their expectations of what they can use the account for will be met.'

Based on this hypothesis, we decided to focus on introducing an account at the point of need, not as an independent ‘create account’ event. That means we ask users if they want to create an account where they can save their answers after they’ve completed the Brexit transition checker, not before.

How to talk about what accounts can do

We also decided that we were going to need to be super-clear about what the account can do now, while at the same time outlining what users might be able to do with it later. Another hypothesis said:

'We can’t deliver all of the value of accounts in one go. We have to take an iterative approach. We can’t promise everything up front and will need to manage expectations.
If we explain clearly that accounts are a work in progress and they will increase in use value over time
Then users will trust us more and be happier to sign up for and use an account
Because we will be managing their expectations better'

Based on this hypothesis, we decided to be upfront about the specific value users participating in the trial would get out of an account now.

Stay up to date with a GOV.UK account webpage

Getting meaningful consent

Earning users’ trust is really important if accounts are going to work. That’s why we’ve tried to be transparent at every point in the journey. Another of our hypotheses says:

‘We observed in user research that people tend to trust government with their personal data but aren’t always aware of how their data could be used.
If we design a consent model for collecting and processing data that asks users to engage with the consent they are giving
Then users will be better equipped to make decisions about what they consent to
Because they’ll be more aware of the consequences of sharing their data’

The current journey has a page in the signup flow which describes how users can control how we use information about them. Users can then choose whether or not to:

  • let us use cookies to learn about how they use GOV.UK while they’re signed in to their account
  • email them to ask for feedback about their account

When users have created an account, they can see sign-in attempts and what services have used information about them. They can also change what they’ve consented to and report any suspicious account activity if they’re worried.

Security webpage

Working remotely as a user-centred design team

Like all teams who have to work remotely, we’ve had to figure out which tools and processes best work for us. Things that have worked well include:

  • weekly design critiques (crits) between content designers, designers and user researchers - which often turn into collaborative design sessions
  • swarming on user research analysis, for example encouraging the whole team to watch user research videos and take notes in a shared Google Doc
  • using Figma for prototyping, research and the single-source-of-truth for where design work is at

Things we haven’t quite nailed yet include:

  • ad-hoc design crits because it’s harder to quickly check something remotely - sometimes one of us gets blocked if the other person is working on something else
  • the whole team having a shared view of the zoomed-out, bigger picture journey - we’ve struggled with this without a whiteboard and walls

What we’re learning

We’re learning loads from the trial already.

Plenty of users have signed up, and a large proportion of them have signed into their account more than once. We’re seeing really high levels of opt-in for cookies and lots of users saying they’re willing to provide feedback. We’re hopeful that this means when we’re transparent about what we’re using data for, users are more likely to opt-in to things like cookies, because they understand what it is they’re opting in to.

What’s next

We’ll be doing more trials, more research, and more thinking about how this scales. We need to find a balance between iterating what we’ve launched and exploring some of the bigger questions we have.

Now we have a small number of users, we can try out some more ideas we’ve been working on, like personalising the GOV.UK publishing platform. For example, if we know that you have a business based in the UK and you’re exporting to Europe, how can we help direct you to relevant content you weren’t aware of? And how do we manage consent when we’re offering a user the ability to do that?

Some of the bigger questions are things we still want to explore before we ship anything. We’re interested in ‘hats’: users using GOV.UK as different personas. For example, people have different needs depending on whether they’re finding out something for themselves or someone else, for their business or for their family. We’ve seen people feel some discomfort at mixing those personas, and we want to help manage that. If we can find a good way to support people using GOV.UK while they are wearing different hats, it should make it easier for people to find the right information for the thing they’re trying to do.

We also need to do more work looking at how an account works when it’s attached to more than one service. For example, we want to find the best way:

  • for users to sign out of a service rather than an account
  • to share data securely and transparently between services
  • to give users control of their data and be transparent about how the account uses it
  • to continue making it clear what is and isn’t possible within an account

Lots to do then, so on we go. We’ll blog more soon about our research and technology approaches in this first phase.

Sharing and comments

Share this page


  1. Comment by mirko posted on

    very nice project.

  2. Comment by Chris posted on

    Thanks for sharing this, it's great to hear about the process behind the scences.

    I particularly liked to hear about your hypothesis driven design approach, but did wonder about how these were measured? I guess the 'We will know this when…' part. Interested in your thoughts!

    • Replies to Chris>

      Comment by Roz Strachan posted on

      Hi Chris! Thanks for your question. We'll be testing our hypotheses in a few different ways, for example through user research, by going through the support requests we get from users, and by looking at things like consent rates.

      For our hypotheses about 'when to let users create an account' and 'how to talk about what accounts can do', we'll want to use user research and user support requests to see whether users are confused about why they're being asked to create an account at this point and whether their expectations are being met when they create an account.

      For our 'getting meaningful consent' hypothesis, we'll be looking at things like cookie consent rates to see how users are responding to the consent model we've designed.

      These are early - and broad - hypotheses so we’re trying to use different sources of information to get a good picture of them rather than relying on only one measure.