15 September 2003

Design for eGovernment

By Nico Macdonald

In a presentation on designing for eGovernment earlier in September Matt Hopgood, an information architect at Web integrator Sapient, reported on responses from staff to templates developed for the Office of the e-Envoy (OeE).

"'I will look at it and come back to you with things specific to me'", was a common reaction he noted, "but they don't".

Sapient's design solutions seemed to have addressed the needs of the Office, and where they didn't, Hopgood explained, they created templates for the 'exception cases'. A remarkable aspect of the project was how, with early input from design, the OeE had developed Web resources in which look and feel, component layout, and page structure were separated. This allowed for a variety of templates to be used, content to be re-used elsewhere, and pages to be displayed in text readers or on small-screened portable devices.

As both national and local government step up their online ambitions design is becoming increasingly important. But why is design important? Because information technology and the processes it facilitates are invisible, and design (whether or not it is applied by designers) both makes it visible and usable, and allows its full potential to be realised.

We should be clear, however, that design in the context of the Web is not primarily about visual things - aesthetics, layout, colour - but about a dynamic interaction between users (citizens and other bodies) and an organisation (government) providing a service. The more sophisticated eGovernment becomes the more important it will be to understand interaction-based design.

Interaction design is a relatively new discipline, and one that grew out of the ability of computing to give objects and interfaces behaviour [see note 1]. In his seminal 1990 book The Design of Everyday Things [see note 2] the US-based academic Donald A. Norman outlined a useful model for understanding interaction with objects (typically products) and interfaces. He noted that a good interface to a tool has four elements: it should be visible (the user should be able to see its current state); easy for the user to form a conceptual model of the tool; there should be a good mapping between the interface and its functions; and there should be feedback to the user on the result of their actions (and how to address error or failure). These principles are entirely applicable to design for the Web and provide a good model for thinking about and evaluating design solutions.

Although interaction design is the most important Web design skill, many other skills contribute to creating appropriate design solutions. These include interface design, which overlaps considerably with interaction design, information design, and information architecture. The later skill addresses underlying organisational structure and navigation, and to an extent coheres the other design inputs. Graphic design, typography and other skills are also important, though in subsidiary roles.

Overall, with respect to users, the goal of a design should be to create "successful and satisfying experiences" - a formulation proposed by California-based designer Lauralee Alben. Successful in that the user can complete their task efficiently. Satisfying in that this experience is pleasurable and not merely functional, and where pleasure may have aesthetic, poetic and fun elements. The design solutions that most satisfy people are those that address their whole experience of using a product or service and are not narrowly focused on the explicit tasks it is intended to support.

Understanding the people who will use eGovernment services is critical to creating good services.

Understanding the people who will use eGovernment services is critical to creating good services. This should extend to the way they understand computers and the internet, the ways in which they think about and carry out tasks, and the context in which they will do this. This approach is characterised as user-centred design, a term that has been popular in some areas of IT for almost twenty years.

When considering people's understanding of systems - such as the internet - the idea of 'mental models' (or 'conceptual models', in Norman's terminology) is very useful. People create mental models for all systems with which they interact, from videos to cars, railways to government departments. These models help them get to grips with Norman's maxims: what can I do? how can I do it? why didn't it work and how can I deal with this? Understanding, however, is one thing, use is another. If a service is formally useful to a citizen but takes no account of where they use it, the constraints on their time and attention, their level of technical ability, or the related tasks they need to perform, then it is unlikely to be used at all.

At a macro level, design also needs to have a broader understanding of the context in which the project to develop a service exists. It needs to have a knowledge of current and predicted social trends, a familiarity with the culture of the department or organisation, and, where appropriate, of contemporary culture.

As well as understanding the people who will use a service, designers need to address the needs of the people who will administer it from the back office. They need to learn about the context in which they operate, investigate how they currently work, map the flow of task and approval processes, and learn enough that their design solution delivers appropriate support. If the design of the tools for government staff is poor they will be less productive and more frustrated, and quality of work may suffer. In extreme cases underestimating context of use will be disastrous. In the health service there is much discussion of patient information being entered and accessed via portable digital devices. But current digital devices are far too inflexible, fragile, unreliable, and complex for these purposes. Paper is so well-integrated into hospital processes that any design solution that proposed substantially replacing it in the near future would likely fail, even if it were technically feasible. To the credit of the GLA Congestion Charge payment options have taken into account drivers' context of use, allowing for payment using terminals in car parks and via SMS. This understanding seems to be most readily grasped for revenue collection rather than service delivery.

Beyond understanding the general context in which the client operates, the designer needs to understand the specifics of a project. This begins with establishing what will constitute success and how this might be measured, finding out who has a stake in the project, who is driving it, who makes the final decisions, and the relationship of these stakeholders. They also need to ascertain how the objectives on which the project is founded are currently addressed, look at the history of the project and any related projects, and review how similar projects fared in the past. And they need to be aware of the project constraints, including budgets, availability of client staff, and other client initiatives that may impinge on it.

Design can help avoid developing ill-conceived services.

Historically designers have tended to be invited to get involved in projects late in their development, and are often poorly briefed. Any group with skills that can contribute to a project should be involved earlier than later, and this applies as much to IT professionals and communications staff as it does to designers. Design is able to synthesise the varied and sometimes conflicting requirements of a project, consider the needs of all the project stakeholders (including the end users), and facilitate effective communication. This can be particularly useful in helping stakeholders evaluate design or technical concepts and think about the implications of particular decisions. Used in this way design can help avoid developing ill-conceived services, thereby saving time, money and stress.

Good designers should be open and collaborative members of a team. Although solving a design problem starts with a 'big idea' or innovation, the rest of the process is iterative, based on evaluation and discussion with key project stakeholders. Designers should not be precious about their ideas, or defensive about critical feedback from clients, IT staff, or in usability reports.

As a project develops the effectiveness and success of design solutions also needs to be addressed. Design concepts can be evaluated by experts (other than the designer themselves), against agreed heuristics (universally desirable features such as trustworthiness), or by considering them in 'scenarios of use' developed for the project. They can also be evaluated by usability testing, in which typical users, ideally working in their usual context, are presented with design visualisations and set realistic tasks, then asked to explain their thinking and actions as they try to achieve them.

When a service is live, evaluation of the overall success of the design (and the service) can be extended to analysing the logs of user activity generated from the Web site, reviewing and interpreting feedback from users, and conducting usability testing using the live site. Methods for evaluating the effectiveness of the implemented design for the staff who use it will depend on the nature of their work and the project objectives, but are equally important.

Along with iterative evaluation, designers (and clients and other stakeholders) will benefit from reflecting on and evaluating a project when it is formally complete. Were the department or organisation's goals met by the final implementation of the service? What worked well and what didn't? Were there incorrect or unrealistic assumptions, or were the conclusions based on them inappropriate? How well did the collaboration and communication work? How would such a project be approached if it were started over? This isn't a process of recrimination but one in which designers and others involved in the project actively learn how to work better in the future.

Getting the design and development process right for the current level of eGovernment projects is crucial, and there is much evidence that progress is being made. However there are a number of bigger challenges related to the use of design in eGovernment.

We have already discussed the concept of user-centred design. Although it is important it has to a large extent been reduced to the concept of usability, in both eGovernment and the commercial sphere. While usability is important it is irrelevant if a service is not useful, and it doesn't go far towards making it satisfying to use. In thinking about appropriate user-centred design solutions there is also a tendency to underestimate the capabilities of people - particularly those who are keen to achieve a particular goal - and their ability to adapt things designed for one purpose for other uses.

The focus in eGovernment on usability and accessibility is tending to lead to solutions that satisfy only the lowest common denominator of user needs, and limit innovation.

The focus in eGovernment on usability, and particularly the related concept of accessibility, is also tending to lead to solutions that satisfy only the lowest common denominator of user needs, and limit innovation. This is particularly clear when we consider context of use. The focus on development for PC-based Web access, and to a lesser extent digital TV, requires users to pro-actively navigate a growing sea of information. This model neither takes advantage of the user's context to help them find the information they want, nor delivers information to them at the time and place they need it.

Imagine an eGovernment portal that configured itself according to your government-related activities: an impending tax return, registering with an ante-natal unit, visiting an unemployment benefit office, calling NHS Direct, planning to vote in an upcoming election, renewing a passport, becoming eligible for child benefit. Pro-active triggers for presenting this information could be related to these activities, based on specific dates, visits or calls you have made, or a perhaps a smart form or booklet you have been sent. Imagine if you could also configure this portal with elements of your choice from all online government services. Now imagine the corollary that if you visited a government office relevant and personalised information were delivered to your portable device (phone, PDA) or made available on a private terminal in that space.

Such a model would require a 'persistent identifier' for individuals, and it would necessitate network-enabled objects and spaces. It is of course a speculative future vision, but it addresses basic design heuristics of personalisation, relevance and context. We need, and citizens deserve, vision on this scale. Current developments should be situated along a path that leads in the direction of this grander vision, and substantial innovations as well as incremental improvements initiated to get us closer to it.

The design and technical barriers to raising our ambitions will be substantial, but one of the greatest challenges will be to overcome people's distrust of government. This is not a design problem, but it is one that designers will need to appreciate, in the spirit of understanding the broader context of projects in which they are involved.

Whatever level of ambition eGovernment sets itself we need to get away from the idea that design is either about static aesthetics, or purely focused on task-based interaction. Instead we should champion an understanding of design as a conduit to solutions that deliver successful and satisfying experiences to their intended users. Within eGovernment projects design should also be used to facilitate communication and collaboration, not least to save resources and stress, and help deliver better services.

With sufficient ambition pushing it design can facilitate the creation and communication of inspiring visions for the future of eGovernment, and help put current projects on track to realise them.

Notes

1  See the Interaction Design section of the Design Council's About Design resource for a fuller discussion of interaction design.

2  The Design of Everyday Things (Basic Books, 2002) Information on the book from Norman's web site. This book is eminently accessible for a lay audience and most of Norman's examples strike a chord with readers. The most often cited is the poorly followed convention that we expect a door with a plate to be pushed, and fixed handle to be pulled, and a rotating handle to be rotated and pushed or pulled.

Nico Macdonald is principal of Spy (www.spy.co.uk) and advises on design and technology strategy. His event programming in these areas includes the first major UK conference on usability, and the monthly Design Council-supported AIGA Experience Design group. He writes regularly for national and industry publications, and is author of the recently published book What is Web Design? (RotoVision, 2003) www.whatiswebdesign.com. For further information Nico can be contacted at nico@spy.co.uk.