CSFG
English Deutsch Beta Español Beta język polski (2.6.0)
Chapters Curriculum Guides Appendices

Human Computer Interaction
4.2. Users and tasks

Human Computer Interaction

  • 4.1. What's the big picture?
  • 4.2. Users and tasks
  • 4.3. Interface usability
  • 4.4. Usability heuristics
  • 4.5. User Experience
  • 4.6. Pointing at things: Fitts' Law
  • 4.7. The whole story!
  • 4.8. Further reading

A very important consideration when designing or evaluating an interface is who the users are likely to be. For example, the typical age of a user can be significant: very young children may have difficulty reading some words and prefer images and animations, while someone in a commercial setting who uses an interface frequently will want it to be very fast to use, perhaps using keyboard shortcuts only.

Think about the kinds of considerations you would have to make for the following user groups.

  • Senior citizens
  • Gamers
  • Casual users
  • Foreign visitors
Some possible answers: Don't open until you've thought about it! Spoiler!
  • Senior citizens: use large print, have few features to learn, don't rely so much on memory, allow for poor eyesight and less agile physically (e.g. large buttons help), don't assume previous experience with computers
  • Gamers: use previous experience with typical game interfaces, expecting challenges, possibly running on a high-end machine
  • Casual users: interface needs to be very easy to learn, perhaps based on widely used systems, needs clear guidance
  • Foreign visitors: use simple language and meaningful images/icons

The interface is the only part of a program that the user sees (that's the definition of an interface!), so if the interface doesn't work for them, then the program doesn't work.

Another important thing to do when designing and evaluating an interface is to think about what tasks it is being used for. Advertisements for digital devices often hide the complexity of a task, and simply point out the features available for doing the task. For example, suppose a smartphone is advertised as having a high resolution camera. The real task that someone might want to do is to take a photo of something they've just spotted, and send it to a friend. If you look at what happens in reality, the smartphone might be in their pocket or bag, and if they see something cool going past, they need to:

  1. Get it out.
  2. Unlock it.
  3. Open the camera app.
  4. Adjust the lighting and other settings.
  5. Press a button (is it easy to find when you're holding the camera up?).
  6. Select the photo.
  7. Choose a sharing option.
  8. Select a friend to share it with (does the system help with that?).
  9. Send it (what happens if you're out of reception range?).
  10. Put the phone away.

If any one of these steps is slow or hard to remember, the whole experience can be frustrating, and it's possible the photo opportunity will be missed, or for some other reason the friend won't receive the photo.

It's important to think through all the parts of a task when discussing an interface, as it's the small steps in a task that make all the difference between using the interface in a real situation, compared with a demonstration of some features of the device.

Thinking about the context of tasks Challenge

It's very important to think about the whole context when describing a task. As an exercise, can you provide an example of a real task, including context, for a real person for each of the following:

  • Set an alarm clock
  • Show a slide (e.g. PowerPoint) presentation

Discuss your answers with a classmate or a friend. This should help you to evaluate your own answer, and consider other possible examples.

Dumb users or dumb interfaces? Curiosity

Computer systems often make people feel dumb – in fact, there are lots of "dummies" books available, such as "iPad for dummies" or "The Complete Idiot's Guide to Microsoft Windows 10". These books sell millions of copies, yet chances are the people who buy them are actually quite intelligent – it's just that the interfaces can make people so frustrated that they feel like a dummy. The truth is that if an interface makes lots of people feel like an idiot, chances are the real problem is with the interface and not the user. In the past there has been a culture where the balance of power was with the programmers who designed a system, and they could afford to blame the users for any problems. However, now users have a large choice of systems, and there are competitors ready to offer a better interface, so if a programmer continually blames your users for problems, chances are it's the programmer who is the complete idiot! If you hear people using derogatory terms such as luser, PEBKAC, or ID-10T error (Idiot error), they may be humorous, but they usually show a disregard for the importance of getting an interface right, and are a sign that the system is badly designed.

Sending an email from multiple devices Project

For this project, try sending an email from both a computer and a mobile phone. Take note of all the steps required from when you start using the device until the email is sent.

You will probably notice quite a few differences between the two interfaces.

Keep your notes for later, as you can further analyse them once you have read through more of this chapter.

Designing stovetops and door handles Project
User conflict opening a door.

For this project, you will design the top of a cooking stove, or the handles on a door. This isn't a computer system, but will help demonstrate some of the issues that come up. The main task is to sketch three different configurations for the stovetop which includes the arrangement of the 4 elements and the 4 control knobs.

The task is described in detail in CS Unplugged human interface design activity.

Previous:
What's the big picture?
Next:
Interface usability

Looking for something for primary schools? Check out CS Unplugged.

The Computer Science Field Guide is an online interactive resource for high school students learning about computer science.

Useful Links

  • About
  • Chapters
  • Interactives
  • Curriculum Guides

Community

  • Twitter
  • YouTube
  • GitHub

Help

  • Search
  • Glossary
  • Feedback

Switch to teacher mode

English | Deutsch | Español | język polski (2.6.0)

The Computer Science Field Guide material is open source on GitHub, and this website's content is shared under a Creative Commons Attribution-ShareAlike 4.0 International license. The Computer Science Field Guide is a project by the Computer Science Education Research Group at the University of Canterbury, New Zealand. Icons provided generously by icons8.

3.10.1

This definition is not available in English, sorry!