 A Guide to Good Practice in Collaborative Working Methods and New Media Tools Creation Chapter 20 - User-Centred Product Creation in Electronic Publishing - Good Practice Models New interactive products can be exciting, useful and fun. But too often they disappoint, and fail to deliver on their promise. Many of us are familiar with products that - though they look great in the demo - have fatal flaws when it comes to trying to use them. And it is doubly disappointing when the flaw looks like something the developers should have anticipated. Ask almost anyone, and they can give their own examples of designs that frustrate or confuse: The glitzy website that imposes an unwanted intro, or takes you in directions you don't want to go. An opera house information system that tells you everything about its operas in rich multimedia, except you can't discover the dates when they are being staged. Well-intentioned systems where you simply can't stop the annoying little animated helper appearing on screen. Systems where you have to do repetitive tasks without the aid of shortcuts. Sound effects you can't seem to turn off. Buttons you click on that keep you waiting unpredictably long, giving no hint what's going on, or not going on. Sites that look stylish but frustrate your attempts to do some basic things like finding out what is in them and how to get to it. The list is endless. These things happen again and again. And it simply doesn't need to be that way. In this chapter we explore what those user-centred essentials are, and how they are applied in real-world projects. And we look at an overview of resources to support best practice in user-centred product creation in electronic publishing, which have been made available through VNET5 (www.vnet5.org), a thematic network supported by the European Commission. Principles and good practice First let's consider the key principles of the user-centred design process. The list below draws on accepted best practice, founded on the experience of countless practitioners and researchers in user-centred design. Like the rest of this chapter, it tries to set out the principles in plain language with minimum technical terminology. Know what matters for your users: who are your users? What are their goals and expectations? The principles are well established, but they are not always sufficiently understood or applied. The difficult thing, as usual, is to find the right balance - understanding which principles are most significant in developing your particular product - and to decide how to apply the principles effectively. The following sections provide some explanation of the principles and how to apply them, with observations and commentary about what can happen in projects. Know what matters for your users. (This is often not easy, but it is a prerequisite for success). Who are your users? People mean different things when they talk about "users". Here we are principally talking about the people who will actually be using the product (the "end users"). The history of electronic publishing is littered with products that developers expected to be desirable and easy to use, but which failed - because they left the intended end users confused, frustrated or simply indifferent. People who use electronic publishing products can have widely varying skills and changing expectations. Sometimes they are very diverse ("the general public"), but even so it is usually possible to home in the significant characteristics of the people you really want to target. There will typically be several different categories of user, with different aims and different skills. Be aware of them all, but be selective in your focus, to ensure you can at least meet the needs of your main target users. What are your users' goals and expectations? What do people really want to achieve through using your product, and what are their expectations about how to achieve these goals? Here, we are looking beyond functional requirements to the way the functionality will be presented. If the way the product works fails to fit with the way its intended users think and work, how many people are likely to use it? The answer usually is that most people won't bother, unless the visible benefits are so great that they justify putting effort into learning how to use the product. Designers need good insights into how their target users think about what they want to achieve: the concepts and products that are familiar to them, and the language and terminology they use. Define the vision At its most basic, the principle here is to start with the end in mind. Make sure you have a clearly defined vision of what your product will be, what it will do, and what the benefits are. Express that vision simply and concisely, in words that the users, designers, implementers and others will understand. Share that vision with all the stakeholders. If developers don't understand a clear, shared vision, how can they be expected to bring it to life? And if users can't understand the product vision, how can you expect them to want to use it? This may sound obvious, but it is amazing how many projects fail because they have no shared vision of what they are doing. Projects sometimes seem to be trying to develop a product simply because it appears to be technically possible. One difficulty is that projects arise from a proposal that puts forward some kind of vision of what the product will be - a proposal expressed convincingly enough to win sponsorship and funding. And that proposal usually has to be written before the project has the funding to do a full user requirements analysis. Which is why in this list of principles, "understand your users" comes first - even if it means investing money up front. More enlightened sponsors are prepared to fund feasibility studies and market research, though these studies sometimes focus on technical feasibility and on demonstrating consumer demand for the proposed functionality. Understanding users goes deeper than that. Many good designers are naturally observant, inquisitive and insightful - even so, a bit of method can greatly assist the process of insight. There is a good history of successful innovative products, and improvements to products, coming out of ethnographic studies and contextual observation, dating back to the work of Lucy Suchman at Xerox in the early 1980s. Prioritise your objectives What kind of quality objectives and usability objectives will support the vision of the product, and meet the user requirements? For any interactive product, success depends on achieving an acceptable "quality of use". At its simplest, this refers to how effective, efficient and satisfying the product is in enabling its intended users to achieve their goals - to use it successfully in the way they want. Qualities associated with usability include how appealing and engaging the product is; how easy it is to learn (or to guess how to use); how fast it responds; how easy it is to navigate; how well it helps people avoid (or recover from) errors. Often these objectives can pull a design in different directions. For example, a design aimed at helping beginners may frustrate the more expert, who find that the "helpful" stuff simply gets in the way once they know what they are doing. Or an appealing-looking interface, rich in graphics, may turn out to be too slow to use, or frustrate people by concealing its purpose, its navigation or its manner of use. Good design is informed by knowledge of what matters most, what is essential and what is just nice to have. We try to meet the needs of different users - great designs meet multiple needs in the simplest way possible - but difficult trade-offs often have to be made. So it is essential to know the priorities for your product. Use guidelines and standards wisely This principle treads dangerously close to being so general as to be useless. Which is precisely the problem with most guidelines and standards. And they are legion. For example, when Smith and Mosier integrated the available design guidelines for human-computer interaction some years ago, they identified more than 1,000. Any sceptic was likely to be struck by the thought that whatever decision you wanted to justify, there was a guideline waiting to be found. Having said that, there are some extremely valuable design guidelines and design principles out there, so long as you understand their rationale and can apply them appropriately. The VNET5 website gives some assistance. For electronic publishing, there are critical issues concerning visual representation, users' comprehension of meaning, the design of the actions required of the user, and users' understanding of how to interact. One of my favourite design resources giving design guidance on these issues is "Designing Visual Interfaces" (Kevin Mullett and Darrell Sano, 1995). This sets out essential principles, gives instances of common errors and explains techniques, and is well illustrated with examples. Designing things for people to use is more demanding than designing simply for graphic communication. It requires additional skill sets. In projects that design interactive products and new media tools, it is valuable to have access to someone with an understanding of cognitive ergonomics - the psychology underlying design for use - at the very least, to help interpret and apply design guidelines effectively. Iterate Iteration is essential to good user-centred design. Just occasionally, a product design may be flawless at the first attempt, spot-on in every detail. But such events are rare, and they are not something any development team can rely on. There is no list of design features that will ensure an innovative interactive product hits the mark first time. Turning a creative original idea into a usable product almost always requires iteration, so it is wise build iteration into the development process from the outset. And the trick is to iterate early (the earlier the better) when changes are cheap, so you can reduce the need for expensive and inconvenient late changes. We still sometimes see project plans where the main "usability activity" is a user test shortly before the product is released, which may be needed but is not sufficient. For many years, I used a particular slide in lectures and seminars to illustrate the essence of iteration in design for use: "coupling design and evaluation" We all iterate intuitively when we are designing something. We think of an idea, a potential solution to a design problem. We may turn it around in our mind, evaluate it, try it out in our imagination and look for what is wrong with it and how to improve it - maybe all in a matter of seconds. What we are doing is early design, and it is iterative. And that iteration can be extended to great effect. As design ideas emerge from our own internal scrutiny, we typically represent them visually or verbally (or in some more formal notation). Further possible improvements may become evident as we inspect our design ideas and evaluate them informally. All designers iterate their design at least this much. Some take iteration no further, until consumer feedback demands expensive changes late in development, or after release of a product - which is something most managers are keen to pre-empt. Express design ideas early To take iteration to the next level early in design, and get timely feedback, we have to represent the design in a form that other people can understand. Ensure that these early representations of interactive product design are shared with other people, and opened to their scrutiny, opinions and evaluative feedback. Of course, getting feedback from others can be a double-edged sword. Anyone who has worked with teams of designers creating interactive products will be familiar with the delicate balance between maintaining the aesthetic integrity of a design (often an individual activity) and ensuring that the design is usable and not fatally flawed in some way (which demands multiple scrutiny). But the earlier we can discover any flaws and causes of difficulty, the more possible it is to find a successful solution. Early design expressions can quickly become prototypes. And this is where the real value arises: the opportunity to try out a prototype early in development on some target end users, or perform some other kind of user-centred evaluation. Build user validation into the work plan Now, of course this planning really should be done at the proposal stage. Otherwise, by the time some formal user evaluation is needed, the skills and resources may not be readily available, and it may be too late for some changes that could have been identified earlier in design. A wealth of methods, tools and techniques is available to help get user feedback on design. So many, in fact, that it can be quite confusing for a project manager tasked with delivering a successful interactive product, on time and to budget. Especially if the planning for the user-based evaluation was not written into the overall project plan. Those methods and tools cover all stages of user-centred development, from initial vision to final testing. So why leave this principle until this point in the current chapter? Because this is the point at which many projects decide to get proactive about usability. "We have a prototype, and it's time to do something about usability. Can you come and have a look at it for us?" is a request I've heard on countless occasions. It is never too late to improve the design - but the costs of making changes escalate rapidly as development proceeds. (How many project managers are not familiar with the feeling, "If I'd known then what I know now, I would have done things differently..."?) Try out the design User-oriented evaluation of design pays dividends. Choose the right method, and you can learn - in just a few hours - more than you could ever have imagined about the usability of your design. And you can do it quite early in product development. The goal of evaluating during design is to see how various aspects of the design stand up against usability criteria, and to find any serious problems and help identify potential solutions. There are countless methods, tools and techniques out there, all intended to help designers evaluate their design from a user's viewpoint. Academia has been prolific over the years in creating them (and I have been guilty of producing some myself). The difficulty lies in finding the most appropriate methods and tools for the job in hand. Put at its simplest, usability evaluation can be based on any of three things: expert judgment, theoretical analysis or testing a design on users. Initial evaluations often use expert walkthrough or other inspection methods. These can be fitted into busy development schedules, don't cost a lot, and can be surprisingly effective - assuming the right expertise is available to provide the expert judgment. A walkthrough will be based on scenarios of use, with the expert putting him- or herself in the position of a user trying to achieve something through using (and interacting with) the design. Some inspection methods incorporate theoretical analysis of the interaction, and deliver more formal findings. User testing can deliver real insights into the quality of use of a product, unattainable by any other means. There is a mature science of user testing. Many readers will be familiar with the concept of a usability lab, and there are numerous variations on user testing - some quite basic and simple - all founded on observing people (who match the profiles of intended users) trying to achieve things through using a product or prototype. Testing can evaluate many aspects of a design, including the navigation model, task-flows, transactions and user support. Observation can tell us about how well a design supports performance in the hands of its users, and help us identify areas of difficulty. To discover what users think about the experience of using a design, and how satisfied they are with it, we have to ask the users. User tests typically employ well-established methods for this, based on interviews and questionnaires. These can reveal preferences and opinions, identify sources of confusion and frustration, explain causes of error, or even give valid measures of perceived usability. The VNET5 website contains guidance on evaluation, with tools to help projects identify the evaluation methods that are most suitable for their particular needs. Get The Findings Acted Upon In large projects this can be a difficult challenge, particularly if the user testing has been left until late in development. Most usability professionals are familiar with having to deliver unwelcome findings, when they have been brought in rather late to "do something about usability". In such circumstances, project managers only want to know about the issues that it is absolutely essential to rectify, and they want quick solutions and minimal changes. Where user-centred iteration is properly planned into the development approach, things are more manageable. Even so, there are specific actions that make it easier to get the evaluation findings fed back into design satisfactorily. First and foremost, involve stakeholders in the evaluation process. When designers and decision-makers see user testing with their own eyes, they are convinced. The challenge may then be to steer them away from acting immediately to correct the particular problems they have witnessed, and get them to consider the broader evaluation findings. To help get the right things done, provide prioritised findings, simple reports and clear recommendations. Getting the right improvements made at the right time can be the difference between failure and success for the product. VNET5 - advancing user-centred product creation So far in this chapter, we have looked at the principles and practice of user-centred design. The remainder of the chapter looks at available support, specifically from VNET5 (www.vnet5.org), an initiative that is helping electronic publishing projects to advance their level of user-centred product creation. VNET5 is a thematic network funded by the European Commission. Its primary objective is to help enable more user-centred results in electronic publishing projects and the wider Information Society Technologies programme in Europe. VNET5 aims to give projects (and individual members) easy access to the particular expertise and resources needed to take an appropriate user-centred approach, and shape their products to the needs of users. At the heart of what VNET5 offers projects is a "common approach" to user-centred product creation. This embraces the key user-centred principles described in this chapter, and draws on a wide base of best practice. It does not seek to promote specific methods, but provides an end-to-end framework for user-centred product creation, and helps projects select the methods most appropriate for their needs. VNET5 guides projects towards suitable methods and tools that support each stage of this process: planning validation; understanding the needs and requirements of users early; adapting the product iteratively to user needs throughout design; and employing suitable user validation and testing activities to assure product success. The help for projects takes the form of coaching, skills-building workshops, and web-based access to supporting resources. Coaching VNET5 coaching is assisting projects in validation planning, user-centred design and evaluation. VNET5 support for projects is based on first understanding each project's needs in the light of its objectives and constraints. It starts with assessment of the maturity of the project's user-centred capabilities, and where required, help with planning appropriate user-centred activities. Support can include targeted coaching for project teams to help them develop needed competence. Planning and requirements Support for user validation planning aims to ensure that projects carry out the appropriate user-centred activities at the right time - with the right skills and resources available. To help projects gather and record the most important user-related information in a simple format, VNET5 uses a Validation Planner. This helps organise thinking about the essential user validation activities, the required and available resources, and the costs, timescales and constraints. Design VNET design resources address methods, guidelines, standards and best practice. Design coverage of electronic publishing applications and tools includes content design (planning the information structure), navigation design (defining the accessible paths across information elements), layout design (addressing interaction and presentation aspects) and operational design (describing the functions and services offered to the user). Evaluation VNET5 offers very comprehensive support for evaluation. The website resources summarise numerous methods, and provide a method selector. VNET5 coaching focuses on a subset of usability evaluation methods - inspection methods, user testing and user satisfaction methods - chosen because they are practical and valuable for use in product creation. Events and resources To help projects and organisations develop the skills they require, VNET5 has run a series of three-day workshops that provide hands-on training in user-centred product creation. Feedback on these has been highly positive, and additional events have been staged in response to demand. Best practice in user-centred product creation has also been shared through a series of VNET5 sessions organised at relevant conferences, exhibitions and professional events. Published resources include an introductory manual, "User-Centred Product Creation in Interactive Electronic Publishing" (Tom Bsser & Elke-Maria Melchior, VNET5 D2.3. May 2002). This sets out the reasons for adopting a user-centred approach, and gives an overview of the methods that are further specified on the VNET5 website. The VNET5 website provides the most immediately accessible support resources. It gives members access to a wide range of resources, and includes tools to help projects choose methods and techniques that will meet their project's specific needs. - continue to CH 21: The Money Man's Perspective - return to the table of contents |
