This is the fourth blog post about the work we are doing around common service patterns. We started working on this project by framing what service patterns are, followed up by explaining how we mapped our services to identify patterns, and then how we prioritised our patterns.
In this post we want to go through how we approached designing and prototyping the ‘check something’ service pattern and the library that will contain all of our patterns guidance.
Service pattern library: what and why
We started by taking a step back and identifying the overall goals of the pattern and library we had in mind. This helped us to be clear about its purpose, and what we needed to do to support it.
There are a number of overarching goals of the pattern library:
- Provide a set of guidance and standards to help teams understand how their services can be improved or reimagined.
- Support the delivery of consistent service experiences across different types of services and transactions.
- Foster a wider conversation about service patterns across the local public sector.
- Encourage continuous development of service patterns: having people to test, contribute and develop the service patterns.
Who are the users and how it can be used
We think the service pattern library will be useful for a range of different people and teams:
Internally at Essex County Council:
- the service design team
- operational service areas, teams and programmes
- Technology Services
Externally:
- other local authorities
- the wider design sector
Testing our approach
Our approach to this phase is hypotheses led: we are not only testing the ‘Check something’ pattern we created, but our approach as well.
Our hypothesis
We believe that we need to create a first draft of the common service pattern library with the pattern “Check something”, which includes best practice guidelines, examples and considerations.
By doing this, it will mean that designers, service teams, and tech services can easily use the pattern library to design and implement an improved experience involving ‘check’.
We will know we have succeeded when the Check something pattern:
- helps guide the design of a service transaction
- is easy to use by the design team, service and tech services
- is further developed and iterated after a service has been designed and then tested with real residents
- encourages ongoing iteration and feedback
We plan to test this by creating the first version of the pattern, applying it to a couple of real services and using it with the teams we designed it for.
Defining a pattern
As we started working on the ‘Check something’ pattern, we needed to establish a definition of a pattern and what it would include and what it wouldn’t.
The patterns and library are mainly guidelines. We looked at other existing pattern libraries as inspiration for what ours might look and feel like. The main examples included GOV.UK design system, Projects by IF Data Permissions Catalogue and Design Patterns for Mental Health.
The content needs to enable people to:
- understand what the specific pattern is
- what problems it might help solve
- make decisions of what patterns and guidelines would be best for a service
- use it to help design and implement an interaction/transaction
- contribute to its development
Building on those examples and what it should enable, we decided that each pattern will have:
- a description of what it is
- when to use it
- when not to use it
- how to use it
- considerations
- interdependencies with other patterns
- case studies
- research and resources
The Check something pattern
Now that we have established the goals, usage, and defined the overall content for each pattern, we needed to start prototyping ‘Check something’.
What “Check something” is
This pattern enables a person who needs to look up information and understand if it applies to them or helps them find something. The information might be about eligibility, status or location. It also helps people make decisions early on before they engage with a service and keeps them up to date after they have used a service.
To start prototyping, we reviewed the ‘Check something’ pattern and the current services we mapped underneath it to better understand the contexts of Check.
Pattern scenarios
We identified different scenarios of when ‘Check’ happens and grouped them into categories as follows:
Check before using a service
Scenario: Check before you apply.
When a user needs to check if a service is the right service for them and if they can apply for it. For example, check if I am eligible for school transport services.
Scenario: Check how a service works.
When services work differently across locations and users need to know how it works in their area.. For example, there might be different ways to recycle bottles across Essex and therefore different advice and guidance provided.
Check to understand something
When the user needs to understand a situation, context or to understand what the status and progress is for something that is happening.
Scenario: Check a risk/potential status
When a user needs to understand the risks or potential of something that is related to a service or situation. For example, ‘check your risk of flooding’, is about risk related to a location and helping users answer the question “Is where I live at risk of flooding?” A ‘potential’ example might be answering the question “Where is best to set up a new childcare centre?” which applies to the online service that offers a ‘childcare sufficiency map across Essex’.
Scenario: Check the live status / progress of something
When a user needs to wait for something to happen when engaging with a service. A real-time status and progress check is necessary to be updated about what is happening while they wait for a service to be completed. For example, reporting a highways issue and being able to easily check the status of the report.
Find something
Scenario: Check what is nearest/best
When a user needs to find a service, people, or asset based on location and/or criteria and preferences. For example, find a youth group that is closest to me, or that offers a specific activity. Other examples, include, find a recycling centre, find a councillor, find an event, and find a school.
The prototype
The prototype is a set of guidelines for Check something, including high level flows for each scenario. In addition to the guidelines, we think that the service patterns will require ongoing development, research and testing and may need a way for people to understand each patterns progress. So we started to think how we can track the development and research completed of each pattern.
We came up with two measures and statuses:
- Development status: Indicates if and how much the pattern has been developed.
- Research and testing completed: How much evidence there is for the pattern guidance based on research and testing conducted.
What next
We now plan to test the Check something pattern with the people that will be using it and applying it to real services. All the parts of the pattern and library we have outlined here need to be tested. Through testing, we will learn what works, what doesn’t, and be able to iterate the pattern and library to better support teams and build on research and testing of the patterns themselves.
For anyone else that’s interested or wants to provide feedback on this work, you can contact the team directly at service.design@essex.gov.uk.
Leave a comment