In a recent workshop on leading service design, I talked about how to introduce end-to-end service design in large organisations that understand and structure work in very different ways, for example in IT portfolios, technology programmes, projects or in terms of enterprise architecture.
We group entire industries and the products and applications they make into things like e-commerce (buying stuff), tasks and utilities (doing something), entertainment (watching or participating in something) and banking (getting, using or saving money).
In government, we also categorise services. Some of the common types that people have identified so far are:
- get permission to do something, for example a licence, permit, authority or visa
- start, for example a business
- stop, for example a business
- move, for example cattle
- claim, for example Universal Credit
- become, for example a childminder
- learn, for example to drive
- share or check something, for example your GCSE results or your right to work
- register or provide information, for example register to vote
Being smarter about services
You can anticipate things about a given type of service. They have repeatable patterns, parts that tend to work well or not work well and likely desired outcomes. We can tell things about the building blocks that could or should underpin them and we can predict some of the goals and policy intent behind them.
The GDS-led Government as a Platform work in 2015 identified some of the commonly occurring stages for the ‘get permission to do something’ type of service. It also brought together common problems for these stages and set out an approach to making them more effective and efficient.
This came out of teams in a few departments looking at different services that fall into this category – staying in the UK, driving and going fishing.
These stages were identified by insight from user research, talking to domain specialists, then abstracting that insight to give a name to repeatable patterns that could be applied across services. Some of this thinking has resulted in design patterns for ‘check before you apply’ and ‘task lists’.
These stages have been extended by a few service designers as a way to explain all the parts of a service. It gives us a way to see whether, and how, current work being done by teams (in projects, programmes and portfolios) supports intended outcomes of a large service.
The problem with this diagram is that stages appear as if they are sequential and linear. In reality, there can be circular loops, backtracking, missing stages and additional stages, as well as differently understood names for the same stages.
Some teams will go in depth on one stage and will need to expand it or label it differently. Others will work across different stages. And it won’t fit neatly with current organisation structures.
That said, it’s still proving useful and widely applicable as a way to understand and communicate a ‘get permission to do something’ type of service. This approach is being used by HMPO to look at the whole service for getting a passport (including delivery and expiry, not just applying for one) and UKVI is reviewing it as a way to manage work on end-to-end services, including visit the UK, work in the UK and study in the UK.
Using service stages to frame work
Government is transitioning from understanding services as transactions or component parts, for example applying for something online or a technical capability, to understanding services as the whole thing from start to end.
Because many services are operationally quite large, we’re using stages to organise what good practice looks like, what problems we’re trying to solve, what the desired outcomes are and how performance, and work, can be measured against these outcomes.
How stages help service management
It has implications for all the disciplines on a delivery team. If we can anticipate common problems at each stage, we can anticipate design approaches and learn from what works or doesn’t work elsewhere.
Design patterns are a start, but there is more to be done around identifying good practice for stages, creating standards for common problems (for example, how we identify someone) and using desired outcomes to align the work of all the different disciplines in a team.
It has implications for portfolio management too. The idea of end-to-end services as end users would know them doesn’t neatly align with traditional ways of describing and measuring work in an enterprise context or large IT portfolio. Service designers in government are learning how to bridge and explain these two worlds to help everyone see if there are better ways to connect projects with outcomes, that work at scale.
It also has implications for service management and ownership. Being clear about the desired outcomes at each stage, not just of the overall service, should help you see how well the end-to-end service is performing and whether individual projects and teams need realigning.
The larger end-to-end services are probably too big for any single owner and are likely split across organisational boundaries. Having owners for various stages in addition to an owner for the end-to-end service could be an interim answer and this model is being investigated.
It’s also interesting to think about what a ‘performance dashboard’ might look like if it took into account the policy intent of services and stages, the costs of operation and performance against outcomes.
Framing work around end-to-end services and stages also changes how we might approach user research. Why would we only do user research within 1 project – which is itself a unit that has a given scope, that is part of a stage of a wider service – rather than user research at the service or stage level itself and what people are actually trying to do?
We could and should be doing continuous ‘design’ user research at each stage of a currently running service, inviting a proportion of users to help us see what it’s really like, what’s good or bad, what’s working and what isn’t, at any given time.
That insight could be a critical resource for teams that need to understand the wider context around the part they’re working on, as well as forming a benchmark for when we change things. That would leave individual teams free to focus their user research on what makes the part they’re working on unique, for example because it has different users, a specific context or because it requires more depth. We’re working on a model for this now.
Make a list of services as end users would know them
We found it useful to make a list of all the services that an organisation does, or does a part of, as an end user would likely know it. Here’s an example of a good format to use.
This helps you see the different types of service your organisation supports. If any of them are a ‘get permission to do something’ type of service, try out the stages above. If they’re not, do some user research to understand what actually happens across a few different services of the same type or ask others in the community.
Work with people who are not you
Some people feel uncomfortable if they don’t see ‘their part’ or ‘their team’s work’ represented in a list like this. You can use this common language for understanding services to show how all the various parts fit together to make a service work, including data, technology, live systems and architecture, business, people and technical capabilities, and activities.
Add other layers as you need. You may need to go into more detail and list various parts of many of these services before people will feel comfortable that the overall service name doesn’t exclude their view of the world. Bear in mind some people may have already spent months mapping out and labelling what they would consider as the end-to-end service, so the hard work is bringing this all together in a way that aligns all disciplines.
For these reasons, it’s best to make this list with a few people from different disciplines and to get the input of others as you go. For example, start with a service designer, a business architect, a product manager, a user researcher, someone from operations and a tech lead. Once you’re all happy with it, expect to take some time to ‘land it’ with the right people at a senior level.