In the same way that successful eCommerce companies have had to get to know their users - not just through focus groups but by involving them in design and development of products, services and interfaces - Government must get to know it's customers.
Getting an interface wrong is costly. Private sector organisations lose money if their interfaces don't fulfil user requirements. So does the government. The difference is that it is the taxpayer's money - most people don't really care if Boo.com loses revenue (they might even enjoy it), but it's a different matter when their hard-earned tax money is poured into poor interfaces, and thus failed projects, in the area of eGovernment services.
Although there are plenty of bad examples out there, the private sector has learnt a lot about successful interface design and can provide many valuable pointers to the public sector. However, it would be a mistake to assume eCommerce approaches to interface design could be universally applied to eGovernment interfaces.
For most companies eCommerce means exploiting Internet technologies to achieve efficiencies or to deliver goods and services through a new channel. While government can certainly benefit by exploiting the web as a channel for service delivery, it can't lose sight of other channels. eGovernment services are for all, and PC penetration is still relatively low, many people have never used a computer and find them frightening enough for simple word processing or email, never mind dealing with the government.
Government will have to deliver services through a variety of channels - including kiosks, phones etc. This introduces new challenges, not least ensuring that each service is delivered to the appropriate audience through the appropriate channel. The phone is a likely to emerge as a popular channel for eGovernment services, but has certain limitations as a hardware device that must be considered when assigning services to this channel.
Not every service is appropriate for delivery over the phone, web and kiosk simultaneously, but some are, or will have to be. These services must be carefully designed to ensure that citizens do not have to "re-learn" a service every time they interact with it, because of the different interfaces and experiences which these devices present. The experience may vary but the interface behaviour must be as consistent as possible.
While eCommerce offerings can be developed around the needs of highly specific market niches or "user groups", eGovernment must ultimately be for everyone. The audience and the variety of associated needs are incredibly wide, and government has a legal obligation to provide services without discrimination to the population at large.
eGovernment offers attractive benefits to customers - less time queuing, accessible information, not having to fill out their name and address every time they fill out a bunch of related forms, freedom from labyrinthine bureaucracy when completing fairly simple tasks. But that doesn't mean they will use services just because they are made available on new channels. They may try them out, but they won't buy into using eGovernment services in the long term if they are difficult or confusing to use.
In the same way that successful eCommerce companies have had to get to know their users - not just through focus groups but by involving them in design and development of products, services and interfaces - Government must get to know it's customers. All aspects of service delivery must be designed around the needs of users - and the users of specific eGovernment services cannot be described with the all encapsulating "everybody".
You cannot design for "everybody". You have to design for somebody. Government must find out who the different groups of "somebodies" are - people with different functional abilities, late adopters, technophiles and technophobes, people who can't read well, or who don't speak English very well, students, farmers, businesspeople, parents and children. They all use services and technologies in different ways, depending on their needs and context and the only way you will ever design an interface for a service is to understand those needs.
Understanding user needs need not be difficult. A good interface designer can employ audience analysis techniques to gather and prioritise user requirements and then turn them into user-friendly interfaces. Doing so will not only ensure time and money savings by getting it right first time but will also significantly increase the likelihood that people will use the services in the longer term, thus yielding longer term benefits for both citizens and government.
The Benefits of Viewing User TestsThe benefits of user testing have long been established. It is still important however to try and maximise these benefits. One way in which this can be done is by viewing the user test yourself.
Back To Basics: How Poor Usability Effects AccessibilityIn recent user testing with a range of participants including Visually Impaired (VIP) and Blind users we found that the majority of problems were common across all groups. However the effect of poor usability is more severe for users with visual disabilities. Surprisingly all of the issues are very familiar and are easy to fix so we thought we’d revisit some of the basics of accessible web design.
Webpage Layout: Right Hand Side BlindnessIn several recent websites we have user tested, the site designers have placed important task critical links and information on the right hand side (RHS) of three column page layouts. The user testing was conclusive, users ignore any information presented on the RHS. We think this is a similar effect to the well documented banner blindness. It is essential to ensure that import links or information is not positioned on the RHS as they will surely be ignored.
Introduction to User Centred Design ProcessUser Centred Design (UCD) is an approach to design where the end user is placed at the heart of the design and development process. It could even be described as a ‘Design Philosophy’. Knowing who your users are, what they want and if your system is fulfilling their needs is central to UCD.
The Interface in the Environment - 'One size fits nobody'An office is an office right? So lets just focus on the task and the user? In certain cases this would be perfectly appropriate as the assumptions that we make about the office bears true, but generalising about work environments can lead to the same problems as generalising about users.
