What is a Pattern?

A pattern is a three part rule describing a relationship between a context, a problem and a (recurring) solution. Patterns have their origins in architecture but became very popular as a tool to describe problems in object oriented design. Since then a pattern community has emerged specifying patterns for different domains. Here we use patterns to describe interaction design solutions to usability and accessibility problems. To describe our patterns we use the following format:

Problem: usability / accessibility problems experienced while playing a game.

Context: specific situations or types of games in which the problem typically occurs.

Forces: within the context a number of forces act which must be resolved.

Solution: a proven solution which resolves the forces.

Why: a reasonable argumentation for the specified impact on aspects of usability when the pattern is applied.

Examples: examples of games that have this patterns successfully implemented.

Why would we want to use it?

We think patterns are a more usable and richer format for capturing design experience. Traditionally best practices concerning interface design have een captures by means of guidelines or heuristics such as Nielsen's heuristics. The purpose of guidelines is to capture design knowledge into concise small rules. The problems with guidelines are:

There are too many: which makes it hard to select the right rule for your system

Some guidelines conflict: because they are numerous they often conflict with eachother leading to confusion among developers

Lack of context: guidelines assume an absolute validity but can often only applied in very specific contexts, sometimes you see a guideline accompanied by a little rule explaining the context, we essentially we have a pattern!

Guidelines because of their conciseness do not tell a designer, what problem the guideline addresses and why it works

Are they better than guidelines?

Our patterns are harvested from real games. Because all patterns use the same format for describing the solutions it is easy to understand them. Patterns and guidelines do not exclude eachother, whereas guidelines are useful as requirements (breadth) patterns describe several rules into a very specific context (depth). It is good to connect patterns to guidelines allowing a designer to select particular solutions from a catalog of patterns that may fulfill these requirements.