Finding a space was
only half the problem.

The original coursework produced interviews, root-cause analysis, a conceptual model and a journey map. The early synthesis did discuss exit, largely through lanes, queues and the gate. The problem was not a missing stage; it was an incomplete interpretation.

A return to the source documents found accounts of reversing with another vehicle behind, difficulty seeing a bay boundary while parking, and vehicle damage. These are related concerns, but not every account is an exit incident. The boundary-visibility example should not be relabelled to fit a sharper story.

The research also described shop-specific restrictions and uncertainty about permission in unfamiliar places. An empty space might still be unavailable to that driver.

The proposed results distinguish open, conditional and restricted parking, with the condition stated in words. Restricted places remain visible but cannot be booked. That could explain why a nearby space is not an option; it could also add clutter. Its usefulness needs testing.

The relevant condition appears at review and arrival as well. Each repetition serves a different task: choosing, checking the commitment and communicating with staff. A digital pass cannot itself grant permission; the service still depends on accurate rules and an operator who recognises them.

Two representations explored the same bay choice. Direction A uses an abstract grid with explicit attributes. Direction B adds the entrance, lanes, wall and pillar so the driver can inspect the physical reason behind a distinction.

Drawing the plan forced a question about B1. It sits at the end of a row, but a pillar constrains it. Being an end bay was not enough to justify calling it easy to leave. That was a design-development observation, not a usability finding.

The current prototype offers both representations. If drivers choose for the same correct reasons in either, the simpler grid may be sufficient. If the distinction is misread as price, availability or an accessible bay, the encoding needs revision before adding more detail.

If a selected bay becomes unavailable, the proposed recovery looks for another available bay with the easy-exit attribute. The system should preserve why the driver chose it, rather than restarting the task without context.

The web model returns no suitable replacement when that attribute is unavailable. It must not invent a match or silently substitute a standard bay. Real inventory and reservation handling would need an authoritative service; this walkthrough simulates the conflict.

A driver blocked by another vehicle needs an actionable next step. The proposed flow attaches the location to a report for the operator. The operator side explains who would receive the issue and what they would need to act.

That makes the dependency visible: staff must be reachable, know enough about occupancy and have a practical response. The prototype’s reported state is not a promise that a vehicle has moved or that help will arrive within a particular time.

The proposed entry-and-exit condition record explores whether a comparison could help with uncertainty about damage. The source accounts support investigating the problem; they do not establish that drivers want this exact feature or that it settles responsibility.

The test protocol was revised before any sessions ran. Entry capture was inserted into the participant’s path instead of being narrated by the moderator. Otherwise, the exit task would ask them to rely on a record they had never created.

The work has produced a clearer problem framing, alternative bay representations, original priority screens and an interactive simulation. These demonstrate design and implementation, not customer effectiveness.

The existing test plan targets bay comprehension, pass legibility, discovery of blocked-in help and use of condition comparison. Its scripts have been reconciled to remove inconsistent geography, mismatched permission scenarios and narration that would prime the comparison task.

No sessions have run. Driver testing also cannot validate staff operations, so operator interviews and a real-lot walkthrough remain separate requirements. Failures should change the design and become part of the case, rather than being explained away.