We’ve talked lot about service patterns. Time to show one.
This is a pattern we’re calling check before you start.
The pattern is for users to check whether they can and should use a service. It could be used in services like apply for a licence, register an object or make a funding application.
The pattern works by asking a user questions, then gives them the information and list of tasks specific to the thing they need to do. For example start a business.
The link above contains guidance and a prototype. Guidance for why and when to use the pattern. A prototype to show what the pattern actually is.
As the pattern is bigger than a web-page, we've used an example service – become a childminder – to show it in use.
Services using similar patterns now
Patterns are found, not made. We find them by testing, learning and sharing what works. This pattern is a collaboration and brings together much testing and learning from across government.
Although not using the exact pattern and at different stages in their development, many services already have users check before they start.
Some of these services are:
- Carer's Allowance, DWP
- Register to Vote, CO
- Renew your Passport, HO
- Drivers Medical, DVLA
- Digital Marketplace, CO
- Child Benefit, HMRC
- Export Licensing, BIS
- Budgeting Loans, DWP
We collected these examples by visiting several teams to understand why and how they designed this part of their services.
Although they meet seemingly different user needs, I find it really interesting how similar the reasons are for these services to let their users check before they start.
Testing and prototyping
We’ve been prototyping the new pattern with the Environment Agency, to see if it can be used on services with lots of rules, like environmental permits. The lab testing we have done shows it probably does.
The pattern is still experimental: it needs more testing. Given its size this can only happen in real services, with real users. We’d like to hear from more service teams able to help us test it.
To decide if your team can help, here is why and when to use this pattern.
Using this pattern to meet user needs
Discovering the needs for this pattern has come from user research. User research not just into becoming a childminder, but into other tasks like learning to drive, going fishing, getting a licence to run a pub and getting permission to export goods.
Through this research, we discovered that before using a service users might need to know:
- all the tasks involved to do something, eg export plants
- what rules they must follow, eg environment permits
- if they have to use a service, eg driver’s medical
- if they can apply, eg become a childminder
- how much it'll cost, eg learn to drive
To save time and money
In using this pattern and meeting these needs, we believe services can also save certain running costs. In a similar example, the Department for Work and Pensions is prototyping questions in its Apply for a Budgeting Loan service to reduce applications from users who aren’t eligible to use it.
The running costs we believe this pattern will help reduce include:
Calls from users asking:
- how to do a thing, eg apply, register
- what they need to do, eg fill in a form, visit a post office, pay money
- when they need to do specific things, eg telephoning before filling in a form
- what rules apply to their situation, eg if they're applying for a visa from outside the EEA and EU
- which forms they might need
- what information they need to put on a form
Processing applications from users who:
- don't need to apply
- aren't ready to apply
- aren't eligible
The service might also incur costs from users who:
- fill in the wrong form accidentally
- break the rules because they don't understand what they have to do
To replace features in your services
You can use this pattern to replace features in your service.
Features you might want to replace could include:
- phone calls with users helping them prepare applications, also known as ‘pre app chats’
- documents with lots of instructions on how to fill in a form
- guidance and conditions split over multiple documents
A pattern is never finished: it will continue to be tested and iterated.
As more services use this pattern there will be more data on how it's performing. This in turn will increase teams' trust in using the pattern in their services.
Next we want to test how to scale the finding of patterns. We cannot do this alone. Nor do we plan to. Design patterns are a community, not a library.
There is already a community of designers, developers and managers across government finding patterns. This is great, as it means our main challenges are not motivation or consensus, but consistency and avoiding duplication.
This means our team’s job is to make it:
- simpler and faster to contribute a design pattern
- clearer what and how much evidence is needed
- easier to collaborate with other parts of government to identify and develop patterns, through the design community
By scaling the finding of patterns, we solve more common problems once. We can meet more user needs for less.
Help us do this. This pattern is an alpha. It’s still experimental. It needs more testing. Testing with real services, with real users.
If you think this pattern could improve your service, contact email@example.com or firstname.lastname@example.org.