A fixed product requirement and an open design question look very similar on paper, until you are two days into a debate you did not intend to start.
In my previous role, a single line in a requirement document turned a settled decision about a country code selector into a conversation about whether we were building the right thing at all. The line was: “if there is another option you are more confident in.”
I meant it as design latitude. The UX designer could choose how to approach the component. He read it as product latitude: was this approach the right solution? Both interpretations were reasonable. That was the problem.
The language of a brief quietly decides whether the other person treats it as a constraint or an invitation. Most scope debates do not start with disagreement. They start with ambiguity.
What happened
The requirement was straightforward: a country code selector for a phone number field, defaulting to the user’s likely country. The decision had been made deliberately. It was consistent with the rest of the interface and was not up for discussion.
But I wrote the requirement in a way that left a door open. The designer came back with an alternative approach, a reasonable one. The problem was that the requirement was not actually open. Relitigating it would cost time we did not have, and the decision was sound.
The conversation that followed was polite and eventually resolved. But it took longer than it needed to, and the energy spent on it came from a problem I had created with one clause at the end of a sentence.
Why this happens more than it should
Product Owners often soften requirements because they want to signal trust. You are not a dictator. You believe designers have sharper UX instincts than you do. So you leave room.
But room has to be defined. There is a meaningful difference between these three invitations:
- Here is the pattern we are using. Design execution is yours.
- Here is the outcome we need. How we get there is yours.
- We are still exploring options. What do you think?
Each is legitimate in the right context. The mistake is writing all three as if they are the same thing. When a requirement contains an open-ended phrase, the recipient has to guess which type of invitation it is. In my experience, they will almost always guess the most generous interpretation. That is not their mistake. It is yours.
The fix is structural, not interpersonal
After this conversation, I changed how I write requirements when the decision is fixed. Every brief now has two explicit sections.
Fixed: the requirement, stated plainly, with the reason it is fixed if it is not obvious. Consistency with an existing pattern. A prior decision that has already been debated. A regulatory constraint. A timeline that does not allow for redesign.
Yours: the genuine latitude. Design approach, interaction patterns, visual choices, anything where I do not have a strong preference and the designer’s judgment should lead.
This is not about being prescriptive. It is about being honest. If a decision is already made, saying so is a form of respect. It tells the other person where their energy is best spent. And if the decision is genuinely open, stating that clearly is also a form of respect, because it tells them their input will actually shape the outcome.
What this has to do with trust
A common objection is that separating fixed from open sounds controlling. The opposite is true.
A brief that clearly names what is fixed and what is yours tells the designer: I trust you with the things that belong to you. I am not going to ambiguate my decisions and then be surprised when you question them. The trust is in the clarity, not in the openness of every line.
Senior designers, the ones who do their best work, do not want to guess at requirements. They want to understand the constraint clearly so they can work well inside it. Ambiguous framing does not feel like freedom to them. It feels like a setup for a conversation they did not know they were being invited into.
Jeff Patton’s work on collaborative story writing makes a related point: the conversation around a story matters as much as the words in it. But the words set the frame for the conversation, and ambiguous framing produces ambiguous conversations every time.
A diagnostic you can use today
When you catch yourself softening a fixed requirement with a hedge, “unless you think…” or “open to another approach if…” treat that as a flag. It usually means one of two things.
Either you are not confident enough in the decision yourself, in which case the answer is to revisit it before writing the brief. Or you are writing a requirement that does not reflect your actual intent. Either way, the hedge is a symptom. The fix is to be clear about what you decided and why, before you write anything down.
Since making this change, I have had fewer “but I thought we were open to alternatives” conversations and more “understood, here is how I am approaching the design” ones. The work is the same. The friction is not.
TL;DR: Ambiguous language in a product brief does not create flexibility, it creates scope debt. Separate what is fixed from what is genuinely open, and state it explicitly in every brief. The phrase “unless you have a better idea” is either an invitation or a false door. Decide which before you write it.
Written by Delphine Ragazzi, Product Owner with 20 years in digital product, analytics, and CRO.
