Pain points are not the same as opportunities. Every pain point implies that something could be better. But not all of them are worth fixing, or fixable. Here are four questions to separate the pain points worth solving from the ones that are symptoms of something deeper.

I've opened a paid course on applying systems thinking in practice. 8 weeks. Real work, not just theory. Here's what it is. #SystemsThinking #DesignThinking

When policy says one thing and the service does another, users pay the price. This gap is one of the most common and least discussed failure modes in service design. Here is how it opens up, and what to do about it.

Your service has users. It also has actors. Users are the people trying to get something done. Actors are the people who make the service work, often without users ever seeing them. Understanding both is one of the most underrated skills in service design.

"If we build this, that will happen." That is not a theory of change. That is a guess. A theory of change is a testable model of how your service creates the outcome it promises. Here is what the difference looks like.

Service design in practice is now open. An eight-week, email-delivered course for practitioners who design complex services and want a structured, end-to-end approach. Here is what it is and who it is for.

Something to read under the shade of a tree... Bad Services by @loudowne.bsky.social 💚 #BadServices #ServiceDesign

Most services don't meaningfully improve after launch. Here's what separates the ones that do. 🧵

Seven things systems thinking changes about how you work. Not tools. Habits.

Know the business. Ten concepts. Ten days. Five minutes a day. A thread on what we covered, and why each one was chosen.

Experimentation in public services is genuinely complicated. You can't A/B test a benefits application the same way you'd test an e-commerce checkout. A thread on what responsible experimentation looks like. 🧵

Worldviews are invisible until they conflict. When two teams reach completely different conclusions from the same situation, they're not failing to communicate. They're operating from different mental models.

Vendor lock-in: when the cost of switching exceeds the benefit of a better option. You're not trapped by a contract. You're trapped by the decisions made before the contract was signed.

Measuring whether a service is working is harder than measuring whether it's running. A thread on what performance measurement looks like when it's actually useful. 🧵

Ashby's Law of Requisite Variety: a system needs as many possible responses as the variety of situations it faces. In plain English: if your service has one standard response, it will fail every situation that doesn't fit the standard.

Make, buy, or partner. Every technology or capability decision comes down to one of these three. Most organisations have a default. It's usually wrong.

Risk assessment is usually treated as a governance activity. A form to fill in. A sign-off to get. It could be so much more useful as a design practice. A thread. 🧵

Tipping points are obvious in hindsight. In the data, beforehand, they're almost invisible. But they're not completely invisible. Here's what to look for:

Cost-benefit analysis tells you whether the total benefits exceed the total costs. It doesn't tell you who bears the cost and who gets the benefit. That second question is often where the real decision lies.

Data sharing between public services can dramatically improve user experience, or seriously harm it. A thread on what service designers need to understand about data. 🧵

A vicious cycle is a reinforcing loop running in the wrong direction. The harder you push against it, the faster it spins. Here's how to spot one before it accelerates:

What makes a public service valuable? Not revenue. Not user satisfaction scores alone. Whether it makes people better off in a way the market wouldn't provide. That's welfare economics in one sentence. A thread on how to use it.

Interaction patterns reduce cognitive load, but only if they match what users already expect. A thread on how patterns work and where they fail. 🧵

Optimising the part can harm the whole. This is one of the most reliable ways to create problems in organisations. And it's baked into how most performance management works.

"The data shows it works." Sometimes it does. Often it shows something changed at the same time as what we did. That's different. A thread on thinking more carefully about cause and effect, without a statistics degree.

Policy as architecture: how eligibility criteria shape interactions, and what happens when they can't be delivered as written. 🧵

Mapping a system alone is useful. Mapping it with others reveals more than you could find on your own. Here's how to run a 30-minute group mapping session:

Outputs: what you produce. Outcomes: what changes as a result. These are not the same. But most teams measure outputs and call them outcomes. A thread on why that matters, and how to fix it.

Service blueprinting in practice: not a diagram for its own sake, but a tool for finding where the service breaks. Here's how to use it. 🧵

Not all parts of a system are equally changeable. Some changes make little difference no matter how hard you push. Others are small moves with large effects. Those are leverage points.