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.

Published by

Kars Alfrink

Kars is a designer, researcher and educator focused on emerging technologies, social progress and the built environment.

4 thoughts on “Prototyping is a team sport”

  1. I’ve run sev­er­al teams fol­low­ing the lean UX approach. 

    What seems to have the biggest impact is mak­ing the fol­low­ing two activ­i­ties a team effort: — Hypoth­e­sis for­mu­la­tion — Eval­u­a­tion of the required pro­to­type fideli­ty to answer the hypothesis.

    This cre­ates the required buy-in on the goal and method, and makes arriv­ing at the required fideli­ty a team respon­si­bil­i­ty. Com­bin­ing this with “go-no-go moments” where every­one can pro­vide input, on whether the pro­to­type reached a state where it can answer the hypoth­e­sis makes it a much more grad­ual proces.

    The chal­leng­ing part is that every­one has a dif­fer­ent inter­pre­ta­tion of what “answers” a hypoth­e­sis. This tends to get bet­ter over time as the team gets more famil­iar with user research and gets expo­sure to dif­fer­ent methods. 

    While the UX-team of one is help­ful to keep a high pace, it tends to lim­it you to hypoth­e­sis you as a design­er can pro­to­type. As Bill Scott clear­ly lays out, todays chal­lenges often require a set of dif­fer­ent skills rarely found in one person. 

    Few agile teams are cur­rent­ly posi­tioned to ful­ly com­mit them­selves to a experiment/lean UX approach. It seems that the 20% time type projects are cur­rent­ly best posi­tioned to get them on the fast track to pro­duc­tion by apply­ing lean UX processes. 

    My impres­sion is that few teams out­side the val­ley have got­ten to run a con­tin­u­ous exper­i­men­ta­tion pro­gram. This is sub­ject to change, but might explain the lim­it­ed discussion.

  2. Thanks for drop­ping by and leav­ing such a thought­ful comment!

    Few agile teams are cur­rent­ly posi­tioned to ful­ly com­mit them­selves to a experiment/lean UX approach.

    Why do you think that is?

  3. Good ques­tion! I think its large­ly because they are stuck in an oper­a­tional role, where the out­comes are not mea­sured by impact on the user/business but by num­ber of fea­tures created. 

    Teams where this mea­sure by impact is already at the core (e.g. inno­va­tion or opti­mi­sa­tion depart­ments) are much more able to make the transitions.

    Busi­ness­es are often risk-adverse, while exper­i­men­ta­tion should reduce the risk (val­i­da­tion before going through the entire pro­duc­tion fun­nel). Many busi­ness­es still see it as some­thing that diverts resources from “sure things”.

    Prod­ucts nowa­days reach the plateau (in Jared Spool’s matu­ri­ty mod­el; stage 3: Pro­duc­tiv­i­ty Wars) much ear­li­er, and there­for expec­ta­tions are high­er. I expect this trend to con­tin­ue and with that the rel­e­vance of the exper­i­men­tal approach.

Comments are closed.