I am all for user-driven 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­nally about things” and all that. That per­spec­tive is based on a simul­ta­ne­ous over-valuing of a lin­ear, ratio­nal notion of process (“plan­ning”) and a grudg­ing accep­tance of user behav­ior as “cul­tural” and there­fore out­side the scope a require­ments gath­er­ing process.

The term “non-functional require­ments” speaks vol­umes and cap­tures the Cen­tral IT atti­tude very well. Under that cat­e­gory, 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 versa, 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­nity to inno­vate, leav­ing that to the less timid.

But I also find that user-centric 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 restricted audi­ence for your software–and admit­tedly 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 participant-observation, into gen­er­al­ized prin­ci­ples for an appli­ca­tion. Ulti­mately, good design is what works, and we ret­ro­spec­tively attribute suc­cess to our process. But we really have no clue.

What is it that one is cap­tur­ing by user-centric research, any­way? The atti­tudes and dis­po­si­tions within a class of indi­vid­u­als? This can’t be it. User atti­tudes and men­tal mod­els are highly 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­tic notion of what users want, what they say they want, you will miss the effect soft­ware has on redefin­ing what they really want. This is because users inhabit cul­tural 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­gether as fickle 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 proper focus of user-centric soft­ware design has to be the user-in-context. That is, not the user but the Sit­u­a­tion. But sutu­a­tion defined in a spe­cific, rig­or­ous way. Sit­u­a­tion as the objec­tive, insti­tu­tional frame­work of power 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 example.

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 drive 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­cratic that it is impos­si­ble for users to describe them in enough detail to re-engineer 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, document-logic 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 likely, we’ve pre­served the noto­ri­ous stu­pid­ity 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 encoded in insti­tu­tional data­bases, the tail wags the dog. Think health insurance.

So, what to do? I sug­gest that we pur­sue theory-driven design. We actu­ally try to make sense of the soci­ol­ogy and anthro­pol­ogy of bureau­cra­cies and oper­a­tional­ize the best ideas in these dis­courses as design prin­ci­ples. We think of how soft­ware behaves as an assem­blage of arti­facts in a liv­ing cul­tural envi­ron­ment. This is not social engi­neer­ing, nor is it to tread the tired path of “orga­ni­za­tional behav­ior,” a field that is too closely 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.

Theory-driven design is not anti-empirical. It is the oppo­site: for a good the­ory gen­er­ates testable hypothe­ses. It gives a frame­work to user-centric research beyond the unan­swer­able quest for what users really want. As they say, there is noth­ing so prac­ti­cal as a good theory.

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­ogy of bureau­cracy. Not to con­done the anar­chism of Grae­ber, but to lever the authen­tic­ity 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 power, igno­rance and stu­pid­ity,” it is hard not to believe that a rad­i­cal rethink­ing of the doc­u­ment, and document-logic, would not ben­e­fit from his perspective.

This entry was posted on Monday, May 11th, 2009 at 10:41 am and is filed under Software Design. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.