|
"Beyond User Participation:The Politics of Software Development"(.PDF). The abstract: The politics of technology design are examined in the context of software design where there has been an emphasis on “user participation” as a solution to poor software design. However, in examining the realpolitik of design, our research shows that the process must be situated in an organizational and market context. Thus, traditional concepts of user participation tend to be limited and need to be expanded to incorporate a broader organizational model of how technology and work are structured. To develop a conceptual model and to prescribe principles of practice, I assess the influence of actors, the constraints of organizations, the determinants of technology, and the limits of knowledge and purposeful action. This paper summarizes in-depth research on the process of software design and the development of a model of technology and workprocess development. My favorite quote: Some argue that only by involving users in design can the designer ensure that the software is effective. This nostrum for curing system deficiencies has widespread currency in both the research literature and textbooks and has a great deal of intuitive appeal. It is also very much in the spirit of current thinking about the customer's role in effective design of tangible products in general. However, with respect to software, evidence for approach as sufficient to improve user effectiveness is not compelling. We examined assumptions underlying user involvement and “better design” formulae provides some insight into their inherent limitations. I've been thinking a fair amount about organizational politics and design. In our practice, Adaptive Path stresses doing as much internal discovery work as you can before starting any design. The reason being, all the design work in the world is pointless if it doesn't get implemented, and the best way to ensure getting your designs recognized is to make sure that they respond to internal issues, that you've spoken to all the appropriate people, that there won't turn up any nay-sayers down the line who haven't been given a chance to contribute. Hell, even with something so basic as user testing, we have extensive stakeholder interviews, so that we make sure our recommendations fit with how the company is operating, and don't just analyze and suggest in a vacuum. I would argue that that is in fact the biggest problem with Guru Usability. Little to no concern for a company's operations or how the recommendations will be received--instead there are pronouncements from atop Mount Usable, stone tablets reading "Thou Shalt Keep Links Underlined And Blue", and no real effort made to be sure these recommendations are acted upon. Making usability recommendations is easy--getting them deployed is hard.
5 comments so far. Add a comment.
Previous entry: "Stalking The Wily Spore."
Next entry: "Organizational issues for design."
Comments:
COMMENT #1
I would just like to complain that this paper is very badly written. The language used has an opacity that can only be premeditated. One cannot help but think that if the author had devoted a little less energy to trying to sound authoritative, his ideas might have been heard clearly enough to actually be authoritative.
Posted by jjg @ 12/28/2001 01:55 PM PST [link to this comment]
COMMENT #2
Agreed that the verbiage tends towards the Academically Dense. However, I think it's not TOO dense (or, maybe I'm just reading too much academic literature...), and the points are worth considering. While he's focusing on the design of software within organizations (computer-supported collaborative work stuff), I think the notions apply to all manner of design.
Posted by peterme @ 12/28/2001 03:16 PM PST [link to this comment]
COMMENT #3
You've definitely been reading too much academic lit--the paper is a wretched read. But I agree there are some intriguing ideas, although I think your cliff notes version basically captures them, making the link more or less a formality. I think your closing jab at guru usabilty is basically a fair one *however* I'd add:
-the alternative to gurus who swoop down is to do things the hard way: admit there are no silver bullets, commit to a process, adopt an iterative approach... (in other words, do it right). The fact that Adaptive Path is having success with this approach is *great* and inspiring--now share your secrets for getting jobs and selling yourselves, as many of us are really struggling to sell this kind of approach in organizations who long for silver bullets (and who aren't forking out the dough for gurus these days, either). Note: consultants who sell silver bullets--even though they don't and never will work--are still getting jobs. Not as many, perhaps, but their schtick still sells. -guru usability is good circus: someone needs to get attention, generate interest; I'm not sure the answer is to get rid of the guru usability expert, maybe to relegate them to the conference/workshop circuit
Posted by samantha bailey @ 12/28/2001 05:04 PM PST [link to this comment]
COMMENT #4
Replying to Samantha's last comment about guru usability.... I think keeping it around as the utopian/unnatainable 100th percentile is a good thing. Aspiring to create more usable solutions by using 'guru usability' as a compass is a good place to start when the process of compromise (aka 'working with the client') starts. It's a tool to be used and not just relagated to the workshop circuit. Also, Peter commented that "all the design work in the world is pointless if it doesn't get implemented". To me, this is stating the obvious, but sometimes the obvious needs to be stated. When that implementation time comes along, it is the process of compromise that gets it done. Sometimes that means giving up a design you like for better usability or giving up better usability in order to meet a business requirement (usually at the request of the client). That's my 1 cent worth of opinion :^)
Posted by Dan Kapusta @ 12/28/2001 07:40 PM PST [link to this comment]
COMMENT #5
"Thus, we can see a source of dysfunctionality of software
as coming from structural or inherent features of organizations rather than from an inadequate technical
process of user requirements determination." So very true. If the boss likes orange, you'd better make it orange, or expect to hit a brick wall, user testing be damned.
Posted by James Tikalsky @ 12/29/2001 09:20 AM PST [link to this comment]
Add A New Comment:
|