The Constraint Was The Curriculum

An essay on the benefits of designing friction into a service so that the capabilities of users increases as a result

Written For

Service Designers both in Government and in the private sector

The Constraint Was the Curriculum

As service designers, we’ve been trained to remove friction. Every click eliminated is progress. Every field removed is respect for the user’s time.

But some friction builds capability. And we’ve been removing it alongside the friction that just wastes time—without distinguishing between them.

The question isn’t “how do we make this easier?” It’s “what could someone become by doing this?”

I’ve been thinking about the ZX Spectrum.

Close up of a ZX Spectrum keyboard — The ZX Spectrum - where a generation learned to code by necessity

A generation of bedroom coders taught themselves to program on it—and went on to build Britain’s games industry. Tomb Raider, GTA, the studios that shaped how the world plays.

The obvious reading: we need more coding in schools.

But here’s what I think actually happened.

The ZX Spectrum didn’t teach programming. It made programming the only way to get value from an expensive purchase.

There were no apps. No content to consume. If you wanted games, you either bought them or typed them in from magazines. And when you typed them in, you hit errors. And when you fixed errors, you learned. And when you learned, you started modifying. And when you modified, you started creating.

Sir Clive Sinclair didn’t design a learning platform. He designed a cheap computer with nothing on it. The educational outcome was emergent—a side effect of scarcity, not intent.

The constraint was the curriculum.

Taiwan has a similar story, still running.

Since 1951, every business receipt in Taiwan has carried an 8-digit lottery number. Every two months, numbers are drawn on live television. Match all eight and you win the equivalent of £250,000. Match the last three and you get a few pounds.

The government didn’t design a tax compliance programme. They designed a game where demanding a receipt was the only way to play.

In year one, tax revenue increased 75%—without raising rates or intensifying audits. Seventy-four years later, the system still works. It’s been replicated in China, Brazil, Portugal, Slovakia.

They didn’t teach civic duty. They made civic duty the by-product of self-interest.

The uncomfortable truth is Britain has 2.8 million people out of work due to long-term sickness.

The Keep Britain Working review calls it “the greatest employment challenge for a generation.”

And yet all the evidence says the same thing: good work is good for health. Security, autonomy, purpose, progression—these aren’t perks. They’re protective. People in good work live longer and get sick less often.

So why are we getting sicker?

Because we’ve been systematically stripping work of the things that make it good.

Zero-hours uncertainty, algorithmic management, digital systems that treat humans as inputs. We removed the productive struggle and added the pointless kind.

I design services in government and we’ve spent years optimising for completion rates. Reducing clicks, eliminating form fields so that every friction point removed is progress.

But when we digitised Work Coach interactions—the sitting together, working through complexity, transferring tacit knowledge—we didn’t remove friction. We relocated it.

The claimant still struggles. They just struggle alone now, with a screen that can’t adapt, can’t explain the workaround, can’t spot the safeguarding concern. The transaction completes and yet the capability doesn’t transfer. The dependency remains.

We designed a treadmill.

The ZX Spectrum and the Taiwanese receipt lottery share something. Neither tried to teach the behaviour they needed. They created conditions where the behaviour emerged—because it was the only way to get something people actually wanted.

The Spectrum made coding the path to play. Taiwan made receipts the path to winning.

Both aligned self-interest with system benefit. Both generated capability as a by-product.

What would it look like to design services where the action that helps the user is also the action that builds their capability, also the action that generates the data the system needs?

Not compliance as burden. Compliance as by-product.

Not education bolted on. Learning as the only way through.

Next time you’re designing a service, try asking: What could someone become by doing this?

Not just complete. Become.

If the journey leaves people exactly where they started, just more tired—you haven’t designed a service.

You’ve designed a loading screen that never finishes.

What’s the last service you worked on where the friction was actually the feature?