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 firstname.lastname@example.org or email@example.com.
Comment by Robyn Dalby-Stockwell posted on
This is a much needed project. So much time is wasted on line by badly designed sites. Even little things can annoy like 'date of birth,' followed by 'present age.'
Comment by Emma posted on
I notice with services that use this pattern there is often information displayed below the call to action eg a 'Before you start' section. In your research did you ever find users end up not noticing this information? EG if a user is using a screen reader might they just reach the 'Start now' and continue without reading on?
Comment by Harry Trimble posted on
Thanks for your question.
Lab testing has shown users don't tent to read information after the start button. This includes users of screen readers.
Part of this pattern is to move information typically below start buttons and put it after them in the form of questions. This should help filter users who:
don't need to use a service
aren't ready to use a service
aren't eligible to use a service
Comment by Mike Suter-Tibble posted on
One thing that's missing here is mention of the need to evaluate how accurately these questions identify people as eligible or ineligible, and the impact of incorrect filtering.
While the questions in the example are the kinds of things users would know, in many cases eligibility criteria are complex, and not the sort of things users would necessarily know. For example, eligibility for some welfare benefits is based on whether a user is receiving Income Based or Contributions based JSA. Many users don't know which they are receiving, and guess, often incorrectly. This probably means some users are incorrectly told they are not eligible for a benefit or service they actually are eligible for. While we can design questions to work out which benefit the user is receiving through asking them information they're more likely to know (eg how long they've been receiving the benefit), these are still affected by issues like inaccurate recall, so still aren't likely to be highly accurate.
I'm sure there are similarly complex eligibility criteria for other govt services.
The impact of 'false negatives' (incorrectly identifying someone as inelgible) and 'false positives' (incorrectly identifying someone as eligible when they're not) on both Departments and users, as well as how often this happens needs to be considered and measured.
Comment by Harry Trimble posted on
Thanks for your comment.
I agree, there are questions users can't or shouldn't answer.
These type of questions can and should only be answered with data.
Open or private data depending on the question.
For example asking a user whose applying for planning permission, whether the house they plan to build is in a Site of Significant Scientific Interest. The user has no way of knowing this. This question could be answered with a open data register using an API. Then a service only needs to ask users for a postcode.
Your benefits example can and should be answered with a private data register, which the user gives consent to a service to check.
As more registers and APIs are created, more services will be able to automatically answered these questions. This should make services faster and involve less risk.
Comment by Mike Suter-Tibble posted on
Thanks for the reply.
Checking against a register sounds fine in principle, and in many cases it will be (eg the example you give). However, whether people are receiving benefits is fairly sensitive, so DWP probably couldn't display whether someone's eligible or not for a Budgeting Loan without knowing they are who they say they are.
This leads to requiring people to use verify to find out if they should use a service, which doesn't seem ideal to me.
My main point was that it's important to check these kinds of questions are accurately identifying those who are/aren't eligible/required to use the service, as the implications of getting it wrong, and users losing out or potentially being penalised for not using a service could be significant.
Comment by D Gregor posted on
I would like to have an call on this topic with the GOV.UK Verify team for other new projects.
Any advise who I can get in touch?
Comment by Angus Montgomery posted on
Hello, you can email firstname.lastname@example.org.