The requirements trap: Why user needs cannot be captured in documents

By Adewole Ampitan

A Business Requirements Document (BRD) often feels like a map. It tells you what to build, how it should function, and what stakeholders expect to see. In the UI/UX design ecosystem, there is a dangerous comfort in this well-defined list of requirements.

In 2019, I joined Cyberspace as a UX Designer full of ideas. I was working on Cyberpay applications and the Cyberlyte product suite, a payment tool for businesses across Nigeria. At the time, I held a quiet but firm belief that if we documented everything perfectly, we would build products that actually worked. I thought clarity in requirements, thorough stakeholder feedback, and tightly secured sign-offs would guarantee success. It took me years to realise how wrong I was.

What I could not see then was this: user needs cannot be captured in documents. They do not fully reveal themselves in specifications or stakeholder meetings. You cannot compress them into templates and call it understanding. Real needs show up in lived experience. You have to get out there, watch the people’s struggle, notice the tiny frustrations they do not bother mentioning, and feel the friction yourself. That is the only way to really understand what users need
The moment a project shifts from solving a real problem to simply fulfilling documented requirements, we fall into what I now call the requirements trap. And in that moment, we stop designing experiences. We start decorating decisions that may hold little value for the people we claim to serve.

The Fiction of the Complete Specification

Every designer has encountered the insistence on “all requirements upfront,” with project managers creating exhaustive documents that attempt to anticipate every edge case, every user interaction, and every system behaviour. Organisations celebrate these “comprehensive specifications” as markers of professionalism and rigour.
But the whole approach is built on a lie.

The lie is the assumption that you can sit in a room, far from where real people live and work, write down everything they will ever need, and hand that document over like a blueprint as if human behaviour follows a spec and context does not matter. I watched this play out over and over early in my career at Cyberspace. A requirements document would circulate for weeks. People would comment, revise, and sign off. By the time development started and users finally got their hands on the system, their behaviour revealed things no document had predicted.

I remember a usability evaluation for a payment flow we had spent months documenting. Every requirement was met. Every stakeholder had signed off. On paper, it was perfect. But when the product reached the end users, they abandoned the flow in droves. Nothing was broken. But the terminology confused them. The confirmation messages felt untrusted by them. They just would not complete the transactions we had so carefully enabled.

What stayed with me was this: the system worked exactly as we specified. And it failed exactly as users experienced it.
Both were true at the same time.

What Requirements Cannot Capture

My experience working on over 200 projects has shown me what requirements documents simply cannot do.
-Emotion: No document can hold the anxiety of a user sending money they cannot afford to lose. No specification captures the frustration of someone who has tried three times and still cannot figure out why the system keeps rejecting their input.
-Context: The person in a Lagos market with a cracked phone screen and patchy network is not the user described in any requirements document. Her distractions, her workarounds, her whispered confirmations with neighbours, none of this appears in specifications.

-Workarounds: Users are endlessly creative. They find paths through systems that no designer ever imagined. Requirements documents assume straight lines. Users live in loops, detours, and improvised paths. They do not follow the map we draw. They make their own.

-Trust: This is the one you cannot write down. I think of it as a confidence gap – the space between a transaction succeeding on paper and a user actually believing it worked. You cannot specify that gap. It only reveals itself when real people use real systems in moments that matter.

-Understanding: Requirements documents tell you what the system should do. They tell you nothing about what users should understand. And a system that works but remains unclear has still failed, even if it checks every box in the spec.

I once led an open market initiative in Lagos while working on a product at Interswitch Group. We wanted to see how merchants actually worked. One user shared her phone with two other women selling nearby. She checked transactions with neighbours before trusting them. She built her own mental model of digital payments from years of handling cash.
None of this existed in any document we had written.
The requirements trap had convinced us we understood our users. The market showed us we did not.

The Alternative: Experiential Design

After encountering the requirements trap, I began to work differently when I joined DOT as the Founding UI/UX Designer. My earlier experiences shaped that shift.

While building an agency banking platform and microfinance application from scratch, we made a deliberate decision not to rely solely on requirements documents as our primary design tool. Instead, we immersed ourselves in the environments where our users actually lived and worked.

That decision changed everything.

Through direct observation and constant questioning, we stopped segmenting users based on assumptions and started grouping them based on what we actually saw them do.

We built to learn. Every prototype became a question, not an answer. We put things in front of people not to check boxes, but to discover what boxes should exist in the first place. Each interaction revealed something we could never have written down in advance.

We also designed for the conditions we observed. Low connectivity was not an edge case, it was reality. So, we built offline capabilities, even though no stakeholder had asked for them. The need was not documented. It was visible in the way people kept glancing at their phones, waiting for a signal that might not come.

We iterated constantly. No formal usability labs. No controlled environments. We simply watched, noticed the small workarounds people created, adapted, and kept moving and the system grew alongside the people using it.
In the end, we built an agency banking and microfinance application that reached thousands of users who had previously been excluded. Not because our requirements were better, but because we stopped letting requirements lead.

How to Adopt a Requirement-Trap-Free Product Design

Escaping the requirements trap does not mean abandoning structure. It means rethinking what role documentation should play in the design process.

First, treat requirements as hypotheses, not truths. A requirement should not signal certainty; it should invite validation. The question is no longer, “Have we captured everything?” but “What are we still missing?”

Second, move closer to reality. Insight does not come from documents. It comes from proximity. Spend time where your users are. Watch what they do, not just what they say.

Third, design for learning, not completion. Too many teams focus on finishing products. The better approach is to keep understanding users as the product evolves. Prototypes and iterations should help you discover, not just deliver.

Fourth, pay attention to behaviour over instruction. What users do will always reveal more than what they say. Requirements are built on statements. Good design is built on signals.

Finally, accept that no product is ever fully specified. The moment you believe you have captured everything is the moment you stop paying attention. And once attention is gone, understanding follows.