Hey, what’s interface design? it’s the discipline of designing interfaces. Shocking. Marvelous. Hilarious. I should be in the pictures. But let’s keep going since that doesn’t clean everything up.
Interface design refers to the discipline not of designing an object to achieve an end but to design it so that the surface people interact with (the interface) is something that means they can make it achieve that end. It’s something covered extensively in thousands of online tutorials but also in that pesky Donald Norman’s The Design Of Everyday Things, a book which I fear I will be a chore about to people who listen.
Consider, if you will, a teakettle. This is an object that most Americans aren’t directly acquainted with but the basic device is a pot, with a handle, and a lid, that you can fill with water, plug into a mains power source, then turn on. It will boil the water, let you know when it’s boiled, and stop boiling the water once it’s got there. This device’s design can incorporate all sorts of clever systems; before mains power was used, it was a common design feature that the boiling steam escaping the pot would go through a whistled seam on the kettle, meaning the whole thing made a noise when it was boiling that would persist until you stopped it, which is pretty neat. Similarly, while once they were just metal things you put on a gas or electric stove, now they have dedicated docks and power to those docks, which includes things like fuses and transformers and anti-fire measures and internal cable structures so there’s no wrong way to plug them in and none of that
is interface design.
The majority of the kettle is not a design that you are meant to interface with. In a big top down broad sense, you interact with a kettle because you need a kettle but the kettle itself is not the interface. You only engage with the kettle on its expected interface, which is why it has an insulated handle designed to be easily picked up, and why the button for turning on the element isn’t physically inside the kettle, near where that element goes. Instead the design of a kettle’s interface – the bits you’re meant to deal with – is meant to make sure that you touch as little of the bits that make your hot water as possible. The interface directs your intention towards action without impeding it, and without obscuring what is happening. A gauge for the water level is an entire system meant to keep you from having to open the kettle and look at the (maybe hot) water, but it’s also trying to give you entirely correct information about what is or isn’t inside the kettle. A gauge that gives you incorrect information is, instead of encouraging you to avoid a part of the kettle you shouldn’t mess with (the insides), is encouraging you to engage with it.
In this, the design of the interface of the kettle wants you to engage with it, in the way it should be operated, but also very much not engage with bits of it. This is fundamentally part of interface design and the design of everyday things: The interface is something to engage with so that you do not have to engage with everything else. The problem comes when the design is bad, the interface is bad, the door is labelled wrong or the handle of it teaches you to use it incorrectly.
And that’s where we get to games, because games are pretty much entirely an interface.
This isn’t talking about videogames, of course; a videogame has a display and buttons you can push as your interface, but that interface is layered over a number of systems that are designed to absolutely not inform you what they’re doing. You don’t need to know when your processor is handling memory dumps or garbage collection and indeed, when the computer behaviour starts to be present in the place of the player behaviour, you sort of consider that a failure state of the game’s making. No, here, we’re talking not about glitched out computer systems, but rather the games managed and maintained in a tabletop or board game space.
These analogue games are almost entirely an interface. There’s a process, a system, but the games aren’t feeding that information into a black box that’s designed to process them and keep the non-interface parts of the game away from the players. There’s some things that can be outside of a player’s reach — the information on a face-down card is hard to access, an object can live within a dice tower until it’s forced out, a number can be in potentia until a dice generates it — but the game, usually, is not making systems and objects perform actions where the player cannot see them.
Now part of this is simplicity! It’s not common for board games to have complicated pieces that can do that kind of invisible system management. App-driven games, obviously, immediately change that, where the entire operation of a phone or tablet becomes part of the game’s systems, and those want to be kept well away from the player. But that’s including a complex entity, and you’re getting something for that. Without that kind of inclusion, board games, typically, operate by a system maintained in the mind of the players, and the components, the interface, are there for managing that in their memory. Moving cards and tokens around is the interface of the game, and that interface interacts with a system inside the player’s heads.
Okay so what does that mean?
First it means that any principle of interface design can probably be extrapolated out to game design.
- What is this doing, why is it doing it?
- Is it clear how these pieces interact?
- If a person does something here, does that create meaningful feedback?
- What information do we want the meaningful feedback to have?
- How can we design this interface to impede behaviour we don’t want?
And most importantly:
- How can we make sure this game doesn’t look like a fucking iPhone?