Shared Space Reservation Systems

Reservation systems tend to be designed around the act of booking—selecting a time, submitting a form, receiving a confirmation. What they rarely account for is the messier reality of how people actually make decisions: under time pressure, with incomplete information, coordinating with others, relying on assumptions when the system fails them.

The gap we were investigating: these systems assume users will trust and read what's presented. In practice, users route around systems they don't trust — checking Discord and Reddit to confirm amenities, wandering until they find their room, or simply assuming the first floor is quieter than the second.

Our research questions:

• Why do users make reservations for shared spaces, and in what context?
• What do users value—and what problems do they consistently encounter?
• How can reservation systems be designed to put users first?

This was a team of three graduate HCI researchers. I contributed to every phase: interview protocol design, interview facilitation, survey instrument design and deployment via Prolific, independent thematic analysis, cross-team synthesis, and academic writing.

The analysis process was deliberate: each researcher coded the interview quotes independently, then we converged on a shared synthesis through discussion. That separation was a conscious methodological choice to reduce bias before convergence—the themes we landed on had to survive independent scrutiny from three people before they made it into the findings.

Our interview participants were recruited via convenience sampling (N=6), all from North America, while our Prolific survey participants (N=16) were recruited internationally with no geographic restriction. The two pools don't map onto each other cleanly, and some of the divergences between interview and survey findings reflect that mismatch as much as anything else.

Interviews

We conducted six semi-structured interviews, each 30-60 minutes. Four were remote via Zoom; two were in person. Each interview had a second researcher present to observe and take notes. After each session, the team met to discuss and synthesize what we'd heard before moving to the next interview.

The protocol focused on decision contexts, not just system features—we wanted to understand when and why people make the choices they do, not just a list of things they clicked. That framing surfaced things a feature audit would have missed entirely: the therapist who needed sound-insulated walls and dimmable lighting; the team that had to split a six-hour reservation into two back-to-back three-hour blocks because of an arbitrary policy limit; the participant who checked whether their reservation still existed multiple times in the week leading up to it because the system had erased it once before.

Survey

With interview findings in hand, we designed a 14-question survey and deployed it via Prolific. Four pilot participants helped us catch instrument problems before the main run. The final survey (N=16) covered reservation frequency, how spaces were found, confidence in amenities, group size, and lead time.

The survey established baseline patterns at broader scale—62.5% of reservations are made less than a week in advance, and 81.25% are for multiple people. It also surfaced a tension with the interview data: interviews skewed heavily toward work and school use cases, while the survey found that 50% of reservations were for personal or leisure activities. That divergence is partly a sampling artifact, but it's also a real signal that reservation system designers may be underserving a significant use case.

Analysis

201 key quotes were extracted from interview transcripts. Each researcher analyzed these independently on a Miro board, then we converged through structured discussion—resolving disagreements, refining theme boundaries, and cutting anything that didn't hold up across multiple researchers' independent reads. This yielded seven themes.

The finding that held up most consistently across both methods: users had largely stopped trusting system-provided information as a reliable source of truth. Participants described checking Discord and Reddit to confirm amenities. They described wandering until they found their room. One participant described assuming the first floor of a building was quieter than upper floors—not because the system told them that, but because the system told them nothing useful about noise at all. Another arrived to find that the trash cans listed on the reservation page weren't actually there.

"I was looking for something that was in a quieter space. So I just assumed the first floor is quieter than the second and third. So I planned for the first floor."—P2

"Usually when people come to the desk, they've gotten to that point that they can't figure it out on their own, or there's a time crunch. Giving them a sheet of paper and telling them to go figure it out isn't very helpful. And they probably won't figure it out. And we'll just be frustrated."—P1, library employee

This isn't a feature gap—it's a trust gap. When systems consistently fail to provide accurate, useful information about spaces, users build parallel information-gathering strategies. Design that doesn't account for this will keep producing systems users route around.

A second finding held up just as consistently: users are acutely aware that they're using a shared resource, and they want systems to support that awareness—not just for their own sake but for other users'. People described reserving more time than they needed out of scarcity anxiety. They described the awkwardness of asking someone to leave their reserved space when there was no visible signage confirming the reservation. They described cleaning up after previous occupants before they could use a space. The social dimension of shared space is mostly invisible to the systems that manage it.

The most useful methodological lesson from this project was about what you lose when you skip full qualitative coding. We analyzed key quotes rather than doing a complete coding pass—a reasonable scope decision for a two-month graduate course project, but one that meant our themes were built on a curated subset of the data rather than the full transcript corpus. The findings are directional and grounded, but a complete coding pass would have given us more confidence in what we were leaving out.

The sampling mismatch between interview and survey participants is the other thing I'd address if revisiting this. The divergence between "mostly work/school" in interviews and "50% personal/leisure" in the survey is interesting—but we can't cleanly interpret it because the populations are so different. A more carefully matched design would have made that comparison more meaningful.

What this project reinforced: information design is not a secondary concern in interface design. The single most consistent failure mode we found wasn't a broken workflow—it was a system that couldn't be trusted to tell users what they needed to know. That's a design failure with real consequences for user stress, equity, and time.