
Context + role
Project: The Hursley Escape Room
Role: Project Manager, Designer, and Puzzle Creator
Timeline: 2018 – now
Team: Interation 1: 3 grads, iteration 2: A transient team of 6-8 interns and 4 experienced IBMers, iteration 3: 5-7 experienced IBMers.
Contribution: Team leading, usability testing, logistics & procurement, facilitation
The TOOCAN Escape Room is a physical escape room experience I conceived, designed, built, and continue to run at Hursley House — IBM’s historic manor house headquarters in Winchester, UK. The room serves two audiences: internal teams using it as a team-building exercise, and external clients attending events at the house. It is entirely self-funded, built on borrowed equipment, and staffed by volunteers.
My role covers everything end-to-end: concept and narrative, brand identity, puzzle design, physical environment design, team coordination, playtesting, facilitation, and ongoing iteration. The project has run across three distinct versions since 2018, each one a significant rebuild. A fourth is in early planning. No AI was involved in any version to date — the project predates the current generation of AI tools — though I plan to bring AI into future puzzles both as a showcase of IBM technology and as a design aid.

The problem
Build a fun, team-based activity that could fit into a busy workday. Under 30 minutes. Accessible to people who have never done an escape room. Reliable enough to run for clients.
The real design challenge was harder: how do you make a collection of independent puzzles feel like a single coherent experience — not just a sequence of locks to open?
In V1, I built a set of puzzles with no connecting narrative, and they worked as individual challenges but not as a room. Players finished feeling like they’d completed tasks, not solved a mystery.
V2 introduced the narrative of a hacker investigation but the puzzles still felt loosely stitched to the story rather than essential to it.
By V3 I had a clearer principle: the narrative should be the reason the puzzles exist, not decoration applied over them. Every puzzle needed a reason to be in this room, in this story, at this moment. That required designing the concept and the puzzle logic together, rather than layering one onto the other after the fact.
Research + discovery
Accessing external users proved difficult. The product team viewed the work as an early-stage incubator and initially quesMy primary research method was watching people play and being honest about what I saw.
In V3, we ran playtesting for months before opening, and teams kept failing to complete the room. I adjusted puzzles repeatedly — simplifying clues, shortening steps — but the failure rate barely moved. From inside the project, it felt like we had reached the floor of what we could simplify without removing the challenge entirely. Escape rooms depend on a specific kind of satisfaction: the dopamine hit of solving something genuinely difficult. Strip too much away and you strip that out too.
Then I noticed something that changed my perception. Every test team we had used to that point was assembled from people who had never worked together before. I had been treating team composition as irrelevant. But escape rooms are fundamentally collaborative, and collaboration is much harder with strangers.
As a last attempt before opening, I sourced a test group whose members already knew each other. Their completion rate was significantly higher, and their puzzle-solving felt more fluid and less hesitant.
I decided that was enough evidence to open the room and iterate in live conditions rather than continue testing with unrepresentative groups. It was a gamble but it paid off. With real teams who were colleagues, client groups, people with existing working relationships, our success rate climbed steadily toward the 60% target I had set.
The other major research input was doing escape rooms myself. When the transparency puzzle hit a design dead-end, I played two commercial rooms to understand better what completion felt like. While I had experienced escape rooms before, it became apparent that in order for users to feel satisfied, a clear unambiguous moment of resolution for every puzzle was required. That observation directly shaped how I redesigned the puzzles.



Design process + decisions
1. Turning resource constraints into narrative logic
V3 had no budget and no guaranteed space. That meant sourcing whatever equipment we could find – a mixture of current technology and decade-old hardware that had been sitting in storage. My initial instinct was to try to make everything feel consistent and modern but it proved too challenging with the budget restraints.
So I reversed the approach. Instead of fighting the visual and technical inconsistency of our equipment, I built a narrative that made it the point.
TOOCAN – the Temporal Overseers of Chronologically Anomalous Nuances – is a time-keeping organisation whose puzzles span different eras. Old hardware sits next to new hardware because the puzzles were created by different generations of the group. The time-warp premise gave us license to use whatever we could source, and the four-era branding gave each puzzle a distinct identity that signalled which era it belonged to.
2. Reliability as a design requirement
V2 was riddled with challenges due to network dependency. Our puzzles routed through a public cloud server; the room was in a basement with thick concrete walls in an old manor house and the site team had no business reason to invest money to improve signal there. Puzzles failed mid-session, and we were never able to officially open before the pandemic ended the project.
I set a single non-negotiable constraint for V3 at the very first design session: every puzzle must work without a reliable network connection. This ruled out a class of puzzle designs immediately – anything that relied on a live server, a remote database, or a cloud-hosted response was off the table. The only internet dependency we retained in V3 was posting final scores to a leaderboard, which is non-critical if it fails. It was a deliberate trade-off: we gave up some technical ambition in exchange for a room that actually worked.












3. The transparency puzzle
In V3, I designed the transparency puzzle to be the most physical and spatial puzzle in the room – something that made players move around and engage with the environment. The original design used an old overhead projector: players would find transparencies hidden around the room, overlay them correctly on the OHP, and read a number from the projected image.
Unfortunately the OHP I had sourced required a part too old to find anywhere. With user testing approaching, I tested whether players could simply read the overlaid transparencies without projection. They could, technically. But a tester told me the result felt unclear and unsatisfying. It seems obvious but that comment led me to understand that players wer looking for a specific catharsis at that moment of resolution – a clean signal that they have succeeded.
Fortunately, I was able to find a lightbox which could work as an alternative to the OHP. Users really only needed the light to recognise the pattern in the overlayed design. And to make it fit into the environment, I designed and printed book covers with a running TOOCAN visual identity to hide the transparencies on the library shelves, giving players a reason to explore the space.
This puzzle became the most reliably completed in the room.
Craft + final design
In the V3 experience, players enter the Library at Hursley House, a two-storey, wood-panelled room with floor-to-ceiling bookshelves, period furniture, and genuine character.
The experience starts when the team enters their name into the password verification terminal. Dr Canopy — our narrator, voiced with deliberate comic pomposity — introduces the premise via video: TOOCAN has accidentally pushed a code change that threatens to break time itself. A chrono reset button is locked in the TOOCAN safe. Players have 30 minutes to find four override codes from puzzles left by four different eras of the organisation, enter them into the terminal in the correct order, receive the safe combination, and hit reset.


The four TOOCAN eras each have a distinct logo — designed in the visual style of their period, from a WWII-era emblem through to a contemporary mark. These logos appear on puzzle components and act as a navigation system: players can tell at a glance which pieces belong together. This solved a real usability problem we observed in early testing, where players were connecting the wrong components across puzzles.
Three intentional choices define the final experience. First, every puzzle has a clear completion signal – no puzzle resolves ambiguously. Second, the room has a facilitated hint system: up to three hints per team, delivered by a facilitator watching the session, calibrated to where the team is in the room rather than scripted in advance. Third, the entire room is transportable and can be set up and struck down around events – a constraint that shaped every physical element of the design.
Outcome
Across all three versions, roughly 50 teams (200–300 people) have played the room. V3 is live and running, with sessions facilitated regularly.
The team dynamics finding translated directly into outcomes: as we moved from ad hoc test groups to real cohesive teams, our success rate climbed. The 60% solve target I set at the start of V3 design is now consistently met. The transparency puzzle is reliably the puzzle teams complete most confidently.
The honest reflection: the months we spent in testing limbo before opening cost us momentum, and that had a lasting effect on some team members’ commitment to the project. Momentum is a resource, and I underestimated how quickly it depletes when progress stalls. I have applied that lesson directly to V4 planning – bringing in new team members early, before the energy drops, rather than trying to re-engage people who have already drifted.
What I learnt
The biggest shift across three versions was learning to treat constraints as design inputs rather than obstacles. No budget, patchy network, borrowed equipment, a room that had to disappear for events – none of those were solved by finding more resources. They were solved by changing what the design needed to be. That is a principle I now apply before reaching for more time, more money, or more people.
Reviews

Escape room user
“Amazingly fun and well thought out. Thank you to all the organisers. +1 for doing more in the future! :D”

Escape room user
“I was part of a team that attempted the Hursley Escape Room earlier today…
It was a lot of fun and well thought out – if you’ve not signed up – I really recommend it (I think it’s definitely a room that bigger teams will do well at so bring lots of friends).
Thank you to our host and everyone involved in the creation of the room!”