Prototyping in the browser

When you are design­ing a web site or web app I think you should pro­to­type in the brows­er. Why? You might as well ask why pro­to­type at all. Answer: To enable con­tin­u­ous test­ing and refine­ment of your design. Since you are design­ing for the web it makes sense to do this test­ing and refine­ment with an arte­fact com­posed of the web’s material.

There are many ways to do pro­to­typ­ing. A com­mon way is to make wire­frames and then make them ‘click­able’. But when I am design­ing a web site or a web app and I get to the point where it is time to do wire­frames I often pre­fer to go straight to the browser. 

Before this step I have sketched out all the screens on paper of course. I have done mul­ti­ple sketch­es of each page. I’ve had them cri­tiqued by team mem­bers and I have reworked them. 

Drawing pictures of web pages

But then I open my draw­ing pro­gram—Sketch, in my case—and my heart sinks. Not because Sketch sucks. Sketch is great. But it some­how feels wrong to draw pic­tures of web pages on my screen. I find it cum­ber­some. My draw­ing pro­gram does not behave like a brows­er. That is to say in stead of defin­ing a bunch of rules for ele­ments and hav­ing the brows­er fig­ure out how to ren­der them on a page togeth­er I need to fol­low those rules myself in my head as I put each ele­ment in its place.

And don’t get me start­ed on how wire­frames are sup­posed to be with­out visu­al design. That is non­sense. If you are using con­trast, rep­e­ti­tion, align­ment and prox­im­i­ty, you are doing lay­out. That is visu­al design. I can’t stand wire­frames with a bad visu­al hierarchy.

If I per­se­vere, and I have a set of wire­frames in my draw­ing pro­gram, they are sta­t­ic. I can’t use them. I then need to export them to some oth­er often clunky pro­gram to make the pic­tures click­able. Which always results in a poor resem­blance of the actu­al expe­ri­ence. (I use Mar­vel. It’s okay but it is hard­ly a joy to use. For mobile apps I still use it, for web sites I pre­fer not to.)

Prototyping in the browser

When I pro­to­type in the brows­er I don’t have to deal with these issues. I am doing lay­out in a way that is native to the medi­um. And once I have some pages set up they are imme­di­ate­ly usable. So I can hand it to some­one, a team mem­ber or a test par­tic­i­pant, and let them play with it.

That is why, for web sites and web apps, I skip wire­frames alto­geth­er and pro­to­type in the brows­er. I do not know how com­mon this is in the indus­try nowa­days. So I thought I would share my approach here. It may be of use to some. 

It used to be the case that it was quite a bit of has­sle to get up and run­ning with a brows­er pro­to­type so nat­u­ral­ly open­ing a draw­ing pack­age seemed more attrac­tive. Not so any­more. Tools have come a long way. Case in point: My set­up nowa­days involves zero screw­ing around on the com­mand line.

CodeKit

The core of it is a paid-for Mac app called CodeK­it, a so-called task man­ag­er. It allows you to install a front-end devel­op­ment frame­work I like called Zurb Foun­da­tion with a cou­ple of clicks and has a built in web serv­er so you can play with your pro­to­type on any device on your local net­work. As you make changes to the code of your pro­to­type it gets auto­mat­i­cal­ly updat­ed on all your devices. No more man­u­al refresh­ing. Saves a huge amount of time.

I know you can do most of what CodeK­it does for you with stuff like Grunt but that involves tedious con­fig­u­ra­tion and work­ing the com­mand line. This is fine when you’re a devel­op­er, but not fine when you are a design­er. I want to be up and run­ning as fast as pos­si­ble. CodeK­it allows me to do that and has some oth­er fea­tures built in that are ide­al for pro­to­typ­ing which I will talk about more below. Long sto­ry short: CodeK­it has saved me a huge amount of time and is well worth the money.

Okay so on with the show. Yes, this whole pro­to­typ­ing in the brows­er thing involves ‘cod­ing’. But hon­est­ly, if you can’t write some HTML and CSS you real­ly shouldn’t be doing design for the web in the first place. I don’t care if you con­sid­er your­self a UX design­er and some­how above all this low­ly tech­ni­cal stuff. You are not. Nobody is say­ing you should become a fron­tend devel­op­er but you need to have an acquain­tance with the mate­ri­als your prod­uct is made of. Fol­low a few cours­es on Codecadamy or some­thing. There real­ly isn’t an excuse any­more these days for not know­ing this stuff. If you want to lev­el up, learn SASS.

Zurb Foundation

I like Zurb Foun­da­tion because it offers a coher­ent and com­pre­hen­sive library of ele­ments which cov­ers almost all the com­mon pat­terns found in web sites and apps. It offers a grid and some default typog­ra­phy styles as well. All of it doesn’t look flashy at all which is how I like it when I am pro­to­typ­ing. A pro­to­type at this stage does not require per­son­al­i­ty yet. Just a clear visu­al hier­ar­chy. Work­ing with Foun­da­tion is almost like play­ing with LEGO. You just click togeth­er the stuff you need. It’s pain­less and looks and works great.

I hard­ly do any styling but the few changes I do want to make I can eas­i­ly add to Foundation’s app.scss using SASS. I usu­al­ly have a few styles in there for tweak­ing some mar­gins on par­tic­u­lar ele­ments, for exam­ple a foot­er. But I try to focus on the struc­ture and behav­iour of my pages and for that I am most­ly doing HTML

GitHub

Test­ing local­ly I already men­tioned. For that, CodeK­it has you cov­ered. Of course, you want to be able to share your pro­to­type with oth­ers. For this I like to use GitHub and their Pages fea­ture. Once again, using their desk­top client, this involves zero com­mand line work. You just add the fold­er with your CodeK­it project as a new repos­i­to­ry and sync it with GitHub. Then you need to add a branch named ‘gh-pages’ and do ‘update from mas­ter’. Presto, your pro­to­type is now on the web for any­one with the URL to see and use. Per­fect if you’re work­ing in a dis­trib­uted team. 

Don’t be intim­i­dat­ed by using GitHub. Their on-board­ing is pret­ty impres­sive nowa­days. You’ll be up and run­ning in no time. Using ver­sion con­trol, even if it is just you work­ing on the pro­to­type, adds some much need­ed struc­ture and con­trol over changes. And when you are col­lab­o­rat­ing on your pro­to­type with team mem­bers it is indispensable. 

But in most cas­es I am the only one build­ing the pro­to­type so I just work on the mas­ter branch and once every while I update the gh-pages branch from mas­ter and sync it and I am done. If you use Slack you can add a GitHub bot to a chan­nel and have your team mem­bers receive an auto­mat­ic update every time you change the prototype. 

The Kit Language

If your project is of any size beyond the very small you will like­ly have repeat­ing ele­ments in your design. Head­ers, foot­ers, recur­ring wid­gets and so on. CodeK­it has recent­ly added sup­port for some­thing called the Kit Lan­guage. This adds sup­port for imports and vari­ables to reg­u­lar HTML. It is absolute­ly great for pro­to­typ­ing. For each repeat­ing ele­ment you cre­ate a ‘par­tial’ and import it wher­ev­er you need it. Vari­ables are great for chang­ing the con­tents of such repeat­ing ele­ments. CodeK­it com­piles it all into plain sta­t­ic HTML for you so your pro­to­type runs anywhere.

The Kit Lan­guage real­ly was the miss­ing piece of the puz­zle for me. With it in place I am very com­fort­able rec­om­mend­ing this way of work­ing to anyone.

So that’s my set­up: CodeK­it, Zurb Foun­da­tion and GitHub. Togeth­er they make for a very pleas­ant and pro­duc­tive way to do pro­to­typ­ing in the brows­er. I don’t imag­ine myself going back to draw­ing pic­tures of web pages any­time soon.

Design without touching the surface

I am prepar­ing two class­es at the moment. One is an intro­duc­tion to user expe­ri­ence design, the oth­er to user inter­face design. I did not come up with this divi­sion, it was part of the assign­ment. I thought it was odd at first. I wasn’t sure where one dis­ci­pline ends and the oth­er begins. I still am not sure. But I made a prag­mat­ic deci­sion to have the UX class focus on the high lev­el process of design­ing (soft­ware) prod­ucts, and the UI class focus on the visu­al aspects of a product’s inter­face. The UI class deals with a product’s sur­face, form, and to some extent also its behav­iour, but on a micro lev­el. Where­as the UX class focus­es on behav­iour on the macro lev­el. Sim­ply speaking—the UX class is about behav­iour across screens, the UI class is about behav­iour with­in screens.

The solu­tion is work­able. But I am still not entire­ly com­fort­able with it. I am not com­fort­able with the idea of being able to prac­tice UX with­out ‘touch­ing the sur­face’, so to speak. And it seems my two class­es are advo­cat­ing this. Also, I am pret­ty sure this is every­day real­i­ty for many UX prac­ti­tion­ers. Notice I say “prac­ti­tion­er”, because I am not sure ‘design­er’ is the right term in these cas­es. To be hon­est I do not think you can prac­tice design with­out doing sketch­ing and pro­to­typ­ing of some sort. (See Bill Buxton’s ‘Sketch­ing User Expe­ri­ences’ for an expand­ed argu­ment on why this is.) And when it comes to design­ing soft­ware prod­ucts this means touch­ing the sur­face, the form.

Again, the real­i­ty is, ‘UX design­er’ and ‘UI design­er’ are com­mon terms now. Cer­tain­ly here in Sin­ga­pore peo­ple know they need both to make good prod­ucts. Some prac­ti­tion­ers say they do both, oth­ers one or the oth­er. The lat­ter appears to be the most com­mon and expect­ed case. (By the way, in Sin­ga­pore no-one I’ve met talks about inter­ac­tion design.)

My con­cern is that by encour­ag­ing the prac­tice of doing UX design with­out touch­ing the sur­face of a prod­uct, we get shit­ty designs. In a process where UX and UI are seen as sep­a­rate things the risk is one comes before the oth­er. The UX design­er draws the wire­frames, the UI design­er gets to turn them into pret­ty pic­tures, with no back-and-forth between the two. An iter­a­tive process can mit­i­gate some of the dam­age such an arti­fi­cial divi­sion of labour pro­duces, but I think we still start out on the wrong foot. I think a bet­ter prac­tice might entail includ­ing visu­al con­sid­er­a­tions from the very begin­ning of the design process (as we are sketching).

Two things I came across as I was prepar­ing these class­es are some­how in sup­port of this idea. Both result­ed from a call I did for resources on user inter­face design. I asked for books about visu­al aspects, but I got a lot more.

  1. In ‘Mag­ic Ink’ Bret Vic­tor writes about how the design of infor­ma­tion soft­ware is huge­ly indebt­ed to graph­ic design and more specif­i­cal­ly infor­ma­tion design in the tra­di­tion of Tufte. (He also men­tions indus­tri­al design as an equal­ly big prog­en­i­tor of inter­ac­tion design, but for soft­ware that is main­ly about manip­u­la­tion, not infor­ma­tion.) The arti­cle is big, but the start of it is actu­al­ly a pret­ty good if unortho­dox gen­er­al intro­duc­tion to inter­ac­tion design. For soft­ware that is about learn­ing through look­ing at infor­ma­tion Vic­tor says inter­ac­tion should be a last resort. So that leaves us with a task that is 80% if not more visu­al design. Touch­ing the sur­face. Which makes me think you might as well get to it as quick­ly as pos­si­ble and start sketch­ing and pro­to­typ­ing aimed not just at struc­ture and behav­iour but also form. (Hat tip to Pieter Diepen­maat for this one.)

  2. In ‘Jump­ing to the End’ Matt Jones ram­bles enter­tain­ing­ly about design fic­tion. He argues for pay­ing atten­tion to details and that a lot of the design he prac­tices is about ‘sig­na­ture moments’ aka micro-inter­ac­tions. So yeah, again, I can’t imag­ine design­ing these effec­tive­ly with­out doing sketch­ing and pro­to­typ­ing of the sort that includes the visu­al. And in fact Matt men­tions this more or less at one point, when he talks about the fact that his team’s deliv­er­ables at Google are almost all visu­al. They are high fideli­ty mock­ups, ani­ma­tions, videos, and so on. These then become the start­ing points for fur­ther devel­op­ment. (Hat tip to Alexan­der Zeh for this one.)

In sum­ma­ry, I think dis­tin­guish­ing UX design from UI design is non­sense. Because you can­not prac­tice design with­out sketch­ing and pro­to­typ­ing. And you can­not sketch and pro­to­type a soft­ware prod­uct with­out touch­ing its sur­face. In stead of tak­ing visu­al design for grant­ed, or talk­ing about it like it is some innate tal­ent, some kind of mag­i­cal skill some peo­ple are born with and oth­ers aren’t, user expe­ri­ence prac­ti­tion­ers should con­sid­er being less enam­oured with acquir­ing more skills from busi­ness, mar­ket­ing and engi­neer­ing and in stead prac­tice at the skills that define the fields user expe­ri­ence design is indebt­ed to the most: graph­ic design and indus­tri­al design. In oth­er words, you can’t do user expe­ri­ence design with­out touch­ing the surface.

My plans for 2016

Long sto­ry short: my plan is to make plans.

Hub­bub has gone into hiber­na­tion. After more than six years of lead­ing a bou­tique play­ful design agency I am return­ing to free­lance life. At least for the short term.

I will use the flex­i­bil­i­ty afford­ed by this free­ing up of time to take stock of where I have come from and where I am head­ed. ‘Ori­en­ta­tion is the Schw­er­punkt,’ as Boyd says. I have def­i­nite­ly cycled back through my meta-OODA-loop and am firm­ly back in the sec­ond O.

To make things more inter­est­ing I have exchanged the Nether­lands for Sin­ga­pore. I will be here until August. It is going to be fun to explore the things this city has to offer. I am curi­ous what the tech­nol­o­gy and design scene is like when seen up close. So I hope to do some work locally.

I will take on short com­mit­ments. Let’s say no longer than two to three months. Any­thing goes real­ly, but I am par­tic­u­lar­ly inter­est­ed in work relat­ed to cre­ativ­i­ty and learn­ing. I am also keen on get­ting back into teaching.

So if you are in Sin­ga­pore, work in tech­nol­o­gy or design and want to have a cup of cof­fee. Drop me a line.

Hap­py 2016!

Blog All Kindle-clipped Locations: Destruction and Creation

I fin­ished my pre­vi­ous post on why design­ers should be inter­est­ed in John Boyd with the rec­om­men­da­tion to read his essay “Destruc­tion and Cre­ation”. I thought I’d share the bits I high­light­ed in my copy. It is part of Osin­ga’s Sci­ence, Strat­e­gy and War, to which the loca­tions below refer.

Loca­tion 3176 – Boyd intro­duces a very sim­ple but fun­da­men­tal rea­son for why we should care about deci­sion making:

… a basic aim or goal, as indi­vid­u­als, is to improve our capac­i­ty for inde­pen­dent action

Loca­tion 3183 – the same applies to design and design­ers. We do not want to be con­trolled by our cir­cum­stances. Boyd was talk­ing to a mil­i­tary audi­ence, but the descrip­tion below is true of any social sit­u­a­tion, includ­ing the design practice:

In a real world of lim­it­ed resources and skills, indi­vid­u­als and groups form, dis­solve and reform their coop­er­a­tive or com­pet­i­tive pos­tures in a con­tin­u­ous strug­gle to remove or over­come phys­i­cal and social envi­ron­men­tal obstacles.

Loca­tion 3190

Against such a back­ground, actions and deci­sions become crit­i­cal­ly important.

Loca­tion 3192

To make these time­ly deci­sions implies that we must be able to form men­tal con­cepts of observed real­i­ty, as we per­ceive it, and be able to change these con­cepts as real­i­ty itself appears to change.

Loca­tion 3195 – design­ers are asked to do noth­ing but the above. The suc­ces of our designs hinges on our under­stand­ing of real­i­ty and our skill at inter­ven­ing in it. So the ques­tion below is of vital impor­tance to us:

How do we gen­er­ate or cre­ate the men­tal con­cepts to sup­port this deci­sion-mak­ing activity?

Loca­tion 3196 – in the next sec­tion of the essay Boyd starts to pro­vide answers:

There are two ways in which we can devel­op and manip­u­late men­tal con­cepts to rep­re­sent observed real­i­ty: We can start from a com­pre­hen­sive whole and break it down to its par­tic­u­lars or we can start with the par­tic­u­lars and build towards a com­pre­hen­sive whole.

Loca­tion 3207

… gen­er­al-to-spe­cif­ic is relat­ed to deduc­tion, analy­sis, and dif­fer­en­ti­a­tion, while, spe­cif­ic-to-gen­er­al is relat­ed to induc­tion, syn­the­sis, and integration.

Loca­tion 3216

… such an unstruc­tur­ing or destruc­tion of many domains – to break the cor­re­spon­dence of each with its respec­tive con­stituents – is relat­ed to deduc­tion, analy­sis, and dif­fer­en­ti­a­tion. We call this kind of unstruc­tur­ing a destruc­tive deduction.

Loca­tion 3225

… cre­ativ­i­ty is relat­ed to induc­tion, syn­the­sis, and inte­gra­tion since we pro­ceed­ed from unstruc­tured bits and pieces to a new gen­er­al pat­tern or con­cept. We call such action a cre­ative or con­struc­tive induction.

Loca­tion 3227 – here Boyd starts to con­nect the two ways of cre­at­ing con­cepts. I have always found it grat­i­fy­ing to immerse myself in a design’s domain and to start teas­ing apart its con­stituent ele­ments, before mov­ing on to acts of creation:

It is impor­tant to note that the cru­cial or key step that per­mits this cre­ative induc­tion is the sep­a­ra­tion of the par­tic­u­lars from their pre­vi­ous domains by the destruc­tive deduction.

Loca­tion 3230

… the unstruc­tur­ing and restruc­tur­ing just shown reveals a way of chang­ing our per­cep­tion of reality.

Loca­tion 3237 – so far so fair­ly straight-for­ward. But Boyd gets increas­ing­ly more sophis­ti­cat­ed about this cycle of destruc­tion and cre­ation. For exam­ple, he sug­gests we should check for inter­nal con­sis­ten­cy of a new con­cept by trac­ing back its ele­ments to the orig­i­nal sources:

… we check for reversibil­i­ty as well as check to see which ideas and inter­ac­tions match-up with our obser­va­tions of reality.

Loca­tion 3240 – so this is not a two-step lin­ear act, but a cycli­cal one, where we keep tun­ing parts and wholes of a con­cept (or design) and test them against reality:

Over and over again this cycle of Destruc­tion and Cre­ation is repeat­ed until we demon­strate inter­nal con­sis­ten­cy and match-up with reality.

Loca­tion 3249 – in the next sec­tion, Boyd prob­lema­tis­es the process he has pro­posed by show­ing that once we have formed a con­cept, its matchup to real­i­ty imme­di­ate­ly starts to deteriorate:

… at some point, ambi­gu­i­ties, uncer­tain­ties, anom­alies, or appar­ent incon­sis­ten­cies may emerge to sti­fle a more gen­er­al and pre­cise match-up of con­cept with observed reality.

Loca­tion 3257 – the point below is one I can’t help but iter­ate often enough to clients and cowork­ers. We must work under the assump­tion of mis­match­es occur­ring soon­er or lat­er. It is an essen­tial state of mind:

… we should antic­i­pate a mis­match between phe­nom­e­na obser­va­tion and con­cept descrip­tion of that observation.

Loca­tion 3266 – he brings in Gödel, Heisen­berg and the sec­ond law of ther­mo­dy­nam­ics to explain why this is so:

Gödel’s Proof indi­rect­ly shows that in order to deter­mine the con­sis­ten­cy of any new sys­tem we must con­struct or uncov­er anoth­er sys­tem beyond it.

Loca­tion 3274

Back and forth, over and over again, we use obser­va­tions to sharp­en a con­cept and a con­cept to sharp­en obser­va­tions. Under these cir­cum­stances, a con­cept must be incom­plete since we depend upon an ever-chang­ing array of obser­va­tions to shape or for­mu­late it. Like­wise, our obser­va­tions of real­i­ty must be incom­plete since we depend upon a chang­ing con­cept to shape or for­mu­late the nature of new inquiries and observations.

Loca­tion 3301 – so Gödel shows we need to con­tin­u­ous­ly cre­ate new con­cepts to main­tain the use­ful­ness of pri­or ones due to the rela­tion­ship between observed real­i­ty and men­tal con­cepts. Good news for design­ers! Our work is nev­er done. It is also an inter­est­ing way to think about cul­ture evolv­ing by the build­ing of increas­ing­ly com­plex net­works of pri­or con­cepts into new ones. Next, Boyd brings in Heisen­berg to explain why there is uncer­tain­ty involved when mak­ing obser­va­tions of reality:

… the mag­ni­tude of the uncer­tain­ty val­ues rep­re­sent the degree of intru­sion by the observ­er upon the observed.

Loca­tion 3304

… uncer­tain­ty val­ues not only rep­re­sent the degree of intru­sion by the observ­er upon the observed but also the degree of con­fu­sion and dis­or­der per­ceived by that observer.

Loca­tion 3308 – Heisen­berg shows that the more we become intwined with observed real­i­ty the more uncer­tain­ty increas­es. This is of note because as we design new things and we intro­duce them into the envi­ron­ment, unex­pect­ed things start to hap­pen. But also, we as design­ers our­selves are part of the envi­ron­ment. The more we are part of the same con­text we are design­ing for, the less able we will be to see things as they tru­ly are. Final­ly, for the third move by which Boyd prob­lema­tis­es the cre­ation of new con­cepts, we arrive at the sec­ond law of thermodynamics:

High entropy implies a low poten­tial for doing work, a low capac­i­ty for tak­ing action or a high degree of con­fu­sion and dis­or­der. Low entropy implies just the opposite.

Loca­tion 3312 – closed sys­tems are those that don’t com­mu­ni­cate with their envi­ron­ment. A suc­cess­ful design prac­tice should be an open sys­tem, lest it suc­cumb to entropy:

From this law it fol­lows that entropy must increase in any closed system 

… when­ev­er we attempt to do work or take action inside such a sys­tem – a con­cept and its match-up with real­i­ty – we should antic­i­pate an increase in entropy hence an increase in con­fu­sion and disorder.

Loca­tion 3317 – it’s impor­tant to note that Boy­d’s ideas are equal­ly applic­a­ble to design plans, design prac­tices, design out­comes, any sys­tem involved in design, real­ly. Con­fused? Not to wor­ry, Boyd boils it down in the next and final section:

Accord­ing to Gödel we can­not – in gen­er­al – deter­mine the con­sis­ten­cy, hence the char­ac­ter or nature, of an abstract sys­tem with­in itself. Accord­ing to Heisen­berg and the Sec­ond Law of Ther­mo­dy­nam­ics any attempt to do so in the real world will expose uncer­tain­ty and gen­er­ate disorder.

Loca­tion 3320 – the bit below is a pret­ty good sum­ma­ry of why “big design up front” does not work:

any inward-ori­ent­ed and con­tin­ued effort to improve the match-up of con­cept with observed real­i­ty will only increase the degree of mismatch.

Loca­tion 3329 – when­ev­er we encounter chaos the instinct is to stick to our guns, but it is prob­a­bly wis­er to take a step back and recon­sid­er our assumptions:

we find that the uncer­tain­ty and dis­or­der gen­er­at­ed by an inward-ori­ent­ed sys­tem talk­ing to itself can be off­set by going out­side and cre­at­ing a new system.

Loca­tion 3330 – cre­ativ­i­ty or explo­rative design under pres­sure can seem like a waste of time but once we have gone through the exer­cise in hind sight we always find it more use­ful than thought before:

Sim­ply stat­ed, uncer­tain­ty and relat­ed dis­or­der can be dimin­ished by the direct arti­fice of cre­at­ing a high­er and broad­er more gen­er­al con­cept to rep­re­sent reality.

Loca­tion 3340

I believe we have uncov­ered a Dialec­tic Engine that per­mits the con­struc­tion of deci­sion mod­els need­ed by indi­vid­u­als and soci­eties for deter­min­ing and mon­i­tor­ing actions in an effort to improve their capac­i­ty for inde­pen­dent action.

Loca­tion 3341

the goal seek­ing effort itself appears to be the oth­er side of a con­trol mech­a­nism that seems also to dri­ve and reg­u­late the alter­nat­ing cycle of destruc­tion and cre­ation toward high­er and broad­er lev­els of elaboration.

Loca­tion 3347 – chaos is a fact of life, and as such we should wel­come it because it is as much a source of vital­i­ty as it is a threat:

Para­dox­i­cal­ly, then, an entropy increase per­mits both the destruc­tion or unstruc­tur­ing of a closed sys­tem and the cre­ation of a new sys­tem to nul­li­fy the march toward ran­dom­ness and death.

Loca­tion 3350 – one of Boy­d’s final lines is a fine descrip­tion of what I think design should aspire to: 

The result is a chang­ing and expand­ing uni­verse of men­tal con­cepts matched to a chang­ing and expand­ing uni­verse of observed reality.

John Boyd for designers

The first time I came across mil­i­tary strate­gist John Boy­d’s ideas was prob­a­bly through Venkatesh Rao’s writ­ing. For exam­ple, I remem­ber enjoy­ing Be Some­body or Do Some­thing.

Boyd was clear­ly a con­trar­i­an per­son. I tend to have a soft spot for such fig­ures so I read a high­ly enter­tain­ing biog­ra­phy by Roger Coram. Get­ting more inter­est­ed in his the­o­ries I then read an appli­ca­tion of Boy­d’s ideas to busi­ness by Chet Richards. Still not sat­is­fied, I decid­ed to final­ly buck­le down and read the com­pre­hen­sive sur­vey of his mar­tial and sci­en­tif­ic influ­ences plus tran­scripts of all his brief­in­gs by Frans Osinga.

It’s been a huge­ly enjoy­able and reward­ing intel­lec­tu­al trip. I feel like Boyd has giv­en me some pret­ty sharp new tools-to-think-with. From his back­ground you might think these tools are lim­it­ed to war­fare. But in fact they can be applied much more broad­ly, to any field in which we need to make deci­sions under uncer­tain circumstances. 

As we go about our dai­ly lives we are actu­al­ly always deal­ing with this dynam­ic. But the stakes are usu­al­ly low, so we most­ly don’t real­ly care about hav­ing a thor­ough under­stand­ing of how to do what we want to do. In war­fare the stakes are obvi­ous­ly unusu­al­ly high, so it makes sense for some of the most artic­u­late think­ing on the sub­ject to emerge from it.

As a design­er I have always been inter­est­ed in how my pro­fes­sion makes deci­sions. Design­ers usu­al­ly deal with high lev­els of uncer­tain­ty too. Although lives are rarely at stake, the con­tin­ued via­bil­i­ty of busi­ness­es and qual­i­ty of peo­ples lives usu­al­ly are, at least in some way. Fur­ther­more, there is always a leap of faith involved with any design deci­sion. When we sug­gest a path for­ward with our sketch­es and pro­to­types, and we choose to pro­ceed to devel­op­ment, we can nev­er be entire­ly sure if our intend­ed out­comes will pan out as we had hoped.

This uncer­tain­ty has always been present in any design act, but an argu­ment could be made that tech­nol­o­gy has increased the amount of uncer­tain­ty in our world.

The way I see it, the meth­ods of user cen­tred design, inter­ac­tion design, user expe­ri­ence, etc are all attempts to “deal with” uncer­tain­ty in var­i­ous ways. The same can be said for the tech­niques of agile soft­ware development. 

These meth­ods can be divid­ed into rough­ly two cat­e­gories, which more or less cor­re­spond to the upper two quad­rants of this two-by-two by Venkatesh. Bor­row­ing the dia­gram’s labels, one is called Spore. It is risk-averse and focus­es on sus­tain­abil­i­ty. The oth­er is called Hydra and it is risk-savvy and about anti-fragili­ty. Spore tries to lim­it the neg­a­tive con­se­quences of unex­pect­ed events, and Hydra tries to max­imise their pos­i­tive consequences. 

An exam­ple of a Spore-like design move would be to insist on thor­ough user research at the start of a project. We expend sig­nif­i­cant resources to dimin­ish the amount of unknowns about our tar­get audi­ence. An exam­ple of a Hydra-like design move is the kind of playtest­ing employed by many game design­ers. We leave open the pos­si­bil­i­ty of sur­pris­ing acts from our tar­get audi­ence and hope to sub­se­quent­ly use those as the basis for new design directions. 

It is inter­est­ing to note that these upper two quad­rants are strate­gies for deal­ing with uncer­tain­ty based on syn­the­sis. The oth­er two rely on analy­sis. We typ­i­cal­ly asso­ciate syn­the­sis with cre­ativ­i­ty and by exten­sion with design. But as Boyd fre­quent­ly points out, inven­tion requires both analy­sis and syn­the­sis, which he liked to call destruc­tion and cre­ation. When I reflect on my own way of work­ing, par­tic­u­lar­ly in the ear­ly stages of a project, the so-called fuzzy front end, I too rely on a cycle of destruc­tion and cre­ation to make progress. 

I do not see one of the two approach­es, Spore or Hydra, as inher­ent­ly supe­ri­or. But my per­son­al pref­er­ence is most def­i­nite­ly the Hydra approach. I think this is because a risk-savvy stance is most help­ful when try­ing to invent new things, and when try­ing to design for play and playfulness.

The main thing I learned from Boyd for my own design prac­tice is to be aware of uncer­tain­ty in the first place, and to know how to deal with it in an agile way. You might not be will­ing to do all the read­ing I did, but I would rec­om­mend to at least peruse the one long-form essay Boyd wrote, titled Destruc­tion and Cre­ation (PDF), about how to be cre­ative and deci­sive in the face of uncertainty.

Sources for my Creative Mornings Utrecht talk on education, games, and play

I was stand­ing on the shoul­ders of giants for this one. Here’s a (prob­a­bly incom­plete) list of sources I ref­er­enced through­out the talk.

All of these are high­ly recommended.

Update: the slides are now up on Speak­er Deck.

The real­ly good cre­ative peo­ple are always orga­nized, it’s true. The dif­fer­ence is effi­cien­cy. If you have an agenda—a schedule—you will be bet­ter. In order to have moments of chaos and anar­chy and cre­ativ­i­ty, you have to be very ordered so that when the moment arrives it doesn’t put things out of whack.”

Rem­i­nis­cent of “play is free move­ment with­in a more rigid sys­tem” – I always enjoy using pro­fes­sion­al cook­ing as source of inspi­ra­tion for improv­ing design.

(via The Stan­dard — Can the Brains Behind elBul­li Take the Chaos Out of Cre­ativ­i­ty?)

Nobody does thor­ough­ly argued pre­sen­ta­tions quite like Sebas­t­ian. This is good stuff on ethics and design.

I decid­ed to share some thoughts it sparked via Twit­ter and end­ed up rant­i­ng a bit:

I recent­ly talked about ethics to a bunch of “behav­ior design­ers” and found myself con­clud­ing that any designed sys­tem that does not allow for user appro­pri­a­tion is fun­da­men­tal­ly uneth­i­cal because as you right­ly point out what is the good life is a per­son­al mat­ter. Impos­ing it is an inher­ent­ly vio­lent act. A lot of design is a form of tech­no­log­i­cal­ly medi­at­ed vio­lence. Get­ting peo­ple to do your bid­ding, how­ev­er well intend­ed. Which giv­en my own voca­tion and work in the past is a kind of trou­bling thought to arrive at… Help?

Sebas­t­ian makes his best point on slides 113–114. Eth­i­cal design isn’t about doing the least harm, but about doing the most good. And, to come back to my Twit­ter rant, for me the ulti­mate good is for oth­ers to be free. Hence non-pre­scrip­tive design.

(via Design­ing the Good Life: Ethics and User Expe­ri­ence Design)

Week 174

STT again

This week on Wednes­day I found myself in the love­ly KNAW build­ing to talk about the far future of applied game design. I was invit­ed to do so by STT, togeth­er with David Shaf­fer, Jeroen van Mas­trigt and Jeroen Elf­ferich. I talked about the inca­pac­i­ty of design as well as sci­ence fic­tion to effec­tive­ly imag­ine a future, how to deal with that as a design­er, and two areas that I see as tru­ly vir­gin ter­ri­to­ry for applied game design: the new type of city we’ve seen emerge in the East, and syn­thet­ic biol­o­gy. I got some nice respons­es and some chal­leng­ing ques­tions from the crowd, so I guess things went OK. The anno­tat­ed slides will find their way to the Hub­bub blog soon. 

Aside from this, I spent the week work­ing on PLAY Pilots — con­tin­u­ing work on the next pilot for Le Guess Who? togeth­er with Monoban­da. And at the HKU, work­ing with my stu­dents on the Pam­pus project. Final­ly, my interns have kicked off their third game at the Learn­ing Lab, this one run­ning on their inter­nal blog plat­form. It involves mon­keys and a blind drag­on. Look­ing for­ward to the write­up for that one.

Quite a few bits of con­tent found their way online too, by the way. In case you missed them the first time around, here they are:

Plus a video of the Boc­ce Drift ses­sion Hub­bub ran a while back:

5 things I’m thinking about

You have Alper to blame for this. Alice start­ed it, many fol­lowed (some well worth read­ing) and now the meme has crossed the pond it seems. I know, we’re a bit slow in NL. So, what am I think­ing about?

My upcom­ing hol­i­day, which will be the first break in over a year. I am plan­ning to com­plete­ly unplug, which I am both dread­ing and look­ing for­ward to. It seems the longer I am self-employed, the hard­er it gets to just leave work behind for an extend­ed peri­od of time. It seems crazy to be wor­ried about the con­ti­nu­ity of my busi­ness when I’m only away for a week on a freak­ing Wad­den island.

Today marks the last day of final exams at the HKU and I am lead to won­der about the future of design edu­ca­tion as it hap­pens there and at oth­er sim­i­lar insti­tutes around the world. It often seems too closed off from the out­side world, too insu­lar. I am look­ing for­ward to tan­gling with this sub­ject mat­ter more in an upcom­ing project with Riv­er Insti­tute.

Choos­ing has nev­er come easy to me. In the past I have found it painful to choose between dis­ci­plines, skills to devel­op, projects to work on. And at some point I sort of decid­ed to stop forc­ing choic­es and find ways to have them all mesh. I think that final­ly I am get­ting to a spot where I am com­fort­able in not choos­ing. So now I won­der why that is, what the val­ue of refus­ing to choose is and what that means for cre­ative disciplines.

I am essen­tial­ly pes­simistic about the future of this world. I have a very hard time con­ceiv­ing of any future, in fact. Recent­ly I found myself in a work­shop aimed at mak­ing plans for an event in 2015 and I was total­ly lost. Hav­ing learnt this about myself the next ques­tion is how to act — I don’t wan’t to “play dead” as Bruce Ster­ling would say — so what’s the alternative?

Since it is at the core of my busi­ness I am think­ing a lot about domains where games could go next. I am think­ing a lot about cit­i­zen engage­ment, par­tic­u­lar­ly when it comes to pub­lic pol­i­cy, but I am most­ly stumped about mak­ing inroads into that area locally.

There you have it.