Present unfinished design work with a clear ask.

Open with the decision you need help making

Unfinished work is easier to discuss when the audience knows what kind of response will help. Start with the task, the current stage, and one decision you want to resolve. Explain what is deliberately unfinished and what is out of scope. You do not need to apologise for using rough screens; you do need to make their purpose clear. Visual polish should not be mistaken for implementation readiness.

Send a short agenda in advance when possible. Identify the people whose input is needed, such as someone responsible for content, service operations, or engineering constraints. Do not ask a broad audience to approve a solution when an unresolved policy question belongs to a specific owner. A focused review can end with a useful question instead of premature approval.

Label the status of both artifacts and claims

Put the date and status on the material itself so the context survives a forwarded link. Distinguish explored, selected for further work, tested in a stated context, and implemented. Do not mark an option “validated” merely because colleagues prefer it. Separate verified constraints, research evidence, working assumptions, and open questions. Use words as well as colour so the status labels remain understandable in print and for people who cannot distinguish the colours.

Use synthetic content in shared examples. Remove customer details, confidential roadmap information, and raw participant material before distributing the deck. An internal-looking prototype can still be publicly accessible through a sharing setting. Check permissions and share the smallest amount of information needed for the discussion.

Compare options on the same terms

Show the relevant task in each option at a similar level of detail. If one direction is polished and another is a sketch, people may react to finish rather than the decision. Name the benefit you expect, the cost or risk, and the uncertainty for each. Explain which constraints are real and which are assumptions. Keep unrelated screens available for questions rather than making everyone tour the entire file.

Facilitate feedback without defending every pixel

Walk through the task briefly, then restate the review question. Invite people to inspect the material before speaking so the first opinion does not determine the whole discussion. When a comment is vague, ask which part of the task it concerns and what difficulty the reviewer anticipates. Distinguish a preference from a constraint, a risk, or direct evidence. Capture disagreement without turning it into a contest over seniority.

If you do not know an answer, record the question and who can help resolve it. When feedback drifts outside the agreed scope, acknowledge it and place it in a separate list. Do not promise every suggestion will be implemented. A useful closing summary explains which decisions were made, which remain open, and why.

Share a decision record, not a claim of consensus

After the review, send a short record with the selected next step, its rationale, unresolved risks, and the responsible people. If there was no agreement, say so and name the evidence or authority needed to move forward. Link to a stable version rather than silently changing the artifact everyone reviewed. In asynchronous reviews, give a clear response window and explain how comments will be resolved.

Review feedback is evidence about the review discussion, not proof of user benefit or business impact. Keep that limitation visible when you later describe the project. An early design can be worth sharing even when research access or engineering feasibility is unresolved. The professional move is to make uncertainty manageable and visible, not to hide it behind a finished-looking presentation.