Whether you design physical objects, digital experiences, or classroom curricula, your design is a contract with the users.
Well designed products of all stripes — videogames, classrooms, objects from the Internet of Things — all make a promise to the player/student/user: this product is usable, reliable, and trustworthy. However, there is not always a promise for ease of use — especially when, as with videogames and classrooms, learning is part of the designed experience. Instead, there’s a Design Contract between the designers and the users, that goes beyond usable, reliable, and trustworthy.
First, usable is a lesson learned by the U.S. videogame industry back in the 1980s — games were being shipped and sold that were fundamentally broken. So Nintendo developed the Seal of Approval, which promised that the game would actually start up and be playable — instead of the game version of a 404 message — and at least wouldn’t set your console on fire. (Which was, at the time, an unfortunately radical promise!) Because of this, Nintendo is still a major international player in the games business, unlike, you know, Atari.
Reliable was also a part of the Seal of Approval: Nintendo devoted time, money, and expertise to advising game development companies. They wanted to accomplish more than just ‘playable’ — they wanted their games to reliably be enjoyable, as part of the promise they made to their players to be delivering a game. And since game design is as much art as science, they made their experts available to companies designing for the Nintendo platform. Part of the expert advising no doubt focused on a key but understated component of good games: the importance of designing for productive (and playful) learning.
Learning is inextricably intertwined with trustworthy in videogames. Although people often associate ‘learning’ with the extremely limited context of formal education, learning is part-and-parcel of how we become someone else within novel game contexts. How else can I — a portly middle-aged academic — become Old Snake, Sackgirl (or both), and a threadbare wizard gardening and fishing on a relaxed island?
These possibilities exist only because each of these games teach — and I learn — how to be those widely disparate characters. This teaching and learning primarily occurs through failure paired with feedback, and requires trust from the player that when they fail, the game will include feedback on why they failed. There is nothing quite like arbitrary failure to ruin a learning experience, whether that’s a teacher taking off points for something unexpected or a game just randomly killing you off. This is where the Design Contract comes into play (pun intended).
I adapted and extended the Design Contract from Brousseau’s didactical contract. Brousseau is a French mathematics teacher and scholar who recognized the tendency of mathematics students to ask their teachers for an algorithm, and bemoaned the tendency of mathematics teachers to actually just give the algorithm. As a result, he developed the didactical contract, which essentially stated that teachers must design tasks in such a way that the student can learn using only their prior knowledge and the information included in the task. In turn, the student must use what they already know alongside the new information from the task, and the mathematical learning will emerge naturally from adapting what they already know to that new problem. In other words, as I wrote previously in my dissertation (pdf):
The student knows that the task was designed to elicit some new form of knowledge, but “she must also know that this knowledge is entirely justified by the internal logic of the situation and that she can construct it without appealing to didactical reasoning [e.g., asking the teacher for the algorithm]” (Brousseau, 1997, p. 30).
So the teacher and student here are promising to each play their own part in this contract: the teacher promises that the new problem is solvable, and the student promises to use the knowledge they already possess and dig deep into the problem in order to learn more.
With the broader Design Contract, the designer promises that the product is usable, reliable, and trustworthy— the very least of what we should expect from our products! — and that the product can be used with only whatever prior knowledge the user brings. That prior knowledge will be challenged with new problems and novel contexts, but the user has everything they need within themselves and within the product to accomplish their goals, whether playful or productive (or both). Slight modifications to the above quote gives us this:
The player knows that the game was designed to elicit some new form of action or knowledge, but ‘she must also know that this action or knowledge is entirely justified by the internal logic of the game and that she can play it without appealing to resources outside of the game.’
The designer, as one side of the Design Contract, doesn’t promise that playing the game, using the product, or learning in school will be easy — but only that playing, using, and learning will be achievable. The other side of the Design Contract — the player, user, or student — in turn must promise to honestly bring their prior knowledge and effort to that designed object. If the designer doesn’t follow through on their part of the Contract, there will be rage-quitting, frustration, and attempts to just get the algorithm. And if the user doesn’t follow through on their part of the Contract, they will make lesser known but prevalent versions of a user error: a lack of fun playing the game, blaming the product for their own inefficiencies, or trying to get a good grade while learning as little as possible.
As designers, we make a promise; as users, we also make a promise. The best games, products, or classes are the ones in which both sides of that promise adhere to the Design Contract: the designers develop an internally consistent experience that use failure and feedback to build upon the users’ prior knowledge; and the users bring a willingness to use and adapt that prior knowledge, alongside trust that the designers delivered on their part of the contract. Paying for a game, product, or class is but the first step — if we design it well, the players, users, or students may not have an easy time, but they will have a playful, productive, and learning-filled time.
This work is licensed under a CC BY-NC-SA 4.0 license. Attribution must include a link to this work.
This article builds upon my previous piece about failure and feedback — so if you want more details about how failure paired with feedback is important, read it here.
My plenary at the 2020 Human-Computer Interaction Symposium introduced the Design Contract — watch the video here. Particular thanks go to the folks who asked brilliant questions at the end, and made me think I should write more about this!
My primary research focus is on mathematical play in videogames. You can read some of my work on mathematical play in digital media or the importance of gesture in mathematics games, and how mathematical play connects to learning and design.