Apr 05, 2006

How Can We Make Use of the 12 Principles for User-centred Systems Design in Practical Projects?

Tags:

This is an essay I wrote for a course in user centered design. It can also be downloaded as PDF here. Comments are welcome!

___
The twelve principles by Gulliksen [2003] are intended to create a deeper understanding of User-centered design (UCD) for any type of development teams. He argues that the concept of UCD has no agreed upon definition and therefore endangers the quality and user satisfaction of (IT) projects. For this reason these twelve principles have been created, to make development processes more likely to produce satisfactory results [cp. Standish Group, 1995].

The use of these principles, that were intended for the people working and managing development processes, can pose different obstacles. While some of the obstacles are rather easy to overcome (e.g. “Evaluate use in context”), some of them require rather much effort. Mainly those principles that require the support of the (project) management and the project team can be difficult to implement. A survey covering Sweden on this topic [Gulliksen et al., 2004] also showed that user experience professionals mostly regard the factors of support by management (and therefore by the project plan and team) and the users as crucial for a well user-oriented development process. Still, what happens, if these requirements are not given, how can the principles be introduced? In this work I will briefly focus on a few principles and show possible examples.

The first interesting principles are “User focus” and “User centred attitude”. Both principles affect the whole project team and therefore also the company. As it has been shown [Gulliksen et al., 2004] is the focus on the user predominant in the academic field, but not that far in the business field – at least if we take Sweden as a representative example with a long tradition with user-centred design [cp. Bødker et al., 2000]. On the other hand, the CHAOS Report [Standish Group, 1995] already showed that there is an awareness that user involvement leads to successful projects. Obviously, this consciousness has still not spread through all layers of businesses. This issue mostly needs time and figures (produced by time and money) to convince people in a company. The CHAOS Report is one small step, another one are the publications by Gulliksen and other authors in business journals. Also, a usability expert group in a company could provide some support in this missionary process. Special focus here should be laid upon the enhancement of the development process to support user involvement [cp. Gulliksen et al.,2004], since dedicated time in a project plan will give usability folks a better stand in a project. If time is planned, the other developers do not feel like their precious time is stolen, but moreover can use the output from the user-experience group as a basis to build their solution upon.

Another interesting principle is “Active user involvement” and the principle of “Simple design representations”, which is tightly linked to it. This connection comes from the fact that for involving users in a meaningful way, it is important that users understand what they do and what all is about. This can be achieved by providing intelligible prototypes from the beginning, ideally starting with low-fi paper prototypes [cp. Gulliksen et al., 2003]. These prototypes should do the trick for end users. However, might their company also be required to provide its employees the possibility to participate; e.g. reserve time. This issue is more difficult, but should be able to be tackled with a set of arguments. First, the end users (its workers) will be more satisfied and work more productive, since the product will be custom-taylored. Further more are happy workers more effective workers and require less time off. Second, will a custom-fit product be harder to be used by a competitor, which means that competitors will need higher effort to receive similar benefits. Third, can the custom-fit solution be used to support the present processes better than a standard solution and therefore also avoid differences between the ideal and the de-facto process. The extreme counter example here is SAP [cp. SAP, 2006], which does not only require users to adapt their processes, but even force companies to adapt their processes to implement the business software, which costs time and money.

A last set of principles is “Evolutionary systems development” and “Prototyping”. Both principles are shared with other development models (i.e incremental models and rapid prototyping models). Such examples can be eXtreme Programming (XP) or RUP. These measures can be seen to mitigate risks earlier [cp. Kroll, 2005], which is a crucial thing for expensive projects. The prototypes have the advantage that they not only can be used to communicate and document the design process, they also provide a way to test different solutions and maybe reveal critical problems. Similarly the evolutionary approach lets the solution be built step by step, which means that each release brings a preview to the final product and a improvement over the old version. This bears the advantage that possible problems can be resolved in the next iteration (or the one thereafter). Even more important, some possible users might already work with one of these intermediate releases and provide valuable feedback about requirements or other problems [cp. Gulliksen et al., 2003].

These three sets of principles can be regarded as examples how problems of introducing UCD-thinking in real-world projects can be resolved. They provide a basic set of arguments, why the principles are important and should be used and what the improved outcome is.

No comments.