1. A major problem with Web interfaces
is that many designers believe they know what their users or customers (the
second persona, or implied audience) ought to want. Bruce Tognazzini points
out that [d]evelopers often fixate on the method of
use they personally prefer. [...] Developers tend, by and large, to prefer
abstractions.
Many Web designers pack in features and options as "value
added" content or function. What they fail to recognize or acknowledge is
that their users
- do not realize the features even exist
- did not ask for these features in the first place
- do not visit the site for the purpose of performing the tasks that these features "facilitate"
- may perform these tasks in other applications or interfaces geared specifically for a single purpose or a type of task.
2. At least part of what I mean
by Control is well-articulated by Robert
R. Johnson's system-centered model of technology (25). Johnson even asserts
that the system-centered view is so embedded in Western
cultural ways of thinking about technology that even the best user-centered
design approaches can unwittingly fall victim to the system-centered ideology
(29). He goes on to critique Donald Norman's model of user-centeredness.
While Norman advocates composition or design that keeps the user in mind
and makes things easy, his model still perpetuates design as dissemination,
and ultimately as Control--though a kinder, gentler Control.
Norman is telling designers (rhetors) to compose with the audience in mind,
and make it easy for them to receive information (29-30).
3. With such a cacophony of voices
asking for features (or asking for their removal), the designer is left
with the difficult task of filtration and implementation. Many designers
will simply choose to implement every suggestion. Interoperability between
components is a useful thing, but the desire to turn every product into
a Swiss Army Knife leads to problems. Though a grossly oversimplified version
of Johnson's model, the "Swiss Army Knife syndrome" run amok is what I fear
about Consensus. At the very least,
Consensus seeks user imput, which Control does not. But Johnson's
positioning of community and culture at the
outer fringes of the user-centered rhetoric model gives me pause. The website
you are reading is a good case study for examining how this model could
run amok, and the need for an alternate model, of informed Compromise.
Compromise
4. Eventually, the designer is compelled to seek Compromise. What will the majority of users want? What do users like about the suggested features, especially the ones they did not at first anticipate or understand? How do these desires and needs change over time? Sometimes creativity must be sacrificed for productivity; similarly, sometimes the user as an individual must be abstracted or idealized or even ignored for the sake of the group.
5. Key to compromise is identifying
the problems or needs of the group and limiting them according to abilities
and resources. In part, this is like selecting a thesis for a paper (something
I've struggled with during this whole composition). But it also requires
significant cost/benefit analysis. Designers must internalize the iterative
nature of Web design, community building, and usability testing. Designers
must also recognize the nature of Internet communication forms as a continuum,
and that users may or may not move fluidly from their role
as audience members to producers of messages
(Morris and Ogan 42). As
Edgar Schein says, one of the central conditions of organizational
health [is] the ability to cope and adapt
(235). Designers must be fluid
as well, exerting Control at times when productivity is vital, seeking
Consensus when time permits and effectiveness requires it, and knowing
how to Compromise. Key components of Compromise are community
(users, culture, and context), interface, and
technologies.