Applying UX skills to game design

Nathan Verrill of Natron Baxter Applied Gaming provides a wonderful in-depth
explanation of how he designed Signtific
Lab,
a game that facilitates prolific high-quality brainstorming around a
central question. While the project was wholly a game, Nathan’s
descriptions of the process steps and deliverables will sound very
familiar to any UX designer: mind maps, wireframes, design comps, user
testing, analytics, and so on. His background is in the design of
conventional user experiences, and those same core competencies lent
themselves well to the design of a successful game.

While they
currently reside in different industrial families, user experience
design and game design share a common parent in human-computer
interaction. To the extent they differ, there are opportunities for
cross-discipline learning. To the extent that they’re similar,
expertise and skills transfer well from one practice to another. My
own experiences applying UX skills to game design provide examples of
both.

I designed my first game in 2002, when Unisys started an
annual tradition of sending e-cards with embedded games to clients,
employees, and partners. Each year, the in-house Web team would design
and develop an original game, taking it from concept to delivery. Our
first idea was for a miniature golf game that fit in with the company’s
sponsorship of professional golf tournaments. While we were excited
about the opportunity, none of us had made video games before. So we
applied the same methods and skills that we used in the design of
websites, simply because they were the only ways we knew to approach
any design problem.

We started by conducting ethnographic
research at a miniature golf course. Now I realize that last sentence
reads like it’s meant to be facetious, but this was actually an
indispensable step in understanding what makes the real-life game
interesting, exciting, frustrating, funny, social, competitive, and
worthwhile. For example, we discovered that the courses were often
designed to tempt people who overestimate their own proficiency to
attempt difficult putts which, if missed, put the ball much farther
away from the hole. This in turn creates a social dynamic that can
reverse the fortunes of beginners who play it safe, and skilled golfers
who take greater risks.

From there I designed a short wireframe,available here as a PDF.
In some ways this was a traditional document, showing the
core functionality while saying very little about the game’s
appearance. But in other ways it was very different. The document
focused on small interactions, as we were developing every interface
element from the ground up instead of relying on ready made widgets
like those baked into Web browsers. These were presented as atomic
pieces that could be assembled to build a course, much like a pattern
library. I also experimented with ways to show motion over time, and
the effects of objects moving relative to one another.

The
finished game, which you can play here, had
its strengths and weaknesses. The visual presentation was fantastic
and the level design was really good (owing to the efforts of Todd
Horning and Mike Rosario), but it had some important usability and
learnability problems (precisely the things that I should have been on
top of). I think the core mistake was in describing the interface
elements as individual pieces without showing how they should be put
together. At the time, I reasoned that game design needed broad
creative latitude and that the traditional prescriptive wireframe would
have been too limiting. But it turned out that the way the pieces hang
together, as with a conventional user interface, is really critical the
experience of the game. For subsequent games in the holiday series my
documents actually started to look more and more like Web wireframes.

Do you have examples of games you’ve designed using conventional UX methods? If so, I’d love to hear from you!