Designing Usable and Accessible Games with Interaction Design Patterns

From Gamasutra by Eelke Folmer.

Traditionally best practices concerning interface/interaction design have been captured by means of guidelines or heuristics such as Nielsen’s heuristics or the W3C web content accessibility guidelines. The purpose of guidelines is to capture design knowledge into concise small rules, which can be used to inform interface and interaction design.

Attempts to capture design knowledge have been made with regard to game interaction design. Houser & Deloach present seven principles for effective game design. Melissa Federoff has looked at how existing usability heuristics such as proposed by Nielsen apply to games and a set of 42 game heuristics is proposed. These guidelines specifically focus on usability issues and are different from attempts to describe game play such as Noah Falsteins 400 project.

Problems with heuristics

Guidelines are useful for requirements specification but if we look at their usability as a design tool some shortcomings have been identified by Welie with regard to selection, validity and applicability:

• Guidelines often suggest a general absolute validity but in fact they can often only be applied in a specific context. For example Federoff specifies “The game should have an unexpected outcome” which makes sense and works for an adventure game but does not apply to arcade games such as pong.

• It is often unclear what the problem is the guideline actually tries to solve and why. Federoff specifies “Players should be able to save games in different states” but it does not explain what usability problem it addresses and why the proposed solution would work and how it can be implemented.

• Compacting design knowledge in small concise rules has the obvious problem that you end up with a lot of rules in order to describe everything. A large number of guidelines makes it hard for a game designer to select the right rules and worse the lack of context makes certain guidelines contradict with each other. For example, “The game should have an unexpected outcome” and “there should be a clear overriding goal of the game presented early” might possibly conflict.

Design tools should first and foremost be usable. We need to be able to tell the designer exactly when to apply the solution, how the solution works and why the solution works. A requirement specified as a feature such as “closed captions” is much easier understood and implemented by a developer than the abstract guideline “Provide a text equivalent for every non-text element” it embodies. The usability and accessibility problems that we have identified are contextual; I propose to use interaction design patterns for capturing design experience, as this offers a much richer description format and hence is more useful and usable as a design tool.