Somewhere, in a department far, far away is a man whose hand I want to shake. I’ve never met him. He doesn’t even know I exist. But he has greatly contributed to my and my team ’s efficiency and effectiveness.
How? By writing things down. He made really good notes about what his team was designing and why. Crucially, he did this as if knowing that, one day, someone might read them so they could fix something. Or make something better. Which is what we do in service optimisation.
That sounds so easy. Yet so often we’re not covering the basics. We have brilliant people designing brilliant services, but the boring paperwork like minutes, summaries and write ups often don’t exist.
Which is a problem because they’re critical to understanding how and why a service was built.
Such paperwork would really help us in service optimisation. We take live services and iteratively improve them. We flounder without good notes, asking questions that have probably already been answered. We start to question the original design because we don’t know better.
Maybe there was a really good reason for these things when the service was built, but technology, the law or the user need has changed and it’s no longer relevant.
Sharing the know-how
Simply saving different iterations of prototypes isn’t enough. Each of those iterations represents a wealth of knowledge and understanding. Something seemingly small – a piece of guidance or an interaction – could represent hours, days or weeks of hard graft. That insight is gold dust.
Ideally, the team that built a service would maintain and improve it, but the reality is that people come and go. We should all assume that we’ll hand our services over at some point. And when we do, we need to give the next team the know-how it needs.
This stuff isn’t glitzy. You’ll never be able to stand up and speak at a conference about how awesome your minutes are. But that doesn’t mean your efforts aren’t appreciated. They are – I can vouch for that.
So thank you Jeremy Wyatt, secret keeper of notes and all-round helpful human. If we ever meet, make sure you claim that handshake.
Tips for a good handover
- Write down names and job titles of everyone involved in the build, from senior management to developers to contacts at GOV.UK.
- Keep a list of additional functionality or design changes you would have explored if you’d had the time.
- If you can, put together a map of the end to end journey. They’re great for quickly getting a bird’s-eye view of a service.
- If you do a heuristic review of an existing service, include screenshots of it at the time of review. Years down the line, without screenshots, it can be really tricky to work out what you were looking at.
- Save everything in one place, with a clear taxonomy and naming conventions.