In this article we discuss ‘slanty design’, which incorporate three new principles into a conventional user-centered design process. These are designing for non-goals (things you wish the user not to be able to do); creating anti-usability (designing so that it is difficult to achieve the non-goals); and clean design (solutions without unwanted side-effects that then have to have solutions designed for them). Slanty design incorporates many of the concepts of socio-technical approaches, and is explained using a variety of examples, including an airport baggage carousel, and the remaining challenges outstanding are described.
TopIntroduction
Many big software projects fail (Jones, 1995; McManus & Wood-Harper, 2008; Reel, 1999). Many small ones do as well. And even many that don’t officially ‘fail’ do not bring to their users the benefits that perhaps were initially envisaged. It seems to be an unfortunate truism that, in software circles, it is the case that you can have only two of ‘on time, ‘on budget’, and ‘desired functionality’. One of the reasons for designs failing is their creation independent from the social context of their use: in extreme cases, requirements are gathered, passed to designers who create concepts, passed to programmers who implement it, and then delivered back to the users. The cartoon in Figure 1 humorously demonstrates this.
Figure 1. Compartmentalized software development, without user involvement (source unknown)
Unfortunately, this Chinese Whispers approach to project management causes a whole host of problems in itself, but even if resolved, cannot get away from the initial gap between official requirements and actual needs, and even if that were solved, the final delivered project only meets the needs of a year or more ago – and things have moved on in that time anyway. One resolution to this is to utilise user-centered design (UCD) approaches (Abras, Maloney-Krichmar, & Preece, 2004), popularised in Scandinavian countries but gaining wide acceptance everywhere (Vredenburg, Mao, Smith, & Carey, 2002). The key focus of the UCD methodology is to take input from users as you iterate through ever increasingly detailed versions of the system, from brainstorming concepts through paper prototypes though working prototypes until the final system is reached. This has the advantage of refining requirements as the project progresses, as well as taking account of the changes in practices inherent in an evolving business or enterprise. The focus on user input with constant discussion and challenge focused on artifacts reduces the Chinese whispers, and gives all parties a more concrete handle on what is being developed. This approach can be augmented with other tools such as personas, in which characters are created to represent archetypal users and user groups, and who can be used to argue for, or against, features and perspectives on the system – they are especially useful for communicating design ideas and decisions to people outside the immediate team (Pruitt & Grudin, 2003).
However, this approach has its problems, in that it has a focus on usability as a central tenant - and usability is not everything. By looking at what people want to do, we tend to forget the things that they don’t want to do, which may in fact be more critical. The UK government’s systems for managing the personal data of families appears to do all the things that the agencies want it to do – but without considering the things that they don’t want it to do, like being able to be written onto a DVD and posted into the public domain (BBC, 2007), serious consequences can occur.