Doing UX inside of Scrum

Some notes on how I am cur­rent­ly “doing user expe­ri­ence” inside of Scrum. This approach has evolved from my projects at Hub­bub as well as more recent­ly my work with ARTO and on a project at Eden­spiek­er­mann. So I have found it works with both star­tups and agency style projects.

The start­ing point is to under­stand that Scrum is intend­ed to be a con­tain­er. It is a process frame­work. It should be able to hold any oth­er activ­i­ty you think you need as a team. So if we feel we need to add UX some­how, we should try to make it part of Scrum and not some­thing that is tacked onto Scrum. Why not tack some­thing on? Because it sig­nals design is some­how dis­tinct from devel­op­ment. And the whole point of doing agile is to have cross-func­tion­al teams. If you set up a sep­a­rate process for design you are high­ly like­ly not to ben­e­fit from the full col­lec­tive intel­li­gence of the com­bined design and devel­op­ment team. So no, design needs to be inside of the Scrum container.

Stag­gered sprints are not the answer either because you are still split­ting the team into design and devel­op­ment, ham­per­ing cross-col­lab­o­ra­tion and trans­paren­cy. You’re basi­cal­ly invit­ing Tay­lorism back into your process—the very thing you were try­ing to get­ting away from.

When you are uncom­fort­able with putting design­ers and devel­op­ers all in the same team and the same process the answer is not to make your process more elab­o­rate, par­cel things up, and decrease “messy” inter­ac­tions. The answer is increas­ing con­ver­sa­tion, not elim­i­nat­ing it.

It turns out things aren’t remote­ly as com­pli­cat­ed as they appear to be. The key is under­stand­ing Scrum’s events. The big event hold­ing all oth­er events is the sprint. The sprint out­puts a releasable incre­ment of “done” prod­uct. The devel­op­ment team does every­thing required to achieve the sprint goal col­lab­o­ra­tive­ly deter­mined dur­ing sprint plan­ning. Nat­u­ral­ly this includes any design need­ed for the prod­uct. I think of this as the ‘pro­duc­tion’ type of design. It typ­i­cal­ly con­sists most­ly of UI design. There may already be some pre­lim­i­nary UI design avail­able at the start of the sprint but it does not have to be finished. 

What about the kind of design that is required for fig­ur­ing out what to build in the first place? It might not be obvi­ous at first, but Scrum actu­al­ly has an ongo­ing process which read­i­ly accom­mo­dates it: back­log refine­ment. These are all activ­i­ties required to get a prod­uct back­log item in shape for sprint plan­ning. This is emphat­i­cal­ly not a solo show for the prod­uct man­ag­er to con­duct. It is some­thing the whole team col­lab­o­rates on. Devel­op­ers and design­ers. In my expe­ri­ence design­ers are great at facil­i­tat­ing back­log refine­ment ses­sions. At the white­board, fig­ur­ing stuff out with the whole team ‘Lean UX’ style. 

I will admit prod­uct back­log refine­ment is Scrum’s weak point. Where it offers a lot of struc­ture for the sprints, it offers hard­ly any for the back­log refine­ment (or groom­ing as some call it). But that’s okay, we can evolve our own.

I like to use Kan­ban to man­age the process of back­log refine­ment. Items come into the pipeline as some­thing we want to elab­o­rate because we have decid­ed we want to build it (in some form or oth­er, can be just an exper­i­ment) in the next sprint or two. It then goes through var­i­ous stages of elab­o­ra­tion. At the very least cap­tur­ing require­ments in the form of user sto­ries or job sto­ries, doing sketch­es, a lo-fi pro­to­type, mock­ups and a hi-fi pro­to­type and final­ly break­ing the item down into work to be done and attach­ing an esti­mate to it. At this point it is ready to be part of a sprint. Cru­cial­ly, dur­ing this life­cy­cle of an item as it is being refined, we can and should do user research if we feel we need more data, or user test­ing if we feel it is too risky to com­mit to a fea­ture outright. 

For this kind of fig­ur­ing stuff out, this ‘plan­ning’ type of design, it makes no sense to have it be part of a sprint-like struc­ture because the work required to get it to a ‘ready’ state is much more unpre­dictable. The point of hav­ing a loos­er groom­ing flow is that it exists to elim­i­nate uncer­tain­ty for when we com­mit to an item in a sprint.

So between the sprint and back­log refine­ment, Scrum read­i­ly accom­mo­dates design. ‘Pro­duc­tion’ type design hap­pens inside of the sprint and design­ers are con­sid­ered part of the devel­op­ment team. ‘Plan­ning’ type of design hap­pens as part of back­log refinement.

So no need to tack on a sep­a­rate process. It keeps the process sim­ple and under­stand­able, thus increas­ing trans­paren­cy for the whole team. It pre­vents design from becom­ing a black box to oth­ers. And when we make design part of the con­tain­er process frame­work that is Scrum, we reap the rewards of the team’s col­lec­tive intel­li­gence and we increase our agility.

Prototyping is a team sport

Late­ly I have been bing­ing on books, pre­sen­ta­tions and arti­cles relat­ed to ‘Lean UX’. I don’t like the term, but then I don’t like the tech industry’s love for invent­ing a new label for every damn thing. I do like the things empha­sis­es: shared under­stand­ing, deep col­lab­o­ra­tion, con­tin­u­ous user feed­back. These are prin­ci­ples that have always implic­it­ly guid­ed the choic­es I made when lead­ing teams at Hub­bub and now also as a mem­ber of sev­er­al teams in the role of prod­uct designer.

In all these lean UX read­ings a thing that keeps com­ing up again and again is pro­to­typ­ing. Pro­to­types are the go-to way of doing ‘exper­i­ments’, in lean-speak. Oth­er things can be done as well—surveys, inter­views, whatever—but more often than not, assump­tions are test­ed with prototypes. 

Which is great! And also unsur­pris­ing as pro­to­typ­ing has real­ly been embraced by the tech world. And tools for rapid pro­to­typ­ing are get­ting a lot of atten­tion and inter­est as a result. How­ev­er, this comes with a cou­ple of risks. For one, some­times it is fine to stick to paper. But the lure of shiny pro­to­typ­ing tools is strong. You’d rather not show a crap­py draw­ing to a user. What if they hate it? How­ev­er, high fideli­ty pro­to­typ­ing is always more cost­ly than paper. So although well-inten­tioned, pro­to­typ­ing tools can encour­age waste­ful­ness, the bane of lean. 

There is a big­ger dan­ger which runs against the lean ethos, though. Some tools afford deep col­lab­o­ra­tion more than oth­ers. Let’s be real: none afford deep­er col­lab­o­ra­tion than paper and white­boards. There is one per­son behind the con­trols when pro­to­typ­ing with a tool. So in my view, one should only ever progress to that step once a team effort has been made to hash out the rough out­lines of what is to be pro­to­typed. Basi­cal­ly: always paper pro­to­type the dig­i­tal pro­to­type. Together. 

I have had a lot of fun late­ly play­ing with brows­er pro­to­types and with pro­to­typ­ing in Framer. But as I was get­ting back into all of this I did notice this risk: All of a sud­den there is a per­son on the team who does the pro­to­types. Unless this solo pro­to­typ­ing is pre­ced­ed by shared pro­to­typ­ing, this is a prob­lem. Because the rest of the team is left out of the think­ing-through-mak­ing which makes the pro­to­typ­ing process so valu­able in addi­tion to the testable arte­facts it outputs.

It is I think a key over­sight of the ‘should design­ers code’ debaters and to an extent one made by all pro­to­typ­ing tool man­u­fac­tur­ers: Indi­vid­u­als don’t pro­to­type, teams do. Pro­to­typ­ing is a team sport. And so the suc­cess of a tool depends not only on how well it sup­ports indi­vid­ual pro­to­typ­ing activ­i­ties but also how well it embeds itself in col­lab­o­ra­tive workflows. 

In addi­tion to the tools them­selves get­ting bet­ter at sup­port­ing col­lab­o­ra­tive work­flows, I would also love to see more tuto­ri­als, both offi­cial and from the com­mu­ni­ty, about how to use a pro­to­typ­ing tool with­in the larg­er con­text of a team doing some form of agile. Most tuto­ri­als now focus on “how do I make this thing with this tool”. Use­ful, up to a point. But a large part of pro­to­typ­ing is to arrive at “the thing” together. 

One of the lean UX things I devoured was this pre­sen­ta­tion by Bill Scott in which he talks about align­ing a pro­to­typ­ing and a devel­op­ment tech stack, so that the gap between design and engi­neer­ing is bridged not just with process­es but also with tool­ing. His exam­ple applies to web devel­op­ment and app devel­op­ment using web tech­nolo­gies. I won­der what a sim­i­lar approach looks like for native mobile app devel­op­ment. But this is the sort of thing I am talk­ing about: Smart think­ing about how to actu­al­ly do this lean thing in the real world. I believe organ­is­ing our­selves so that we can pro­to­type as a team is absolute­ly key. I will pick my tools and process­es accord­ing­ly in future.

All of the above is as usu­al most­ly a reminder to self: As a design­er your role is not to go off and work solo on bril­liant pro­to­types. Your role is to facil­i­tate such efforts by the whole team. Sure, there will be solo deep design­er­ly craft­ing hap­pen­ing. But it will not add up to any­thing if it is not embed­ded in a col­lab­o­ra­tive design and devel­op­ment framework.

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)