Speaking Technology with the Service Standard
How does the UK Government Service Standard look from a technology point of view?
I think a lot about technology design, whether that’s architecture, build and deployment pipelines or the structure and clarity of code. The value of technology is in what you do with it.
The UK Government has an open Service Standard setting out the perspective and principles on which services (often citizen-facing services) are expected to be designed and built. I’m a fan of principles. They encode layers of experience and wisdom, making them accessible for our future selves to learn from and experiment with.
For me there’s no distance between service design and technology design. They’re integral to each other. Technology has little intrinsic meaning and value until it’s part of a connected whole: put into practice in service of a meaningful outcome. To this end, it’s important for technology thinking to work with service thinking.
So I thought it would be good to take the service standard and, from a technology standpoint, speak to each of the areas to see how technology dovetails into an overall multidisciplinary endeavour. I think the whole will have a more unified and meaningful impact for being integrated.
So let’s look at the points of the service standard:
1. Understand users and their needs
Good technology design is about right-sizing a solution architecture. For example, making a service available 24/7 when users only need it during office hours, or designing for 1M users when peak traffic is a few hundred, can quickly drive up cost and complexity for building, operating and iterating a system, significantly decreasing pace and multiplying time to deliver. A solid understanding of user needs enables smart design decisions and specific tradeoffs to be made, increasing solution fit and decreasing complexity risk.
2. Solve a whole problem for users
For a majority of services, technology is an integral part of meeting user needs, however it is rarely the whole picture and certainly not the point. The best architectures render technology almost invisible to the user. The best designs get out of the way, facilitating the user’s journey without attracting attention to themselves.
3. Provide a joined up experience across all channels
A good technology design has clear boundaries and open communication. The ability of a technical architecture to take the user’s perspective, to interface and integrate with wider organisation systems and processes, whether technical, human or offline, is a measure of its ability to be a good citizen in the world that the user is trying to navigate.
4. Make the service simple to use
This is one of the easiest things to say and one of the hardest to do. At best you can iterate towards it, gradually noticing and acknowledging areas of friction and then finding ways to reduce and remove them. Being clear, letting the user know what’s going on, making things feel familiar, guiding attention and taking the user’s perspective are all good design ideas, and good design is key to good architecture. Remember that when you’re designing technology, the user might be a developer or another part of the system. Look after them too.
5. Make sure everyone can use the service
When it comes to technology, or any specialised discipline, it’s easy to be unaware that people you’re communicating with don’t necessarily get your world. Having empathy, building bridges, making the people you interact with feel seen, heard, welcome and included adds a little to world peace. Whether it’s the next person who will work on your code, an operations person reading a log line, or an end user trying to understand an error message, work to be accessible. Technology can seem mysterious, but it doesn’t need to be.
6. Have a multidisciplinary team
Movements like DevOps reflect the idea that working together, side-by-side, with people who come from different backgrounds from us, makes us richer people and increases the impact of what we build. It can feel inconvenient, it always takes effort, but in the end it’s worth it. Working with a range of disciplines, with respect and dignity is basically non-negotiable in a connected world.
7. Use agile ways of working
Acknowledging uncertainty, exploring risks, increasing clarity and course-correcting in response to new and unexpected information are a staple for workability in technology. If we want to build anything substantial, we’re going to need to prioritise, collaborate, limit work in progress and limit change to work in progress. When you’re doing something innovative, it’s like walking in fog: you can only see a little way ahead. Take a few steps, re-asses and change direction if needed. Agile came from the technology world, but sometimes we stick to technologies that aren’t helping us. It’s ok to change direction, and the sooner the better.
8. Iterate and improve frequently
Developers know that if a piece of code works first time it’s either trivial or they’re not testing it right. Experimenting, iterating, aggregating marginal gains, this is how we make progress. Aiming to build something complex without trying out the parts as you go is a surefire way to spend a lot of time on something that not only won’t work, but probably can’t be made to work later. Starting simple and iterating is an honest response to a complex world. Rome wasn’t built in a day, nor could it have been. Complex systems evolve in response to progress and feedback in the real world.
9. Create a secure service which protects users’ privacy
This may sound like a technical area, but bear in mind the wider context. For example, making a password too hard to remember, or forcing regular changes, might mean the only way people can cope is to write it on a sticky note and leave it on their desk. Sometimes a small decrease in theoretical security leads to a leap in workability — and that might well afford better protection overall.
10. Define what success looks like and publish performance data
If you’re familiar with the principles of Google Site Reliability Engineering, you’ll know that measurement and monitoring are the foundations of operations. But measuring everything is overwhelming. It’s hard to see what matters in a sea of dashboards, dials and data. Take time to understand what matters and measure that. Just because CPU utilisation is available, doesn’t mean it’s useful. Dashboards are great, but if they don’t speak to the observer, they’re usually a colourful smokescreen that announces that we don’t understand our service.
11. Choose the right tools and technology
Tools and technology used to spark contentious discussion in technical communities. It’s still the case to an extent, but there’s a shift. Where someone might have referred to themselves as a “Java Developer”, it’s now just “Developer”. Where once we’d wed ourselves to a single technology for the span of our career, the reality of the pace of technology change means it’s increasingly important to flex with that change and it’s not unusual to have multiple skills. If the only constant is change, it’s important to make choices that can be changed as and when technology moves on.
12. Make new source code open
This has become a norm in the technology world and there are some interesting underlying reasons why this can be a good idea. Perhaps the most relevant to service design is that code is just the visible output that embodies the value, rather than being valuable in and of itself. The real value is the learning and understanding it encodes. This is why the advice to throw away an Alpha prototype works. Learning isn’t lost when code is decommissioned, because it’s “sketch” code that was used to study a few key concepts. It makes perfect sense to put the sketch aside when it comes to rendering a high-fidelity finished piece.
13. Use and contribute to open standards, common components and patterns
In the same way we might talk about a visual language or an experience language, technology also has a language. Systems around the world share common standards and patterns that enable them to be understood by people and by other systems than need to work with them. Building a common language makes everyone's life easier and enables us all to focus more on our unique work and value, rather than spending time on the mechanics of being able to connect and communicate.
14. Operate a reliable service
This is where bodies of work including Amazon Web Services Well Architected framework and Google’s Site Reliability Engineering approach to operations add real, practical value. Both organisations have iterated their way to running some of the largest and most reliable technology systems in existence and it shows in the real-world discipline and pragmatism of these frameworks. The world is a complex and unpredictable place so striving for perfection isn’t realistic. Planning for the inevitable and learning to react with swiftness, grace and learning means you continue to improve and grow, even as the world changes around you.
The big picture
The best, smartest and most impactful technology is the kind you never see. Brilliantly-integrated systems manage to stay out of sight, tucked just behind your experience as a user. Most of us never stop to think about undersea fibre cables, datacentres and cell towers when we unlock a smartphone and ask for directions — that’s a remarkable achievement.
To make things possible without taxing attention is a hallmark of good design. For me, technology is a thread that runs through the service standard. It can be a foundation, a canvas and perhaps even the paint, but it’s rarely if ever the picture. Flour makes bread, but flour isn’t bread.
Service design that fluently incorporates technology, without being distracted or overwhelmed by it, can go a long way to making meaningful change.
