User Requirements for Inclusive Communication

Speech given at the Leading Modernisation Programme Workshop ‘Implementing the National Programme for IT: Moving from Planning to Delivery’

Date: 18/11/2004
Venue: Hilton Hotel, York, UK


I am going to tell you a few things which you already know in your hearts but which might not quite have crystalised. I also want to make it clear from the outset that I recognise and respect your commitment to serve every single person in our country; so if you find the tone slightly jarring because I am urging you to do something you really want to do, this is because I have got so used to campaigning in the face of indifference that it's a hard habit to kick.

What's the difference between the computing and the television experience; here are some characteristics of television:

  1. Even with an electronic programme guide covering 900 potential channels and 168 hours of data per channel you don't get lost; and you can do all this with a numeric keypad
  2. If you press the wrong button it's easy to put things right
  3. If something goes wrong the broadcaster takes responsibility.

So, you can find what you want with a simple device, the system is robust and you're not blamed when something goes wrong. For these, and a variety of other reasons, notably our culture's attachment to broadcasting, we trust our tellies much more than our computers; so if you want to communicate with people via the internet, the end user has to enjoy a broadcast-like experience. For many people that experience  won't be the Sky EPG but the use of only two or three channels, so we might have to consider a very simple on-screen array. In these circumstances it is vital that we observe the (7 + or - 2) rule which says that when you are making a selection from a wide variety of items, if there are more than nine classes there are too many and if there are fewer than five classes they are too big.

Limiting yourself to nine classes places a quite severe strain on taxonomy. In fact, the biggest single usability problem on web sites is poor taxonomy or, in some cases, no recognisable taxonomy at all. Students coming out of design school may have a fine aesthetic eye but they are not likely to have taken Philosophy 101. I would not recommend more than three layers of menu, so if you have a top, second and third level of seven with all cells filled you can have 343 items. At that point, if you want to drill down deeper, you are probably into lists which can be scrolled. If in doubt, you need a key word search function and remember this should be SMS-able, not just qwerty.

Which brings me nicely to the user interface experience. For the past two and a half years I have been involved in a big DfES project called Cybrarian, designed to get the disenchanted online, a very similar demographic to the heaviest NHS users - the elderly, the disabled, the poor. My responsibility was to assemble the user requirement for the information system and top of the list came the requirement that the information should be available on television and on telephones as well as through the PC. As I have noted, this imposes all kinds of design disciplines but it also provides end users with an interface choice. People who live alone, for example, may be quite happy to undertake health related transactions on a television in their living room but people living together will want assured privacy and they might prefer a mobile phone or the PC in their bedroom.

Here are some other Cybrarian user requirements ranked in descending order:

  1. Cross platform
  2. Input/Output Customisable data and metadata (font, print size; foreground/background colour; sound out; justification, proportional spacing, leading; file size; data array)
  3. Output Data/Metadata customisable (Purpose; reading age; ranking)
  4. Internal language engineering (reading age)
  5. Language Translation

All these should be automated.

  1. Portable customer profiles
  2. Multimodal
  3. Variable navigation systems
  4. Compatible with accessibility peripherals.

Most of these requirements boil down to customisation which in turn requires simple design, granularity and migration tools. The characteristic most likely to be overlooked is multimodality which means providing identical information in a variety of forms; for example, many people will prefer a diagram of the body which allows them to click on a certain part which opens up a file of information but such click-on images are no use either if you have a device without a mouse or if you can't see or are accessing the data over a traditional telephone. So as much material as possible should be graphical and text based allowing speech out and all the information should be customisable. Not only do different people have different print size requirements, for example, this may vary depending upon the lighting conditions and the time of day or year.

This sounds like a huge array of requirements and I have a small library of standards and tables from which I have gleaned a few essentials; but at base you have to imagine your clients. The most basic user requirement of all is that your information should be designed for your user. If, for example, the professional requirement is radically different from the patient requirement in the case of medical records you have to work out whether one customisable file can do both jobs or not. My guess is that with good automated tools it can, on the basis that it is much easier using automation to simplify than to elaborate. Most information systems imposed on the public are not designed for public; some are designed for professionals whose job it is to serve the public. a good example of this is just about any Government web site which is organised according to Departmental structure. Most sites, however, are designed by designers for themselves; they are acts of complete self indulgence, reflecting the passionate belief of designers that they are part of the television industry, not the intellectual progeny of graph paper designers. It is my experience that when a designer says something can't be done, you have got the wrong designer.

This leads naturally to the vexed topic of user testing. I say vexed because most user testing is not conducted using properly weighted demographic samples; most so called user testing is undertaken by in-house technophiles. On the rare occasions where a representative sample is assembled, people are usually asked to undertake rigorous testing without being paid; this particularly irks unemployed people.

So, here in brief are the key points about user requirements for a digital information system to be used by the whole population:

  1. Produce a broadcast-like experience
  2. Design for a variety of interfaces
  3. Make data and metadata customisable
  4. Design primarily for the end user
  5. Conduct user testing with a representative sample.

Finally, and crucially, this is a package; what you must not do is to design the bulk of your system, which we will call the locomotive, and then sequentially attach carriages for usability, accessibility etc. The approach has to be integrated for two key reasons: first, of course, there is cost; but, secondly, there is a legal requirement in the face of which ignorance or indigence are no defence.