What designing a user interface shares with creating a puzzle

At various points in my adult life, I’ve taken up the challenge of creating puzzles for other people to solve, generally in the context of fairly elaborate treasure hunts created for friends or my children. A relative of mine recently observed the contrast between designing such puzzles and creating user interfaces. I’d never really considered how these activities are similar; ultimately they’re both examples of experience design. The interesting thing to me is that they both involve careful consideration of progressive disclosure — in one case hard-won, while in the other case, it should be effortless.

User interface designers often concerned themselves with what they call the initial user experience: the sequence of actions they expect a new user to take in, say, the first ten minutes of using a product. Similarly, a puzzle designer gives careful consideration to the alternating sequence of bafflement and insights they hope the solver will experience. Both design tasks require consideration of the audience’s abilities and especially motivation, which in turn establishes a timeframe.

Take, for example, a simple puzzle I created for Hope2Die, the 1996 installation of The Game in Seattle. Treasure hunts for The Game entail something like 18-20 puzzles over 24 hours, including driving time between locations, and the time required to solve the puzzle. This leaves about 15-45 minutes for actual puzzle solving time. The audience is a set of 10-20 teams, which are highly motivated by the desire to outperform their peers. They have free access to technological tools, including the Internet, in solving a puzzle.

In this case, game teams found the following card (in a burned-out building, I believe, although that’s not relevant to solving the puzzle):

The hope2die text on the card is simply a logo. Likewise the “PW” is just an indicator that the clue will produce a password to unlock the next clue — in that day and age, on a CD-ROM each team had received. The title and body text constitute the puzzle.

The experience I’m looking for goes something like this:

1. First reading. Bafflement.
2. Attempts to interpret the clue as simply as possible. (Here, trying to make sense of the text as English words.) A tiny bit of frustration, but reader was expecting — or desiring — it, so this really leads to satisfaction.
3. The search of patterns. Confidence, crumbling to frustration.
4. Opening the set of possible interpretations. New but dwindling hope with each, wilder, idea.
5. Catching hold of something that seems significant; identification of a hypothesis. Faint hope.
6. Initial testing of the hypothesis (applying it to a few cases; here, words). Anxiety about whether this will work, turning to excitement as each result doesn’t disqualify the hypothesis.
7. First intelligible results. Complete elation.
8. Complete application of the confirmed theory. Satisfaction.
9. In many cases, the puzzle has more than one layer, in which case this process repeats.

Some nice parts of this puzzle: The word “BeAm” here turned out to coincidentally reference the next clue. The password obtained by solving the puzzle produced the surprisingly short and vague instruction to simply “Go to Redmond” (Washington). This didn’t seem to be nearly enough specific information to get teams to the next clue. It was early evening as the teams approached the town of Redmond — where they saw green lasers shooting into the sky from the location of the next clue. The password itself was also fun to select, being the longest interesting one I could construct given the puzzle’s mechanics, and one consistent with the over-the-top tone of the game show theme in this particular Game.

The real challenge in designing a puzzle like this is trying to get everyone through it in somewhere between 15 and 45 minutes. It’s easy to make something that looks like a puzzle but is, in fact, trivial. It’s also not that hard to make a puzzle that’s impossible — that requires either time-consuming brute force, or some completely wild conceptual leap for which the puzzle offers insubstantial support. The puzzle needs to resist easy solution, then yield upon sustained effort. Some individuals will see the solution to the above puzzle instantly; others will need a full-team effort for the full time.

Over and over again, I keep asking myself: Is this puzzle going to be fun to solve? I’m just a dilettante puzzle designer, so in a case like The Game, I feel satisfied if the puzzle simply keeps hyped-up teams in the flow of the event. This felt like the right puzzle for the right place in the treasure hunt. In the end, it was part of a sustained sequence of about 5 hours’ worth of puzzles and activities that were, by all accounts, interesting, and for many the highlight of the game.

Designing a puzzle requires controlling that progression of understanding so that it unfolds at just the right pace to produce the intended experience. Designing a user interface is the same: the user’s understanding needs to unfold at just the right pace to produce the intended experience. Unlike a puzzle, a UI needs to look simple, interesting, and useful at the very first glance. In the next few minutes, it needs to show the user everything they think they might want to do, while still not overwhelming them. And then it needs to tuck a bunch of rarely-used stuff away somewhere where the user won’t even notice it until the day, maybe months later, when they suddenly need it and think to look for it. The emotional experience needs to balance the sense of potential power and possible mastery with delight and instant accomplishment.

Pulling that off, of course, can be quite a puzzle.

[If you’ve found the solution to the puzzle, feel free to offer it, or perhaps a hint, as a comment.]