| Website | https://www.simonwhatley.co.uk |
| https://www.linkedin.com/in/simonwhatley/ |
When the same problem returns despite different people and different solutions, the structure is producing it.
Not the people. The structure.
Change the structure. Change the results.
What structure is your system organised around?
Data is a service design issue.
When users can't see what data a service holds about them, they can't correct errors. When data is shared between agencies without warning, users are caught off guard. When records persist long after a relationship ends, the data outlives its usefulness.
These aren't just compliance questions. They're about trust, and what kind of relationship a service has with the people it serves.
A public good is non-excludable (you can't stop people using it) and non-rivalrous (one person using it doesn't reduce it for others).
Street lighting. Disease surveillance. Navigation charts.
The market under-provides these. That's the original reason government exists: to provide what markets won't.
Relationships matter as much as components.
A system isn't defined only by its parts. It's defined by how those parts interact. Two organisations with the same people, the same tools, and the same processes can produce completely different outcomes if the relationships between those elements differ.
Change the relationships. Change the system.
What relationship in your work would you change first?
Plain language isn't dumbing down. It's respecting the reader.
When someone uses a service, they're usually anxious, distracted, or in a hurry. Clear, direct language helps them move through without stopping to decode what you mean.
"You must notify us within 14 days" does the same job as "It is incumbent upon the applicant to ensure notification is provided to the relevant authority within a 14-day period", except one of them actually gets read.
"We think we contributed, but we're not certain."
That's not a weak evaluation. That's an honest one.
The rigorous version of claiming impact has three checks: would it have happened anyway? Who did you measure? What else changed at the same time?
The most valuable thing about drawing a systems map isn't the map itself.
It's the conversation it starts.
Different people draw it differently, and the differences show you where your understanding of the system breaks down. That's where to look.
What problem would benefit from mapping?
The policy says one thing. The service delivers another.
Not because teams are bad at their jobs, because policy and delivery are designed separately, often by different people, in different buildings, at different times.
Bringing them together is one of the most underrated skills in service design.
Vanity metrics feel good. They're easy to increase, hard to interpret, and rarely connected to whether the service is working.
The test for any metric: what decision would be different if this number went up?
If the answer is nothing, it might be a vanity metric.
Safe-to-fail experiments: the change you can run without betting everything on it.
If it works, expand it. If it doesn't, you learned something cheaply and can adjust.
The goal isn't to prove you're right. It's to find out.
What could you test in the next two weeks?