Vapid pro­to­typ­ing

Earlier this year Mike Migurski posted some notes from Stewart Brand’s ex­cel­lent How Buildings Learn se­ries, which I re­cently watched in its en­tirety. (I still have not fin­ished the book.)

All of Brand’s the­sis res­onates deeply with me as a soft­ware and ar­chi­tec­ture guy (not soft­ware ar­chi­tec­ture, a com­pletely dif­fer­ent thing), and it’s a hum­bling re­minder that these were thoughts from the 1990s, yet mean­while in­dus­try, me­dia, and most acad­e­mia are still run­ning with the Randian myth of an ar­chi­tect as a supreme in­tel­li­gent Creator whose sa­cred de­signs must never yield to change, not ever. Which has­n’t worked since the very dawn of time: af­ter six straight all-nighters, God fin­ished in­vent­ing the Universe and de­clared that it looked pretty good to him, then prob­a­bly re­gret­ted ever start­ing the pro­ject be­cause he had to spend the rest of his life deal­ing with ten­ants who im­me­di­ately messed with it.

In this anal­o­gous com­par­i­son be­tween tech­nol­ogy and the built en­vi­ron­ment, my own white whale has been to con­vince the ar­chi­tec­ture in­dus­try to do more “post-occupancy eval­u­a­tion,” which is more-or-less known as “user ex­pe­ri­ence re­search” in the ag­ile tech­nol­ogy / lean startup world. The idea is some­what of a com­pro­mise be­tween in­evitable, un­de­signed change and forced preser­va­tion; as­sum­ing things adapt in the fu­ture to the needs of its users or in­hab­i­tants, we can and should bring that into the do­main of the ar­chi­tect. So there is a con­certed ef­fort on the part of the build­ing’s de­sign team to bridge the gap be­tween their de­sign and its in­tent, a rea­son­able spot to be in if you want a cre­ative pro­fes­sional to be proud of the value they pro­vide to the world, and not just let things just sort-of-hap­pen by chance. To get there, they must test their prod­uct with in­hab­i­tants, make qual­i­ta­tive (and quan­ti­ta­tive) judg­ments on how wide or nar­row that gap is, and then mod­ify the prod­uct over time, and re­peat the process un­til every­one is sat­is­fied. Like true user re­search. Unfortunately, this never hap­pens.

I started talk­ing about it a bit, in re­sponse to Mike, on a top-se­cret civic tech­nol­ogy mail­ing list used by Code for America to or­ga­nize a plan for world dom­i­na­tion (months be­fore mov­ing all the dis­cus­sion over to Slack):

“Post-occupancy eval­u­a­tion” (that’s ar­chi­tect-speak for “user re­search”) has been taught in schools for decades but rarely ever prac­ticed in real life be­cause prop­erty own­ers don’t want to pay for it.

There are phys­i­cal lim­i­ta­tions that make it hard to it­er­ate on a build­ing the way you do with code, so even the fastest it­er­a­tive process is slower by an or­der of mag­ni­tude, but I also used to de­sign cof­fee shops — a lot of cof­feeshops, for the same brand, so they could eas­ily learn from one store and build the next one dif­fer­ently. It’s a bit of an irony that while for­mula re­tail tends to get a bad rap, it just hap­pens they’re some of the only ma­jor ar­chi­tec­ture clients that ac­tu­ally mea­sure and learn from the in­ter­ac­tion their cus­tomers have with their spaces.

Mike’s re­sponse:

I don’t think the “post oc­cu­pancy” term has come up, but the con­cept has come up a bunch of times. There’ve been in­ter­views with ar­chi­tects in the US and Netherlands who seem to pay at­ten­tion to their build­ings post-con­struc­tion. I don’t think the lack of this is a fail­ure of ar­chi­tects btw, but a fail­ure of how they’re hired and funded. Lots of close analo­gies to what we talk about with gov­ern­ment here, with ob­vi­ous par­al­lels to pro­cure­ment and health­care.gov.

Lou, say more about the cof­fee shops.

I to­tally failed to pick up that ball and run with it, but I think I can get to a first down by con­tin­u­ing some thoughts on a blog with very low read­er­ship (this one).

I’ll get to the cof­fee shops again in a sec­ond, but a quick com­ment on the bro­ken hir­ing and fund­ing process for ar­chi­tec­ture: ZURB re­cently pub­lished a post about how Silicon Valley is killing the de­sign agency, which is­n’t re­ally talk­ing about ar­chi­tects and ur­ban plan­ners at all, but I think is very much re­lated. For one thing, most ar­chi­tec­ture firms are run like cre­ative agen­cies, with low mar­gins on client work, and not a lot of prod­uct stew­ard­ship. If I haven’t al­ready touched on how ter­ri­ble this is for built en­vi­ron­ments in this blog or else­where, it will cer­tainly be a re­cur­ring theme in other things I say.

Now let’s talk about cof­fee shops. Or, for­mula re­tail gen­er­ally.

Formula re­tail pro­jects get to be dif­fer­ent from one-off ar­chi­tec­ture pro­jects as a busi­ness model, be­cause it makes a neat com­pro­mise be­tween pay­ing for a sin­gle be­spoke item ver­sus pay­ing the same amount for a whole bunch of very sim­i­lar items. In other words, there’s an econ­omy of scale that starts to ex­ist when your ini­tial pro­to­types aren’t dis­carded. Instead, these pro­to­types can be de­ployed any­way, be­cause your prod­uct is­n’t a sin­gle web­site that any­one in the world can reach, it’s a phys­i­cal lo­ca­tion only a small au­di­ence can visit, so the only way to reach more of your de­mo­graphic is to build more of those things in other places.

In Emeryville, there is a Peet’s Coffee (so yeah, that’s the chain I worked with) that was a pretty rad­i­cal pro­to­type. It was an ex­per­i­ment to fo­cus most of its re­tail space on beans sales rather than drinks-to-go. We went through a ton of back-and-forth it­er­a­tions (paper pro­to­typ­ing, kinda), and even­tu­ally built a real life pro­to­type to op­er­ate as a real store. After a year or so of mea­sur­ing cus­tomer in­ter­ac­tions it was deemed a fail­ure. Customers were con­fused by the kiosks, walked right past it, and or­dered drinks as they were ex­pected to do. The mar­ket for beans sales just was­n’t there. It was an ex­per­i­ment for Peet’s, one that I think taught them some re­ally im­por­tant lessons about their cus­tomers. But they did­n’t scut­tle and re­place that store. It’s still op­er­at­ing in Emeryville, a rem­nant in time of that ex­per­i­ment.

It’s a no­table ex­am­ple be­cause I can pick on it, and you can see it, but what’s less vis­i­ble is the it­er­a­tions that we did on the for­mula that you would never see oth­er­wise, un­less they were side by side. Like vis­it­ing a page on a day by day ba­sis from the Internet Wayback Machine, changes hap­pened sub­tly and un­evenly over time, but across dif­fer­ent stores in some­times wildly dis­parate phys­i­cal lo­ca­tions. You might not be able to tell the dif­fer­ence be­tween the Peet’s in Redwood City and the one in Concord. But I could walk any Peet’s de­signed in the last decade and tell you ap­prox­i­mately what year it was built. The clues are in how cer­tain pieces of fur­ni­ture are con­structed, whether some pieces were there or some newer ones were plugged in, how we laid tile, the col­ors of the walls, the kind of wa­ter­proof ma­te­r­ial used be­hind the bar, the shape of the bar it­self, and the arrange­ment of cer­tain pieces of equip­ment. To name a few.

It’s be­cause for­mula re­tail gives us one thing in the built en­vi­ron­ment that most other ar­chi­tec­ture pro­jects can­not: re­de­ploy­a­bil­ity.

The very de­rided na­ture of its cookie-cut­ter, one-size-fits-most de­sign style is the ex­actly the kind of rapid ex­per­i­men­ta­tion that lets Peet’s ar­chi­tects A/B test their prod­uct and make mod­i­fi­ca­tions from one store open­ing to next mon­th’s store open­ing. Each Peet’s is not an in­di­vid­ual prod­uct, but rather, all Peet’s are a sin­gle prod­uct, with many in­stances de­ployed from var­i­ous lo­ca­tions in its Git his­tory. And it fits so well into the busi­ness model of ex­pand­ing stores into new mar­kets that one for­gets they’re do­ing any user re­search at all.

This is not unique to Peet’s, of course. Retail psy­chol­ogy and tweak­ing spaces to in­flu­ence con­sumer be­hav­ior is a well-trod busi­ness and mar­ket­ing sub­ject mat­ter. Any ma­jor chain does it. But no one sat down and said, “I know, I’ll do X!” and in­stantly per­fected their for­mula–at least, I’d doubt any­one got it right the first try. That chain got there by re­lent­less user re­search, col­lect­ing met­rics and ex­per­i­men­ta­tion. Then they put to­gether a liv­ing style guide, grow­ing as economies and tastes change. Next, they scaled up, re­de­ploy­ing in­stances as far as they could throw them.

So that’s how user re­search, rapid pro­to­typ­ing and it­er­a­tive pro­ject de­vel­op­ment hap­pens in ar­chi­tec­ture, an in­dus­try that gen­er­ally is ser­vice-ori­ented rather than prod­uct-ori­ented. But it’s a lit­tle per­verse, if you think about it: that the only way to fo­cus on your users is by fig­ur­ing out how to fit it into a busi­ness model based on an econ­omy of scale. The re­search is dri­ven by profit seek­ing to the ex­tent that it only ben­e­fits ex­ec­u­tives and share­hold­ers fi­nan­cially; cus­tomer ex­pe­ri­ence is im­proved be­cause it helps you part with your money eas­ier, and we never man­aged to achieve any sort of con­cern for the em­ployee ex­pe­ri­ence as well. I had a store man­ager plead with me to do some­thing about their com­plete lack of counter space, but there was­n’t any­thing I could do about it.

So there is still a long ways to go.