Engagement design worksheets

Engagement design workshop at General Assembly Singapore

In June/July of this year I helped Michael Fil­lié teach two class­es about engage­ment design at Gen­er­al Assem­bly Sin­ga­pore. The first was the­o­ret­i­cal and the sec­ond prac­ti­cal. For the prac­ti­cal class we cre­at­ed a cou­ple of work­sheets which par­tic­i­pants used in groups to grad­u­al­ly build a design con­cept for a new prod­uct or prod­uct improve­ment aimed at long-term engage­ment. Below are the work­sheets along with some notes on how to use them. I’m hop­ing they may be use­ful in your own prac­tice.

A prac­ti­cal note: Each of these work­sheets is designed to be print­ed on A1 paper. (Click on the images to get the PDFs.) We worked on them using post-it notes so that it is easy to add, change or remove things as you go.

Problem statement and persona


We start­ed with under­stand­ing the prob­lem and the user. This work­sheet is an adap­ta­tion of the per­sona sheet by Strat­e­gyz­er. To use it you begin at the top, flesh­ing out the prob­lem in the form of stat­ing the engage­ment chal­lenge, and the busi­ness goals. Then, you select a user seg­ment which is rel­e­vant to the prob­lem.

The mid­dle sec­tion of the sheet is used to describe them in the form of a per­sona. Start with putting a face on them. Give the per­sona a name and add some demo­graph­ic details rel­e­vant for the user’s behav­iour. Then, move on to explor­ing what their envi­ron­ment looks and sounds like and what they are think­ing and feel­ing. Final­ly, try to describe what issues the user is hav­ing that are addressed by the prod­uct and what the user stands to gain from using the prod­uct.

The third sec­tion of this sheet is used to wrap up the first exer­cise by doing a quick gap analy­sis of what the busi­ness would like to see in terms of user behav­iour and what the user is cur­rent­ly doing. This will help pin down the engage­ment design con­cept fleshed out in the next exer­cis­es.

Engagement loop


Exer­cise two builds on the under­stand­ing of the prob­lem and the user and offers a struc­tured way of think­ing through a pos­si­ble solu­tion. For this we use the engage­ment loop mod­el devel­oped by Sebas­t­ian Deter­d­ing. There are dif­fer­ent places we can start here but one that often works well is to start imag­in­ing the Big Hairy Auda­cious Goal the user is look­ing to achieve. This is the chal­lenge. It is a thing (usu­al­ly a skill) the user can improve at. Note this chal­lenge down in the mid­dle. Then, work­ing around the chal­lenge, describe a mea­sur­able goal the user can achieve on their way to mas­ter­ing the chal­lenge. Describe the action the user can take with the prod­uct towards that goal, and the feed­back the prod­uct will give them to let them know their action has suc­ceed­ed and how much clos­er it has got­ten them to the goal. Final­ly and cru­cial­ly, try to describe what kind of moti­va­tion the user is dri­ven by and make sure the goals, actions and feed­back make sense in that light. If not, adjust things until it all clicks.



The final exer­cise is devot­ed to visu­al­is­ing and telling a sto­ry about the engage­ment loop we devel­oped in the abstract in the pre­vi­ous block. It is a typ­i­cal sto­ry­board, but we have con­strained it to a set of sto­ry beats you must hit to build a sat­is­fy­ing nar­ra­tive. We go from intro­duc­ing the user and their chal­lenge, to how the prod­uct com­mu­ni­cates the goal and action to what a user does with it and how they get feed­back on that to (fast-for­ward) how they feel when they ulti­mate­ly mas­ter the chal­lenge. It makes the design con­cept relat­able to out­siders and can serve as a jump­ing off point for fur­ther design and devel­op­ment.

Use, adapt and share

Togeth­er, these three exer­cis­es and work­sheets are a great way to think through an engage­ment design prob­lem. We used them for teach­ing but I can also imag­ine teams using them to explore a solu­tion to a prob­lem they might be hav­ing with an exist­ing prod­uct, or as a way to kick­start the devel­op­ment of a new prod­uct.

We’ve built on oth­er people’s work for these so it only makes sense to share them again for oth­ers to use and build on. If you do use them I would love to hear about your expe­ri­ences.

Gift outcompetes exchange in design too

I just fin­ished Eric Steven Raymond’s Home­steading the Noos­phere. It’s a ter­rif­ic read for any­one look­ing for a thor­ough look at the inner work­ings of the open source soft­ware devel­op­ment com­mu­ni­ty. Like oth­ers, when­ev­er read­ing this kind of stuff soon­er or lat­er apophe­nia hits and I try to tie bits to my own dis­ci­pline, which isn’t pro­gram­ming but design.

In one of the last chap­ters of the essay (titled Gift Out­com­petes Exchange). Ray­mond offers some tan­ta­lis­ing insights into the rela­tion­ships between doing com­plex cre­ative work, moti­va­tion, and reward. While read­ing it I recog­nised a lot of ideas that I’ve long felt are impor­tant but could nev­er real­ly artic­u­late. Now I final­ly have some great quotes, and (over 10 year old) research to back it up!

Psy­chol­o­gist There­sa Ama­bile of Bran­deis Uni­ver­si­ty, cau­tious­ly sum­ma­riz­ing the results of a 1984 study of moti­va­tion and reward, observed “It may be that com­mis­sioned work will, in gen­er­al, be less cre­ative than work that is done out of pure inter­est.”. Ama­bile goes on to observe that “The more com­plex the activ­i­ty, the more it’s hurt by extrin­sic reward.” Inter­est­ing­ly, the stud­ies sug­gest that flat salaries don’t demo­ti­vate, but piece­work rates and bonus­es do.

Thus, it may be eco­nom­i­cal­ly smart to give per­for­mance bonus­es to peo­ple who flip burg­ers or dug ditch­es, but it’s prob­a­bly smarter to decou­ple salary from per­for­mance in a pro­gram­ming shop and let peo­ple choose their own projects (both trends that the open-source world takes to their log­i­cal con­clu­sions). Indeed, these results sug­gest that the only time it is a good idea to reward per­for­mance in pro­gram­ming is when the pro­gram­mer is so moti­vat­ed that he or she would have worked with­out the reward!

Oth­er researchers in the field are will­ing to point a fin­ger straight at the issues of auton­o­my and cre­ative con­trol that so pre­oc­cu­py hack­ers. “To the extent one’s expe­ri­ence of being self-deter­mined is lim­it­ed,” said Richard Ryan, asso­ciate psy­chol­o­gy pro­fes­sor at the Uni­ver­si­ty of Rochester, “one’s cre­ativ­i­ty will be reduced as well.”

So a team of design­ers work­ing in the mode Ray­mond describes would choose their own projects and not be reward­ed for their per­for­mance on projects (which is usu­al­ly mea­sured in effi­cien­cy and client sat­is­fac­tion). In stead, to real­ly keep them moti­vat­ed, they’d be giv­en a large amount of auton­o­my (and wouldn’t be instruct­ed on which prob­lems to solve and how to go about it). Of course, this only works with skilled work­ers, but I don’t think that’s the rea­son these philoso­phies haven’t been applied to design work on the scale they have been in pro­gram­ming. I think a lot of resis­tance for actu­al­ly allow­ing design­ers work like this in a com­mer­cial set­ting are relat­ed to a fear of giv­ing up con­trol. Lat­er on Ray­mond fin­ish­es the chap­ter with:

Indeed, it seems the pre­scrip­tion for high­est soft­ware pro­duc­tiv­i­ty is almost a Zen para­dox; if you want the most effi­cient pro­duc­tion, you must give up try­ing to make pro­gram­mers pro­duce. Han­dle their sub­sis­tence, give them their heads, and for­get about dead­lines. To a con­ven­tion­al man­ag­er this sounds crazi­ly indul­gent and doomed—but it is exact­ly the recipe with which the open-source cul­ture is now clob­ber­ing its com­pe­ti­tion.

When will the first exam­ples appear of design done in this way? When will the first projects pop up that out­com­pete the cathe­dral style designs process (or are they already among us)? Are there any design­ers out there actu­al­ly work­ing in this way? I’d love to hear from you.

Update: I changed the link to Flickr into one point­ing to a post by Tom Coates on how Flickr was built.