Tag Archives: design

Theory Driven Design

I am all for user-dri­ven design method­olo­gies. My instinct is to dis­trust the Cen­tral IT ethos of “we know bet­ter” because “we think more ratio­nal­ly about things” and all that.  That per­spec­tive is based on a simul­ta­ne­ous over-valu­ing of a lin­ear, ratio­nal notion of process (“plan­ning”) and a grudg­ing accep­tance of user behav­ior as “cul­tur­al” and there­fore out­side the scope a require­ments gath­er­ing process.

The term “non-func­tion­al require­ments” speaks vol­umes and cap­tures the Cen­tral IT atti­tude very well.  Under that cat­e­go­ry, the whole point of effec­tive soft­ware design is swept under the rug.  We know that soft­ware will be most effec­tive when it adapts to user behav­ior and vice ver­sa, but we often side­step that issue, hop­ing for incre­men­tal, evo­lu­tion­ary changes to pro­duce the desired effects over the long run.  We miss the oppor­tu­ni­ty to inno­vate, leav­ing that to the less timid.

But I also find that user-cen­tric method­olo­gies are based on naive assump­tions about what users want, or who The User is, or what the point of the user research is in the first place.  Unless you have a very restrict­ed audi­ence for your software–and admit­ted­ly one often does–it is very dif­fi­cult to trans­late the views of a few peo­ple, whether cap­tured by focus group, sur­vey, or even par­tic­i­pant-obser­va­tion, into gen­er­al­ized prin­ci­ples for an appli­ca­tion.  Ulti­mate­ly, good design is what works, and we ret­ro­spec­tive­ly attribute suc­cess to our process.  But we real­ly have no clue.

What is it that one is cap­tur­ing by user-cen­tric research, any­way?  The atti­tudes and dis­po­si­tions with­in a class of indi­vid­u­als?  This can’t be it.  User atti­tudes and men­tal mod­els are high­ly vari­able, and they are muta­ble because humans are adap­tive, more than we think.  If you build soft­ware based on some sta­t­ic notion of what users want, what they say they want, you will miss the effect soft­ware has on redefin­ing what they real­ly want.  This is because users inhab­it cul­tur­al envi­ron­ments, and soft­ware inevitably has effects on those envi­ron­ments.  If you focus too much on the abstract user–what’s “in” the user–you will often have the feel­ing of the goal posts mov­ing.  Or you may end up dis­miss­ing the user alto­geth­er as fick­le and irre­spon­si­ble, and go on with your own design ideas.   If you design soft­ware for a liv­ing, I am sure you know what I am talk­ing about.

I think the prop­er focus of user-cen­tric soft­ware design has to be the user-in-con­text.  That is, not the user but the Sit­u­a­tion.  But sutu­a­tion defined in a spe­cif­ic, rig­or­ous way.  Sit­u­a­tion as the objec­tive, insti­tu­tion­al frame­work of pow­er and infra­struc­ture in which peo­ple work.  This is dif­fi­cult ter­rain to study, hedged in as it is by all sort of taboos and mis­recog­ni­tions that keep the social gears mov­ing.  Let me give you an exam­ple.

One of the areas where the Cen­tral IT soft­ware design ethos dom­i­nates is in the area of doc­u­ment man­age­ment.  Two fac­tors dri­ve the design of solu­tions: (1) devel­op­ers assume (know) that paper­less­ness is a Good Thing, and (2) the paper-based work­flows that users are enmeshed in are so crufty, com­plex, and idio­syn­crat­ic that it is impos­si­ble for users to describe them in enough detail to re-engi­neer them.  The result is that the dig­i­tal doc­u­ment man­age­ment solu­tion will almost always build around people’s behav­ior, or else it will break work­flows where it has to.  So, instead of step­ping back and rethink­ing what the data flows entailed by a paper form entail, or tak­ing advan­tage of the metaso­cial moment and ask­ing Why are We Doing This in the First Place, doc­u­ment-log­ic is repro­duced in the soft­ware.  The eff­fect is not to repro­duce the old way, and make it more effi­cient.  It is some­thing unpre­dictable and bound to have hid­den con­se­quences, not all of which can be good.  Most like­ly, we’ve pre­served the noto­ri­ous stu­pid­i­ty of bureau­cra­cies and have ensured its con­tin­ued sur­vival in a mutant  and more pow­er­ful form.  Because once cat­e­gories get encod­ed in insti­tu­tion­al data­bas­es, the tail wags the dog.  Think health insur­ance.

So, what to do?  I sug­gest that we pur­sue the­o­ry-dri­ven design.  We actu­al­ly try to make sense of the soci­ol­o­gy and anthro­pol­o­gy of bureau­cra­cies and oper­a­tional­ize the best ideas in these dis­cours­es as design prin­ci­ples.  We think of how soft­ware behaves as an assem­blage of arti­facts in a liv­ing cul­tur­al envi­ron­ment.  This is not social engi­neer­ing, nor is it to tread the tired path of “orga­ni­za­tion­al behav­ior,” a field that is too close­ly tied to the exec­u­tive per­spec­tive.  It is to pur­sue a rich, empir­i­cal under­stand­ing of soft­ware in the wild, or at least, the office.

The­o­ry-dri­ven design is not anti-empir­i­cal.  It is the oppo­site: for a good the­o­ry gen­er­ates testable hypothe­ses.  It gives a frame­work to user-cen­tric research beyond the unan­swer­able quest for what users real­ly want.  As they say, there is noth­ing so prac­ti­cal as a good the­o­ry.

A good start­ing point might be to take Ted Nelson’s ideas about doc­u­ments and hyper­text and com­bine them with, say, David Graeber’s crit­i­cal anthro­pol­o­gy of bureau­cra­cy.    Not to con­done the anar­chism of Grae­ber, but to lever the authen­tic­i­ty of per­spec­tive he brings to a dis­cus­sion about the role of doc­u­ments in the orga­ni­za­tion.  Read­ing his essay, “Beyond Power/Knowledge an explo­ration of the rela­tion of pow­er, igno­rance and stu­pid­i­ty,” it is hard not to believe that a rad­i­cal rethink­ing of the doc­u­ment, and doc­u­ment-log­ic, would not ben­e­fit from his per­spec­tive.