Hi, my name’s Dave Mills and I am the Product Owner for UK Visa and Immigration’s China visit visa exemplar – part of the Immigration Platform Technology programme.

My background is in business operations, rather than digital, but I joined a talented agile team who valued the insight I could offer into overseas visa operations. In return, they taught me a lot about the role digital plays in service development.

Our task was to deliver a public beta online application tool for visit visa customers in China.

The China visas office

The challenges

Working on an international project like this comes with a unique set of challenges, including:

• visa applications were made online already through “Visa-4-UK”. With a clear expectation from the department that the beta would do everything an individual applicant might need, our minimum viable product wasn’t going to be all that minimal.
• we had a challenging deadline and would launch at the peak of summer visa demand
• unlike many government departments, we’re in a competitive industry, particularly in China. The UK, Schengen, USA, and Australia all seek a larger slice of the tourist and business visitor market.
• the tool had to integrate into several existing systems – caseworking, appointment booking and Worldpay payment portal
• our customers did not have English as a first language and many had very little English at all
• time zones meant that as we were starting our working day, Beijing were coming to the end of theirs
• China is a long, long way away so site visits would be rare

The Visa Application Centre, Beijing

Getting started

Undaunted, the team set about the task. Unable to travel to China in the early stages, our user researchers came up with innovative alternatives:

Several late nights and early mornings conducting remote research.

Forging links with English language schools in the UK and carried out research with their students.

Working with cleaning staff in our HQ to research with people who did not use computers on a daily basis.

Visiting a secondary school and researching with sixth-formers who weren’t used to completing official forms.

Based on that research, our analysts and developers could create stories and solutions at an impressive pace.

We’re extremely grateful to GDS for support with content design. Integration with other systems is as big a challenge as we feared. But, by developing robust relationships with all the suppliers through plenty of hard work, we got there.

(Not) lost in translation

With a project like this, there is a huge amount of translation required. Not just questions but guidance, radio buttons and error messages – a task made more demanding because, in true agile style, the English language content changed often.

Through the combined efforts of a professional translator and native-speaker colleagues in Beijing, we completed translation only a day or so before release.

Simplified Chinese is available extensively

Leaving on a jet plane

We invested our travel budget in two trips to China – to support transition testing and to conduct post-release user-research. Both were money well spent, highlighting a variety of changes and improvements we could make. There is no doubt in my mind that one of our big lessons learnt is that we should have sent our researchers out to China much earlier.

Sorting user research in China.

Ready for launch

We launched on 30 June, expecting about 30 customers a day to try out the beta. But, within a week, we were seeing 400 customers per day. By the start of September approximately 15,000 customers had used the service.

Many of those customers provided feedback. Overwhelmingly, they were positive – finding the new tool quicker and easier to use. But, they also suggested a number of improvements, several of which we were able to introduce quickly. One of our first big changes was to introduce a facility to change appointments online, which was prioritised entirely because of user feedback.

It’s still early days, but the exemplar appears to be a real success with our users and has accrued benefits for the business department too (for example, reduced data-entry times at post).

Importantly, the experience of using agile methodology has been a success for the Home Office, and not just because we are delivering a valued product. Staff have been pleasantly surprised by the level of involvement they had in designing the tool and the speed with which we could respond to their ideas; a quite different experience from some IT projects of the past.

For me personally, it was a tremendously rewarding opportunity to try new ways of working and to learn from a multi-disciplined and diverse team.

You can follow the progress of the Visas exemplar here. Sign up for email alerts.

A few weeks ago, I went to Coventry to visit the Skills Funding Agency, where a team is working on a new online service to help young people in England apply for apprenticeships.

How apprenticeships work

Anyone over 16 and not in full-time education can apply for an apprenticeship.

Making apprenticeships work means pulling together four different components:

• an employer with a job to offer
• training, both on-the-job and away from it, usually at a college
• someone who wants to be an apprentice
• funding from the Skills Funding Agency

Sometimes a young worker will be offered the chance to convert to an apprenticeship by their existing employer, so not all apprenticeships begin with the online service. But even so, the online service handles 1.76 million applications every year ¹. It’s an important part of the government’s policy on helping people find work after school or college.

At the moment, making an application means using the existing web service which has been in place since 2008.

That web service was not designed in a user-centric way, and sometimes causes problems of its own. Searching for an apprenticeship vacancy is hard enough, because there are five different search types you can start with. The search results don’t always match what you’ve entered as a search term either (I tried searching for driving jobs, and got results including beauty therapist, hairdresser and solicitor’s receptionist).

The registration process has problems too. The registration form collects data that isn’t needed. The form is too daunting for many people, because it presents them with a long list of questions. Lots of people drop out at this point.

Of those who do register, around one in six never activate their account ², because the activation email that gets sent to them often ends up in their email service’s spam or junk folder.

Starting with user needs, not government needs

This is what the new apprenticeships beta looks like:

The team have simplified things, and they’ve done that by starting with user research, which helped them concentrate their efforts on specific changes:

They simplified the search input – the old system asks people to pick a search type (from a list including “keyword”, “occupation type” and “learning provider”), then enter keywords, then choose a location. Users find it confusing, because it asks for too much.

So the new service does less. As you can see in the screengrab above, there are now two boxes: one for keywords (which is optional), and one for location. User researcher Nahella Ashraf explained: “We realised after talking to users that most of them just want an answer to the question ‘What’s available near me?’”

The new service makes it easy to find out. It’s all about empathy, and understanding your users: in this case, about understanding that most potential apprentices are on a budget and can’t afford to travel far to take up an apprenticeship.

The next step was to simplify the search output. There used to be seven different ways to sort the list of search results, but user research showed that most people only used two, and were usually most interested in what was geographically nearest. So now there are just two sorting options for search results, and distance is the default.

They have also simplified the registration form. The new one asks fewer questions, and makes use of a more robust email system to help prevent messages being incorrectly tagged as spam.

Rather than split information across several pages, the new service puts everything on one page. User research showed that people don’t mind scrolling - it’s what they expect to do.

The new service lets people use their email address as a username, so that’s one less thing to remember. Researchers also realised that users are often sitting inside Jobcentres when they access the site, which means they don’t necessarily have easy access to their personal email account. Sending confirmation emails to them will only slow things down – so a future release of the service will be able to send confirmation messages by SMS, directly to users’ pockets wherever they are. Again, it’s all about empathy.

Other comments from users include things like:

That was really fast, it was good. You’ve just asked for the questions that are needed.

This is clear and really useful, really quick to apply.

It’s really simple. Even though apprenticeships themselves are quite difficult and hard to get, the site is simple and helpful.

Our sixth Design Principle says: Build for inclusion. In more detail, it says: “In fact, the people who most need our services are often the people who find them hardest to use. If we think about those people at the beginning we should make a better site for everyone.” That’s what you can see happening here.

Behind the scenes

As you might expect with a service handling hundreds of thousands of applications, the technology behind the scenes of the existing service is pretty complicated. It has a tightly integrated and hard-to-change architectural and system design, along with slow and infrequent deployment and release cycles. That leads to ‘high stakes’ product decisions, which in turn slow everything down.

The new service has been designed to change all that, building a service with loosely-coupled components, making it easier to iterate and change. That’s a big step for the Skills Funding Agency, requiring them to take a radically different approach to both technology choices and service governance.

For Product Manager Angela Scale (that’s her pictured at the top of this post), this is a huge relief. She told me this:

“I’ve worked on the existing web service from the start. For so long my day-to-day discussions have been about what the service can’t do. It’s taken a while to adjust to the concept that I’ll be able to improve the service whenever I need to – that’s a huge change for the Agency.”

The alpha successfully passed a Service Standard Assessment in April and officially moved to beta. The aim is to make a public beta release towards the end of this year.

Projects need people

I said it on my visit, but I’ll repeat it here: well done, apprenticeships team. You’re doing exactly the right thing. This is how we imagined the transformation process working from the outset, and I’m delighted to see it actually happening. Just three years ago, even talking about this sort of radical change and service re-design would have been impossible. How far we’ve come, in such a short time.

The team is small but their work has been noticed. More and more people are attending their fortnightly show-and-tell sessions, and showing an interest in agile working.

The team aims to do its work in the open, and it’s good to see that designer Scott Smallman and front-end developer Henry Charge have been strong contributors to the Design Patterns Hackpad, where teams from different service and project teams compare notes.

The Skills Funding Agency has been undergoing some big changes recently, not least a reduction in staff numbers from 1,900 to 900. It’s been a difficult time. What’s exciting, though, is that the management can see the need to hire people with digital skills. They’re desperate to recruit more people and have ambitious digital plans, but progress to date has been slowed by the restructure and reform programme.

Tim Clayton, Chief Digital Officer, told me: “The exemplar is just the start of a pretty radical overhaul of our digital services. We know the Midlands has a wealth of digital talent and our new digital delivery structure has roles across the entire set of digital delivery disciplines. We’re keen to talk to people who are up for the challenge.”

Good point. I’ve said it before: London is not the only place where you find skilled digital people. There are excellent digital people in every corner of the UK, and I’m sure there are many in and around Coventry who could help the apprenticeships team build a better digital service.

Government needs to get better at getting those people in – either as civil servants, or as temporary contractors. If that means changing some rules that have been in place for years, so be it. It’s no good saying we’re going to do the hard work to make it simple if there aren’t enough of the right people on the team to get that hard work done. I’ll do whatever I can to help the agency build the team it needs.

Follow Mike on Twitter, and don’t forget to sign up for email alerts.

Footnotes

1 – Figure from Apprenticeships service transaction dashboard

2 – Figure from Skills Funding Agency operational reports

You hear the word agile in government a lot these days. And not only within the teams making digital services.

Agile development is a way to make software. We build a simple prototype quickly, then keep improving it by releasing frequent updates. You can read more about it in the agile manifesto.

We’re using agile development to build digital services throughout government. The Office of the Public Guardian used agile methods to build the digital service to make a lasting power of attorney.

As you might guess, the service makes it much simpler to make a lasting power of attorney. Instead of filling out long paper forms, the service asks you a series of questions, and fills in the forms for you. You simply sign and post them back. It’s a great example of agile development delivering a service that can make things easier for millions of potential users.

The other day, we put a video camera in front of the Public Guardian, Alan Eccles, and got him talking about agile development. I think it’s fair to say he’s a fan. Anyway, here’s the film of what Alan had to say:

It’s interesting to hear is how agile methods have influenced the whole culture at the Office of the Public Guardian. But it takes time to adjust. To begin with, words like alpha, beta and live can be alienating. At GDS, we can help people by talking to them, and pointing out relevant bits of the Service Manual.

And here’s some background on some of the other terms Alan talks about: minimum viable product, scrum, and sprint.

And if you’re very interested, here’s a longer version of the film.

Want to know more? Join the discussion on Twitter, and don’t forget to sign up for email alerts, too.

Here’s the transcript:

Public Guardian Alan Eccles talks about his personal experience of using agile software development to create the online lasting power of attorney service https://www.gov.uk/lasting-power-of-attorney

The Public Guardian on agile development

Agile development involves building a core digital service quickly and then continually improving it to make it better

Alan Eccles, Public Guardian for England and Wales:

The key thing about agile is it not only puts the customer in the heart of what we’re doing, but actually puts the customer in the place of driving development. It’s about breaking down those customer expectations into small chunks so you can deliver something that they’ve asked for really quickly. You can say, “Is this what we expected? Is this what you were looking for?” It’s open, it’s transparent.

Methods

The two-weekly sprint and the continual iteration of what we’re doing has worked particularly well. That’s helped us to see a product emerging, and for us to be able to shape it with the developers, and we’ve moved from process to customer outcomes, so we no longer measure how quickly we move the piece of paper, but we measure what the impact is on the customer.

Governance

Doing something in an agile way doesn’t mean you’ve thrown governance out of the window. In fact I feel that I’ve got more control over an agile development, because I see what is being done, or have the potential to see what’s being done, once a fortnight, I can say whether I like it or not, and I can stop things really quickly if they’re not going right.

Challenges

I’ve had to learn a whole new language about discovery, alpha, beta, live, scrum – so it’s learning what that actually means in practice and bringing it alive to other people.

Culture

It’s changed the language of the organisation. It’s quite interesting just to overhear conversations even in the office for people who aren’t in the digital team, talking about, “Well, before we start off on this project, what’s the minimum viable product here we want to deliver?” Also people talk about iterating customer delivery and services and processes, so it’s got into the psyche.

You may have already seen the good news earlier today, but I wanted to mention it here too: Liam Maxwell has signed on the dotted line to stay with us as Chief Technology Officer for government until at least 2018.

That’s good news for all sorts of reasons.

Liam is famous around government for waving his phone at people. Wrapped around that phone is a case emblazoned with the words “What is the user need?”  - a simple question that we’re encouraging government departments to ask more often, because knowing the answer helps them do the right thing.

Armed with that phone case, Liam and his team have started the process of redesigning technology governance in Government from top to bottom. Gone is the astonishing complexity that used to govern how we bought and procured IT in the past. (Look at the diagrams below – we have closed over 20 boards, and introduced governance by browser wherever possible.) Liam’s made it simpler, which has made it better.

Technology governance – before…

…and after

Gradually, we’re saying goodbye to the days of government services run as huge monolithic silos. Now we want to implement government as a platform, government made from platforms: re-usable, interconnected, easily replaced components that can be used and shared by everyone.

Since he joined GDS, Liam has been an important force for change. His team has achieved a great deal in a short time (take a look at the team blog and you’ll see what I mean). Liam, supported now by Magnus Falk as deputy CTO, has attracted the type of talent we need in Government. Andy Beale and Tom Read are rolling out new common technology services, James Duncan is transforming the Public Services Network and Kevin Humphries is establishing a cross-government technical architecture function.

Outside of the central group, Liam is pivotal in recruiting experienced technology talent and the quality of the Technology Leaders group is evidence that we are at last bringing in top-tier technology skills.

We need to keep up that momentum, and we need more time to make bigger, more ambitious changes happen, then let them settle down and become the new normal. With Liam as CTO for at least the next three years, I’m confident that’s going to happen.

A few weeks ago GDS hosted the latest training session for Digital by Default (DbD) assessors. There were over 50 attendees from across government – the largest assessor training session we have run so far.

This training is designed to explain why the Service Standard is important to digital services, and share the experience of assessing services against it.

The Service Standard team started training people in January. The first attendees were nominated by Digital Leaders. Some had already run assessments and sent through reports to certify that services (those with less than 100,000 transaction a year) are Digital by Default.

The Training

The training lasted about 3 hours with a mixture of presentations, a Q&A panel made up of GDS assessors, and mini-assessment exercises.

View this presentation on Slideshare.

The session opened with a welcome presentation from Richard Sargeant, Director of the Performance and Delivery Unit at GDS (the area where the Service Standard reports into). Richard talked about the importance of changing the approach to digital in government, and the need to find a new way of delivering services. He explained that the DbD standard is not just part of the Digital Strategy, but a way to guide departments and agencies to build digital services that people prefer to use.

I talked through examples of standards outside government, such as the Apple App Store guidance, and consistent but localised Google branding around the world.

On the walls around the room were reports written by GDS assessors without the result written on them. During the break, everyone had an opportunity to read them and decide if the service had been successful or not at an assessment. The trainees were surprised by the directness of the reports, and the breadth of the services government offers.

Q&A panel

It wasn’t possible to answer every question as time was short, but it was great to share ideas and knowledge. This sort of training helps give new assessors a feel for the process at GDS, and examples of the types of assessments happening across departments.

A lot of questions were about the depth of questioning in assessments, and the panel agreed that while it does depend on the service, most like to cover all areas of the standard and drill down into areas where they have concerns or see potential weakness.

One questioner asked “What makes a really good service?”. The panel all agreed that a focus on the users, coupled with an approach that welcomes change, will always create a strong foundation.

Mini-assessment exercise

The mini-assessment exercise gave the assessors the opportunity to practice questioning each other and develop the skills they need to run an internal assessment of services.

While the scenarios were not to do with government (Lego and Doctor Who), the groups had to question each other like they would in an assessment, taking notes and focusing on the areas of the DbD standard such as User Needs or Security and Privacy. Everyone took part, and took the opportunity to meet new people from across government who will be sharing the role.

Outcomes

The feedback so far has been positive with lots of comments on the open style of training and the understanding this is new across government:

I particularly liked the openness, and acknowledgement that we are all learning and improving as we go through this.

I appreciated contact with GDS’s learning culture.

At the end of the session we asked everyone what they would find useful to support them in their role as assessors. So we have agreed to get together all the assessors we have trained so far some time at the end of the year as a conference and learn from each others experiences.

I’ve been following up after all the training sessions using Survey Monkey to ask some straightforward questions and get some more detailed feedback. The good news is that everyone who fed back is confident they are equipped to run or be part of an assessment of services now.

Some of the suggested changes included giving time to what a good service looks like and more time in the training exercise (and more help with the scenarios). The clear favourite section of the training was the Q and A session with a panel of GDS assessors.

Here are the slides from the day

Follow Tom on Twitter, and don’t forget to sign up for email alerts. 

Hands up if you remember Transport Direct – www.transportdirect.info. It was a journey planner for British transport – all of it, everywhere. Roads and traffic, rail journeys, cycle routes, foot and vehicle ferries, you name it. It included and integrated a huge volume of data from hundreds of sources, put it all together in one place, and made it searchable.

It was funded by the Department of Transport, the Scottish Government and what was then the Welsh Assembly, now the Welsh Government. There’s a detailed account of its history and context on Wikipedia. It closed for good this week (last Tuesday, 30 September), after a Department for Transport review concluded that there are plenty of equivalent services provided by the private sector.

The reason I’m flagging up its closure here is because it’s a good example of what happens when you make data open.

Regular readers will know that we’re big fans of open data here at GDS. In fact, we’re fans of open everything. One of our design principles is make things open, it makes them better.

In this case, opening up the enormous transport information database in recent years allowed hundreds, even thousands of services to bloom. Services you probably use on your smartphone, or in a web browser, every time you plan a journey, switch on your satnav, or buy a train ticket.

Government should do only the things that only government can do. In this case, government had the data, and the sensible thing to do was open it up, make it available, and see what the rest of the world can do with it. As it turned out, the rest of the world made a bunch of transport planners and searchable timetables and ticket-buying apps that were far, far better than anything government could have done.

We made things open, and that made them better.

Of course, there will be some people who are sad to see Transport Direct go, not least the team responsible for building and maintaining it, for whom I have nothing but the greatest respect. They built a genuinely useful web service that was way ahead of its time.

And in that sense, it was a success. It demonstrated a need and paved the way for where we are today, but now we need to move on. It’s now a service that government does not need to  provide. The money spent on it can now be spent on other things – things only government can do.

View your driving licence information is a new digital service from DVLA. It’s a simpler, clearer and faster way to view your driving information online.

The service is free and available 24 hours a day. Here’s a short film we’ve made about it:

Signing in takes a matter of moments. You just need your driving licence number, National Insurance number and postcode.

The service lets you see when your licence expires, how many penalty points you have, and which vehicles you’re licensed to drive. For instance, you can find out whether you’re allowed to drive a tractor or mowing machine on the road.

You can also see your personal details registered with the DVLA to check if they’re up to date.

Join the conversation on Twitter, and don’t forget to sign up for email alerts.

To meet the Digital By Default Service Standard, digital services have to ‘make all new source code open and reusable, and publish it under appropriate licences (or give a convincing explanation as to why this can’t be done for specific subsets of the source code).’  This reflects our design principle of making things open because it makes them better.

This post is about the types of circumstances where we think it’s appropriate not to publish all source code, and how we in GDS approach decisions about what not to publish.

There are three types of code that we think it’s appropriate not to publish.

1. Information about how our software is configured

In industry there is an accepted separation between configuration and code. We don’t publish information about how our software is configured. For example, this includes information about:

• what software we’re using to enforce certain security measures (‘security enforcing function’) eg antivirus software, intrusion detection software
• specific versions of the software that we use
• detailed configuration of firewalls and other security-related software

This is because for these categories of things, making things open does not make them more secure and the public interest is better served by not publishing them. We also think the impact of not publishing these categories of things is low. The specifics are unlikely to be helpful to other people because they are at a level of detail that others wouldn’t find useful.

For example, there will inevitably be times when there is a gap between us finding out about a vulnerability in some software that we’re using, and us being able to fix it. Not publishing specific information about which version we’re using makes it harder for an attacker to use publicly known vulnerabilities to attack while we are still fixing them.

2. Implementation of code that performs a security enforcing function

Where our code performs a security enforcing function, we will make the design public but not the implementation.

We build on top of open standards, for example we use SAML for GOV.UK Verify and the profile is published. We don’t publish information about the implementation of the design because it would allow people to create a duplicate and practise hacking it without our being able to detect that activity.

In instances where we don’t publish our code because it fulfils a security enforcing function, we make it available for peer review and subject the code to penetration testing. This involves commissioning security experts to attempt to break into the system to help us identify any areas of weakness and potential improvement.

3. Code that it’s not appropriate to publish at that time, but may be later

We may also occasionally judge the public interest not to be served by publishing our own software when the policy hasn’t yet been announced so we can’t / it’s not helpful to reveal the code without that context. In this case we may publish the code later. We expect the teams responsible to still develop the code as if it were open to make sure there are as few barriers as possible to opening it up when the time is right. We did this in some cases whilst building GOV.UK.

Over the last year or so, we’ve been working on moving the websites of 311 government agencies and arms length bodies onto GOV.UK, as part of the transition towards a single online platform for all government services. You can read more about the transition process here.

Transitioning the websites of over 300 agencies on to GOV.UK means drastically altering the experience for users of these sites. Because of this, user research and analytics can be crucial in making the transition a smooth one.

We can’t measure all 300 of these transitions, so we’ve been focusing on some of the bigger or more complex agencies whose users are dependent on digital content to do their jobs. The Environment Agency (EA) is one such agency. Using research and analytics, we were able to identify places that were causing trouble for users, develop solutions, then use analytics to confirm that our solutions were effective.

User research pre-transition

After all EA’s content had moved over to the GOV.UK site and was ready to go, we decided to hold off a week before switching traffic over from the old site. During this time, we were able to do some remote testing with environmental professionals, in real life conditions on the site, rather than using a prototype as we had been doing for previous rounds of research. This enabled us to spot any major problems users might have, before the old site was redirected.

Overall, the research went very well, with users generally being able to find all the information they had regularly looked for on the old site. Only a couple of potential problems were thrown up – for example the removal of “what’s in your backyard” branding from the local environmental data checker. This confused some of the users we spoke to, as they no longer recognised the service as being the one they were used to. After transition, we were then able to confirm this was an issue through analysis of internal search term data, and made this change to the page as a result:

Analytics immediately post-transition

When the re-directs went live on April 8, we monitored the success of transition in three ways:

• on-page contacts
• analytics
• call centre volumes

Immediately after launch we reviewed the Environment Agency user experience with a Google Analytics dashboard to ensure that people were finding the content they needed. For any problems revealed we conducted deeper page-level analysis, using insight from user research, analytics and information architecture.

Japanese Knotweed improvements

Lots of people were arriving on GOV.UK after searching for ‘Japanese knotweed’ in Google. They were landing on a browse page that had no reference to the weed, because although the Environment Agency had covered it, we hadn’t anticipated such an interest.

To improve this, the Environment Agency changed the misleading redirect to point to a relevant DEFRA page. Now the DEFRA page comes first in Google, and GOV.UK is getting the most traffic for this term. This is a great example of departments putting user needs over departmental divides.

This Hitwise graph shows that GOV.UK is getting the most traffic from Google for the term ‘Japanese knotweed’:

Review two weeks post transition

After two weeks we conducted a page-level analysis of Environment Agency content with a team including three content designers, a user researcher, an information architect and an analyst. We made 15 changes to content as a result of this review.

Two weeks later, we met again to look at whether these changes had affected the experience for users. We found that traffic had gone down 25% (mostly because of a long bank holiday weekend), but searches went down 42%, and on-page feedback decreased by 62%. Fewer people had to search or complain, because they were finding the information they needed.

Fishing licence example

One of the biggest improvements was made to the page Buy a UK fishing rod licence. On-page feedback and searches revealed that people didn’t realise that they could go fishing immediately after buying a licence – they thought they had to wait to get their certificate in the post. There were 7 complaints similar to the one below, from people who hadn’t received their licences in the two week post-publish period:

So a content designer added a call-out box explaining this, and there have been no complaints on this issue since:

Call centre and on-page contact volumes

We asked the Environment Agency to inform us of any change in call centre traffic, and they didn’t report any increase. There was also no overall increase in user contacts on the GOV.UK site as a result of this transition.

Benefits of this approach:

• testing with users live on the site allows a realistic view of how successful transition is likely to be – this approach allows us to see how users find us in Google, what pages they visit, and follow the true user-journey
• combining analytics, customer feedback and user research allowed us to understand and react rapidly to issues as they came up, and validate the magnitude and importance of the problem
• working with content designers during the analysis process meant that solutions were designed to be fit for content, and actioned immediately

This case study shows that by doing research before going live, and combining that with analytics immediately after transition, we can make sure that users’ journeys are disrupted as little as possible.

Research can identify problems, and start people thinking about solutions. Findings can be validated post-publish with data from a full-sized audience, and be resolved quickly. People often take sides regarding the effectiveness of qualitative and quantitative data. But they’re natural partners, and by combining them you can overcome the inherent limitations in each.

Follow Charlotte on Twitter, join in the conversation with Lana, and don’t forget to sign up for email alerts.

“Do less” is one of our design principles. Visiting the Environment Agency in Bristol, it struck me that sometimes one of the best things departments can do to support digital transformation is to let the really talented people get on with it. “Doing less” can mean more delivery and less bureaucracy.

The Environment Agency (EA), has had a tough spring, with heavy floods in the southwest. In the middle of that, they’re delivering one of the 25 exemplars, waste carrier registration. They’re also working on a range of other projects, including:

• rod catch returns
• modules that can be used across different environmental services
• developing their own web operations system

The team gave some really interesting presentations about these, as well as about the waste carriers exemplar.

The waste carriers exemplar

Waste carriers is a service that allows users to register for a permit to transport waste. It includes two different tiers. Lower tier is for businesses that transport waste as a small part of their main business, like plumbers, gardeners or builders. Upper tier is for users who transport waste on a wider scale, or who transport special kinds of waste. These users have slightly different needs.

Meeting the needs of new users

Until earlier this year, lower tier waste carriers didn’t have to register. For those users, possibly as many as 450,000, registering as a waste carrier is a new thing. It’s our job to make it as simple as possible. Complying with the law should be an easy, straightforward process, not a confusing hassle.

The decision to bring in this requirement was only made in August 2013, so speed was critical if the team was to meet the 1 January 2014 deadline for the new service. Listening to the team at the EA talk about how they pulled together to build a service robust enough to go into public beta between mid-September and mid-December was really heartening. This is one of the great things about working in an agile way. You can adjust your projects to meet user needs – it doesn’t matter if those changes are because of last minute decisions from lawmakers, or from things you’ve found in user research.

Making things better for users

For upper tier waste carriers, the user needs are a little different. They’ve always had to register as waste carriers, and tend to be businesses where transporting waste is central to their business. They have to renew their registration once every 3 years.  We have about 120,000 of these in total, so about 40,000 renew their registration every year. There are currently two different ways of doing this, either online, or with a paper form. About 30% of the users currently register by paper and about 70% use the current web service. The EA will bring as many of these as possible online, with an assisted digital programme to support those waste carriers (both upper and lower tier) who are not online. Assisted digital users will be able to get help using the digital service by calling the EA phone line, or visiting an EA office.

So why did we need to transform the web service? The current way of renewing the form is unnecessarily difficult. The service just really doesn’t fit user needs. How do we know? Because for every registration on the existing online service, we get 1.2 calls to the service call centre in Sheffield. The questions are almost all about how to fill in the form. Remember that many of the users of the service are renewing their permits? That means even people who have gone through the process before can’t figure out what they need to do. The existing form needs three pages of complicated explanation for a six page form, and people still can’t work it out. That’s a system that just doesn’t work.

It’s expensive, too. Every time someone calls the call centre about the upper tier service, it costs the taxpayers money. Money that could be spent elsewhere. It also undermines the credibility of the government, with a slow drip, drip, drip of inadequate services.

Integrating everything

Integrating the two tiers of the service was always part of the plan. Of course, the upper tier waste carrier registration is a little bit more complicated. People have to be able to pay for part of the service, and it requires different steps to be taken. An integrated service is now being prepared to go into public beta so that users for both types of waste carrier are offered the same simpler, clearer and faster service. It might take a little longer to get things right when you start working in a new way, but it means people are learning by doing.

Culture change and ‘lightbulb moments’

One of the big challenges in transforming government is culture change. The lower tier beta was put together in 12 weeks, and the team were really learning agile by doing. Led by service manager Paul Wright and working with transformation manager Ian Hunter from GDS, a multidisciplinary team, including suppliers CACI Ltd, made a place for themselves in the heart of the EA’s building, just by the cafeteria on the ground floor.  To encourage the rest of the EA staff to learn more about what the team is doing, they even have a sign to encourage people to ask them about it:

A lot of the people who started working on the project were a little apprehensive about working in a new, agile way. They wondered how it was going to work, after being used to a lot of box-ticking and bureaucracy. That said, Nikki Wilson, a project manager who has been at the Environment Agency for 7 years, described “a lightbulb moment” when the team really started seeing results. “I’ve been a product manager for over 20 years and I’ve delivered more new services in the last 9 months than I have in a long time,” she said.  Some of these came from really focusing on user needs; the team realised that there were a lot of things that just weren’t important to building a really good service. “Do less” at its best.

Then, when the EA transformation team started building the lower tier beta, they were told that they needed to follow a 6 week service introduction process (a period when the service goes through a final set of checks and activities prior to going live) when they were only taking 9 weeks to build it. That’s totally out of proportion and not very agile. But out of that, they were able to create a much lighter touch service introduction process, which is much more agile and keeps being iterated to fit the team’s new ways of working. That’s great news. Transformation is about refusing to accept that “this is how we do things”.

What do users think of the lower tier service so far? Stephen Lang, who is running user research on it, said that a lot of the users came in expecting a website that’d be hard to use and bureaucratic. Instead, a couple of them said things like:

The simplicity is pleasantly surprising

The content is better than other government websites I have visited – more straight forward than a lot of what I have to do

Registration was straight forward and quick to complete

Was very impressed with the service, cannot think of anything to improve as the system was so easy to use.

Intuitive and straightforward. Very happy.

Those are the sorts of things we’re always looking for: services so good that people prefer to use them. User research can also help us get rid of assumptions that are in the way of transformation. For example, not all of the data that upper tier users had entered in the past would be migrated onto the new system. Some people working on the exemplar were worried that this would be a problem; that users renewing their registrations would be annoyed about having to enter information that they might have supplied in the past. Instead, it turns out that the new service is so easy to use users aren’t bothered about entering data again. Problem solved.

Building great public services

Great public services are built from the ground up. They’re not built by big plans, but by pulling together parts of infrastructure that are already there. Beyond the exemplar programme, we saw that the web ops team built a pilot programme in 12 weeks, which could allow people to upload changes to the servers in 30 minutes, rather than the several months it takes at the moment. This will make it easier for teams to work in an agile way. The web ops pilot was completed by a small team of six: Dave Blackburn,  Shelley Campher, Stuart Fish, Sam Griffiths, Imran Javeed and Tom Tant. If there’s anything we need more of in government, it’s people with web ops skills.

Another thing we can do to help is to keep reforming how we hire people. We need to be able to get talented people in to work on projects on short notice. Finding talented people internally, like Polly Jones who went from having an administrative role but with a passion for design to actually working as a designer on the exemplar, is great. But when an agency needs to hire people to cover maternity leave, they should be able to hire close to where the action is, in order to keep up a sustainable development of services. That means an agency like the EA shouldn’t have to go to department level to get approvals for what ought to be a straightforward process. What we can do is make sure that the people on the ground have the support they need to deliver great services for users. Digital civic infrastructure is built on the ground, not through grand designs.

Follow Mike on Twitter, and don’t forget to sign up for email alerts.

GOV.UK is 2 years and 1 billion visits old today. So we’re celebrating. But it’s worth remembering that we couldn’t have got this far without a great deal of support from others.

On 17 October 2012, GOV.UK became the official website of the UK government, taking over from Directgov and Business Link, both of which were switched off on the same day. Thousands of pages were redirected to their new, user-centric counterparts at GOV.UK. Since then, the site has been continuously improved to meet user needs. Performance data guides us too, constantly teaching us new things, such as:

• 36% of GOV.UK users now use a mobile device or tablet (compared to 21% back in 2012)
• 71% of people using calculate your child maintenance do so on a mobile device
• the top 3 digital services, by usage per day, are renew vehicle tax, make a SORN, and book a driving test

Those are just three examples – we learn more every day. GOV.UK is a platform that everyone in government can use and build upon. It’s designed to meet user needs. It’s simpler, clearer and faster. It has changed how government works internally, and inspired other governments to follow a similar path. Which is fine by us.

The team at GDS has worked extremely hard over the last 2 years. Well done, all of you, and thank you.

There’s a wider team beyond GDS, a team that stretches across traditional departmental boundaries. GOV.UK would not be what it is today without the enthusiasm and support of many, many people in Whitehall and elsewhere.

If I wrote a list it would be hundreds of names long, but I’m going to pick out just a few: Francis Maude, Minister for the Cabinet Office, who backed us at every step.  Antonia Romeo at Ministry of Justice, Brian Etheridge at the Department for Transport, and Adam Bye at Foreign Office, all of them early supporters whose efforts laid the foundation for moving all 24 departmental websites, plus Number 10 and the Office of the Deputy Prime Minister, on to GOV.UK. And Melanie Dawes, another unsung hero who made sure we had access to Business Link when we needed it.

And of course there’s Martha Lane Fox. Not just because she wrote the report that started it all, but because she’s been a constant source of encouragement and inspiration to the whole team. Thanks for that, Martha.

Most important of all are the users. None of this would have happened without them. Their input and feedback is the most important part of the puzzle.

After the inevitable celebratory cake in our office (there will be cake, I’m pretty sure of that), it’ll be back to work, because there’s still loads to do. There are a few more agency and arms-length body websites to transition over to GOV.UK. There are exemplar services we haven’t finished with yet, platforms like GOV.UK Verify that have only just started to operate in public, and dozens of other projects we’ve yet to start. We’ve come a long way, but we’ve barely begun.

We’re still going in the same direction: onwards!

We know that owning a gov.uk domain address tells users that we can be trusted, and we’re proud of this message – it is an important part of building trust and reducing the potential for people to use misleading websites as part of phishing and scamming activity.

As part of our work we carry out audits of different domain groups. I completed an audit of all central government gov.uk domains a while ago, and recently started the process again.

This time, I’m looking at the 1900 or so gov.uk domains belonging to local authorities, the devolved governments, and locally related services, e.g. fire services, National Park Authorities etc.

You can see the entire list of around 4000 gov.uk domains here (go on, I dare you to take a look).

An audit of local authority sites had never been carried out before, and it’s a big job involving basic checks of each site. Working with The Naming and Approvals Committees (NAC), the goal is to advise domain owners if their website appears to breach any of our current guidance by being inaccessible, nonfunctional or leading to a non government domain, e.g. a .com .co.uk .org etc.

Its important to help make gov.uk owners aware where their websites don’t meet the needs of Local government: naming and registering websites.

Over the coming months the aim is to get in touch with domain owners where possible breaches of the standards are identified, and get these corrected.

We are also doing this to influence the approach to defensive registration including dealing with stockpiled domains.  We want to instil trust that .gov.uk is reserved for use by the public sector (which is managed by government and the NAC).

We are making sure we know why a domain is being approved and what it will be used for – we will also never allow a non-public sector organisation to register with our gov.uk domain. As part of this and if an authority has a number of domains that are not all in use, we may ask if they would mind handing them back for retirement.

The benefits to us are the gov.uk estate is neat, and tidy, and fully understood. The benefits to the local authority are financial as they will save on the maintenance charge of £40 + VAT every 2 years for each retired site. The benefit to the user is the continued reassurance that GOV.UK is the best place to find government services and information online.

In the meantime, here is some advice for local government domain owners:

For those with little technical experience when it comes to websites, we appreciate that managing one can sometimes be a little daunting, so the best things to do are:

• check every so often that your website looks like it is supposed to look
• familiarise yourself with the Local government: naming and registering websites guidelines
• if you are concerned that you may be breaching the standards, just get in touch with NAC via the gov.uk registrar JANET and we’ll be happy to assist
• consider using an analytics tool like Google’s to check how many views your website gets, so you can measure its success and whether it needs an update or refresh
• finally, you might find Government Digital Service’s website style guide helpful. It can be found on GOV.UK at www.gov.uk/guidance/style-guide

Join the conversation on Twitter, and don’t forget to sign up for email alerts.

I am one of the trainers here at Government Digital Service and I work alongside Brij Thakrar. Our role is to train people in departments and agencies how to write and publish to GOV.UK. We take people through the GDS focus on user needs so they can understand how it will apply to their content and information.

Spreading the word

We’ve provided training, support and access to more than 1,000 writers across government, who have published more than 120,000 pieces of content to the site. The word about user needs and transforming content has spread from the people we’ve trained to their colleagues and wider teams. The training is now so popular even people who aren’t in digital teams want to understand user needs and how to write for the web.

More than a copy and paste job

Moving 300+ departments and agencies to a single platform meant we had to think carefully about the needs of our users. What information were they coming for? How did they expect to find that information? What frustrated them about our content?

Moving to GOV.UK means organisations have to transform the way they talk to users. Copying and pasting existing content is not an option. We have to help people understand that putting their users’ needs ahead of government needs is the right thing to do.

Changing the way we think about content

We also want to change the way writers think about content. If you’ve worked with content you’ll know it can be difficult to look at objectively. There is history – and sometimes emotion – between the lines, and knowing where to start can feel overwhelming. Policy, legacy and a culture of ‘this is the way we’ve always done it’ can get in the way of simple, clear communication.

We designed a series of training courses so we can talk about why, and how, GOV.UK puts user needs first and how this applies to content. Brij Thakrar built courses on how to use the publishing system and analytics to make sure content was easy to find in search engines. I wanted to give the reasons for GOV.UK style guide decisions and point out what may be different to what people are used to. Many of these decisions were based on learnings from the user research team at GDS.

Observing and iterating

By observing people using GOV.UK, we can reassure training attendees that users are able to find and use information successfully. One thing I’ve noticed is how the structure of the content has an effect on how quickly users are able to understand it. I created an exercise to demonstrate how we can use user needs and acceptance criteria to help make decisions on how to structure content.

The content and publisher training sessions started with an alpha – just like GOV.UK. We gathered feedback, learned from it, and iterated the courses. We then moved our training into beta and repeated the feedback, learning and iteration cycle until we moved into ‘continuous improvement’. Questions from these sessions mean we are able to adapt the training so it is relevant to agencies before, during, and after transition to GOV.UK.

Users first

As Martha said: ‘revolution not evolution’. Our training is building the skills of teams across government so users are considered first and content created with them in mind.

Follow Christine on Twitter, and don’t forget to sign up for email alerts.

As we announced in August, it’s now possible to make an accelerated property possession online.

The service lets a property owner evict a tenant at the end of a tenancy agreement. This is the first claim to go live as part of the Civil claims service, which is part of the government’s transformation programme.

Here’s a short film we’ve made about the service:

The development team has put a lot of work into simplifying the language from what was, in some cases, rather archaic legalese. As Mike wrote back in July, this is a great example of what we mean by our 4th design principle: Do the hard work to make it simple. The law might be an old one, but that doesn’t mean the language we use to describe it needs to be.

The team will build on this work to put other claims online in the near future.

Follow James on Twitter, and don’t forget to sign up for email alerts.

Our eighth design principle is build digital services, not websites. “Our service doesn’t begin and end at our website. It might start with a search engine and end at the post office.”

Assisted digital is support for people who can’t use digital services independently. They’re most likely to receive this support over the phone, or in person, with someone helping them to use the digital service.

Redesigned and rebuilt digital services are simpler, clearer, and faster. They use plain English, not confusing legal jargon. They don’t make users fill out unnecessary forms. And they give users only the information they need. We want everyone to be able to use our digital services and experience these benefits, not just people who can do it on their own.

When we build digital services, we don’t assume that what is already in place is fit for purpose. We do research to understand what our users need, design a service based on that, and keep testing it with users to improve it. This includes doing research with users with low digital skills. It’s important that services are designed to be as simple as possible and work for all users, no matter how confident they are online.

But we recognise that the service is more than the website. For people who need help to use the digital service, we can’t assume that any existing support they may access meets their needs.

We do research to understand what our users need, and build and test assisted digital support based on this – just as we do for the digital service.

Research carried out by the carer’s allowance team showed that anxiety over the consequences of getting an application wrong can lead users to seek help, and they need a safe, supportive environment to make their claim. It’s important to understand the context in which users are accessing our digital service.

The prison visit booking team surveyed over 2,200 callers to the booking lines. They’ve used the findings from their research to design assisted digital support which encourages callers to use the digital service, while booking a visit there and then for users without access to the internet. This keeps calls short and minimises costs, while meeting user needs.

Our job at GDS is to make sure that before they go live, services have the right support in place for those that need it – and that this support is designed based on research and testing with real users. That’s why assisted digital is point 10 of the digital by default Service Standard.

Like most things, it’s about user needs. We don’t assume any existing online service meets user needs, and we’re not assuming any existing offline support does either.

If you’re interested in our work, don’t forget that GDS has 14 blogs including this, the main one. For a flavour of some of the things we’ve been up to lately, here are 5 (spoiler alert: it’s really 6) recent posts from some of the others. You can see the latest from all government blogs at www.blog.gov.uk, where you can search or filter by organisation.

1. Our new Admin App: building Performance Dashboards faster

On the GDS data blog, here’s Matt Harrington on a new app to build and deploy Performance Dashboards without the need for developer time.

On average a new dashboard took us weeks to develop. The app means we can create one in minutes.

2. Student finance: how Conversion Funnel Analysis gives an insight into how a service is performing

Lindsay Brown and Jim Williams have taken to the Digital Transformation blog to explain the importance of Conversion Funnel Analysis to improving services.  By looking at how many users are dropping out of a transaction, and where (that’s the funnel), you have a better idea of what to fix first.  In one case, the proportion of users progressing from a particular page leapt from 27% to 81% thanks to this sort of analysis.

3. How designers prototype at GDS

Over on the GDS design notes blog, Rebecca Cottrell has written about how designers at GDS prototype in HTML, and why that’s nothing to be afraid of.

A prototype does not mean code must be perfect. In fact, it shouldn’t be: the majority of time should be spent iterating the design, not making code beautiful. Prototypes are made to be tested and iterated (and if they fail, thrown away).

4. Social media planning: It’s time for some perspective

On our social media blog, Georgina Goode sounds a note of caution against jumping feet-first into new social networks, merely because they’re new.

Understanding the actual size of specific audiences on each channel is key. Like any channel, you need to go where your users are spending time. Sounds obvious? It is. And yet, in some cases, hard numbers are still not being used to make social planning decisions.

5. Info pages: publishing data about user needs and metrics

On the Inside GOV.UK blog, Jake Benilov has written about the release of info pages – counterparts to many of the pages on GOV.UK which display useful information, including the user need that the main page its associated with should meet.

Publishing the GOV.UK user needs should also make the team’s work more transparent and traceable. Eventually, there shouldn’t be any GOV.UK page without a validated user need.

There’s an “info” page for most GOV.UK pages. To access one, just insert /info after www.gov.uk in the URL eg the “info” page for www.gov.uk/apply-uk-visa is www.gov.uk/info/apply-uk-visa.

And in case you’re having a long lunch break, here’s a bonus post:

6. Anatomy of a good sticky note

Here’s Leisa Reichelt at the user research blog on the art and/or science of sticky notes, from colour, to pen thickness, to the quality of your adhesive, through the lens of user research.

There’s nothing more annoying than having your sticky notes rain from the walls while you’re trying to do analysis. When it comes to sticky notes, the glue really matters and you get what you pay for.

If any of these have piqued your interest, here’s the current list of the 13 other GDS blogs:

Assisted digital

Data at GDS

Digital Marketplace

Digital inclusion

Digital transformation

GDS design notes

GDS social media

GOV.UK transition

Government technology

Identity Assurance

Inside GOV.UK

Technology at GDS

User research

As a copywriter who’s written online content for the likes of BBC, Yahoo and Nokia, I have always thought about how the text appears on web pages. I think the way it looks is almost as important as the words you write, because users have to be persuaded to start reading.

I’ve been training people how to write for GOV.UK for the last year and in the sessions I talk about how content is part of the user experience (UX). Government information can be complex and content creators want to better understand how to help their users.

I am often asked in training: “how can I make sure people read to the end of the page?”

You can’t. But there are things you can do to improve the user’s experience of your content and persuade them to keep reading.

These include:

• using short sentences
• writing in clear English
• having lots of paragraph breaks
• using subheadings

Doing this creates visual clues that the content is easy to get through. We know users scan text online rather than read it. People blink less often when they use a computer screen and the bright backlight tires eyes, making text harder to read.

Structure is important

Eyetracking studies from the Nielsen Norman Group show that people tend to read in an F-shape pattern online. People read less of the content the further down the page they go. It’s a myth that people don’t scroll, however, and the increased use of tablets and mobiles shows that people are comfortable with scrolling.

Because we pay more attention to the content at the top of the page, we need to get straight to the point. This is where you tell your users what they can do here. Don’t give background information, it clutters up the page and can hide useful information. People want to know if they can get the answer to their question, not how they might have arrived there.

The way we read

When you read, your eyes jump around over the text. We don’t take all the words in and our brains fill in the rest. White space helps the brain see the text, making for a more comfortable reading experience. This is why you should have plenty of paragraph breaks.

Using plain English also helps because users are more familiar with those words. They will be able to get through the sentences more quickly and understand what they’re reading.

User research should test the copy too

At GOV.UK we test our designs and navigation with real users to see if we can improve them. We are also testing our copy. Imagine trying to test a page or transaction that only had dummy text on the page – you wouldn’t be able to use it.

We’ve written some guidance if you’re writing help text for transactions. When we test transactions we start with little or no help text. We are then able to see which parts they struggle with and add text. Read the 9 content tips to help you build a better digital service.

Another way we can see how the text is being understood is when we A/B test our content.

Help users do what they need to

Content and UX work together to help users do what they need to. Designers and writers can help by understanding their content, users and organisation. Consider the words you use, the formatting and how to structure the information.

Follow Christine on Twitter, and don’t forget to sign up for email alerts.

The Digital Marketplace helps government find and compare cloud services for their technology projects. I am the Service Manager for the Digital Marketplace and lead the multidisciplinary team tasked with its design and build.

All new or redesigned digital services being built in government need to meet the digital by default service standard. Services processing or likely to process over 100,000 transactions a year are assessed at GDS. Services with fewer than 100,000 transactions per year are internally assessed with the department self-certifying that they meet the standard.

Despite being a service that doesn’t have to be part of the formal service assessment process, we decided that it would be in the best long-term interest of the service to opt for an assessment.

Government isn’t building websites, it is building digital by default services to meet users’ needs. This standard makes up a crucial part of the DNA of those services that will help build services people can use.

The Digital Marketplace provides an important service to government buyers and it marks the next step in the process of opening up government to the wider supplier market.

The service standard as part of the everyday process

Having now been through an alpha and a beta assessment we thought we should share some of what we’ve learnt. You can read the full details of the service assessment report published on GOV.UK.

For those of you who don’t know, each service is assessed on 26 points. Very early in our project – at inception – we went through all the points as a team, and made sure we understood clearly what was required of us.

Running through these points early on helps keep the standard in mind from the outset. By doing this the standard then becomes inherent to the process and allows a team to concentrate on making a great service. It’s a useful exercise as the team is assembled from different places and has a varied level of experience of things like user-centred design or government security standards.

For example, when I joined, this was the first time anyone on the team had worked with user research. Going through the points on the service assessment helps to remind everyone on the team that each discipline matters, that accessibility can’t be added in at the end, and that user needs are balanced against security decisions rather than superseded by them.

Taking time to prepare

As a Service Manager, when I was preparing for the alpha assessment  – my first assessment – I was advised that the assessment itself would be in the form of a discussion, not a presentation. I would be required to show and not tell; just come in prepared to show the thing and answer questions about the service.

The structure of the assessment is shared ahead of time so, as a team, you can get ready.

For both assessments I went through the questions with the core team. For the alpha assessment we also ran an additional session for everyone just to focus on things that we felt were important to highlight. There is room to tell the story of the things you, as a team, are proud of.

The assessment is conducted by a panel of subject-matter experts assembled from across GDS. There is a person who leads, and the subject matter experts ask questions relating to their area to see evidence of meeting the criteria. The meeting can last for up to 4 hours and will work to establish whether your service meets the criteria for the level you are putting yourself forward for.

Building a service vs passing an assessment

Each stage of the service assessment requires you to demonstrate a particular aspect of how you are delivering your service. For alpha, that means having a good understanding of what your service needs to do, and for beta it’s about having a service which has a good tech stack, ready to go live.

Our first  beta assessment for Digital Marketplace was at the end of September, as we were confident that we knew what our service was doing to meet the criteria and how we were going to address the issues we considered to be outstanding. In this first assessment the panel advised us that they couldn’t pass us on 4 criteria and that we should return for a reassessment when those had been fully addressed.

One of the criteria we didn’t pass was to do with the lack of product analytics being monitored. While we have analytics technology in place from day one, the specific role was yet filled. The choice we made was to wait for the right person. Our new Product Analyst, Lana, has already made a great impact and we can now demonstrate improvements that we’ve made based on her first findings.

There are things we know we are good at

The service design has been truly informed by user research and analysis of user needs. The team gave excellent examples of this during the assessment by describing the research-prompted features of saved searches, and/or searches, the need for repeatability, and service descriptions.

Every other time we see people as part of user research, we map where they sit on the Digital Inclusion scale. This allows us to have a really clear idea of who our users are beyond their level and knowledge of buying and selling. Our panel commented that this was the first time they’d seen this level of consideration.

Advice I would give

Buyers, service managers, builders of services: think about what it means to deliver to the service standard. Behaviours of agile delivery need to be embedded in your team and the way you think because you won’t be able to add them in at the end.

Don’t forget:

• think about the criteria early
• service assessments are a team thing
• bring what you want to show off to the table
• prepare, prepare, prepare
• it’s not supposed to a chore, but a way to make your service great

Suppliers: whether you are providing the cloud services that the digital by default services are being built on, or the team that is helping to define, test, build, deliver the service, you need to understand the full requirement.  If you have a cloud-based service that you think can help government departments with delivering a digital service, G-Cloud 6 is open for submissions.

Follow us on Twitter @GOVUKDigiMkt, and visit our blog for regular updates.

One question we’ve been asked a few times is: “What does your film production team look like? How can our department/agency/organisation build a team like that too?”

In the spirit of “publish, don’t send,” and since this isn’t a topic covered by the Service Manual, this post explains how our team works at GDS. You might find the same approach works for you.

Flexible roles

Filmmaking, like user research, is a team sport. We usually get a team together for each film, and we take a flexible approach to assigning tasks and roles, depending on what’s required.

With a bit of juggling, it is possible for one person to do everything: setting up the camera, recording the audio, and conducting the interview. It’s possible, but we don’t recommend it – this approach is hard work for one individual, and you’ll get much better results by spreading the load a bit further.

So at a minimum, we tend to assign two people to each film project: one to operate the camera/monitor the sound, and one to conduct the interview. They are the owners of that film project and will look after it from beginning to end. This works very well for the majority of films we make, which are usually talking-heads interviews with one, two or three people.

Film-making roles

The camera operator is responsible for the recorded image. They need to make sure the subject is well framed, properly lit, and in focus. Lighting is a skill in itself, whether that means making use of available natural light or setting up specialist lighting equipment. Recording the sound properly means someone has to listen to it while the interview is taking place. We usually combine those three roles, so the camera operator is in charge of setting up lights and listens to the audio while watching the camera screen as well. It’s quite demanding and requires a lot of concentration, but it works for us.

If you can separate out the technical roles of camera operator and sound recordist, you’ll make life easier for both of them. That means they have fewer tasks to juggle at once. We don’t do this for every shoot, but it’s useful to have it as an option.

We’re lucky enough to have several people who can take on the role of editor. Like operating the camera, recording the sound, setting up the lights and designing motion graphics, editing footage is a skilled job that can take years to learn. Our camera people double as editors too, but that doesn’t mean you can’t separate the roles if you’re able to. One thing to consider is that editing is very time-consuming; if your camera operator and editor are one person, you’ll have to allow them enough time to edit each film they shoot.

We don’t use motion graphics in all films, but we do in some, and one member of our team is a motion graphics designer. This is another job that’s often a lot more complicated and time-consuming than people expect it to be. While it’s not essential for all films, we think it helps to have access to someone with this skill – either as a member of the team, or as an occasional freelancer.

The interviewer poses questions, and has to listen carefully to the subject’s answers and respond appropriately. A good interview sounds like a conversation. The interviewer should prepare in advance by ensuring they understand what the finished film needs to say, and how they can guide the interviewee to say the most helpful things. Generally speaking, our interviewers double as writers for the rare occasions when we write a script or a storyboard.

The producer makes sure that everyone on the team:

• knows where and when to be for the shoot
• has what they need to make the film
• understands what the purpose of the film is

Often, it’s useful for the producer to sit in during filming, keeping an eye and an ear open for problems that the interviewer and camera operator are too preoccupied to spot.

Roles and people

We’ve found that roles don’t necessarily equal individuals. Often, the individuals on a film production team will perform more than one role, and those roles vary from one film to the next.

Just as you’d expect with other multidisciplinary teams in government, the film team is flexible. Sometimes a film might only need input from two or three of us. At other times, all of us will chip in. It helps to have lots of people with a variety of skills, so they can swap roles when needed. Sometimes we do hire in extra help from a production company, and on those occasions juggle our roles and to-do lists to fill the gaps that the production company’s team can’t fill.

We usually go through rough cuts as a team as well, and use feedback from those sessions to make more polished edits.

Whatever works for you

This arrangement works well for us, but we’re very aware that we still have a lot to learn from other teams elsewhere in government. So if you have tips or suggestions based on your own experience, please let us know or post your story in the comments below.

Join the conversation on Twitter, and don’t forget to sign up for email alerts.

The new Carer’s Allowance digital service goes live today. If you have access to the internet it’s now easier than ever to apply for Carer’s Allowance. Here’s a short film we’ve made about the service:

As you can see, the Carer’s Allowance team in Preston has done much more than digitise the paper application form. By doing user research, and diving into the detail of the application process, the team has been able to remove 170 questions from the application process – that’s 49% of the questions.

This is crucial because carers don’t have a lot of time on their hands – a fact highlighted by service performance data which showed usage spikes in the small hours of the morning.

The service is part of government’s transformation programme, and it’s a great example of doing the hard work to make it simple.

Join the conversation on Twitter, and don’t forget to sign up for email alerts.

Transcript: