The Bit That Never Makes It Into the Brief

The Bit That Never Makes It Into the Brief

Designing software from a brief alone is a bit like planning a kitchen from the floor plan. The measurements are right, the layout looks sensible, and on paper, everything seems to be where it should be. Then someone starts using it every day and realises the fridge door opens the wrong way, the bin is miles from the prep space, and the kettle somehow has nowhere to live.

The plan wasn’t useless. It just couldn’t show what the room would feel like once real people started moving around in it, and software briefs can run into exactly the same thing. They’re very good at describing what needs to be built, but not always as good at capturing how that thing will actually be used in the middle of a working day.

That doesn’t make a brief any less important, and we’re not arguing against writing a good one. The challenge is that the most useful details often sit just outside it, in the habits, exceptions, and small judgment calls that keep the work moving without anyone ever thinking to write them down.

The bit the brief doesn’t show

Take a report that needs to be generated, reviewed and sent. The person doing it might need to check one figure against another source, adjust something by hand, or wait on a sign-off that’s never been formally documented because everyone involved just knows it happens. The brief describes the output. The working day tells you everything that has to happen before anyone actually trusts it.

The same thing comes up in websites, applications and platforms. A patient-facing website can sound fairly contained until medical review, accessibility requirements, internal governance and ABPI considerations start shaping what actually needs to be built. An e-commerce platform can look simple in the early document and become much more involved once fulfilment rules, stock exceptions and customer service handovers are properly understood.

That’s why we like spending time with the people closest to the work and asking what happens on a normal Tuesday. Where does something slow down? What gets checked twice? What already works and should be left alone? Those questions explain why something can be delivered on time, signed off and still leave the team keeping a tracker on the side or quietly saying “it works, but…” That is usually where the real work begins.

Starting with the problem, not the feature list

Mechanical Orchard, drawing on IDC research, notes that worldwide investment in digital transformation between 2022 and 2024 was expected to reach $6.3 trillion, with Boston Consulting Group research suggesting around 70% of those projects fail. As McKinsey has pointed out, the gap tends to open up when technology decisions drift away from the people actually doing the work, and it’s a pattern we recognise well.

Starting with the business problem rather than the feature list changes what gets built. What’s taking too long? What are people doing outside the system because it doesn’t quite support the work? Sometimes the answer isn’t to rebuild everything. Sometimes it’s a clearer workflow, a better way of managing content, or one small change that removes a surprising amount of unnecessary effort.

The brief still has a job

A good brief gives a project structure and keeps everyone moving in the same direction, which is exactly why we love a clear one. It just works best when it’s treated as the start of the thinking rather than the end of it, because the strongest projects bring together the clarity of the brief and the working knowledge of the people who’ll actually use what gets built. That might be an internal team managing reports, a healthcare professional looking for the right information, a patient using a website, or a customer trying to complete an order without getting stuck.

A brief tells you what someone asked for. The business tells you what actually needs to work. Good software needs both.