Nathan Jahnke
Participatory Design, Week II
Scandinavian Design
In his two-part book chapter, Pelle Ehn first offers a retrospective on 20 years of
developments in participatory design from a Scandinavian perspective. He then applies the
concept of the "language-game" of the 20th century philosopher Wittgenstein to his
experiences with PD to try to explain why we fail to design useful tools for people. Though
this article, especially the second half, is fairly thick, I found that it ultimately helped
explain why the software development process is often so ridiculously hard.
Hen’s argument hinges on the proposition that a given skill cannot be exhaustively
characterized by a purely formal description (2), as is often done in the process of systems
development (e.g. requirements lists). Since language is the tool we use to make formal
descriptions, Ehn is saying that language alone (as in, what users are telling us) is not
enough to help us understand what users need. This is fairly obvious, I think, when we
consider that the users themselves do not know what they need, so they could never hope
to tell us that outright. We have to get in there and become a user to learn how we can help
them. Only then can we hope to speak the same language.
Ehn concludes that "participatory design means not only users participating in design but
also designers participating in use" (18). Is it realistic to expect designers to learn to do
the jobs of users? On the other hand, is it realistic to expect designers to come up
with something useful when they don't understand the task whose efficiency they
are trying to improve?
Ehn also concludes that "the design work should be playful" in order to keep users from
becoming bored and ending their participation (18). I sure hope management doesn't learn
about this - they could disenfranchise workers everywhere simply by boring them out of
important meetings! But seriously: not only do we have to get in there and learn the
jobs of users, but now we have to entertain them as we redesign their tools, as well?
This sounds Sisyphean. Have all of our great tools been designed purely on accident,
then? Or are there actually people out there who can live up to this challenge? Ehn
suggests prototyping early and often - can anyone think of any other good examples?
Incidentally, if you're interested in getting a better picture of what the Scandinavians were
doing in the 1970s with the early forms of participatory design, you should check out these
links:
http://www.time.com/time/magazine/article/0,9171,908715-1,00.html
I love Pehr Gyllenhammar, the Volvo manager's, quote in this Time article: "As people
became more educated--and Sweden spends perhaps more money per capita for education
than any other country--their jobs have become less complex," he says. "That does not
make sense."
More on the Kalmar plant:
1
Nathan Jahnke
http://74.125.95.132/search?q=cache:UrGGIZqSy4kJ:www.swlearning.com/quant/kohler
/stat/resources/applications/app22_3.doc+volvo+kalmar+plant&hl=en&ct=clnk&cd=1&gl
=us&client=firefox-a
More on sociotechnical systems theory, which asks us to consider how to "optimize" both
the people's lives and the machines' functions inside an organization (instead of one or the
other):
http://en.wikipedia.org/wiki/Sociotechnical_systems_theory
Achieving Cooperative System Design
The Grønbæk et al. article argues for a focus on process, not product, when it comes to
software development. The authors offer two "case studies" for our examination: the first is
something of a disaster, with the project being canceled after three years without the
release of the product, while the second was more successful, perhaps in spite of itself.
Even in the second case, though, there was a substantial cost overrun due to changing
requirements brought on by actually testing prototypes with real users.
This article echoes the thesis of the previous one but in a more applied way. We can see the
fallout when two different, large-scale projects attempted to produce products based solely
on requirements lists. This was true even for the second project, whose requirements lists
came from real users! The shift to iterative design was especially difficult in the second case
because the contract binding the various interested parties together had to be renegotiated
every time changes to the system were made. I am reasonably sure that this is where most
of the cost overrun came from.
Having previously read Kuniavsky, I'm sure we're all already familiar with what happens
when products are developed without real users both in mind and invested in the process.
The question this article brings to the fore is, then, how we can help with user-centered
design when lawyers demand that we state in advance the work we are going to do?
Ideas? Anyone? Besides stating the obvious (that "contracts between development and
user organizations could also provide explicitly for the use of certain cooperative design
techniques" (9)), the authors of the article don't offer many suggestions, so I'm curious to
hear what yall think.
Cooperative Prototyping
Bødker and Grønbæk report on a series of participatory design sessions they carried out
utilizing a complex computer-based prototyping system based on HyperCard (sort of a
precursor to HTML). In particular, I thought that how they helped users integrate hypertext
into their workflows was way ahead of its time.
2
Nathan Jahnke
The authors use activity theory to explain why they have to observe users using the
prototype tools they create in order to improve them. They also use activity theory to
explain why user-centered design is necessarily iterative: because users will inevitably
come up with new uses for technology when confronted with the possibilities it affords
(467). Thus, testing a prototype and brainstorming new uses of technology often occur
simultaneously in PD.
The authors report that they experienced some limitations doing design work with users
employing prototypes, for example when the prototype breaks down and the user becomes
bored as the designer tries to fix it (470-471), or when the user becomes so engrossed in
the prototype that he or she is no longer teaching the designers anything about his or her
work (471-472).
It is important to model work in sufficient detail and to come to the design session
prepared to augment the prototype on the fly (473).
How might we use contextual inquiry to prepare ourselves for participatory design
sessions?
3