Adjacency Matrix

Ask a user group who they need to be near and everyone says everyone. The matrix only becomes useful when the question changes from preference to movement: what travels between these two rooms, how often, and what happens if it has to go further.

Workflow

Step 1. Take the list and the movements

Ask, in one message:

1. The room list. If space-program is running, point at it rather than retyping.
2. For the building as a whole: who moves through it, and are there flows that must not cross? Public and staff, clean and dirty, secure and open, goods and people.
3. Which rooms have a fixed position already: an entrance, a loading dock, a plant space, an existing core?
4. Are there separations required by code, licensing, security or acoustics? Name what requires each.
5. Who is available to answer questions about the operation, and have they been asked yet?

If the room list is long, ask which rooms are worth pairing. A matrix of eighty rooms has three thousand cells and almost all of them are empty.

Step 2. Fix the vocabulary before filling any cell

Agree the relationship kinds first, and use no others:

Mark	Means	Test for it
Required	Must be adjacent, and something fails if not	What fails? Name it
Desired	Better if adjacent	Better for whom, and by how much?
Neutral	No relationship
Separate	Should not be adjacent	Why not?
Prohibited	Must not be adjacent	What prohibits it? Quote it

The difference between required and desired is the whole value of the matrix, and it collapses the moment a cell is filled without a reason. Every required and every prohibited carries a reason in the same cell or it is downgraded.

Step 3. Fill by movement, one row at a time

For each pair, ask what actually travels between them and how often. Not "should these be close". A relationship with no traffic behind it is desired at best.

Fill by row rather than by scanning the whole grid. A room at a time, with the person who uses that room, produces answers that a group session does not.

Record the source of each answer: which user, which department, which document. When two user groups disagree about the same pair, record both and mark the cell disputed rather than averaging them.

Step 4. Read the matrix back

The reading is the point, and it is what a bubble diagram cannot do:

• Over-demanded rooms. Count the required marks per room. Any room with many is a room that cannot be where everything needs it. Name them; these usually turn out to be reception, a lift core, a store, or a staff base, and the answer is usually to duplicate or to relocate the demand rather than the room.
• Direct conflicts. Any pair that is required to one group and separate to another. List them individually; they are decisions, not errors.
• Chains. A required to B, B required to C, C separate from A. These cannot all hold and the matrix is where they are visible.
• Clusters. Groups of rooms with dense internal requirements and few external ones. These are the building's departments whether the brief named them or not.
• Orphans. Rooms with no relationships at all. Either they were not asked about, or they can go anywhere, and those are very different findings.

Step 5. Report

The matrix, then the five readings, then:

• Every cell filled without a reason, counted.
• Every disputed cell, with both positions and who holds each.
• Every prohibited whose source was not quoted.
• What has not been asked yet, and of whom.

Close by saying that the matrix is an input and that no plan follows from it automatically.

Step 6. Save, if asked

Ask whether to write the matrix to a file and where. Markdown or CSV.

Rules

• Never fill a cell from a building-type convention.
• Every required and prohibited carries a reason, or it is downgraded.
• Ask what travels, never whether they should be close.
• Record who said each thing. Disputes stay disputed, never averaged.
• Report over-demanded rooms and conflicts, every run.
• Never produce a layout.

Anti-patterns

• Filling the matrix from what is usual for the building type.
• Treating a user group's preference as a requirement because they stated it firmly.
• Averaging two departments' disagreement into one mark.
• Marking everything required, which produces a matrix with no information in it.
• Producing a bubble diagram and calling the analysis done.
• Duplicating space-program's room list instead of reading it.
• Presenting a plan as following from the matrix.

Resources

None. This skill is one file. Output is written directly at the path you choose.