I am all for user-driven design methodologies. My instinct is to distrust the Central IT ethos of “we know better” because “we think more rationally about things” and all that. That perspective is based on a simultaneous over-valuing of a linear, rational notion of process (“planning”) and a grudging acceptance of user behavior as “cultural” and therefore outside the scope a requirements gathering process.
The term “non-functional requirements” speaks volumes and captures the Central IT attitude very well. Under that category, the whole point of effective software design is swept under the rug. We know that software will be most effective when it adapts to user behavior and vice versa, but we often sidestep that issue, hoping for incremental, evolutionary changes to produce the desired effects over the long run. We miss the opportunity to innovate, leaving that to the less timid.
But I also find that user-centric methodologies are based on naive assumptions 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 audience for your software–and admittedly one often does–it is very difficult to translate the views of a few people, whether captured by focus group, survey, or even participant-observation, into generalized principles for an application. Ultimately, good design is what works, and we retrospectively attribute success to our process. But we really have no clue.
What is it that one is capturing by user-centric research, anyway? The attitudes and dispositions within a class of individuals? This can’t be it. User attitudes and mental models are highly variable, and they are mutable because humans are adaptive, more than we think. If you build software based on some static notion of what users want, what they say they want, you will miss the effect software has on redefining what they really want. This is because users inhabit cultural environments, and software inevitably has effects on those environments. If you focus too much on the abstract user–what’s “in” the user–you will often have the feeling of the goal posts moving. Or you may end up dismissing the user altogether as fickle and irresponsible, and go on with your own design ideas. If you design software for a living, I am sure you know what I am talking about.
I think the proper focus of user-centric software design has to be the user-in-context. That is, not the user but the Situation. But sutuation defined in a specific, rigorous way. Situation as the objective, institutional framework of power and infrastructure in which people work. This is difficult terrain to study, hedged in as it is by all sort of taboos and misrecognitions that keep the social gears moving. Let me give you an example.
One of the areas where the Central IT software design ethos dominates is in the area of document management. Two factors drive the design of solutions: (1) developers assume (know) that paperlessness is a Good Thing, and (2) the paper-based workflows that users are enmeshed in are so crufty, complex, and idiosyncratic that it is impossible for users to describe them in enough detail to re-engineer them. The result is that the digital document management solution will almost always build around people’s behavior, or else it will break workflows where it has to. So, instead of stepping back and rethinking what the data flows entailed by a paper form entail, or taking advantage of the metasocial moment and asking Why are We Doing This in the First Place, document-logic is reproduced in the software. The efffect is not to reproduce the old way, and make it more efficient. It is something unpredictable and bound to have hidden consequences, not all of which can be good. Most likely, we’ve preserved the notorious stupidity of bureaucracies and have ensured its continued survival in a mutant and more powerful form. Because once categories get encoded in institutional databases, the tail wags the dog. Think health insurance.
So, what to do? I suggest that we pursue theory-driven design. We actually try to make sense of the sociology and anthropology of bureaucracies and operationalize the best ideas in these discourses as design principles. We think of how software behaves as an assemblage of artifacts in a living cultural environment. This is not social engineering, nor is it to tread the tired path of “organizational behavior,” a field that is too closely tied to the executive perspective. It is to pursue a rich, empirical understanding of software in the wild, or at least, the office.
Theory-driven design is not anti-empirical. It is the opposite: for a good theory generates testable hypotheses. It gives a framework to user-centric research beyond the unanswerable quest for what users really want. As they say, there is nothing so practical as a good theory.
A good starting point might be to take Ted Nelson’s ideas about documents and hypertext and combine them with, say, David Graeber’s critical anthropology of bureaucracy. Not to condone the anarchism of Graeber, but to lever the authenticity of perspective he brings to a discussion about the role of documents in the organization. Reading his essay, “Beyond Power/Knowledge an exploration of the relation of power, ignorance and stupidity,” it is hard not to believe that a radical rethinking of the document, and document-logic, would not benefit from his perspective.