Build a layout review rubric that reviewers can apply consistently

Two reviewers can examine the same office and disagree because they use different meanings of ready. One values complete furniture; another needs a route that a newcomer can explain. A review rubric makes those judgments comparable. It does not replace the product's controls or automatically approve a Kiguri map.

Define coverage from participant tasks

List the activities the proposed layout must support. For a workshop, choose arrival, gathering, presentation access, and departure. Give each activity at least one review row. Avoid letting twenty decorative observations outweigh an unchecked required route. Mark activities outside the review's scope explicitly so an approval of this workshop layout does not become a promise about every possible office use.

Give every row an evidence state

Use columns for task, expected result, observed result, evidence, and reviewer. Add a state: passed, failed, or not checked. For example, presentation access expects a participant to reach the intended usable object; the observation might show an unobstructed route while the interaction remains untested. Split that into separate rows. A screenshot supports appearance, while a performed action supports only the behavior actually observed.

Classify consequences before preferences

Agree on three categories: blocks a required activity, complicates it but has an acceptable alternative, or changes appearance without preventing use. A cabinet across the only approach can be a blocker. An uneven decorative border may be optional. Record the reason for each classification and an owner for unresolved work. Do not label everything critical merely to make a preferred visual change happen sooner.

Reconcile reviewer disagreement with evidence

Ask a second reviewer to apply the same rows independently. When judgments differ, compare the task, starting position, available access, and evidence rather than averaging the opinions. One may have used a different route or tested another seat. Repeat the disputed check under agreed conditions when practical. Preserve uncertainty if it cannot be resolved; a confident comment should not overwrite an explicitly unchecked result.

Write a bounded acceptance statement

Summarize covered tasks, remaining blockers, accepted alternatives, and untested conditions. Name who accepts the result and what changes would require another review. For example, accept the workshop arrival and departure routes while withholding a claim about group audio. Keep the rubric with the version context in an existing team record. Its value is a traceable decision that another reviewer can understand, rather than another generic instruction to walk around.