By Gerd Waloszek
In this review, I take a personal look at the book Participatory IT Design by Keld Bødker, Finn Kensing, and Jesper Simonsen. I would also like to add that this is not a “full-fledged” review but a review from a user interface designer’s perspective.
|Keld Bødker, Finn Kensing, & Jesper Simonsen
Participatory IT Design: Designing for Business and Workplace Realities
MIT Press, 2005
Keld Bødker and Finn Kensing are Associate Professors of Computer Science at Roskilde University, Denmark. Jesper Simonsen is Associate Professor at The IT University of Copenhagen, Denmark.
More information on the authors is available on their homepages (see “Related Links”).
Bødker, Kensing, and Simonsen’s book Participatory IT Design: Designing for Business and Workplace Realities does not quite fit the kind of books that user interface designers usually read. But it intimately connects to their domain, as it deals with the introduction of new information technology (IT) systems into an organization. This is particularly the case if the process is not only viewed from a business-oriented perspective but also from a socially sensitive one: as an approach that, as the authors write, “takes into consideration the specific organizational context, as well as first-hand knowledge of users’ work practices and allows all stakeholders – users, management, and staff – to participate in the process.” Hence the book’s title “Participatory IT Design.”
The MUST Method for IT Design
In the book, the authors present the MUST method for IT design, which they developed and tested in thirteen IT projects in the industry. MUST is a Danish acronym for “theories and methods of initial analysis and design activities.” So, are we encountering here just another variant of design, called IT design? Yes, we are, and it is quite different from what user interface designers are concerned with in their daily work. According to the authors, IT designers are “people with IT competencies who plan and carry out a design project with a company.” But these people are not UI or Web designers, as one might jump to conclude. Instead, they are “people who already work in systems development, or people with a systems development or programming background who will be carrying out a design project.” Interestingly, the authors leave open the way in which IT designers qualify for the social aspects of an IT project.
The authors divide an IT project into two parts: a design project and an implementation project. Both are typically separated by a call for tenders. According to the authors, “an IT design project is carried out at a company with the aim of designing sustainable IT usage in response to a more or less specified problem within the company.” The authors deliberately use the term “IT usage” instead of “IT systems” in order to indicate that “an IT design project also needs to focus on the organization of the work which the IT systems will support and on the required user qualifications.”
Based on the results of the IT design project, typically a summary report which may be supplemented by prototypes, suppliers can decide whether existing IT systems meet a company’s needs or whether new development is required, and make their bids. Readers should keep in mind that the book and the MUST method cover only the design part of an IT project, also known as the IT design project.
Overview of the Book
The book comprises of three parts:
Part I introduces the concepts of the MUST method, that is:
- The question of what IT design is, an overview of the MUST method and its relation to other methods, as well as five IT design project example
- The four principles of the MUST method: coherent vision for change, genuine user participation, first-hand experience with work practices, and anchoring visions
Parts II and III are designed by the authors as a “practical toolbox” and destined to be read “on demand” in the course of an IT design project:
- Part II describes the four phases of the method in detail, the initiation phase, the in-line analysis phase, the in-depth analysis phase, and the innovation phase. Each of these are described according to the same concerns, such as objective, motivation, situations and ambitions, examples, possible phase activities, and possible results of the phase.
- Part III lists the MUST method’s suggested techniques and representation tools. This part is intended as reference material. It starts with an introductory overview, which, according to the authors, should be read in full, “while individual tools and techniques can be studied as one considers implementing them.”
Finally, in the epilogue the authors describe some of their general experiences on how the MUST method can be included in the repertoire of IT practitioners.
A Few Comments on MUST and Contextual Design (CD)
In Part I of the book, the authors relate the MUST method to other methods that address the same concerns and issues, such as the waterfall and evolutionary models, Rational Unified Process (RUP), Business Process Reengineering (BPR) – and, as a surprise to me, Contextual Design (CD), a method developed by Karen Holtzblatt and Hugh Beyer (read the review of their book Contextual Design) that is well known and acknowledged in the UI design community. According to the authors, MUST and CD have a similar scope but “CD does not deal with project management and seems to expect the design team itself to be in charge. … CD does not distinguish between the users – those that will interact directly with the systems – and the customers – those that order and pay. In addition, the method does not suggest ways of handling potential conflicting interests” (between management and employees, I would like to add).
As I already noted, I was surprised that the authors related the MUST and the CD methods. For me, CD is so deeply embedded in the UI design field that I never considered it as a method for managing change in a company, whereas MUST seems to be clearly focused on project management and organizational issues. In a sense, MUST, according to the authors, ends where CD starts: “MUST argues for a separate design activity where such specifications [added: as created by the CD method] are deferred until a decision has been made on what to build or buy.” Particularly, “MUST is inscribed in an overall project model where it is assumed that not all IT systems are built from scratch and where the implementation of customized systems [added: such as SAP’s enterprise software] will be most likely outsourced.” The authors even “hold the point of view that detailed technical descriptions are superfluous for those systems that the company in question decides to buy as a standard system, those that are outsourced for a vendor to deliver, and those that are not to be pursued any further.” Does that make CD superfluous as well? Not at all, in my opinion, but the place for the CD method may not be companies’ IT design projects. Instead, it is design projects carried out by software vendors. And this is what indeed has happened when SAP and incontext, Karen Holtzblatt and Hugh Beyer’s consulting firm, cooperated on design projects.
In my opinion, CD deals much more with organizational issues than might be concluded from this short comparison. Particularly, the cultural and the flow model (two of the five work models derived from site visit data) may lead to dramatic consequences that impact individual as well as cooperative work (and may involve far-reaching organizational changes). In addition, the actual UI design part is performed at a comparatively late stage in the CD process. But the authors rightfully point out that CD does not offer any support for managing design projects, particularly in the context of bigger changes within companies.
The introduction of a new IT system presents huge challenges for companies because it involves much more than simply exchanging the hardware and/or software of an existing IT infrastructure. The impact of such changes on a company’s organizational structure and the ways work is done individually as well as in cooperation cannot be underestimated. This is the reason why user interface designers (or whatever job title they may have), who regard themselves as – and usually are – the primary user advocates in a company, should consider reading this book, even though, admittedly, it targets IT designers (and students of IT design). IT designers are responsible for leading an IT design project and producing results on which a decision about an IT system can be based. But if user interface designers take their role as user advocates seriously, they should be familiar with what goes on during an IT (design) project, what its main concerns and outcomes are, and particularly, where user participation is relevant or even mandatory to make an IT project successful.
Moreover, UI designers will profit from the “toolbox,” especially, from the techniques and representation tools presented in Part III of the book.