Notes on play, exploration, challenge and learning

(My read­ing notes are pil­ing up so here’s an attempt to clear out at least a few of them.)

Part of the play expe­ri­ence of many dig­i­tal games is fig­ur­ing out how the damn thing works in the first place. In Rules of Play on page 210:

[…] as the play­er plays with FLUID, inter­ac­tion and obser­va­tion reveals the under­ly­ing prin­ci­ples of the sys­tem. In this case the hid­den infor­ma­tion grad­u­al­ly revealed through play is the rules of the sim­u­la­tion itself. Part of the play of FLUID is the dis­cov­ery of the game rules as infor­ma­tion.”

(Sad­ly, I could not find a link to the game men­tioned.)

I did not give Don­ald Nor­man all the cred­it he was due in my ear­li­er post. He doesn’t have a blind spot for games. Quite the con­trary. For instance, he explains how to make sys­tems eas­i­er to learn and points to games in the process. On page 183 of The Design of Every­day Things:

One impor­tant method of mak­ing sys­tems eas­i­er to learn and to use is to make them explorable, to encour­age the user to exper­i­ment and learn the pos­si­bil­i­ties through active explo­ration.”

The way to do this is through direct manip­u­la­tion, writes Nor­man. He also reminds us that it’s not nec­es­sary to make any sys­tem explorable.1 But (on page 184):

[…] if the job is crit­i­cal, nov­el, or ill-spec­i­fied, or if you do not yet know exact­ly what is to be done, then you need direct, first-per­son inter­ac­tion.”

So much writ­ten after DOET seems to have added lit­tle to the con­ver­sa­tion. I’m sur­prised how use­ful this clas­sic still is.

I’m remind­ed of a sec­tion of Matt Jones’s Inter­ac­tion 08 talk—which I watched yes­ter­day. He went through a num­ber of infor­ma­tion visu­al­i­sa­tions and said he’d like to add more stuff like that into Dopplr, to allow peo­ple to play with their data. He even com­pared this act of play to Will Wright’s con­cept of pos­si­bil­i­ty space.2 He also briefly men­tioned that eas­i­ly acces­si­ble tools for cre­at­ing infor­ma­tion visu­al­i­sa­tions might become a valu­able tool for design­ers work­ing with com­plex sets of data.

Nor­man actu­al­ly points to games for inspi­ra­tion, by the way. On page 184 just before the pre­vi­ous quote:

Some com­put­er sys­tems offer direct manip­u­la­tion, first-per­son inter­ac­tions, good exam­ples being the dri­ving, fly­ing, and sports games that are com­mon­place in arcades and on home machines. In these games, the feel­ing of direct con­trol over the actions is an essen­tial part of the task.”

And so on.

One of the most use­ful parts of Dan Saffer’s book on inter­ac­tion design is where he explains the dif­fer­ences between cus­tomi­sa­tion, per­son­al­i­sa­tion, adap­ta­tion and hack­ing. He notes that an adap­tive sys­tem can be designed to induce flow—balancing chal­lenge with the skill of the user. In games, there is some­thing called dynam­ic dif­fi­cul­ty adjust­ment (DDA) which has very sim­i­lar aims.

Salen and Zim­mer­man have their doubts about DDA though. In Rules of Play on page 223 they write:

Play­ing a game becomes less like learn­ing an expres­sive lan­guage and more like being the sole audi­ence mem­ber for a par­tic­i­pa­to­ry, impro­vi­sa­tion­al per­for­mance, where the per­form­ers adjust their actions to how you inter­act with them. Are you then play­ing the game, or is it play­ing you?”

Per­haps, but it all depends on what DDA actu­al­ly adjusts. The tech­nique might be objec­tion­able in a game (where a large part of the point is over­com­ing chal­lenge) but in oth­er sys­tems many of these objec­tions do not apply.

With a suc­cess­ful adap­tive design, the prod­uct fits the user’s life and envi­ron­ment as though it were cus­tom made.”

(Design­ing for Inter­ac­tion, page 162.)

Adap­tive sys­tems explic­it­ly antic­i­pate trans­for­ma­tive play. They allow them­selves to be changed through a person’s inter­ac­tions with it.3

A char­ac­ter­is­tic of good inter­ac­tion design is play­ful­ness, writes Mr. Saf­fer in his book on page 67:

Through seri­ous play, we seek out new prod­ucts, ser­vices and fea­tures and then try them to see how they work. How many times have you pushed a but­ton just to see what it did?”

The fun­ny thing is, the con­di­tions for play accord­ing to Saf­fer are very sim­i­lar to some of the basic guide­lines Nor­man offers: Make users feel com­fort­able, reduce the chance for errors and if errors do occur, make sure the con­se­quences are small—by allow­ing users to undo, for instance.

Mr. Nor­man writes that in games “design­ers delib­er­ate­ly flout the laws of under­stand­abil­i­ty and usabil­i­ty” (p.205). Although even in games: “[the] rules [of usabil­i­ty] must be applied intel­li­gent­ly, for ease of use or dif­fi­cul­ty of use” (p.208).

By now, it should be clear mak­ing inter­ac­tions play­ful is very dif­fer­ent from mak­ing them game-like.

  1. Appar­ent­ly, “explorable” isn’t a prop­er Eng­lish word, but if it’s good enough for Mr. Nor­man it’s good enough for me. []
  2. I blogged about pos­si­bil­i­ty space before here. []
  3. Yes, I know I blogged about adap­tive design before. Also about flow and adap­ta­tion, it seems. []

Space to play

Tree by Pocketmonsterd on Flickr

The lan­guages you’ve mas­tered shape your think­ing. Nouns, verbs, adjectives…if you think of your day-to-day inter­ac­tions on the web it’s clear the lan­guage you’re using is (very) lim­it­ed. Does that lim­it your range of thoughts, and the things you’re able to express? Cer­tain­ly, I’d say.

A quote from an old Ben Cer­ve­ny bio found in the Doors of Per­cep­tion muse­um:

Cer­ve­ny is inter­est­ed in har­ness­ing the com­pu­ta­tion­al pow­er of plat­forms like Playstation2 to cre­ate sim­u­la­tions with basic rule-sets that allow com­plex­i­ties to emerge, form­ing pat­terns of behav­iour and inter­ac­tion that peo­ple instinc­tive­ly parse. He believes that this essen­tial human abil­i­ty to find pat­terns in com­plex sys­tems remains untapped by cur­rent “click on the smi­ley face to buy our prod­uct” inter­faces. “There is a cer­tain algo­rith­mic light­ness to a basic rule­set, like that of the game Go,” he argues. “Espe­cial­ly as it replaces a top-down spec­i­fi­ca­tion for human-com­put­er inter­ac­tions.“ ‘

That was in 2001. Game-like inter­ac­tions have the poten­tial for expand­ing your think­ing. Sta­men—where I’m told Cer­ve­ny is spend­ing part of his time—is doing this with datasets.

Recent­ly, I’ve been asked by sev­er­al peo­ple to come up with con­crete exam­ples for my “play­ful” shtick. I’m wor­ried that peo­ple expect stuff that makes a typ­i­cal UI more play­ful. Like a sauce. That’s nev­er been my inten­tion.

The exam­ples I’m con­sid­er­ing (which I intend to describe as pat­terns) are of a more struc­tur­al kind. When I point to emer­gent behav­iour in games, I’m not kidding—the idea here is to allow for sur­pris­ing results. Results that you as a design­er have not fore­seen. Space to play. That’s what sets the typ­i­cal web inter­ac­tion apart from some­thing like Digg Labs.

Play is free move­ment with­in a more rigid struc­ture”. There is (almost) no free move­ment in your typ­i­cal web app. That’s why I would not call it play­ful. These apps are designed to fit pre­de­fined user sce­nar­ios and eval­u­at­ed based on how well they sup­port them. No sur­prise they turn out bor­ing in stead of fun.

How­ev­er: Not every web app has to be play­ful, because not every web app is try­ing to teach you some­thing.

In DOET Nor­man writes on p.124:

What are not every­day activ­i­ties? Those with wide and deep struc­tures, the ones that require con­sid­er­able con­scious plan­ning and thought, delib­er­ate tri­al and error: try­ing first this approach, then that—backtracking. Unusu­al tasks include […] intel­lec­tu­al games: bridge, chess, pok­er, cross­word puz­zles, and so on.“1

So that’s why I believe much of the foun­da­tions of human-cen­tered design are not applic­a­ble to play­ful experiences—the teach­ings of Nor­man are aimed at every­day activ­i­ties. The activ­i­ties that are not aimed at mak­ing you smarter, at giv­ing you new insights.

On the web (and in com­put­ing in gen­er­al) we’ve moved beyond util­i­ty. If we keep design­ing stuff using meth­ods derived from Don­ald Norman’s2 (and other’s) work, we’ll nev­er get to play­ful expe­ri­ences.

  1. Nor­man has a blind spot for dig­i­tal games, although he does include a NES as an exam­ple in his book. About this he admits he made “a few attempts to mas­ter the game” (p.138). []
  2. I’ll be speak­ing at a con­fer­ence that has Mr. Nor­man as keynote speak­er. I mean no dis­re­spect. []

Spectra of learnability

They gave us Don­ald Norman’s The Design of Every­day Things1 to read in inter­ac­tion design school. I remem­ber read­ing it and—being young an cocky—finding it all very com­mon sense and “Why do they ask us to read this stuff?” And so on.2

I am reread­ing it now, in the hopes of sharp­en­ing my argu­ment for play­ful user expe­ri­ences.

(There are a lot of things I want to blog about actu­al­ly, such as how Hill and Webb’s adap­tive design reminds me of Salen & Zim­mer­man’s trans­for­ma­tive play, why Cook rejects MDA while Saf­fer embraces it and more.)

Any­way, my new copy of DOET has a nice intro­duc­tion by Nor­man in which he sum­ma­rizes a few core con­cepts form the book. On page xi—writing on con­cep­tu­al models—he writes:

[G]ood design is … an act of com­mu­ni­ca­tion between the design­er and the user, … all the com­mu­ni­ca­tion has to come about by the appear­ance of the device itself.”

In oth­er words, if you can’t fig­ure “it” out by just look­ing at it, it’s not well designed. Where “fig­ure it out” basi­cal­ly means under­stand how to oper­ate “it” suc­cess­ful­ly. Of course this is an impor­tant con­cept, but I think something’s miss­ing.

In games, it’s not enough just to be able to fig­ure out how to make Mario jump—for instance—you want to learn how to jump well.

It’s about skill and mas­tery in oth­er words. A “Nor­man Door” (a door that is dif­fi­cult to open) can be fixed so that peo­ple can open the door eas­i­ly. But a door has a nar­row spec­trum of learn­abil­i­ty. Or as Koster would prob­a­bly say: The pat­tern to “grok” is real­ly sim­ple.

Figure 1: A door’s spectrum of learnability

And any­way, why would you want to become a mas­ter at open­ing doors, right?

But a lot of the things I’m work­ing on (for instance cre­ative tools, but also toy-like envi­ron­ments) have more com­plex pat­terns and there­fore (wether I like it or not) have a wider spec­trum of learn­abil­i­ty. And that’s where usabil­i­ty alone is not enough. That’s where in test­ing, I’d need to make sure peo­ple don’t just under­stand how to do stuff by look­ing at it. (That’s the start, for sure.) But I also want to be able to tell if peo­ple can get bet­ter at doing stuff. Because if they get bet­ter at it, that’s when they’ll be hav­ing fun.

Figure 2: A toy’s spectrum of learnability

  1. Or The Psy­chol­o­gy of Every­day Things as it was then titled. []
  2. I still con­sid­er myself young, only slight­ly less cocky. []