• 6 min read
• Listen (requires a Medium account)

In any software project, we need to understand the people who will use the product. There are many different points of view onto what approach we should take.

Spool: Vision, feedback, culture

Some promote approaches to usability practice alternative to User Centered Design (UCD).

Spool (2008, 2009) calls the attention of the usability community to the risk of accepting methodologies blindly, of following them as dogma. Instead of measuring the results, he says, usability practitioners tend to focus on convincing people: “We are following the right methodology, so the product must be good”.

Instead of UCD, which he argues never worked, but leads to people following the process blindly, he encourages what he calls informed design. This is a reward system for any design activity such that the effectiveness of the activity can be measured.

Spool states having researched successful and unsuccessful interaction design projects. He claims having found three quality attributes successful projects had in common: a long-term user experience vision, a working feedback loop, and a culture of encouraging design failure.

“Vision : Can everyone on the team describe what the experience of using your design will be like five years from now?” (Spool, 2008, 2009)

The point here is that you have a larger goal, and when you take daily baby steps in your design, you can tell whether those steps are towards what you’re aiming, or not. This seems to also facilitate consistency, as everyone in the team are supposedly aiming for the same, shared goal.

“Feedback : In the last six weeks, have you spent more than two hours watching someone use yours or a competitor’s design?” (Spool, 2008, 2009)

The usefulness of feedback from actual users is rather obvious. Spool seems to stress the importance that everyone in the team have the experience of seeing real users use your design — supposedly, in order to remember just how differently real users perceived your design than you did.

The reason Spool argues for six weeks as the maximum amount of time one should be allowed to not sympathize with users, is that according to him, after that time memories fade. In an online, distributed development environment, we want to regularly expose developers to perceptions about how users experience their designs.

“Culture : In the last six weeks, have you rewarded a team member for creating a major design failure?” (Spool, 2008, 2009)

Here, Spool argues that encouraging failure results in a culture of learning from that failure, instead of making contributors ashamed or afraid of mistakes. This also seems to facilitate creativity and trying also experimental design ideas.

Regardless of the validity of Spool’s criticism against UCD, his propositions for things to include when designing for our actual users look useful, because they can be adopted seemingly without burdening the team with a heavyweight process.

Open source, for example, has been considered loosely a form of distributed participatory design (Barcellini et al., 2008; Terry et al., 2010) . Participatory design is concerned about democracy at work and about democracy in design. In its roots then, its approach to design is quite similar to the ideals of open source (Nichols & Twidale, 2003), where transparency of the development process is a key value.

Participatory design

In UCD, the focus is on researching the users so that designers can make better design decisions. In contrast, participatory design seeks to empower users as decision makers in the design process itself.

Researcher-designers are thus expected to facilitate user-designer cooperation instead of representing the users (Iivari, 2009) . Ehn (1993) approaches the question of communicating understanding about the intricacies of work, between designers and users, in terms of wittgensteinian language-games:

“If designers and users share the same form of life, it should be possible to overcome the gap between the different language-games [of users and designers]. It should, at least in principle, be possible to develop the practice of design to the point where there is enough family resemblance between a specific language-game of the users and the language-games in which the designers of the computer application are intervening. A mediation should be possible.” (Ehn, 1993, p. 70)

Within the domain of participatory design there are techniques, supposedly helping both users and designers see “other person as partner” instead of “other person as problem”, recognizing the differences in perspective of different stakeholders (Allen et al., 1993). Also in the context of an open source project, users and developers have different language-games. Participatory design explores the conception that making mediation possible between those language-games facilitates design and user participation through enhanced communication.

Erickson (1996) discusses telling stories, considered perhaps an initial, less formal alternative to scenarios , as a similar “equalizer” of different participants of discussion, since storytelling requires no special skills. This comes very close to the challenge of involving users in development that seems to have a culmination point in open source development.

An open source community indeed engages users at a level of discussion. Observation of users in their real working environment is difficult — and sharing those observations in a way that engages the community (such as a video narrative illustrating users’ environments) raises privacy issues — and again, is very time-consuming. Thus, the notion of a solution encouraging users to further participate in the design instead of being observed is a very tempting one.

However, Iivari (2009) states that in the OSS project she studied, users do not have actual decision making power regarding the OSS but are left in a consultative role. This seems to be true of most OSS projects. Ultimate decision making is left to developers only, to whom a very limited amount of understanding about the users of the software is available in the forums of the community (Iivari, 2009).

In OSS projects, user involvement is thin from the perspectives of both UCD (no usability practitioners to represent users) and participatory design (the few users who do participate have no true power over the eventual software). Warsta & Abrahamsson (2003) have studied the similarities of agile methodologies and open source development. Sy (2007) builds a case for agile as an efficient framework in which to employ user-centered design.

Further research could reveal whether these approaches might also be applicable to open source development. So central questions, yet ones without clear answers, seem to include:

• Is there a way UCD understanding could enrich the natural way OSS projects learn about their users?
• Could usability practitioners plug in to the community’s existing means of communication, finding fruitful points of contact with the community while using methods favoured by UCD, such as ethnographies, to fuel design?
• Or should we perhaps concentrate on what seems to come naturally to an OSS community, and only refine user research methods to be based on the open source community’s feedback?

(Adapted from master’s thesis, Chapter 8.1. Originally published in Moodle usability blog. Featured image: Garry Knight: Chatting with a Shopkeeper, CC-license)

References

Allen, C. D., Ballman, D., Begg, V., Miller-Jacobs, H. H., Muller, M., Nielsen, J., & Spool, J. (1993). User involvement in the design process: why, when & how? In Proceedings of the INTERACT’93 and CHI’93 Conference on Human Factors in Computing Systems (p. 254). ACM Press.

Barcellini, F., Détienne, F., & Burkhardt, J. (2008). User and developer mediation in an Open Source Software community: Boundary spanning through cross participation in online discussions. International Journal of Human-Computer Studies, 66(7), 558–570.

Ehn, P. (1993). Scandinavian Design: On participation and skill. In D. Schuler & A.Namioka (Eds.), Participatory Design. Routledge.

Erickson, T. (1996). Design as storytelling. interactions, 3(4), 30–35. doi:10.1145/234813.234817

Iivari, N. (2009). User Participation in ‘Configuring the User’ in OSS Development. International Conference on Information Systems (ICIS) 2009 Proceedings, Paper 199. Retrieved March 19, 2009, from http://aisel.aisnet.org/icis2009/199

Nichols, D. M., & Twidale, M. B. (2003).The Usability of Open Source Software. First Monday, 8(1). Retrieved from http://firstmonday.org/article/view/1018/939

Spool, J. (2008, April 12). Journey to the center of design (Slideshow with audio). Retrieved from http://www.slideshare.net/jmspool/journey-to-the-center-of-design
See also: Spool’s own in-depth story

Spool, J. (2009, March 19). Journey to the center of design. Presented at the SXSWi 2009. Retrieved from http://www.youtube.com/watch?v=WCLGnMdBeW8
See also: Spool’s own in-depth story

Terry, M., Kay, M., & Lafreniere, B. (2010). Perceptions and practices of usability in the free/open source software (FoSS) community. In Proceedings of the 28th International Conference on Human Factors in Computing Systems CHI ’10 (pp. 999–1008). ACM Press. doi:10.1145/1753326.1753476

Warsta, J., & Abrahamsson, P. (2003). Is open source software development essentially an agile method? In Proceedings of the 3rd Workshop on Open Source Software Engineering (pp. 143–147). Presented at the 25th International Conference on Software Engineering.