If you’ve ever joined a project in progress, you probably know the feeling: you sit down on day one and get access to all of the project management tools, including hundreds of pages of “requirements.” Every screen is mapped, every workflow described, but hardly even considering edge cases.
At first glance, it feels like a gift. So much context, so much detail. But as you start reading, something feels off. The language, the assumptions, and even the tone feel like they belong to a different time. The documents describe how things should work, but they never explain why.
It doesn’t take long to realize these weren’t written for this project at all. They’re remnants from an earlier version of the product; a previous attempt that stalled, or failed, or pivoted. They were built around early limitations and untested ideas. And now, months or even years later, those same documents are quietly shaping what your team believes to be “the plan.”
The truth is, these kinds of inherited requirements can be more dangerous than having none at all.
The Illusion of Completeness
The more detailed a requirement document looks, the more legitimate it feels. Teams mistake documentation for alignment. Project managers can build schedules around it. Engineers can make estimates. Stakeholders can point to progress. Everyone feels safer when there’s a long list of things to build.
But completeness isn’t the same as clarity.
When requirements are written around features instead of intent, they may describe what to build, but not what problem it’s supposed to solve. You can have a thousand lines of “how,” yet still have no idea “why.”
Designers inherit those documents and assume the thinking has already been done. But those pages don’t represent clarity; they represent a snapshot of incomplete understanding frozen in time. Every line item carries assumptions about users, business priorities, technology constraints… that might no longer be true.
In many ways, old documentation is a mirror of the organization that wrote it. It reflects its confidence, its fears, its compromises, and its blind spots.
Why Old Thinking Persists
If the artifacts are outdated, why not just start fresh? Because old thinking offers comfort.
It provides the illusion of progress—a roadmap that feels familiar and safe. There’s a seductive certainty in believing, “Someone already figured this out.”
But those documents were often written when the product vision wasn’t fully formed, or when the team didn’t yet understand its users deeply. Many of them were shaped by constraints that no longer exist, whether they are legacy systems, resource shortages, internal politics, or early guesses about how users behaved.
Over time, those early choices solidified into “requirements.” And when new teams inherit them, they rarely know which parts were strategic and which were just tactical improvisations. They assume all of it carries equal weight, and in doing so, they rebuild yesterday’s thinking with today’s tools.
That’s how misalignment hides in plain sight—inside perfectly organized documentation.
Rediscovering Intent
When I’m brought into a project like this, I don’t treat the existing documentation as sacred. I treat it as evidence.
Every requirement is a breadcrumb pointing back to an earlier moment in the product’s story. Someone wrote it for a reason, even if that reason no longer applies.
So instead of asking, “How do we build this?”, I ask, “What outcome was this trying to achieve?”
-
What behavior was this requirement hoping to encourage or simplify?
-
What assumption about the user’s world is hidden inside it?
-
And does that assumption still hold true today?
Often, these questions reveal gaps. The requirement may still be valid, but its purpose has drifted. Or worse, the purpose was never clearly defined in the first place.
Rediscovering that intent is the real work. Because if a requirement isn’t anchored to a clear outcome, it becomes impossible to know whether the goal has actually been met. You can deliver a feature perfectly and still fail the experience entirely.
Design isn’t about making requirements real—it’s about making sure the requirements are right.
When Features Replace Experiences
Feature-level requirements are seductive because they’re concrete. They describe things we can see and measure: buttons, flows, dashboards, exports. But when each one is written in isolation, the product becomes a collection of parts rather than a cohesive experience.
Every feature may make sense on its own, but together they are forming an incoherent system that checks all the boxes and still feels broken.
That’s what happens when intent disappears from the process. The team builds toward completeness rather than connection.
As a senior designer, your job is often to step back and ask:
-
What experience are we actually trying to create?
-
How does each of these requirements support that experience?
-
Are we solving the same problem in three different ways because no one’s looking at the whole picture?
Mapping requirements against user goals can be incredibly revealing. Suddenly you see which features ladder up to meaningful outcomes, and which ones are artifacts of old habits.
The Politics of Rewriting
Of course, challenging old documentation isn’t just a design exercise; it’s an exercise in politics and diplomacy.
People invested real effort into writing those requirements. They defended them in meetings. They justified budgets and headcount with them. When you question them, it can feel like you’re questioning them.
That’s where empathy matters. The goal isn’t to dismiss the past; it’s to update its context.
I’ve found language like this helps:
“This made perfect sense for where the product was back then — but we’ve learned a lot since.”
“This requirement still makes sense, but maybe its purpose has evolved. Let’s restate what success looks like today.”
By reframing, you move the conversation from critique to evolution. You make it safe for others to admit that what once felt right might not fit anymore. And that psychological safety is what allows teams to unlearn outdated assumptions together.
Rewriting as a Design Skill
Over time, I’ve come to believe that rewriting requirements is one of the most underrated design skills there is.
Rewriting forces clarity. It exposes what’s missing. It reconnects execution to intent.
And it’s a deeply creative act. Not only because it produces visuals, but because it reshapes understanding.
When you rewrite, you translate static documentation into shared meaning. You elevate design from decoration to direction.
This is especially true now, as AI tools accelerate production and documentation alike. Generative tools can help teams move faster, but they can’t tell you whether you’re moving in the right direction. That still requires human discernment—someone who can look at a beautifully detailed spec and say, “This is solving the wrong problem.”
That’s design leadership in its purest form: not just making things usable, but making sure the work itself is useful.
Remembering the “Why”
So the next time you inherit a thick binder of requirements—or a perfectly organized Confluence space full of them—resist the urge to celebrate how “ready” the project seems.
Start by asking, Why does this exist? What intent was this trying to serve? And does that intent still matter today?
Clarity doesn’t come from how much is documented. It comes from how deeply the team understands its purpose.
The job of a senior designer isn’t to accept the brief; it’s to realign it with reality.
Because sometimes the most important work you’ll do on a product isn’t designing something new; it’s helping everyone remember what they were really trying to accomplish in the first place.
That’s the heart of good design: not decoration, not execution, but meaning.
And meaning always starts with intent.