






Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
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
1 / 11
This page cannot be seen from the preview
Don't miss anything!







Lesson 2.
Human error is the result of any action whose consequences are not what was intended by the person performing the action.
Lesson 2.
➢ 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).
→ 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 stages → Each 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
Summary