I once joined a project in Discovery where the development team had already built the solution.

Not a prototype. THE SOLUTION.

There was just one slight problem:

We didn’t really know enough about the problem yet.

This was a service that could contact someone unexpectedly and tell them the service might not have the right details. On the face of it, that sounds relatively harmless.

Unless that person happens to be waiting for a potentially life-changing result, then suddenly the context in which that message lands matters enormously.

So we stopped.

I drew out the service and got everyone around a wall of Post-its with a very simple question:

What do we actually know?

Which, unsurprisingly, uncovered an awful lot of:

We don’t know.

We didn’t fully understand all the circumstances in which the message could be received, and we hadn’t connected everything with the other teams involved.

We needed to explore safety and policy requirements around contacting people. There was support to think about.

There was even a wider communications problem. If we wanted people to take more ownership of keeping their information correct, this wasn’t just a screen. It could involve GP surgeries, radio, TV and other similar services.

So we slowed down for about two weeks, not to faff around with a design process but to fact-find.

Our researchers spoke to people. Service design mapped what happened around the screens. Content explored how we communicated something potentially sensitive. We challenged what we thought we knew.

And we discovered another team already had part of the answer; removing duplication is part of the solution, right? Rather than building another standalone thing, we could make keeping your details correct a natural part of an existing service, with another route for people who couldn’t use it.

The stakeholder had been worried that stopping would mean missing the deadline.

We didn’t.

If anything, understanding the problem properly helped us move faster afterwards.

There’s always pressure to start building. We know this game, developers need work, delivery wants momentum, stakeholders have dates, and consultancies have commercials.

But something reaching into someone’s hand or home without warning deserves care.

If we design from our own assumptions, it’s incredibly easy to end up saying:

“Well, it works for us.”

And “us” might just be a room full of people who already understand the subject matter.

That’s not good enough.

Take the time to care. The race isn’t the deliverable. The race is making it right and, more importantly, making it safe.

That’s proper design stuff.