# Compare the directions and prepare the selected one

These are design deductions from the fictional ROOM-4 brief. No preference, comprehension, task completion, accessibility or conversion study was conducted. No rendered layout was inspected. Selection below is an editorial choice for the next design pass, not a user result or an instruction to implement now.

## Fixed versus variable

| Element | Fixed across A and B | Deliberate variation |
| --- | --- | --- |
| Person and task | Coordinator chooses a room for four people, then reviews | None |
| Day and hour | Sample day; 14:00–15:00 UTC; full hour; no flexibility | None |
| Equipment requirement | Whiteboard required; display optional | None |
| Candidate content | Same three rooms, capacities, availability, equipment, fit and actions | None |
| Order and filtering | Cedar, Birch, Elm; all three retained | None |
| State and next step | No selection; review before any booking | None |
| Typography, palette, action emphasis | Same declared stack, scale, colors and 40-unit action drawing height | Width follows the grouping |
| Wide information structure | All supplied fields visible | A aligns field columns; B groups a room's facts in a card |
| Narrow information structure | All supplied fields remain visible, order retained | A becomes separated labeled entries; B becomes a vertical card stack |
| Extra features or facts | No photos, prices, filters, scores or added inventory | None |

## Tradeoff reasoning

| Criterion | A: comparison list | B: room cards | What remains to learn |
| --- | --- | --- | --- |
| Information visibility | Same fields align in a wide row; fit/action follows the facts. | Each room is a complete unit; availability and fit are close to its own action. | Which facts real coordinators need first, and whether the grouping makes those facts findable. |
| Comparing rooms | A reader can compare the same field at shared x-coordinates on the wide composition. | A reader moves between card groups to compare a repeated field. | Actual reading paths, mistakes and effort; geometry alone does not measure them. |
| Ineligibility | Birch's hour and Elm's equipment sit beside their written exclusion reasons. | Each card contains the cause and the unavailable action locally. | Whether users understand the reasons and what they expect next. |
| Narrow arrangement | Column alignment is replaced by labeled, separated entries; the desktop advantage is reduced. | Bounded room groups remain bounded when stacked. | Rendered wrapping, text zoom, focus order and behavior on actual devices. |
| Growth in content | Additional fields may make the comparison list wider or taller. | Extra room-specific details have a local group but increase card length. | Whether extra details are needed at all; no photos or details were invented for the comparison. |
| Next-step clarity | Shared bottom explanation states that choice leads to review. | Same explanation plus a local action per card. | How selection, review, conflict and confirmation should work in a real interface. |

## Selected direction: A, provisionally

The given job is to compare three rooms on a short set of repeated fields. A exposes that relationship directly in its wide composition. Keep A for the next design pass while preserving B as an alternative. This choice does not mean lists are universally better, nor that anyone preferred A in a test. It is revisable if later requirements emphasize richer room-specific information or the narrow comparison is unsatisfactory.

## State and question sheet for the next pass

| State / open point | Known from this brief | Still to decide or draw |
| --- | --- | --- |
| Initial loaded | Three fixed candidates; none selected | Real data source and how freshness would be communicated |
| Cedar selected | Selection is intended to lead to review, without booking | Selected marker, review summary, back/change behavior; whether selection is retained across navigation |
| Birch unavailable | Cannot choose for this fixed hour | Explanation interaction, if any; do not silently suggest another time |
| Elm lacks whiteboard | Cannot choose under the fixed requirement | How to communicate missing equipment in accessible text and navigation |
| No eligible rooms | Not present in this supplied inventory | Empty state and an explicit way to change request if a future task allows it |
| Availability changes | No live system in this example | When to recheck, what happens if Cedar becomes unavailable, how to keep the user's request |
| Loading or data error | Not represented | Loading content, retry behavior, stale-data treatment |
| Review to booking | Review exists only as an intended next step | Required fields and any eventual confirmation flow; booking remains outside this exploration |
| Keyboard and assistive access | Text reasons supplied in static art | Actual semantics, focus indication, order, unavailable-action explanation and announcements |
| Narrow layout / text zoom | Separate 390-unit composition drawn | Render and inspect wrapping, zoom, scrolling and intermediate widths later |
| Longer names / different language | Not represented | Content limits, localization, time-zone presentation and wrapping rules |

## Complete next-pass design request

```text
Continue ROOM-4 using Direction A as a provisional layout choice.
Keep the full fixed content in room-selection-brief.md and the numbered map.
This choice came from the stated comparison task, not from user testing.

Prepare additional static views for:
1. Cedar selected with a review summary; no booking made.
2. Cedar no longer available at review, preserving the original request.
3. Loading, data error and no-eligible-room states, clearly labeled as new
   states to specify rather than changes to the initial three-room data.

Propose the missing selection, back/change and unavailable-reason behavior.
Keep policy choices explicit where the brief has no answer. Describe planned
keyboard order, focus treatment and text expansion for the narrow layout.
Do not implement a booking flow or invent tested preferences.
```

This request deliberately asks for the next design pass. Implementation should follow a sufficiently specified chosen design and the actual project's scope, rather than treating either static original as a finished application.