This is the third blog post about the work we are doing around common service patterns. We started working on this project by framing what service patterns are and we followed up by explaining how we mapped our services in order to identify patterns.
In this post we want to dive into the details of the patterns we’ve found, how we've classified them and what we want to do about them.
Three levels of service patterns
As we got into the as-is mapping of services, we started to identify recurring patterns while better understanding the interactions and dependencies between them.
The more time we spent mapping services, the clearer the list got. It became very apparent that not all service patterns sit at the same level.
We learned that some patterns can represent an entire service, whereas some focus on very specific parts of services. Some start and end very quickly while others might involve a set of interactions that happens over a longer period of time.
We identified and defined three levels of service patterns:
Service Patterns - Level 1
Building Blocks - Level 2
Building Blocks - Level 3
Service Pattern (Level 1)
This can be an end-to-end service (e.g. ‘Apply for a school place’) or a specific step of a service (e.g. ‘Booking a registrar for a wedding’). It is typically made up of Building Blocks (Levels 2 and 3) and will also have interdependencies with other Service Patterns.
The Service Patterns (Level 1) we identified are:
- register for something
- check something
- tell us something
- request something
- apply for something
- book something
- update something
Building Blocks (Level 2)
These are what Service Patterns (Level 1) are made of. They are heavily task-based and are fundamental for Service Patterns to work, but by themselves they wouldn’t mean that someone can complete an end to end service.
The Building Blocks (Level 2) we identified are:
- fill in something
- send something
- pay for something
Building Blocks (Level 3)
We also identified two others that could be called Building Blocks (Level 3), ‘Understand something’ and ‘Get a notification’. We found that these generally exist when triggered by something happening at Level 2. We are not 100% sure that ‘Understand something’ is a Service Pattern, or is more related to information and guidance.
Using this example, we now know that you have to register for an account on an Education portal. So, in this case, the 'Apply for something' pattern is interdependent with another Level 1 Pattern, ‘Register for something’. After registering yourself, you will need to fill in an application form and you will then receive an acknowledgement email. That’s why, in this instance, the ‘Apply for something’ pattern is linked to ‘Fill in something’ and ‘Get a notification’ , Level 2 and 3 Patterns.
How we’re prioritising patterns
We have now identified seven Level 1 Patterns, three Level 2 Patterns and two Level 3 Patterns, and have had to decide which one to work on first.
As a next step we have created a prioritisation framework. The key criteria were:
- The certainty of the information we had collected. We wanted to prioritise a pattern where no additional discovery was needed (for now).
- Creating a good case study for this approach in the short term. We wanted to start with a pattern that is enabled by tech systems that are flexible enough to accommodate new guidelines within a tight timeframe, to show impact quickly.
- To demonstrate impact, building the case for this approach in the long term. We wanted to select a pattern that will make the benefits of this approach clear enough to help us to move on with the next patterns. This meant looking at the volume of different types of service patterns and considering the different types of services, and priorities across different areas of the council.
For each pattern, we created a summary overview of key data - this includes the number of times it appears to the number of functional areas within Essex County Council that offer at least one service that uses the pattern.
This information is backed up by our map, where we listed not only the services and the sub-services (or steps to get through the service), but also the role of the council, the level of authentication needed to access the service, current tech components enabling the service, any data and any key pain points. Here is the full 'Check something' as is table if you want to dive into the details - volume data and pain-points have been removed as these are still being validated.
Which pattern we want to focus on now and why
Using the key criteria we mentioned above, we ran a workshop to prioritise where to start. By the end of the session, we decided that ‘Check something’ is the first pattern we wanted to work on.
There are multiple reasons that supported this decision. One reason was the fact that this pattern happens early within any service journey and it has the potential to influence the steps that follow. On top of that we feel fairly certain about the information we collected about ‘Check something’ and it’s tech-enabled by systems like Achieve Forms that should be flexible enough to welcome the guidelines we are in the process of crafting.
Where next?
In the next three weeks, we are going to design and build the first prototype for a ‘Check something’ pattern. By prototype, in this case, we mean a set of guidelines that will set the standard for how ECC does ‘Check something’ when this is included in a service. It will be possible to use by service owners to improve the current service (and staff) experience or to rethink it completely, and by the procurement team to make sure that any new tech solution will be compliant with these.
If you want to get involved to review our ‘Check something’ prototype or to test it, or if you simply want to know more about the other patterns and suggest which one we should focus on next, you can contact the team directly on service.design@essex.gov.uk .
Leave a comment