Lesson 2.5 Errors and User-Control, Lecture notes of Systems Design

The different types of human errors that can occur in interface design and how to prevent them. It covers slips, lapses, and mistakes, as well as mode errors and common features of human error. The document also provides tips for avoiding capture and description slips, mode errors, and lapses. Additionally, it discusses user control and freedom, clearly marked exits, manual overrides for automatic systems, and supports undo. Finally, it covers traditional software engineering processes and user-centered design in design, including analysis, generating design sketches, scenarios, storyboards, and contextual inquiry.

Typology: Lecture notes

2020/2021

Available from 04/02/2022

gwen-hermo
gwen-hermo 🇵🇭

10 documents

1 / 11

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Lesson 2.5
Errors and User-Control
Human error is the result of any action whose consequences are not what was intended by the
person performing the action.
slips and lapses and mistakes according to how they occur.
Slips and lapses are found in skilled behavior execution of procedures that the user has already
learned.
A slip is a failure of execution or control
- A good mental picture for this is that you’ve developed a mental groove from executing
the same sequence of actions repeatedly, and this groove tends to capture other sequences
that start the same way.
A lapse is a failure of memory
- A loss of intention lapse happens when you start executing a procedure and forget your
goal in the interim.
A mistake is an error made in planning or rule application.
MODE ERROR
states in which the same action has different meanings.
- Mode errors are generally slips, an error in the execution of a learned procedure, caused
by failing to correctly evaluate the state of the interface.
COMMON FEATURES OF HUMAN ERROR
Inattention - associated with insufficient attention to the execution of the procedure, or omission
or distraction of attention at a key moment.
high similarity to the correct behavior
AVOIDING CAPTURE AND DESCRIPTION SLIPS
applying the converse of the Consistency heuristic - different things should look and act
different, so that it will be harder to make description errors between them.
Avoid actions with very similar descriptions, like long rows of identical buttons.
well-separated from frequently-used commands.
AVOIDING MODE ERRORS
Eliminating the modes
spring-loaded or temporary modes - user has to do something active to stay in the alternate
mode
designing action sets so that no two modes share any actions.
AVOIDING LAPSES
keep procedures short
put more obvious structure on the procedure, a technique called dialog closure
Action sequences should be designed with a beginning, a middle, and an end
OTHER RULES FOR ERROR PREVENTION
allow users to select rather type - reduces the user’s memory load
information needed by a task should be visible or otherwise accessible in the interface for that
task
Protect users’ work
Confirmation dialogs can substantially reduce the efficiency of the interface
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download Lesson 2.5 Errors and User-Control and more Lecture notes Systems Design in PDF only on Docsity!

Lesson 2.

Errors and User-Control

Human error is the result of any action whose consequences are not what was intended by the person performing the action.

  • slips and lapses and mistakes according to how they occur.
  • Slips and lapses are found in skilled behavior – execution of procedures that the user has already learned.
  • A slip is a failure of execution or control
    • A good mental picture for this is that you’ve developed a mental groove from executing the same sequence of actions repeatedly, and this groove tends to capture other sequences that start the same way.
  • A lapse is a failure of memory
    • A loss of intention lapse happens when you start executing a procedure and forget your goal in the interim.
  • A mistake is an error made in planning or rule application. MODE ERROR
  • states in which the same action has different meanings.
  • Mode errors are generally slips, an error in the execution of a learned procedure, caused by failing to correctly evaluate the state of the interface. COMMON FEATURES OF HUMAN ERRORInattention - associated with insufficient attention to the execution of the procedure, or omission or distraction of attention at a key moment. → high similarity to the correct behavior AVOIDING CAPTURE AND DESCRIPTION SLIPSapplying the converse of the Consistency heuristic - different things should look and act different, so that it will be harder to make description errors between them. → Avoid actions with very similar descriptions, like long rows of identical buttons.well-separated from frequently-used commands. AVOIDING MODE ERRORSEliminating the modesspring-loaded or temporary modes - user has to do something active to stay in the alternate mode → designing action sets so that no two modes share any actions. AVOIDING LAPSESkeep procedures short → put more obvious structure on the procedure, a technique called dialog closureAction sequences should be designed with a beginning, a middle, and an end OTHER RULES FOR ERROR PREVENTION
  • allow users to select rather type - reduces the user’s memory load
  • information needed by a task should be visible or otherwise accessible in the interface for that task
  • Protect users’ work
  • Confirmation dialogs can substantially reduce the efficiency of the interface
  • Reversibility - undoable, using automatic save or keeping unsaved drafts in a special directory. WRITING ERROR MESSAGES & DIALOGS
  • stop and ask yourself whether it’s really necessary
  • error message is evidence of a limitation or lack of flexibility on the part of the system – a failure to prevent an error or absorb it without complaint. o be precise and comprehensible o suggest reasons and solutions o be polite USER CONTROL & FREEDOM ➢ An interface should encourage this kind of exploration, not only by making things more visible, but also by making the consequences of errors less severe. ➢ the idea that in the give and take between the user and the system, the user should have ultimate control. CLEARLY MARKED EXITSveto – the ability to cancel an operation, even if it was something they asked for. ➢ Users should not be trapped by the interface.
  • dialog - the general pattern of back-and-forth communication between the user and the interface, as if the user and the system are having a conversation. MANUAL OVER RIDES FOR AUTOMATIC SYSTEM ➢ we build software in the first place is to automate a process, taking some burden off the human users. ➢ Austin Henderson - building systems that demand coherence from their users and their environment, expecting input that fits into expected categories and rejecting all others ; the real world is fuzzy, full of exceptions and oddities, and we should build pliant systems that can survive the exceptions. NEVER ASK ME AGAIN ➢ inefficient (and annoying) to keep asking the same question repeatedly – so many of these dialogs offer the option Never ask me again. ➢ remember that just because the user has seen a message doesn’t mean they’ve learned what it had to say. It’s not clear that this really fixes the problem, but I haven’t seen any better solutions. USER CONTROL OVER DATA ➢ interface should provide a way to go back and change what the user originally entered ➢ CRUD - if you can Create an object or data field, you should be able to Read , Update , and Delete it, too. ➢ make sure data are mutable NO ARBITRARY LIMITS ON USER-DEFINED NAMES ➢ Artificial limits on length or content should be avoided ➢ If an interface allows users to name things, then users should be free to choose long, descriptive names, with any characters or punctuation they want. SUPPORTS UNDOCancel - most common answer for user control over dialog ➢ Undo - most common answer to user control over data.

Lesson 2.

User-Centered Design

USABILITY ENGINEERING IS A PROCESS

➢ User interfaces are hard to build, and usability is a hard property to guarantee. ITERATIVE DESIGN → don’t go around the design-implement-evaluate loop just once → Using the results of evaluation , we redesign the interface, build new prototypes , and do more evaluation. → optimizations for the iterative design process: design guidelines reduce the number of iterations by helping us make better designs ; cheap prototypes and discount evaluation techniques reduce the cost of each iteration. → Basic realization that in general: you won’t get it right the first time → offers a way to manage the inherent risk in user interface design. → the software is refined by repeated trips around a design cycle: o first imagining it (design), o then realizing it physically (implementation), o then testing it (evaluation).

  • SPIRAL MODEL → offers a way out of the dilemma → build room for several iterations into our design process, and we do it by making the early iterations as cheap as possible. → radial dimension of the spiral model corresponds to the cost of the iteration step – or, equivalently, its fidelity or accuracy.

→ if we find ourselves with several design alternatives, we can build multiple prototypes (parallel design) and evaluate them, without much expense. → After we have evaluated and redesigned several times, we have (hopefully) learned enough to avoid making a major UI design error. → The more iterations we can make, the more refinements in the design are possible. → We keep the parts of the design that work , and redesign the parts that don’t. So we should get a better design if we can do more iterations. TRADITIONAL SOFTWARE ENGINEERING PROCESS : WATERFALL MODEL → one of the earliest carefully-articulated design processes for software development. → models the design process as a sequence of stagesEach stage results in a concrete product – a requirements document, a design, a set of coded modules – that feeds into the next stage. → Each stage also includes its own validation : the design is validated against the requirements, the code is validated (unit-tested) against the design, etc. → the discipline it puts on developers to think first, and code second. Requirements and designs generally precede the first line of code. → expected to meet certain milestones for each stage of your project, and each milestone had a concrete product o (1) a design document; o (2) code modules that implemented certain functionality; o (3) an integrated system. → Validation is not always sufficient; sometimes problems are missed until the next stage. → The waterfall model implicitly needs feedback between stages. → useful for some kinds of software development, it’s very poorly suited to user interface development. o Development is inherently risky o users appear in the process in only two places: requirements analysis and acceptance testing. o when UI problems arise, they often require dramatic fixes: new requirements or new design. User-Centered Design in Design

  • knowing who your users are and understanding their needs o Who are they? o What do they already know? o What is their environment like? o What are their goals? o What information do they need?

Summary

  • Models for software development o Waterfall model makes sense for low-risk projects o Iterative or spiral models are needed when the requirements and design space are unknown or risky o UI development is often risky
  • User-centered design process o Iterative , prototype-driven o Early focus on users and tasks o Constant evaluation