You must start designing and the requirements are genuinely unclear. What do you do?

What is being tested

Whether you can make progress without either freezing or committing prematurely.

The moves, in order

1. Separate what is unknown from what is undecided. Unknown facts can be researched. Undecided positions need a decision-maker. Knowing which you face determines whether to investigate or to go and ask someone.

2. Do the work that is independent of the answer. In almost every ambiguous situation a substantial part of the design does not depend on the open question. Doing it produces progress and frequently clarifies the question, because concrete work exposes what actually matters.

3. State assumptions explicitly and proceed. "We are assuming a peak of 5,000 concurrent users; if it is 50,000 the design changes in these ways."

This is better than waiting, and it frequently prompts the answer — stakeholders correct a stated assumption far more readily than they answer an open question.

4. Design for a range, not a point. If the number might be 10x or 100x, ensure the design works at 10x and can be extended at 100x, rather than optimising for a figure nobody knows.

5. Keep the one-way doors closed while ambiguity persists; make the two-way ones freely.

6. Force the decision where it genuinely blocks. Present two or three options with consequences and ask for a choice. Stakeholders decide far more readily between options than in the abstract, and an open question rarely resolves itself.

What to avoid

• Waiting for clarity that will not arrive.
• Guessing silently, so the assumption is invisible and unchallenged until it is wrong.
• Designing for every possibility, which produces a system optimised for nothing.
• Escalating every ambiguity, which teaches the organisation you cannot operate without direction.

What makes it acceptable to others

Be explicit about what is assumed, what is decided and what remains open. A design document with a clear open questions section and stated assumptions is more credible than one that appears certain — and concealed uncertainty is discovered later at greater cost.

The framing

Ambiguity is the normal condition of architecture, not an exception to be resolved before work begins. The skill is not eliminating it but deciding well despite it.