I’ve had this rattling around my Figmas for about 6 years and used it with just about everyone I’ve worked with since. It’s a small technique that can have outsized results. I wish I had a less macho name for it but this is what’s stuck in my head and I can’t get rid of it.
User: “I want a thing done”
System “Here’s a button that does the thing”
User: [presses button]
System: “The thing is now done”
This is the ‘extreme’ of design a service, as far as you can go.* It’s silly thought experiment, but also truth and a very real goal to strive for. If you could make everything work like this why wouldn’t you?
Now come the excuses 😉
But really really why can’t your service work that well? Are you sure it can’t? But what if it could? Why can’t you fix the things that are blocking it? What would it take for you to make the experience that simply?
Keep asking “why not?” like a 4 year old on a Haribo fix. What services need joining up, what data needs to be available, what contracts need changing, what silos need busting? Good digital can do amazing things.
Invert the frame
I often reference Jon Kolko’s post about the “simplicity on the other side of complexity“. His point it that you get to simple design by doing the hard work of working through the complexity of the problem. This is how design works.
But using ‘extreme’ service design is a cheat code for getting to the simplicity. You just start with simplicity. Work still needs to be done, but maybe less. Instead of trying to solve complex design challenges first work on making them go away. If you can it feels like magic. The hardest part is often helping others understand it isn’t.
We can’t always work actual magic (however much we want to)
There are things that can’t be fixed, can’t be imagined away. These are usually structural complexities outside of the scope of the current implementation.
One example might be regulations that legally require people to do certain things. I once worked on a global banking service transformation and there was one – technically automatable – step that in China required wet signatures with three witnesses and CCTV recording. Not much can be done about that. More recently in my work with Thread, we limited by regulations around drone use. We have have the technology and data to allow a fully automated ‘one click’ inspections using drones-in-a-box. But (quite reasobably) flight regulations demand that a qualified pilot with a remote flying waiver supervises the drone while it’s flying. We can imagine the service without this step but we can’t implement it.
Another example might be data stuck in legacy platforms that don’t have APIs. For now that means there may need to be a manual step in the process to check data or join things up.
Recognising these as structural complexities that prevent simplicity – rather than truths to be accepted – makes it easier to imagine fixes and improvements that tend the service back towards one-click simplicity. Maybe RPAs or AI agents can be used to patch the problem – maybe it won’t be straight-though-realtime-digital but it can get closer. If a person does have to be involved how do we create tools and experiences that simplifies their work and increases reliability to it approaches semi-automated
Treasure rough diamonds; don’t polish turds
Mindset. Culture. Team motivation. Delivering product takes more than a design team – or design technique – and how we frame and approach design problems sets the tone for everyone involved.
Bottom-up service iteration is often achored in yesterday’s problems, yesterday’s bad decisions, yesterday’s technology. Stockholm syndrome to 10,000 inherited cuts.
Vision-first service design anchors thinking in the best it could possibly be. It might not be a perfectly finished brilliant-cut flawless diamond at first, but everyone can see it can and will be.
Organisations, teams, and customers are more inspired, more creative, more innovative, and more motivated when they understand they are polishing rough diamonds than when they believe they are polishing turds.
Studied naivity
I’ve spoken about it as a ‘silly thought experiment’ or being childlike. It’s both and neither. As a designer working this way you need deep domain knowledge of the problems, complexities, conventions, and politics that will prevent simplicity, and the technologies and user needs and behaviours that will enable it. If you don’t you’re just fantasising. But you also need to be able set that aside and imagine ‘impossible’ new realities. A state of mind I think of as studied naivity – deep expertise with childlike wonder and playfulness. Naivety is a tool if you sharpen it.
But what do customers want?
Yeah, that’s the catch. You need to know with some confidence. You can’t shortcut being user-centred, you need to have done your research and know your users.
Using ‘extreme’ service design thinking effectively is powerful partly because you get others to buy into an exciting vision. If this vision is based on poor understanding of users you’ll build something the risk of delivering something bad is amplified. And the chances are you’ll waste effort and break trust with your team.
Give it a go
Let me know how if it’s helpful.
* I said at the top that this ‘one click and it happens’ model of service design is as far as we can go. That’s not quite true. It’s possible to be more extreme. It’s possible to anticipate a users needs and do it for them. But this removes agency from our users, and I’m not sure that removing agency ever leads to good service design.