Common & Particular Needs: A Challenge to Participatory Design
Rachel Bellamy, et al.
Designing a visualization of IBM’s corporate business controls. (via Participatory Design)
This is an experience report. The story begins with a meeting with IBM controllers in the midst of this design process. They met with controllers and showed them visualizations. They described their design process to them:
The controllers shared their control process. Controllers are responsible for compliance with regulations (e.g. legal responsibilities, accuracy, financial reporting, address or report controls). A business control is a documented and verifiable test of a business process. These are run every quarter and reported.
The controllers were using a home-grown Lotus Notes db.
(Switching to 1st person, Rachel == I/We)
We offered visualization for access to their data. We ran into participatory design issues:
– We could only have read access to their database
-This would limit our possible solution
– They were considering alternative reporting solutions, and were under pressure from their management to adopt one in particular
– We needed approval from upper management for further work,
We moved forward anyways.
We learned about the compliance process.
We started to do design experiments and used them as a way of learning more about what their needs really were. We used sketches as conversational props. For example, we showed relative proportions of defects (“5% failed”), they didn’t want that they wanted more concrete details (“3 failed”). The reason for this is that compliance is concerned with each error, not relative percentages.
We built a prototype. (Note, many designers have rolled their eyes at the ugliness of the design. However, the controllers sought this.)
Note about the sensitive power issues.
We needed to involve (more controllers?) or upper management. At the beginning of the design process this was seen as a problem. Now that trust had been built, this was sensible to the controllers.
To deploy the visualization, the controllers participated (and had a solid amount of control).
Note, in design they would have conflicting feature requests from two controllers. There was a tension between group needs and the specific needs-of-a-few. It is not cost-effective to serve the needs of just individuals (not sub-groups or roles or etc…). How to address this *one* frustration?
This issue caused us to revisit our design process. This issue with the common vs. the individual is not new.
MacLean et al. (1990) prescribe a slope towards tailoring as a solution. (ref. End-User Programming). Allow for customizations and allow people to help each other do that (via sharing customizations).
We’re still working. To be continued.
Does this require the software engineers to change their relationship with the controllers? Yes, this affects both the software engineers giving daily IT support to the controllers and the software engineers designing the solution.
This is difficult because now you are asking software engineers to meet a different kind of challenge.
In a Scandivanian context, one answer would have been to catch this issue much earlier instead of being surprised by this. One could have held an information forum in advance to educate the users of the limits? (I’m not sure I caught this comment correctly).
Note, another ref: C. Letondal. (2006) Paricipatory Programming: Developing Programmable Bioinformatics Tools for End-users.
The solution to individual needs was “End User Programming”. Wow, I didn’t expect that at all. I would like to see where they go with this project. Someone in the audience essentially said, “In Scandinavia, an introductory forum would have avoided this issue.” Is that the solution to individual needs? Educate users that this isn’t possible? I must have missed most of that comment.
That still leaves the question. How, as a designer, do you address the individual needs of a user when you are trying to serve a plurality? Perhaps one solution is to make a tough decision and decide whether or not Bob’s particular concerns ought to be cut from the program. This is a difficult decision. The least critical issue is: if you are interviewing Bob at the minimum you know that if you please Bob, you’ll have someone who likes and uses your design. A larger issue is this. How do you decide whether Bob is representative or not? On what authority?
(Note, personally, I am partial to the tailorable/customizable/end-user-programmable solution).