Category: Articles

Move 37

Design­ers make choic­es. They should be able to pro­vide ratio­nales for those choic­es. (Although some­times they can’t.) Being able to explain the think­ing that went into a design move to your­self, your team­mates and clients is part of being a pro­fes­sion­al.

Move 37. This was the move Alpha­Go made which took every­one by sur­prise because it appeared so wrong at first.

The inter­est­ing thing is that in hind­sight it appeared Alpha­Go had good rea­sons for this move. Based on a cal­cu­la­tion of odds, basically.

If asked at the time, would Alpha­Go have been able to pro­vide this rationale?

It’s a thing that pops up in a lot of the read­ing I am doing around AI. This idea of trans­paren­cy. In some fields you don’t just want an AI to pro­vide you with a deci­sion, but also with the argu­ments sup­port­ing that deci­sion. Obvi­ous exam­ples would include a sys­tem that helps diag­nose dis­ease. You want it to pro­vide more than just the diag­no­sis. Because if it turns out to be wrong, you want to be able to say why at the time you thought it was right. This is a social, cul­tur­al and also legal requirement.

It’s inter­est­ing.

Although lives don’t depend on it, the same might apply to intel­li­gent design tools. If I am work­ing with a sys­tem and it is offer­ing me design direc­tions or solu­tions, I want to know why it is sug­gest­ing these things as well. Because my rea­son for pick­ing one over the oth­er depends not just on the sur­face lev­el prop­er­ties of the design but also the under­ly­ing rea­sons. It might be impor­tant because I need to be able to tell stake­hold­ers about it.

An added side effect of this is that a design­er work­ing with such a sys­tem is be exposed to machine rea­son­ing about design choic­es. This could inform their own future think­ing too.

Trans­par­ent AI might help peo­ple improve them­selves. A black box can’t teach you much about the craft it’s per­form­ing. Look­ing at out­comes can be inspi­ra­tional or help­ful, but the process­es that lead up to them can be equal­ly infor­ma­tive. If not more so.

Imag­ine work­ing with an intel­li­gent design tool and get­ting the equiv­a­lent of an Alpha­Go move 37 moment. Huge­ly inspi­ra­tional. Game changer.

This idea gets me much more excit­ed than automat­ing design tasks does.

Books I’ve read in 2016

I’ve read 32 books, which is four short of my goal and also four less than the pre­vi­ous year. It’s still not a bad score though and qual­i­ty wise the list below con­tains many gems.

I resolved to read most­ly books by women and minor­i­ty authors. This lead to quite a few sur­pris­ing expe­ri­ences which I am cer­tain­ly grate­ful for. I think I’ll con­tin­ue to push myself to seek out such books in the year to come.

There are only a few comics in the list. I sort of fell off the comics band­wag­on this year main­ly because I just can’t seem to find a good place to dis­cov­er things to read.

Any­way, here’s the list, with links to my reviews on Goodreads. A * denotes a par­tic­u­lar favourite.

Favourite music albums of 2016

I guess this year final­ly marked the end of my album lis­ten­ing behav­iour. Spo­ti­fy’s Dis­cov­er and Dai­ly Mix fea­tures were the one-two punch that knocked it out. In addi­tion I some­how stopped scrob­bling to Last.fm in March. It’s switched back on now but the dam­age is done.

So the data I do have is incom­plete. I did still delib­er­ate­ly put on a num­ber of albums this year. But I won’t post them in order of lis­tens like I did last year. This is sub­jec­tive, unsort­ed and hand-picked. I will even sneak in a few albums that were pub­lished towards the end of 2015.

My sources includ­ed Pitch­fork’s list of best new albums which used to be how I dis­cov­ered new music and still wields some influ­ence. I cross-ref­er­enced with Spo­ti­fy’s top songs of 2016.

So first Spo­ti­fy tells me what to lis­ten to and then it gives me a list of things I actu­al­ly lis­tened to. This is get­ting weird…

Any­way, here they are. A * marks a par­tic­u­lar favourite.

  • A Tribe Called Quest – We Got It From Here… *
  • Solange – A Seat At the Table
  • Hamil­ton Lei­thauser + Ros­tam – I Had A Dream That You Were Mine
  • The Avalanch­es – Wildflower *
  • Blood Orange – Free­town Sound
  • Whit­ney – Light Upon the Lake
  • Car Seat Head­rest – Teens Of Denial *
  • Chance The Rap­per – Col­or­ing Book *
  • ANOHNI – HOPELESSNESS
  • Moody­mann – DJ-Kicks *
  • Grimes – Art Angels * 
  • Float­ing Points – Elaenia
  • The Range – Potential *
  • Sepal­cure – Fold­ing Time
  • Jami­la Woods – HEAVN

Here’s a playlist which includes a cou­ple of more albums if you want to have a listen.

A year of two crashes

A year ago today I was in Bali. 

We spent the bet­ter part of Decem­ber 2015 there. It was­n’t real­ly a hol­i­day, but we weren’t real­ly work­ing either. I was wrap­ping up a few final Hub­bub things back then. But for the most part life was qui­et. Very qui­et. We would get up real­ly ear­ly. We would buy some veg­eta­bles and things from a lady who would dri­ve into town every morn­ing with a load from the market. 

I’d swim, exer­cise, med­i­tate, have break­fast and do some work. Writ­ing and read­ing most­ly. By the end of the morn­ing we would cook lunch. The major meal of the day. In the after­noon we would­n’t do much of any­thing because of the heat. Decem­ber is rainy sea­son in Bali and it gets incred­i­bly hot and humid. Towards dusk we would often take a walk. We would have an ear­ly light din­ner and enter­tain our­selves with the antics of tokay geck­os. We would turn in early.

Now I am writ­ing this back in our home in Utrecht. In many ways my life has returned to the way it was before that month in Bali. But in oth­er ways it has changed. I used to run a small agency and would be in the stu­dio almost every day. Now I am free­lanc­ing and I split my time between work­ing on site at clients, work­ing from home and meet­ing up with peo­ple in town. I enjoy the variety.

I used to be in the busi­ness of design­ing games and play­things for learn­ing and oth­er pur­pos­es. Now I am back to my old voca­tion of inter­ac­tion design and in the­o­ry I can and work on anything. 

Towards the end of Hub­bub’s run I felt boxed in. Now I feel like I can pur­sue what­ev­er inter­ests me.

Right now, under the ban­ner of Eend I am help­ing the Dutch vic­tim sup­port foun­da­tion devel­op new dig­i­tal ser­vices. I spend about three days a week work­ing on site as part of cross-dis­ci­pli­nary agile team made up of a mix of inter­nal and exter­nal peo­ple. It’s good, impor­tant work and I can con­tribute a lot.

The time that remains I divide between the usu­al free­lancer things like admin, net­work­ing and so on, and devel­op­ing a plan for a PhD. 

I’ve been blog­ging on and off about intel­li­gent design tools this year and that is no coin­ci­dence. I am con­sid­er­ing going into research full­time to work in that space. It is still ear­ly days but I am hav­ing fun read­ing up on the sub­ject, writ­ing, mak­ing plans, and talk­ing to peo­ple in acad­e­mia about it.

In between this ‘new nor­mal’ and those qui­et days in Bali was a year of two crash­es. I basi­cal­ly start­ed from scratch in many ways twice this year and I feel like it has helped me get reori­ent­ed.

Crash one.

In Jan­u­ary we moved to Sin­ga­pore. We would end up spend­ing sev­en months there. In that time I joined a start­up called ARTO. I helped build a team, devel­op a design and devel­op­ment process and act­ed as prod­uct man­ag­er and prod­uct design­er. We launched a first ver­sion of the prod­uct in that peri­od and we pushed out a cou­ple of new fea­tures as well. The last thing I did was find a replace­ment for myself.

In between work­ing on ARTO I taught a two-part engage­ment design work­shop with Michael and helped Edo and his team build ArtHit. I got into run­ning and ate my way through the abun­dance of amaz­ing food Sin­ga­pore has to offer.

Of all the things I enjoyed about Sin­ga­pore, its cos­mopoli­tanism has to be the absolute high­light. I worked with peo­ple from Myan­mar, Malaysia, Viet­nam and India. I made friends with peo­ple from many more places. Dis­cov­er­ing the things we have in com­mon and the things that set us apart was a con­tin­u­ous source of enjoyment. 

And like that, just when we were get­ting set­tled and had got­ten into a rou­tine of sorts and start­ed to feel at home it was time to go back to the Nether­lands. (But not before spend­ing a cou­ple of weeks explor­ing Viet­nam and Cam­bo­dia. More great food and gor­geous sights.)

Crash two.

It is weird to have cul­ture shock in a town you’ve spent most of your life in but that was what it felt like for about the first month back in Utrecht. Sep­tem­ber felt very sim­i­lar to Jan­u­ary. I had no work and was net­work­ing like a mad­man and just play­ing the num­bers game. Hop­ing I would bump into some­thing. And of course, as it always does even­tu­al­ly, things worked out.

I con­sid­er myself blessed to be able to take these risks and more or less trust things will turn out okay. I know that if they don’t there are always peo­ple around me who will sup­port me if worse comes to worse.

2017 looks to be a year of more sta­bil­i­ty although one can nev­er be sure. World events as well as occur­rences in my per­son­al cir­cles this year have shown me once again there are no guar­an­tees in life. 

But I plan to build on what I’ve start­ed these past few months and see where it takes me. It is time to shift from ori­ent­ing to decid­ing and act­ing. And for the fore­see­able future I plan to keep the cur­rent ‘sys­tem’ running. 

So no more crash­es for the time being. Although I am sure there will come a time when the need for it aris­es again.

Waiting for the smart city

Nowa­days when we talk about the smart city we don’t nec­es­sar­i­ly talk about smart­ness or cities.

I feel like when the term is used it often obscures more than it reveals. 

Here a few rea­sons why. 

To begin with, the term sug­gests some­thing that is yet to arrive. Some kind of tech-enabled utopia. But actu­al­ly, cur­rent day cities are already smart to a greater or less­er degree depend­ing on where and how you look.

This is impor­tant because too often we post­pone action as we wait for the smart city to arrive. We don’t have to wait. We can act to improve things right now.

Fur­ther­more, ‘smart city’ sug­gests some­thing mono­lith­ic that can be designed as a whole. But a smart city, like any city, is a huge mess of inter­con­nect­ed things. It resists top­down design. 

His­to­ry is lit­tered with failed attempts at author­i­tar­i­an high-mod­ernist city design. Just stop it.

Smart­ness should not be an end but a means. 

I read ‘smart’ as a short­hand for ‘tech­no­log­i­cal­ly aug­ment­ed’. A smart city is a city eat­en by soft­ware. All cities are being eat­en (or have been eat­en) by soft­ware to a greater or less­er extent. Uber and Airbnb are obvi­ous exam­ples. Small­er more sub­tle ones abound.

The ques­tion is, smart to what end? Effi­cien­cy? Leg­i­bil­i­ty? Con­trol­la­bil­i­ty? Anti-fragili­ty? Playa­bil­i­ty? Live­abil­i­ty? Sus­tain­abil­i­ty? The answer depends on your outlook.

These are ways in which the smart city label obscures. It obscures agency. It obscures net­works. It obscures intent.

I’m not say­ing don’t ever use it. But in many cas­es you can get by with­out it. You can talk about spe­cif­ic parts that make up the whole of a city, spe­cif­ic tech­nolo­gies and spe­cif­ic aims. 

Post­script 1

We can do the same exer­cise with the ‘city’ part of the meme. 

The same process that is mak­ing cities smart (soft­ware eat­ing the world) is also mak­ing every­thing else smart. Smart towns. Smart coun­try­sides. The ends are dif­fer­ent. The net­works are dif­fer­ent. The process­es play out in dif­fer­ent ways.

It’s okay to think about cities but don’t think they have a monop­oly on ‘dis­rup­tion’.

Post­script 2

Some of this inspired by clever things I heard Sebas­t­ian Quack say at Play­ful Design for Smart Cities and Usman Haque at ThingsCon Ams­ter­dam.

Adapting intelligent tools for creativity

I read Alper’s book on con­ver­sa­tion­al user inter­faces over the week­end and was struck by this paragraph:

“The holy grail of a con­ver­sa­tion­al sys­tem would be one that’s aware of itself — one that knows its own mod­el and inter­nal struc­ture and allows you to change all of that by talk­ing to it. Imag­ine being able to tell Siri to tone it down a bit with the jokes and that it would then actu­al­ly do that.”

His point stuck with me because I think this is of par­tic­u­lar impor­tance to cre­ative tools. These need to be flex­i­ble so that a vari­ety of peo­ple can use them in dif­fer­ent cir­cum­stances. This adapt­abil­i­ty is what lends a tool depth.

The depth I am think­ing of in cre­ative tools is sim­i­lar to the one in games, which appears to be derived from a kind of semi-ordered­ness. In short, you’re look­ing for a sweet spot between too sim­ple and too complex.

And of course, you need good defaults.

Back to adap­ta­tion. This can hap­pen in at least two ways on the inter­face lev­el: modal or mod­e­less. A sim­ple exam­ple of the for­mer would be to go into a pref­er­ences win­dow to change the behav­iour of your draw­ing pack­age. Sim­i­lar­ly, mod­e­less adap­ta­tion hap­pens when you rearrange some pan­els to bet­ter suit the task at hand.

Return­ing to Siri, the equiv­a­lence of mod­e­less adap­ta­tion would be to tell her to tone it down when her sense of humor irks you. 

For the modal solu­tion, imag­ine a humor slid­er in a set­tings screen some­where. This would be a ter­ri­ble solu­tion because it offers a poor map­ping of a con­trol to a per­son­al­i­ty trait. Can you pin­point on a scale of 1 to 10 your pre­ferred amount of humor in your hypo­thet­i­cal per­son­al assis­tant? And any­way, doesn’t it depend on a lot of sit­u­a­tion­al things such as your mood, the par­tic­u­lar task you’re try­ing to com­plete and so on? In short, this requires some­thing more sit­u­at­ed and adaptive. 

So just being able to tell Siri to tone it down would be the equiv­a­lent of rear­rang­ing your Pho­to­shop palets. And in a next inter­ac­tion Siri might care­ful­ly try some humor again to gauge your response. And if you encour­age her, she might be more humor­ous again.

Enough about fun­ny Siri for now because it’s a bit of a sil­ly example.

Fun­ny Siri, although she’s a bit of a Sil­ly exam­ple, does illus­trate anoth­er prob­lem I am try­ing to wrap my head around. How does an intel­li­gent tool for cre­ativ­i­ty com­mu­ni­cate its inter­nal state? Because it is prob­a­bilis­tic, it can’t be eas­i­ly mapped to a graph­ic infor­ma­tion dis­play. And so our old way of manip­u­lat­ing state, and more specif­i­cal­ly adapt­ing a tool to our needs becomes very dif­fer­ent too.

It seems to be best for an intel­li­gent sys­tem to be open to sug­ges­tions from users about how to behave. Adapt­ing an intel­li­gent cre­ative tool is less like rear­rang­ing your work­space and more like coor­di­nat­ing with a coworker. 

My ide­al is for this to be done in the same mode (and so using the same con­trols) as when doing the work itself. I expect this to allow for more flu­id inter­ac­tions, going back and forth between doing the work at hand, and meta-com­mu­ni­ca­tion about how the sys­tem sup­ports the work. I think if we look at how peo­ple col­lab­o­rate this hap­pens a lot, com­mu­ni­ca­tion and meta-com­mu­ni­ca­tion going on con­tin­u­ous­ly in the same channels.

We don’t need a self-aware arti­fi­cial intel­li­gence to do this. We need to apply what com­put­er sci­en­tists call super­vised learn­ing. The basic idea is to pro­vide a sys­tem with exam­ple inputs and desired out­puts, and let it infer the nec­es­sary rules from them. If the results are unsat­is­fac­to­ry, you sim­ply con­tin­ue train­ing it until it per­forms well enough. 

A super fun exam­ple of this approach is the Wek­ina­tor, a piece of machine learn­ing soft­ware for cre­at­ing musi­cal instru­ments. Below is a video in which Wekinator’s cre­ator Rebec­ca Fiebrink per­forms sev­er­al demos.

Here we have an intel­li­gent sys­tem learn­ing from exam­ples. A per­son manip­u­lat­ing data in stead of code to get to a par­tic­u­lar desired behav­iour. But what Wek­ina­tor lacks and what I expect will be required for this type of thing to real­ly catch on is for the train­ing to hap­pen in the same mode or medi­um as the per­for­mance. The tech­nol­o­gy seems to be get­ting there, but there are many inter­ac­tion design prob­lems remain­ing to be solved. 

Singapore

I am back in the Nether­lands for over sev­en weeks now but I am still busy run­ning around the coun­try recon­nect­ing to peo­ple and telling them about my expe­ri­ences in Singapore. 

It was great. 

I real­ly did man­age to recon­sid­er a lot of things and got reori­ent­ed, about which more later.

Learned a lot about myself and oth­ers by meet­ing and work­ing with lots of new peo­ple from dif­fer­ent backgrounds. 

And I do miss the city already. The iron-clad guar­an­tee of sun and warmth. Many places to explore offer­ing lots of sur­pris­ing expe­ri­ences. And on every street cor­ner, amaz­ing afford­able food. 

I will miss Sin­ga­pore, and I am thank­ful for all it has done for me in the brief peri­od I got to call it my home.

Below are some pho­tos. More are over at Flickr. Hap­py scrolling and maybe don’t look at these if you’re hungry.

Con­tin­ue read­ing Sin­ga­pore

Generating UI design variations

AI design tool for UI design alternatives

I am still think­ing about AI and design. How is the design process of AI prod­ucts dif­fer­ent? How is the user expe­ri­ence of AI prod­ucts dif­fer­ent? Can design tools be improved with AI?

When it comes to improv­ing design tools with AI my start­ing point is game design and devel­op­ment. What fol­lows is a quick sketch of one idea, just to get it out of my system.

‘Mixed-ini­tia­tive’ tools for pro­ce­dur­al gen­er­a­tion (such as Tana­gra) allow design­ers to cre­ate high-lev­el struc­tures which a machine uses to pro­duce full-fledged game con­tent (such as lev­els). It hap­pens in a real-time. There is a con­tin­u­ous back-and-forth between design­er and machine.

Soft­ware user inter­faces, on mobile in par­tic­u­lar, are increas­ing­ly fre­quent­ly assem­bled from ready-made com­po­nents accord­ing to more or less well-described rules tak­en from design lan­guages such as Mate­r­i­al Design. These design lan­guages are cur­rent­ly pri­mar­i­ly described for human con­sump­tion. But it should be a small step to make a design lan­guage machine-readable.

So I see an oppor­tu­ni­ty here where a design­er might assem­ble a UI like they do now, and a machine can do sev­er­al things. For exam­ple it can test for adher­ence to design lan­guage rules, sug­gest cor­rec­tions or even auto-cor­rect as the design­er works.

More inter­est­ing­ly, a machine might take one UI mock­up, and pro­vide the design­er with sev­er­al more pos­si­ble vari­a­tions. To do this it could use dif­fer­ent lay­outs, or alter­na­tive com­po­nents that serve a same or sim­i­lar pur­pose to the ones used. 

In high pres­sure work envi­ron­ments where time is scarce, cor­ners are often cut in the diver­gence phase of design. Machines could aug­ment design­ers so that gen­er­at­ing many design alter­na­tives becomes less labo­ri­ous both men­tal­ly and phys­i­cal­ly. Ide­al­ly, machines would sur­prise and even inspire us. And the final say would still be ours.

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.