Keeping it simple is one of the guiding principles for all content designers. We try to apply it to everything we do, but when the content we’re working with is extra-complicated, it’s not always easy.

The Digital Marketplace alpha has presented us with the perfect opportunity to practise what we preach.

Simplicity is everything

The Digital Marketplace should make it as quick and easy as possible for public sector organisations to find and buy digital products and services when they need to. This means we have to structure content in a clear and easy-to-understand way.

Defining and organising huge volumes of technical content into online categories is about as complicated as it gets. There can be no room for ambiguity. With a limited number of words to describe each category, any loose phrasing or misplaced word can have a dramatic effect on how and whether users find what they’re looking for.

Finding a home for every service

Over the last few weeks, we’ve been thinking about how we can organise hundreds of different IT services on the Digital Marketplace. Our first task was to list and group the services that sit in the Software as a Service (SaaS) category.

We all see things differently

It didn’t take long for us to realise that different descriptions mean different things to different people. While a Human Resources specialist might expect to find time-tracking software under the heading ‘Human Resources and Employee Management’; a project manager may expect to see the same service under the heading ‘Project Management and Planning’. Google Analytics from the CloudStore also showed that people are searching for terms we hadn’t even considered.

Changing the way we talk

A lot of card sorts, tree tests and Post-it notes later, we started to make changes to some of our category headings.

We decided to lose our ‘Web’ category, which was being interpreted in lots of different ways, and house its services under different, more meaningful, headings.

Next, we changed ‘Communications’ to ‘Telecoms’ to help focus the kind of services users might expect to find there. We also realised that it was fine for the same service to live under different category headings. Faceted navigation might be one way to accommodate a more flexible approach.

What happens next

Over the coming weeks, we’ll be taking an even closer look at how we’re describing things to make sure we’re presenting suppliers’ services in the best way possible. If you’re a buyer or supplier, you can help us define and refine our content. Please sign up to our user research to help us shape the new Digital Marketplace.

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

Over the line

The Office of the Public Guardian (OPG)’s lasting power of attorney digital service has just gone from beta to live. This is the first exemplar service to pass the Digital by Default service standard assessment to go into live service. The service has been built by a team made up of OPG, GDS and MoJ Digital Services, so this is a great day for us all.

You can find the service here.

What this means to our users

Visually, not much has changed – the beta banner has been removed, and the wording of the terms and conditions has been tweaked. This is because, over the months we’ve been in beta, over 30 feature releases have already been done, making the small improvements our users have asked for or will benefit from – we only ever do these small, frequent types of release.

The good news in doing things this way is that users see the changes they need quickly, and know that they’ve got a major stake in the product we’ve built for them.

What it means for OPG and the team

We’ve been working hard over the last few months to make sure this is a service that’s so good users will continue to choose to use it. One of the biggest steps on the path to go live was passing the new service standard assessment.

Passing the assessment involved three and a half hours with me, the product owner, the delivery manager and our technical architect answering questions on each of 26 points. This was quite a demanding meeting and it was a great relief when, a few days later, we heard we’d passed.

And here is your host …

As with any product launch, it hasn’t been a totally smooth path to get here. What can be seen as a minor change to our users is backed up by months of work to make sure the service will perform well for the growing numbers of users we’ll be seeing.

As well as figuring out some puzzles, such as how to architect the system given the new security classifications, we’ve also had to build new and better ways of monitoring and change hosting provider. All this will help us to prepare for a big increase in our digital applications – and we’ve got some exciting plans in place to make that happen.

What’s next

After a quick celebration? More of the same. As long as we’ve got users, we’ve got a service we want to develop. We’ve got big plans for the LPA service; we’ve only just started on the road to channel shift, so we’re going to be raising awareness of the service and working with interest groups to encourage professional uptake.

We’re looking at making every aspect of applying for an LPA as user-centric as the digital service is, and we’ve got a backlog of features which we’ll be getting straight to in the morning.

All in all, this might be the end of one journey but it’s the beginning of another.

Transcript

Exemplar 25 Lasting power of attorney
May 2014, live

Kit Collingwood-Richardson, Service Manager
LPA stands for lasting power of attorney, and it’s a deed that you put in place where you appoint people to manage your affairs in case you were to ever lack mental capacity in the future. And we’ve just built a digital service so you can do that online.

Chris Mitchell, Transformation Lead
For users it’s much easier than the paper form. They can fill things in once rather than repeatedly.

Kit
We’ve built a clone button in because we know that people often want to make one lasting power of attorney application based on another one.

Nadine Drelaud, Delivery Manager
It means that they don’t then have to fill out a lot of the forms, they can reproduce it really quickly and just change the key details. There was a lot of form filling, there was a lot of duplication, so what our form does is it actually takes a lot of that out.

Chris
It’s far less daunting, the guidance, and help is provided as you need it, in context.

Kit
A lady had come to us. She wanted to put a lasting power of attorney in place. So this lady had started that process with a solicitor using the paper forms, and in the middle of her doing that our beta service had come online and she’d taken the opportunity to do that by herself in front of a computer with her family. So she saved herself some money because that was to her an unnecessary legal fee. And she’d also managed to fill in the application form that much more quickly and in the comfort of her own home.

Nadine
For our users it’s just saving them so much time and money.

Kit
You can see exactly which decisions you need to make and make them as easily as possible.

www.gov.uk/lasting-power-of-attorney

Found a link you think we’ll like? Share it with us on Twitter: @gdsteam

Ever wondered what your social accounts would look like if they were Lego figures? Of course you have. (Image courtesy of Jeremy Waite)

Creating a great user experience isn’t easy; the National Archives chose WordPress to manage their web content – find out why this open source product to allow them the freedom to customise the tool for their needs.

Interested in how we review content? Our checklist for content criteria helps content designers decide what makes it onto GOV.UK.

This post from Jeremy Waite about how to build a truly social business is worth a look.

Data nerds – here are over 100 weird and wonderful data sets for your perusal.

Need to know if a vehicle is taxed? The DVLA have made this easier.

Read about successful public-sector technology with this interactive map and get a global view of how governments are challenging issues like reducing traffic congestion and preserving natural resources.

Sara Wachter-Boettcher (content strategist, writer, and the editor-in-chief of A List Apart) says that the web industry has a diversity problem; read more here.

The transformation team reminded us this week why we’re lucky to be transforming government services.

All our projects begin with discovery, a short phase in which we start researching the needs of users, understand the things we’ll need to measure to improve the service, and explore technology and other constraints.

Discovery usually involves workshops, whiteboards, paper-prototypes and index cards. Sometimes, though, these simple tools aren’t enough to build agreement within the team, or understand the shape of the alpha phase.

Concept principles

We recently spent six weeks working on a Land Registry concept to experiment with, and learn from users. With such a short amount of time available we needed to keep the team focussed, so we came up with some general principles for prototyping.

Show, don’t tell

The first, and probably most important principle is to show the thing. How often does a group appear to reach a consensus when, in reality, each person has a different understanding of what they’ve agreed to?

A working prototype reduces risk of misunderstanding, and is a more powerful way of explaining how the real service will actually work than the most detailed of documents or beautiful slideshow.

Take the easy things as read. Tackle difficult problems for real.

With a short period of time available you should ruthlessly prioritise what you actually make. There will always be bits people assume to be easy, such as accounting or logging in. Take those as read.

Then there are parts which people worry will be complicated or need hard work to make simple. Build those parts for real. Make sure you have time to put your prototype in front of users and iterate.

Copy, cheat, steal like an artist

Working with open source and the web means we don’t need to reinvent the wheel, design new wheels, or often make a wheel, and certainly during prototyping need to buy wheels. Open source software and web services are strange things in that they increase in value the more people who use them, so we can in good conscience steal each other’s wheels.

Build for the future (with thanks to Marshall McLuhan)

A concept is the perfect place to experiment and demonstrate the future.

You need to go where the hamsters are!

But, we should never ignore the needs of our users. It’s definitely not OK to create a vision and declare “build it and they’ll come”.

You can assemble the most futuristic and inviting hamster cage in your bedroom but hamsters will never spontaneously appear. You need to go where the hamsters are.

A couple of weeks ago, we updated the index page for all the blogs hosted on GOV.UK.

To mark this, we thought it would be a good idea to highlight some of the interesting stuff that teams across government are publishing on their blogs, and we’ve done this by making our own Flipboard magazine.

Flipboard is what the cool kids call a “social news aggregator”. That’s internet-speak for a thing that helps you keep up with news from all sorts of sources and read it on the device that suits you.

It also lets you create your own magazine, pulling together articles from anywhere on the web. That’s what we’ve done with a handful of interesting posts we found on some of the GOV.UK blogs.

Topics covered include marine litter and the future of driving. Not always, perhaps, things you expected civil servants would be thinking about. But that’s exactly what blogs are good for: thinking out loud.

Flipboard magazines look their best when viewed on a tablet or phone using the Flipboard app, but you don’t have to read them that way. They work just fine on the web too.

Today we launch the digital service for Individual Electoral Registration (IER). This is our first major transactional service delivered all the way to live as an agile project.

There are lots of other firsts as well.

For the first time we have:

• linked all local authorities in England, Wales and Scotland with a central national service across the PSN (Public Services Network)
• built a way to verify people against the DWP system to allow online registration, authenticated through National Insurance number
• built a system which works across multiple security levels on a national scale in a way that is safe, secure and transparent to users
• developed an open RESTful API which underpins a national service
• had Ministerial approval at the start of a project, not through a paper submission or governance board, but by having the Minister use the service

I have been asked if agile can deliver at scale. IER supports 46 million voters across 400 local authorities.

I have been asked if agile can deliver robust services. IER underpins the democratic process in this country and is secure and robust.

I have been asked if agile can deliver against tight timescales. The only way we could have successfully delivered the digital service with a small team against a deadline set in legislation is by being agile.

Agile is not a thing you buy, agile is a thing you are. This is reflected in how we have worked and what we have learned.

Over the next few days some of the team will talk about what they learnt in delivering IER as a Product Manager, a Delivery Manager, a Service Manager or a Technical Architect.

There is a great deal to learn from our experiences in delivering IER. This was my first agile delivery project on this scale and I have learnt a lot. We are very happy to share that learning.

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

This is a picture of designers working at DVLA, MoJ, HMRC, GDS and HO meeting up at the Home Office last week to share design patterns. This is something we do regularly as a design community.

As we transform more digital services we need more interaction designers. People with experience of designing easy to use services. Some of these jobs are permanent, some are short contracts and they’re in all parts of the country.

It’s my job to co-ordinate this community and make sure we’re building one user experience across government. It can be hard to find these vacancies and sometimes they crop up at short notice so if you’re interested drop me a line with a url of your work at ben.terrett@digital.cabinet-office.gov.uk and I’ll point you in the right direction.

You should also follow the UK Gov Digital Jobs Twitter because we tweet about all the digital jobs from there.

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

We don’t just write the content for GOV.UK – we design it. The steps sound simple, but they’re fundamental to the way we work: understanding user needs, designing content that meets those needs, and iterating to improve it in response to user feedback.

Dealing with government usually isn’t something people do by choice, they do it because they have to. We want to make sure that our content does what they need it to do, as simply and as quickly as possible.

We’ve written a lot about content design over the past couple of years. Here’s a short selection of interesting posts on the subject, starting with a short video interview with our own Padma Gillen, in which he explains the qualities that make a good content designer.

Before we produce any content, we make sure it meets a user need.

We take a user need and present it in the best way possible.

Government information can be complex, but we try to use plain english and repeat the mantra ‘clarity is king’.

We don’t like FAQs – they’re too slow, they lead to duplication, and they’re tonally wrong (and Twitter agrees).

Content has got to be easy to understand, simple to find and, it goes without saying, useful.

Like everything we do at GDS, we always iterate, iterate, and then iterate again.

Our aim is to make your experience simpler, clearer and faster.

You – our users – inform our style guide;  it’s yours. That’s why our style guide is ever-changing.

GOV.UK will cater for varied audiences trying to complete a wide range of tasks, so consistent standards are vital.

We want to get out of the way of people completing what they came to do. That’s why we aim to write less and say more.

Smart answers are a great tool for content designers to present complex information in a quick and simple way.

We don’t need it to ‘build the GOV.UK brand’ by being obviously quirky or clever, and it doesn’t need to feel especially weighty or governmental. Our hope is that no one ever notices the language.

We aim to make information easy to understand, easy to retain, and easy to act upon (where possible – government can be complex).

Don’t forget to sign up for email alerts.

In April 2014 the Digital by Default Service Standard went live, and since then all new or redesigned services have had to be assessed against all 26 points in the standard.

Here at GDS we run service standard assessments for the major services (those with over 100,000 transactions a year and all exemplars). This means that GDS will assess over 180 services that together make up over 99% of the total online transactions that people have with government.

In October Digital Leaders from across government departments agreed that they would be responsible for assessing, using a panel from their department, services with under 100,000 transactions a year.

In order for a service to go live on GOV.UK we will ask the relevant Digital Leader to certify that the service has been assessed and meets the Digital by Default criteria. As with the assessments run by GDS, our intention is that the internal assessment teams will do this at each development stage of a service; alpha, beta and live.

There are a number of reasons why this is a good thing:

• it ensures that no matter how small the transaction is a service will be built to the same standards
• services and departments have the chance to take control of the process of launching services on GOV.UK
• it increases the knowledge of the Government Digital Strategy and the Digital by Default service standard across departments and agencies
• will provide more knowledge and understanding of digital for civil servants
• the limited resources at GDS can focus on the services which have the greatest public impact

It is up to each department to manage how they run their internal self-assessments. This will vary depending of the skills and capability of departments, but the criteria against which the services are assessed and the tools that will be used are the same as those we use for the larger services.

When departments complete an assessment they will submit their assessment report to the service assessment team here at GDS. This will allow the service to launch on GOV.UK (if it’s in beta or going live). This will also be the basis of the report for the service published on the GDS data blog, sitting along side the assessments of the larger services. It’s really great to see services already that have completed a self-certification published on the blog already.

Ian Hunter and I from the Transformation Team at GDS recently sat in on the first government DbD self-assessment for the Rod Catch Returns service at the Environment Agency. The process was very successful with the Agency assessment team fully knowledgeable about the assessment requirements and asking all the right questions.

David Durant – GDS

We are running the self-assessment certification in ‘alpha’ at the moment. This process and will evolve over time as we learn more about how different departments are approaching self-assessment certification and what support they need.

We will work with departments to review and adapt the process, to make sure that it works for them, and that it delivers services which we are all proud to see and use – and we will feed back on what we learn on the way. Thanks to those who have run assessments already, we are looking forward to seeing the variety of services government offer coming through.

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

I’ve just got back from speaking at a workshop for Norwegian government web editors on how GOV.UK keeps its focus on user needs and maintains content quality. I thought I’d share some reflections on the visit.

The most important thing I learnt was  we’re not only changing the user experience in the UK, GOV.UK is helping users internationally. During the visit I was amazed by web editors’ interest in the detail of what GOV.UK does and their passionate commitment to follow the same user needs approach.

‘Less but better content’

Web editors organised the event just after they launched a private beta of the latest version of their website. They want to make sure they question why content is published on the new site so that it serves user needs better. Their slogan is: ‘Less but better content’.

The current site has 500,000 web pages. There are also cross-departmental topic areas, as on GOV.UK. However, the software that maps these is no longer supported. Search needs improving.

Central content and style standards

The Norwegian government doesn’t use a single, approved style guide, as we do. There is a ‘clear language’ programme (the Norwegian equivalent of plain English) sponsored by one of the departments, but nothing to say that all departments must use it for web content.

However, one of the editors explained that content written by departments was still full of ‘stop’ words:

By that I mean the words used are too technical, unclear or full of jargon and the user stops reading.

From what I saw, many news stories were written for public consumption, but consultation titles and summaries weren’t in plain language.

Web editors’ aims

Guttorm Aanes, who coordinated the workshop (and is the Norwegian Ministry of Justice’s web editor), explained:

Gerry McGovern spoke to us last year and said there are 2 types of web editors: editors and put-it-uppers. In the past we were told to ‘put it up’ and did so but we want to use more of our time being real web editors. We want to stop working in silos and write for the user.

Most web editors I spoke to recognised the importance of a central editorial function and agreed style standards, and how these complement a user needs approach. As a result of the workshop, they’ve started to work on a centrally agreed style guide.

GOV.UK’s work recognised

In the workshop’s afternoon session, Ove Dalen from Netlife Research outlined some of the work his company has been involved in, including the redesign of the Norwegian Cancer Society site (publicised internationally by Gerry McGovern). Ove explained that their approach to changing the content design of the website was based on GOV.UK’s user needs approach.

GOV.UK fans

Camilla Pettersen, web editor at the Ministry of Climate and Environment, said afterwards:

We’ve followed the development of the UK’s Government Digital Service and GOV.UK from the beginning. You’ve been an inspiration to us. Now we’ve learnt more about how the site developed and your approach to user needs and content quality, GOV.UK’s Norwegian fan club is even bigger.

What I learnt

Some of the other things I took away with me were:

•      follow what web teams in other countries are doing – successful solutions don’t stop at national borders
•      a vibrant content community spreads good practice and improves editorial quality and the user experience

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

Last week we launched a new online service allowing people to register to vote. This is a big deal. This is a really, really big deal. You can now get on the electoral roll in just a few minutes, even on your mobile phone, whenever and wherever you are in the world.

Registering to vote is undoubtedly the most fundamental service that the state must offer. The flip side of this is that it is also heavily surrounded by regulation and legislation. Regulation and legislation are not great bedfellows for usability and accessibility.

I want to talk about the law and the value in dealing directly with lawyers in public service delivery. I also want to talk about the value in investing the time to bring the lawyers with you as you build your service. These are things that I’ve got wrong in the past, and things that will definitely change the way I approach public service design and delivery in the future.

Lawyer says no

Too many times in the past, I’ve been told something can’t be done (or must be done) because “it’s the law”.  I’ve usually accepted this and then been constrained by having to design the ‘least worst’ way to help people get past that.

In the early days of designing the register to vote service, I was regularly asking the lawyers if there was any wriggle room on a certain aspect.  Almost every time I would get back the same response.

Lawyer says no.

This sort of thing will be familiar to many people working in government:

On the subject of why we’re asking for it, the simple answer is because legislation says we have to…… In any case the reason for it doesn’t matter, the law requires that the question is asked.

Anonymous

It wasn’t the policy team being obstructive, they were being as helpful as they could be. But something wasn’t working and it made designing the service extremely difficult without context  around information we were being asked to collect.

Going straight to the horse’s mouth

After a time, having been through the above cycle too many times, I decided to try and sit down with the lawyers to plead my case directly.

The first thing that I learned when we got together, was that they hadn’t been taken through the service we were building, to give them the context they needed.  That was a pretty big mistake.  Obvious when I think about it, but I was asking people to make tough decisions without any real understanding as to why it was important, or what it was going to feel like to those using the service.

So, we set some time aside and went through the service in some detail.

It was a game changer.

I fought the law and …

Working directly with the legal team, with a greater understanding of each other’s challenges and constraints, led to some pretty important successes for online voter registration and the people using it.  We managed to:

• get some laws changed while developing the service
• find better, more user friendly ways of meeting the requirements set out in legislation
• gain agreement from the legal team to work with the service delivery team when drafting future legislation

I’m just going to make that last point again:

We managed to gain agreement from the legal team to work with the service delivery team when drafting future legislation.

And that is a special thing.

It’s early days for the register to vote service, but with currently the highest satisfaction rating of any online government service, it’s testament that those battles were worth having.

This is what doing the hard work to make it simple for users is all about.

*drops mic*

Pete Herlihy is a Product Manager at GDS

You should follow Pete on Twitter: @yahoo_pete, and don’t forget to sign up for email alerts.

When we’re working with the 25 exemplar services, the transformation team often get asked how to govern service delivery in an agile world. By ‘govern’ we mean how people steer, direct and assure service delivery; i.e. how to make sure that the right things are being done in the right way.

This is a tricky area, so GDS has been working on some advice on how to do this.

To start with, we’ve come up with six principles for people to start using when they are considering how to govern service delivery. There’s a detailed post about this on the transformation blog. The principles are the start of the work, so keep an eye on the blog for further ideas.

Here are the principles:

1 Trust and verify
2 Don’t slow down delivery
3 Decisions when they’re needed, at the right level
4 Do it with the right people
5 Go see for yourself
6 Only do it if it adds value

We welcome your feedback, please leave a comment on this post, or the full principles post on the transformation blog, or complete our quick survey.

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

As well as this blog, GDS has a small selection of accounts on various social media networks and other web services, and we thought it would be useful to publish a list of them here.

First of all: Twitter. We run two main accounts: @gdsteam which speaks for our team, and @GOVUK which answers enquiries related to the GOV.UK website. We also run the @UKGovDigiJobs account.

YouTube is where we currently publish all our videos.

We have a Flickr account for photos and screenshots of services. This is our photo archive, a useful place to store images in high resolution. We often turn to it when we’re looking for images to use in our presentations.

We also post pictures on our Instagram account, and we have a Pinterest account, too.

We’ve got a company page on LinkedIn.

And that’s pretty much it. We’re not on Facebook, and we don’t create profiles on new sites without some careful thought first.

There’s more detail about all of these channels, along with our guidelines for using them, in the Social Media Playbook.

Don’t forget to sign up for email alerts.

We’ve made quite a few films in the last year or two.

Recently, a few people have got in touch to ask how we do it. The long answer to that is very long. We could write a whole manual on it (and perhaps one day we will). The short answer is much simpler, and it starts with keeping things simple.

We keep things simple

Almost everything we shoot is indoors, usually in an office or a meeting room. We don’t book studios, hire actors, or seek out unusual locations.

The vast majority of our films are made from interview footage edited down to the very best bits. We get good results from simply asking people to talk about what they already know. We don’t always write a script or a storyboard. When we do, we keep it very short.

When we add extra stuff like animated graphics, photography or cutaway shots, we keep them simple too. In demos, we show the thing we want to demo. In other films, we show the people and the environment they work in. It’s good to focus on people – that’s the best way to tell a story and keep viewers interested.

We don’t always make a film

Films are not good for delivering lots of information and detail (that’s done better with words and graphics). Films are not good for explaining things you can’t already explain simply in a few words.

That’s why the first step is always to ask the question: Do we need a film? The answer is “No” more often than it’s “Yes”.

Films are good for explaining ideas, showing new digital services, or introducing teams or the people who make all the good things happen.

We do always make a plan

Before we pick up a camera, we make sure we know:

• exactly what the film needs to say
• who it will say it to
• the context they will see it in (on YouTube? On a big screen at an event? Something else?)

We keep films short

We have a rule: no films longer than 2 minutes. If we can’t explain it in 2 minutes, it’s probably already too complicated. There are occasional exceptions, but they’re rare and only allowed to be longer if there’s a good reason.

We keep films focused

Each film does one thing. It might demonstrate one service, or introduce one team, or explain one particular point. If there’s more than one thing to explain, we’ll make more than one film.

We use a microphone

The one thing anyone can do to ensure good quality sound is to record it with an external microphone, not the one built into the camera.

We use decent kit

We don’t spend a lot of money on equipment, certainly not compared to photographers and filmmaking professionals. But we do make sure we buy decent kit. The essential items are:

• Canon 5d Mark III DSLR camera
• Juicedlink pre-amplifier
• Rode NTG2 microphone or Sennheiser G3 radio mic
• Calumet carbon fibre tripod with Manfrotto 701 head

The complete kit list is longer, but still small enough for one person to carry on a bike – which is quite often how it gets transported around London.

Minimum viable film crew

We work as a team, sharing roles (camera operator, sound recordist, producer, director, interviewer, researcher, writer, animator) between us, and very often doing several of them at once. Most of the time, we do all of the work on a single film with just two or three people.

That’s just a summary. We could go on for hours about the details. There’s lots we can share about composition, camera operating, ISOs, codecs, embed codes, editing software, interview techniques, and more besides. In future blog posts, we might do just that.

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

There’s a letter that gets sent out to some elderly people who make claims for Carer’s Allowance. It opens with these two sentences:

We have decided that you meet the conditions for entitlement to Carer’s Allowance. However, as you are getting State Pension, we cannot pay you Carer’s Allowance.

With the first line it offers help. And with the very next line, it takes that offer back.

So we’re fixing that – we’re working with the team at Carer’s Allowance head office in Preston to transform it into a modern digital service. I’ll come back to the letter in a moment, but first let’s take a look at what Carer’s Allowance is and how it works.

What is Carer’s Allowance?

Carer’s Allowance is a weekly sum paid to eligible people who look after others. Anyone who is over 16 and spends more than 35 hours per week caring for someone else can make a claim. It doesn’t have to be a relative, or someone who lives in the same house.

The poorly person – the one being cared for – must be in receipt of either Disability Living Allowance (at the middle or higher rate), or the Daily Living component of the more recently introduced Personal Independence Payment (PIP). These two benefits cover broadly the same things, but PIP is gradually taking over from DLA.

The point is that Carer’s Allowance and DLA/PIP work together. One is for the carer, and the other is for the person who needs care.

Making things better for users

That interdependency between the two benefits means that claiming Carer’s Allowance involves answering a lot of questions about the person who needs care, the carer, how much they earn, what other benefits they claim, and more besides.

When that was done with a paper form, it resulted in a very long and intimidating document. There was a clear need to make it shorter and simpler.

The new Claim Carer’s Allowance digital service went into public beta last October, and in just over a month it had processed 10,000 new claims. It’s dramatically faster to use and works beautifully on phones and tablets as well as standard computers. The project team at DWP Digital have done an outstanding job.

Crucially, it’s much shorter than the thing it replaces. The team were able to strip out one third of the questions that used to be asked. Those that remain are written in plain English.

I visited the Preston team a few weeks ago, accompanied by Steve Wood and Allon Lister from the GDS transformation team. I spent some time talking to Julie Ward, one of their call centre staff, and she told me about her work. She had already seen the new beta from the user’s perspective.

“The online claim service is fantastic,” she told me. “I know someone outside work who has had to apply recently, and I’ve seen it in action for myself. I know how it works. It’s a fantastic service and it really works.

“Now, when someone calls I can tell them that the online service is quicker and easier and I know it’s true. I wouldn’t want to recommend something I didn’t know anything about.”

It’s great getting feedback like this. Julie has been working on Carer’s Allowance for years, so she knows it inside out. Her words are a fantastic endorsement.

The data looks good too. It used to take people about 45 minutes to fill out the form. Now the average time using the digital service is about 20 minutes.

The team is also working with independent carers’ support groups to find out how we can help people with little or no computer experience use the digital service.

Government by macro

Back to that letter – there’s a photo of it at the top of this post. No-one thinks it’s a good thing. No-one at the CA office. No-one who writes policy. No-one working at GDS or in any government department. But it still goes out, day after day.

Why? Because it’s hard-wired into the system – an old fashioned, inflexible system, built up over decades. Somewhere behind the scenes there’s an outdated mainframe computer that churns these things out the same way it was designed to churn them out years ago. The result is something that makes perfect sense to civil servants, but no sense at all to the people it gets sent to.

The rules on benefits say that you can’t get two benefits that cover the same aspect of entitlement. So if you get Benefit 1 covering issues a, b and c, you can’t also get Benefit 2 that just covers issue b. Fair enough. But the letter isn’t clear enough about this. Those contradictory opening sentences simply end up confusing and upsetting already vulnerable people. Too often, they resort to calling up the Carer’s Allowance team to ask for help – phone calls that could be avoided if the letter was clearer (and nicer) in the first place.

This is an example of failure waste, and it’s endemic in public services. It leads to a huge amount of inefficiency and cost to government, and an unknowable amount of problems for users. In short, we shouldn’t be running public services with word processor macros. The policy team is hands-on with this project, and they’re working to help us phase out that letter. That’s an approach we can roll out across other services in future, too.

So when we talk about “transformation“, we don’t just mean messing about with the hardware and software that makes things happen. We mean thinking about the whole service, getting a multidisciplinary team together, and transforming the experience for users, for the people who are seeking help when they put in a claim. We mean delivering a better experience for them, doing something that makes a genuine difference to their lives.

New ways of working

The DWP team tackled this project using agile techniques. Product manager Leigh Mortimer wrote a great blog post about it towards the end of last year, saying:

DWP had had experiences with some projects described as ‘agile’, but which weren’t. They were, understandably, a little wary. We proved our worth with an alpha, which took a specific user journey through from start to finish. It could be used by a small group, and provided insight into the entire claim from start to finish. GDS collaborated with DWP digital services folk and the Carer’s Allowance operational staff, iterating every week. Inside seven weeks we had a properly coded prototype.

They’re making decisions with data. They’re keen to build up a portfolio of user research and user statistics. The more data they have, the better they get at making decisions. Gone are the days of writing a user response report at the end of a project. Now they start with user research and design to meet user needs. The team has starting building close relationships with groups of users, inviting them in regularly to try out new ideas and give honest feedback about them.

They now release code on a two-week cycle, rapidly iterating on what came before. Many changes, little and often. Compare this to how they used to do things: release a product, and leave it for five years unchanged and unimproved. That’s not how government does things any more.

Another thing: the team is now making use of cloud-based infrastructure and services. That’s not unusual, not in the commercial world anyway, but in government it’s considered innovative, even radical. The team joked about showing this stuff to colleagues from other government departments, who were so struck by it that they came up with the phrase “innovate with infrastructure.” I like that. That’s exactly what’s being done.

Each of these might sound like a small thing, but they add up, and the cumulative effect is visible in the public beta.

Delivery in action

I admire the Preston team for the work they’ve done so far. The DWP’s Digital Leader Kevin Cunnington has some great people working on this and other projects (and has been busy recruiting more).

There’s lots more work to be done, and the team are looking forwards with an ambitious to-do list. It’s a very long list, and it’s going to need a lot of hard work. I have every confidence that they’ll be successful and end up with a truly transformed service, something designed to meet the needs of the people who use it. Something that delivers.

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

HMP Rochester is one of a handful of prisons that helped the Ministry of Justice test early versions of a new digital service, the Prison visit booking exemplar.

I went down to Rochester earlier this year to see the service in action. Prison Governor Andy Hudson and Head of Operations Peter Hickey told me that the new alpha visit bookings service has made a real difference. It’s given them a picture of how future prison services could be run. But it’s just a first step along a much longer path.

The legacy of legacy software

A decade ago, the National Offender Management Service (NOMS) commissioned an IT system for use across prisons and the probation service. Dubbed C-NOMIS (a name later changed to P-NOMIS), it was designed to replace various older systems and combine them into one. It was an end-to-end system, a product that would provide everything needed to run a prison.

In the 1990s, government outsourced a lot of IT, leaving behind smaller in-house teams to manage huge projects with reduced expertise. Despite the best of intentions, the project ran into problems. In 2007, work was halted while efforts were made to try and salvage it. Two years later, a National Audit Office report was blunt:

(The project) was handled badly and the value for money achieved by the project was poor. Many of the causes of the delays and cost overruns could have been avoided with better management of well known issues.

After all that, you might be surprised to learn that the software is still in use in prisons, including HMP Rochester.

The moratorium on additional development work came in just as crucial hooks (known as APIs) were about to be added that would open up the software to the outside world. Without them, it remained stuck in a silo.

How things used to be

Generally speaking, arranging to visit a prisoner is a difficult and tedious process. The steps you must take vary from one prison to another, but it usually begins with the prisoner requesting and filling out  a piece of paper called a Visiting Order (known as a VO). They post the VO to their visitor, who then calls the prison to book a slot. They have to quote the reference number on the VO they were sent, and then remember to bring the VO itself on the day of the visit.

It’s a laborious process. There’s a lot of paper to print (and potentially lose), and there are lots of phone calls (and waiting on hold). Generally it works, but it’s slow, cumbersome, inflexible, and results in lots of cancellations: over 160,000 of them every year – that’s 13% of all bookings, at a cost of over £600,000. ¹

Making it better

The new digital service speeds things up. It removes the need for Visiting Orders, and puts a calendar on a web page where visitors can pick three possible time slots that suit them. It’s quick and easy and takes just a few clicks. Or taps, because it works fine on most smartphones, too.

It’s quicker and easier for users because they don’t have to spend ages on the phone trying to get through to the prison staff. They just pick dates and move on.

It’s also quicker and easier for prison staff who no longer need to spend hours on the phone. Instead they can handle incoming requests at a time that suits them, which means they’re able to spend more time dealing with prisoners.

The digital service removes one of the biggest bottlenecks, and makes things easier for everyone involved.

The office staff love it.

“It makes life a lot easier for us,” one told me during my visit. “I think it’s 10 times better than the old system. We don’t have to spend hours constantly on the phone. We can pick up new emails from anywhere in the prison, we don’t have to be tied to a desk.”

“Before, the phone used to ring non-stop while the line was open,” another staffer said. “We were always printing off Visiting Orders, that took loads of time.”

Prisoners prefer it too, they added. On the whole, the process is simpler and faster and they’re happy because that means more visits, more often.

Paul Shetler’s team at MoJ Digital Services is a poster child for how government departments can embrace digital. They’re doing amazing work, of which this project is just a small fraction. Tony Duarte leads the project for MoJ, with lots of help and input from Roger Holding and Ian Mulholland at NOMS.

Talking to users

The new service has now been rolled out to 86 out of 95 target prisons, and has been well received, but it’s just one part of a much larger whole. Rochester, for example, is still locked into its contract for the old computer system. There’s a lot of data stuck in there. It could buy its way out, but that would cost money the prison can’t spare. Staff still have to do a lot of tedious copying-and-pasting to get information in and out.

It was an educational experience, talking to those prison officers and seeing things through their eyes. I was struck by their dedication, and shocked at the poor quality of the computer systems they have to put up with just to get their work done.

I can’t overstate the importance of meeting and talking to the people who are using the services we’re building. Nothing gives you a better understanding of how well your work has gone so far, and what you can do to improve it next.

Starting small

Rochester has a children’s play room, set up so that young children can visit their dads in the prison in a friendly environment. It cost a lot of money to set up and run, but Andy Hudson says it’s worth every penny because he sees the positive results in prisoners’ behaviour. If less money was being spent on poor IT, there’d be more to spend on projects like this.

Could the prison service hire a few experts on short-term contracts and build its own IT infrastructure for prisons? Probably. Would that be cheaper and more sustainable than a huge IT contract? I’d bet on it. But are they allowed this kind of autonomy, as things stand at the moment? No. But that’s another thing that’s going to change. We need to drive standardisation across the service, for the benefit of the user.

The visit booking system is already going through changes – we expect this to happen, as development teams constantly iterate in response to user feedback. One of the next things will be a simpler way for prison staff to process incoming requests. In future, the booking system will be completely automated so that it works in real-time, just like websites you use to buy cinema or theatre tickets.

This visit opened my eyes to just how hard people will work to cope with inadequate and unsuitable IT systems. They’ll tolerate a huge amount of unnecessary administration without challenge or complaint. These are good people whose time might be better spent actually dealing with prisoners. The beta is the first step towards that, and it was great getting feedback on it from staff on the front line – but it also made me think again about how much more work needs to be done. If you’ve ever wondered why I end so many of my talks with the word “Onwards!”, that’s why.

Footnotes

1. Figures from Ministry of Justice.

Government is building digital services that are simpler, clearer and faster to use.

GDS is working with 8 government departments to build 25 exemplar services.  

By March 2015 we aim to have transformed, using agile methods, this varied selection of major transactions into a set of live services accessible on the GOV.UK website.  The exemplars will demonstrate that departments across government are working to develop digital services are so good that people prefer to use them.

You may already know that it’s possible to follow the overall progress of the Transformation Programme on this page and you can read how we’re meeting key milestones on our monthly highlights blog.  However, we thought it would be a good idea to pull together a selection of interesting posts on the subject of digital transformation, starting with a short video introducing the transformation team.

Explaining the discovery, beta and alpha phases

The way we work

The departments we work with often ask us how to govern agile service delivery. We’ve taken what we’ve learnt and combined them with our experience at GDS to create 6 alpha principles.

Individual electoral registration was our first major transactional service delivered all the way to live as an agile project.

When we do transformation, we meet unique challenges along the way. When delivering online voter registration, we learned the value in dealing directly with lawyers in public service delivery. We even managed to get some laws changed while developing the service. This is a big deal.

We like to share our journeys through from discovery to live on our dedicated transformation blog.

When we are transforming government services, things don’t always run smoothly. But, we like to think we learn from our lessons.

The Lasting Power of Attorney exemplar was first service to achieve the full, live Digital by Default Service Standard

All in all, we think we’re lucky to be transforming government services.

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

We often think of digital analytics as simply counting website visitors, visits and pageviews.

 However, this guest post by Jim Williams, a product analyst at GDS, and Tony Duarte, service manager on the Prison visit booking exemplar shows how teams can use innovative digital analytics to track user behaviour in the early stages of development, in order to improve a service for users.

About the service

Currently different prisons book visits in different ways. Visit bookings are mostly done by telephone or email and often requires family members to spend a long time making calls at inconvenient times and waiting several days for their booking to be confirmed. The digital service makes the process easier for families and friends with loved ones in prison and the aim is to encourage frequent visits from a range of people, whilst maintaining security.

Importantly, with the digital service visitors can select three alternative booking slots to increase the likelihood that a visit can be booked.

Submissions result in an automatic notification email being received by the visitor, and an email with all the relevant details being received by prison visits booking staff in the prison social visits mailbox. Her Majesty’s Prison Service staff then make a booking in the backend system and reply to the visitor’s request with booking confirmation details.

The service meets the needs of prison visitors to book social visits easily and at their convenience. Unlike telephone booking lines, the online service is not reliant on the working hours of prison staff – it’s accessible 24/7 and the process of booking is far quicker.  It also meets the needs of prisoners by supporting rehabilitation through increased social visits as staff can process a greater number of requests for visits more quickly.

Capturing slots booked using digital analytics

We anticipated that allowing visitors to select three alternative booking slots would increase the likelihood that their preferred slot would be available and would make the best use of prison visiting facilities, ensuring that visiting times would be well attended. It was therefore important that the project team could track how many booking slots visitors were selecting.

The first innovative way the prison visit booking team used their digital analytics to improve the service design was by uploading the number of slots selected to their digital analytics tool using whats called a custom metric. Each time a user completed a booking the number of slots selected for that booking was recorded against their visit. Collecting this information for every booking allowed the calculation of the average number of slots selected per booking.

The figures showed that people using the early beta design of the slot picker (below) selected an average of 1.4 slots per booking:

Our user research confirmed what the analytics was showing, and this finding led us to redesign the layout of the slot picker (below). The new design was simpler, placed the slots to the right hand side of the screen, and communicated more clearly to users that they could select up to three slots.

This new design changed the way users engaged with the page and produced an average of 2 slots per booking. Using digital analytics in this way enabled our team to rapidly improve the service. Although user testing has shown that some visitors will simply not be able to select more than 1 or 2 convenient dates, we plan to release further  improvements to the slot picker design that should drive average slots per booking even higher for those who can make use of this flexible way of booking.

Booking requests completed

The second innovative way the team used digital analytics to inform service design was to track the number prison visit bookings made by each prison in the pilot. This was done by setting up custom dimensions and completion goals. Dimensions are characteristics of a visit such as referral source, mobile device or country, but in this example the prison name associated with the booking was uploaded to the digital analytics tool.  Bookings which were tracked as goal completions could then be compared across the different prisons in the pilot.

The chart below shows the number of prison visits booked online:

Cardiff was generating around 40% of the bookings in comparison to Rochester and Durham. On investigation, we discovered that Cardiff were slower to replace the non-digital paper form process and had not considered updating their telephone messaging system to promote the digital service. As soon as these things changed, booking increased rapidly.

This data could have been accessed directly from the prison service. But, in uploading the data to the digital analytics solution, the data was made available centrally and in near real time, without placing a demand on prison staff resources. This allowed us to monitor the performance of the pilot and quickly make changes to maximise success.

If you want learn more about getting the most out of digital analytics then you can talk to Jim on Twitter. Don’t forget to sign up for email alerts.

Lots of people ask me what our design process is like at GDS. I thought I’d write some of that down in a place I can point to. It’s worth saying that we don’t follow this slavishly. We’re flexible and we optimise for meeting user need and for delivery. Consistent not uniform. None of this is revolutionary and it’s probably how lots of you work. But people ask, so broadly, this is how we work.

In the GDS design team we have visual designers, interaction designers and front end developers. All of the designers can code or are learning to code. We call ourselves the Design Team because it’s important to belong to a group with shared skills and experiences. This helps people develop their skills, support each other and build a strong culture with shared standards.

We don’t sit together in a studio or around one table

Designers are embedded within product teams alongside developers, product managers, content designers, user researchers and others. A delivery manager runs their day-to-day workload. Designers are involved in discussions about the product and feedback from users. Designers should observe user research sessions for at least 2 hours every 6 weeks.

Designers sketch on paper

They then build what they’ve sketched in code, either by themselves or with a front-end dev. Sometimes they sketch in InDesign or Illustrator, but that’s rare. We test paper prototypes as well as HTML.

We don’t make wireframes or photoshop mockups

We don’t want a culture of designs being “thrown over a wall” to a dev team. We don’t make “high fidelity mock ups” or “high fidelity wireframes”. We’re making a Thing, not pictures of a Thing.

One of the problems with high fidelity wireframes is that they’re very easy to send around to stakeholders who respond with comments like “Move this up a bit”, or “Make that more blue”. The problem with that is they’re commenting on the picture of the Thing rather than the Thing itself. It’s better to send round a URL and ask people how it works for them. If the shade of blue affects something working, that will be apparent pretty quickly, just as it would be to real users.

We are agile

For readers from a traditional agency background: we don’t sign stuff off in the same way you might do with a Creative Director. We’re optimised for delivery and a Creative Director can be a bottleneck. Obviously quality is important and it’s my job to make sure design work is of a high standard. But one of the reasons for having a strong culture and a shared mission in the Design Team is to encourage peer review and have a shared standard of design work.

One of the advantages of being truly agile is that you can fix things quickly if they are wrong. One of the advantages of having a shared mission and strong culture is that that rarely needs to happen.

User experience is the responsibility of everyone in the team

We don’t have a UX Team. If the problem with your service is that the servers are slow and the UX Team can’t change that, then they aren’t in control of the user experience and they shouldn’t be called the user experience team. Mike wrote a post about service transformation that makes that very point.

Words are as much the interface as design

Designers work closely with Content Designers thinking about how the words we write affect how easy the service is to use. We wrote about ‘Is what it says and what it means the same thing? here.

Having a specific UX person or team can lead to projects allocating 2 weeks of UX to fix all the user experience issues at the end of the project. This doesn’t work. Again, user experience is the responsibility of everyone in the team. “You can’t interface away bad policy”, as my colleague Leisa once said.

Martha’s report asked us to build one user experience for all of government. The booking system from department X should look and work like the booking system from department Y. We have some established design patterns now, most of which can be found on the design elements page. Lots of the big graphic design decisions have been made. We’re now focusing on applying that to different user needs to continually make things simpler and clearer. Someone described this to me recently as being like a monthly magazine where the basic styles are set but there are slightly different design problems every week.

This works for us, for now. If that changes, we’ll change it.

Every time you save a document on your computer, there’s a short string of characters at the end of the filename – the stuff you see suffixed after the dot.

Those letters perform an important task. They tell the computer what format the file is saved in, so that your chosen application can open it. So if your computer sees a file with a “.pdf” suffix, it knows it’s a document, and opens it in an application that can read it when you double-click.

Today, we’re making an announcement about the formats government uses by default. Government documents will use what are known as open standards for document formats. Word processor files will be saved with “.odt” suffixes, rather than “.doc”. It’s a different format, but it does a similar job. These formats are open in the sense that you don’t need any specialist software to use them. If your existing software doesn’t understand them, you can download software that does for free.

We’re making this switch because we want:

• users to have a choice about the software they use to read government documents
• people working in government to be able to share their work more easily (we think sharing is a good thing: one of our design principles is “Make things open, it makes them better”)
• to make it easier and cheaper to do business with government (no-one should have to pay for specialist software just to send us some information)

This isn’t a decision we’ve taken lightly. We’ve spent a lot of time recently asking for feedback from the people who are most likely to be affected. Responses on our Standards Hub (over 500 of them) were overwhelmingly positive. Thanks to everyone who took the time to comment.

This is a big step for government, and things won’t change overnight. We have to make sure that the switch is managed properly. We shall work with departments to make the transition as smooth as possible, and ensure that the burden stays with government and not users.

You can read more details about:

• open standards for viewing government documents
• open standards for sharing or collaborating with government documents
• open formats for documents: what publishers to GOV.UK need to know
• open formats for documents: what this means for Technology Leaders in government

And we’ll keep blogging about our progress in implementing open standards on the Government Technology blog.

Update: I made an error in this post, conflating the concepts of file suffixes and media types. My aim was to simplify things for the general reader, but the experts among you have (quite rightly) pulled me up on it. The purpose and behaviour of file types, MIME types and file extensions is very complicated and varies depending on the context and the computer you’re using. For those readers who want to find out more, start at this Wikipedia page about Internet media types and go from there. Apologies – and I hope the error doesn’t detract from the more important message about open standards.

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