Informatics 43 — Week 6 Lecture Notes

Covers Lecture 11 & Lecture 12: "How do we make software that meets the user's needs? (Parts 1 & 2)"

Table of Contents

1. From Design to Users — Where Lecture 11 Begins
2. Why Usability Matters
3. The Business Case for User-Centered Design
4. Usability Failures — A Gallery of Lessons
5. Three Famous Quotes Worth Memorizing
6. Why Usability Engineering Is So Hard
7. The Rise of the UX Designer
8. The Eight User-Centered Design Methods (Lecture 12)
9. Method 1: Interviews and Observations
10. Method 2: Personas
11. Method 3: Scenarios
12. Method 4: Storyboards
13. Method 5: Wireframes and Mockups
14. Method 6: Design Guidelines
15. Method 7: Heuristic Evaluation (Nielsen)
16. Method 8: User Testing
17. Quiz 6 Study Guide
18. Wrap-Up and Memory Framework

1. From Design to Users — Where Lecture 11 Begins

Week 5 closed with design principles — high cohesion, low coupling, information hiding — and the broader claim that software engineering is the process of building a set of related models that represent the system-to-be. Those models capture structure, behavior, interaction, and non-functional properties of a system.

Week 6 adds the missing piece: a system can be perfectly factored, beautifully decoupled, and architecturally pristine, and still be unusable. The question this week is therefore one zoom out from "how is the system structured?" to:

The progression we are building up is now:

Lecture 11 motivates why user orientation (usability) matters. Lecture 12 walks through eight user-centered design methods that the rest of the quarter will build on.

2. Why Usability Matters

The lecture opens with a deliberately mixed image set — an MRI machine, a power-plant control wall, an airliner cockpit — to make a single point: usability is not a "nice to have" decoration on top of important software, it is embedded in the consequences of using that software. A misread switch on a cockpit panel or a confusing button on an MRI console is not a UI bug; it is a safety event.

The Obama '08 campaign example reinforces the same idea in a much lower-stakes domain. The team A/B-tested two homepage variants that differed on two dimensions — the hero image (a portrait of Obama vs. a family photo) and the call-to-action button (SIGN UP vs. LEARN MORE). The family-photo + LEARN MORE variant lifted sign-ups by roughly 40%, which the campaign later estimated as on the order of $60M in additional contributions. The same logic that applies in life-critical systems applies in marketing: how the interface looks and is worded changes what users do.

The takeaway is not "usability is about pretty buttons." It is that the user's behavior is part of the system. Designing without considering that behavior is designing only half the system.

3. The Business Case for User-Centered Design

The lecture lists five payoffs of doing user-centered design (UCD) right:

Lecture 11's closing summary slide collapses this list into a four-bullet payoff: sales increase, performance increases, traffic counts increase, frustration decreases — and the punchline, "it's all about the user."

A subtler point the slide makes:

The benefit of UCD shifts over time from conversion (first-time customers) to loyalty (repeat customers). Early on, good UX wins users. Later, good UX keeps them.

But despite all of this, the methods are often not used. The rest of Lecture 11 shows what happens when they aren't.

4. Usability Failures — A Gallery of Lessons

Lecture 11 catalogs a series of real-world usability failures. They are funny, but each one encodes a lesson that maps directly onto a Nielsen heuristic from Lecture 12.

A few of these are worth seeing rather than just reading about — the funny ones encode the heuristic violation more vividly than any prose description.

Then the contrast slide:

The point: first impressions matter. The same task — let the user start using the product — looks like one button on Apple's screen, one search box on Google's, and a wall of cryptic acronyms on the typical enterprise app. Users decide in seconds whether the product is worth learning.

5. Three Famous Quotes Worth Memorizing

The lecture quotes three definitions of "good UI" that capture the spirit of the whole week:

"A user interface is well-designed when the program behaves exactly how the user thought it would."
— Joel on Software

"A GUI should provide GUIdance!"
— hallofshame.gp.co.at

"Focus on the user, and all else will follow."
— Google

The first quote is the operational definition: usability = match between the user's mental model and the program's behavior. The second is the design directive: an interface should actively guide the user through the task. The third is the strategic principle: get the user right and other concerns (sales, efficiency, retention) take care of themselves.

6. Why Usability Engineering Is So Hard

If UCD pays off and the methods are simple and cheap, why is good usability still rare? Lecture 11 gives two reasons:

6.1 Usability draws on disciplines outside of CS

A traditional CS curriculum trains none of these well. Software engineers are equipped to reason about correctness and performance, not about color contrast or working-memory limits.

6.2 The audience problem

The engineer's intuitions about "what's obvious" are calibrated on engineers, not on the actual users — accountants, doctors, drivers, schoolchildren, retirees. Designing well for a user you don't resemble requires deliberate methods to bridge the gap. That is exactly what Lecture 12's eight methods provide.

7. The Rise of the UX Designer

Because usability draws on so many fields outside CS, a separate role has emerged:

The UX designer sits at the intersection of art, social science, and engineering. Software engineers are not expected to be UX designers, but they are expected to work with them and to apply the basic UCD methods themselves on smaller projects.

8. The Eight User-Centered Design Methods (Lecture 12)

Lecture 12 introduces the eight user-centered design methods that the rest of the unit will treat one by one. Memorize this list — the quiz study guide explicitly calls for "the 8 user-centered design methods."

The methods roughly progress from understanding users → describing them → drawing the system → evaluating the design. They are not strictly sequential — most projects loop back through several of them as the design matures.

9. Method 1: Interviews and Observations

The first method is also the most basic: go talk to and watch real users. The lecture's images make the point — pilots in cockpits, air-traffic controllers in towers, analysts at multi-monitor workstations, dispatchers in operations centers. Each environment has its own constraints (lighting, noise, time pressure, multitasking) that you cannot guess at from a desk.

The two complement each other. Interviews capture intent and frustration; observations catch the workarounds and habits users no longer notice they have.

10. Method 2: Personas

A persona is a fictional, concrete archetype of a user — built from interview/observation data — that the design team can refer to throughout the project ("would Blake do this?").

10.1 What a persona contains

The MyFlix examples (Blake, Carrie) and the OpenMoko examples (John "The Greenhorn", Emily "The Casual User", Akiko "The Texter", Stephan "The Business User", Roberto "The Power User", Ricky "The Hacker") share a consistent structure:

10.2 Why personas work

A list of "user requirements" is abstract; a persona is concrete. When a designer asks "would Blake (27, programmer, sci-fi buff, watches TV with friends) actually click this?", the answer comes more sharply than it does for "would the user click this?". Personas make the user specific enough to argue with.

10.3 Personas come in sets

Real systems have multiple user types. The MyFlix project, for instance, distinguishes:

• Blake — content consumer (the customer)
• Carrie — application administrator at a movie studio (a back-office user)

A complete persona set covers every meaningfully different user role. The OpenMoko set goes further with six personas spanning the full spectrum from non-technical (Greenhorn) to deeply technical (Hacker), so that no design decision accidentally optimizes for only one slice of the audience.

11. Method 3: Scenarios

A scenario is a short narrative describing a specific persona using the system to accomplish a specific goal. It is written in plain English, in the third person, in a present-tense storytelling voice.

11.1 Two MyFlix scenario examples

Scenario 1: Joining MyFlix

While Blake is searching the Internet to find out if there are any local theaters playing a newly released independent film, he finds the profile page for the film which is also released on MyFlix. Excited that he can watch it and similar films in the comfort of his apartment, he creates an account and begins paying the regular monthly fee. He accesses his account from his TV's browser and is able to stream the movie.

Scenario 2: Discovering Content

Blake has some pretty specific tastes in films and TV shows. At work he browses through various categories on the MyFlix website and reads the reviews on some films in the categories he likes. Reading several summaries and recommendations that match his preferences, he adds these films to his ever growing queue, so later he can quickly pick something to watch.

11.2 What scenarios accomplish

A scenario is persona + goal + context, written as a story. It is the bridge from "who the user is" (persona) to "what we need to build" (mockups, requirements). Each persona usually has multiple scenarios, one per major goal.

12. Method 4: Storyboards

A storyboard is the visual version of a scenario — a sequence of comic-strip panels, each showing one moment in the user's experience, often with handwritten captions and speech/thought bubbles.

12.1 What a storyboard panel typically contains

12.2 The B&Q shopping example

The lecture shows an eight-panel storyboard of "Sarah" using a paintbrush-styled checkout system at a B&Q hardware store: she enters and swipes her card, the device greets her by name, she scans paint, gets a "you may like…" suggestion, browses for a paintbrush, asks for help, gets help from a real person, then exits — all that shopping and help, what a successful trip! Each panel adds one beat to the narrative.

12.3 Why storyboards beat plain text

Scenarios capture goals in words; storyboards capture emotion, environment, and timing in pictures. A frustrated thought bubble in panel three ("I do really need a paintbrush, I wonder where I can find it…") communicates a usability problem more vividly than a paragraph of text. Storyboards also force the designer to think about the physical context — where the user is standing, what they're holding, who else is around.

Storyboards are deliberately rough and hand-drawn. Polishing a storyboard would be a waste — its purpose is to provoke conversation about the experience, not to look pretty.

13. Method 5: Wireframes and Mockups

A wireframe or mockup is a low-fidelity drawing of an actual screen of the product — the layout, the controls, the labels, the navigation — without committing to final colors, typography, or images.

13.1 The fidelity spectrum

13.2 The MyFlix Zombie Romance wireframe

The lecture's example is the movie detail page for "Zombie Romance" on MyFlix:

• A browser-chrome frame at the top (back / forward / stop / home / URL bar)
• A site header with MyFlix | Categories | … on the left, a search box in the middle, and Signup - Login on the right
• A left-side navigation: Browse Movies, Read Reviews, Sign Up
• A breadcrumb trail: Home > Horror > New Releases > Zombie Romance
• The movie title, release year, synopsis, and a Cast and Crew link
• A Sign Up to Watch call-to-action button
• A "Similar Movies On MyFlix" row with three placeholder thumbnails (drawn as boxes with X's)

Horror > New Releases > Zombie Romance`, the movie title "Zombie Romance" with year "Released in 2014", a synopsis, a `Cast and Crew` link, a `Sign Up to Watch` button, and a "Similar Movies On MyFlix" row with three placeholder thumbnails (boxes with X's). No real images, no final fonts, no brand colors — by design.">

Notice what's not there: no real images (placeholders only), no final fonts, no brand colors. The wireframe is designed to surface decisions about layout, labels, and information hierarchy, not visual polish.

13.3 What Balsamiq-style sketchy wireframes signal

Tools like Balsamiq deliberately render wireframes in a hand-drawn-looking style for a social reason: they signal "this is rough — comment on the structure, not the polish." If a stakeholder is shown a pixel-perfect mockup too early, they critique font choices instead of information architecture.

14. Method 6: Design Guidelines

Design guidelines are reusable rules and pre-built components that ensure consistency across an organization's products. Without them, every team invents its own buttons, colors, and form patterns — and the result is a chaotic user experience.

14.1 The "Before" — what happens without guidelines

The lecture's "Before" slide collects two dozen U.S. government website buttons all meant to do roughly the same thing — submit a form, log in, search:

SUBMIT, JOIN US, Log in, Register, Search, GET THE LATEST, Apply Now, Get started, Sign In, Subscribe, Create an account, LOG IN, Where's My Refund?, Q Search, Apply, Search, Reset, Learn more, Login, TRY OUR VISA WIZARD, Get Weather, All Outbreaks, Search, go, …

Every button is a different color, shape, size, and verb. A user who learns one site relearns the next from scratch.

14.2 The "After" — the U.S. Web Design Standards

A design guideline document typically contains:

A design guideline is "the right way to do it" packaged as components. It saves designers from re-deciding, saves developers from re-implementing, and saves users from re-learning.

14.3 Why guidelines win

15. Method 7: Heuristic Evaluation (Nielsen)

Heuristic evaluation = using research-backed principles to evaluate and improve the usability of a system, without needing real users present. It is also called discount usability testing because it is dramatically cheaper than full user studies.

15.1 The process

15.2 Nielsen's 10 Heuristics — the centerpiece of Quiz 6

The quiz study guide says explicitly: "Know and understand all the Nielsen heuristics." Here are the ten, with the lecture's example for each.

15.2.1 Visibility of system status

The system should always tell the user what's happening through appropriate feedback in reasonable time.

Example: Picnik (photo editor) showing a green progress bar with the playful message "Fluffing clouds…" while it loads. Or an inline confirmation: "Your password has been emailed." The user is never left wondering whether the system noticed their click.

15.2.2 Match between system and the real world

The system should speak the user's language and follow real-world conventions, not internal jargon.

Example: macOS Finder uses a folder icon for folders, a document icon for documents, a camera icon for the camera app. iTunes uses Library / Music / Movies / TV Shows / Podcasts / Audiobooks / Radio — words a music listener already knows. Compare to cr_int_sprd from the Lecture 11 fail slide.

15.2.3 User control and freedom

Users make mistakes and need a clearly marked "emergency exit" — undo, redo, cancel, back, exit.

Example: every browser has a back arrow. Every editor has Ctrl+Z. Every multi-step form has a Cancel button next to the primary action. Photoshop's edit toolbar puts undo/redo right next to cut/copy/paste.

15.2.4 Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

Example: Microsoft Office uses the same ribbon, the same icons, and the same shortcuts across Word, Excel, PowerPoint. Mobile platforms have standard icons (phone, search, heart, play, mail, settings) that mean the same thing across apps. Google Translate puts the language picker in the same spot every time.

15.2.5 Error prevention

Better than good error messages is a careful design that prevents the error from happening in the first place.

Example: A form's Update button stays disabled (grayed out) until the user enters something to share — they cannot submit empty content. PowerPoint asks "Do you want to save the changes made to 'Lecture7-1'? [Don't Save] [Cancel] [Save]" before closing — three clearly distinct options, with Save as the primary action (highlighted) and Cancel as the secondary, so the user does not accidentally lose work.

15.2.6 Recognition rather than recall

Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another.

Example: macOS font picker shows each font name rendered in that font, so you recognize the look. PHP/IDE autocomplete shows a dropdown of str_pad, str_repeat, str_replace, str_rot13, strcasecmp, strchr, strcmp, … — the developer recognizes the right function instead of having to recall it from scratch.

15.2.7 Flexibility and efficiency of use (Accelerators)

Accelerators — keyboard shortcuts, gestures, command palettes — let expert users speed up without slowing down novices.

Example: OmniFocus's "Common Shortcuts" panel: Return for Add Action, ⌘N for New Window, ^⌘S for Synchronize with Server, ⌘K for Clean Up, ⌘1 / ⌘2 for Planning / Context modes, ⌥⌘1 for Inbox, ^⌥Space for Quick Entry. A novice never has to learn these; an expert depends on them.

15.2.8 Aesthetic and minimalist design

Dialogues should not contain irrelevant information. Every extra element competes with the relevant elements for the user's attention.

Example: A blog search dropdown that uses contrast (one prominent search button), repetition (consistent radio buttons for Everything / Entries / Photos / Videos / Audio / Users), alignment (everything in a tidy column), and proximity (related options grouped together). The four design principles the slide names — contrast, repetition, alignment, proximity — are worth memorizing as the recipe for minimalist design.

15.2.9 Help users recognize, diagnose, and recover from errors

When errors do occur, error messages should be in plain language, precisely describe the problem, and constructively suggest a solution.

Example: A signup form with three failures, each shown next to the relevant field with a clear, kindly worded message: "bert is already taken. Please choose a different username." / "Passwords must be at least 6 characters and can only contain letters and numbers." / "The email provided does not appear to be valid." Or a 404 page that says "Oh no! It seems the page you were trying to find on my site isn't around anymore. Report it missing using my contact form, or browse my articles listing or browse my blog."

15.2.10 Help and documentation

Even though the system should be usable without docs, help should exist — and it should be easy to search, focused on the user's task, list concrete steps, and not be too large.

Example: Picnik's onboarding tooltip "Welcome to Picnik Collages! Making collages from your photos has never been easier." with a "1 of 8" wizard. Or a small inline ? icon next to a confusing field that, on click, pops "Which one is right for me? Use Windows when… Use SNMP for… SSH works best for…" — context-specific help, exactly where it's needed.

15.3 Summary table

16. Method 8: User Testing

User testing = putting real users in front of the (real or prototype) system, giving them representative tasks, and watching what happens. Where heuristic evaluation uses experts and a checklist, user testing uses real users and observed behavior.

16.1 Improve before testing

User testing is expensive — don't waste a session on a design with obvious flaws. Run the cheaper checks first:

Only after these is it worth booking real users.

16.2 Planning a user test — the five things to design

Notice the parallel to a controlled experiment in any other field: subjects, materials, procedure, measures. User testing is empirical research, just specialized to UI.

16.3 Two settings for user testing

16.3.1 Professional usability labs

Dedicated facilities with a one-way mirror, a controlled testing room (where the user works at a single computer, sometimes with eye-tracking), and an observation room where researchers watch in real time. Sessions are video-recorded for later coding. Expensive but rigorous.

16.3.2 Less formal user testing

Many real-world tests are far simpler:

• Beta releases with feedback channels — the lecture shows a "Super Secret β" page covered in red comment markers from real users
• Analytics dashboards — real-time graphs of session duration, screens-per-session, top-screens-visited, goal completions, in-app revenue. These reveal what users do; they don't always explain why.
• A/B testing — show variant A to half of users, variant B to the other half, measure which converts better (the Obama campaign example from Lecture 11)

Big projects use the lab; everyday product work leans on beta cycles, analytics, and A/B tests. Both are "user testing" in the sense that real users drive the data.

17. Quiz 6 Study Guide

The quiz study guide slide explicitly calls out three items:

17.1 The 8 user-centered design methods

You should be able to name and briefly describe each:

17.2 All ten Nielsen heuristics

Memorize the 10 heuristics from §15.2. A useful mnemonic is to group them:

• Tell the user what's going on: (1) visibility, (2) match real world, (10) help and documentation
• Let the user steer: (3) user control, (7) accelerators
• Make the system predictable: (4) consistency, (8) minimalist design
• Handle errors gracefully: (5) prevention, (6) recognition over recall, (9) recover

17.3 Main ideas of the online readings

(See Canvas for the two short readings; the main ideas of those readings are also fair game.)

17.4 Other concepts that could appear

• Why usability matters (sales/satisfaction/efficiency/loyalty; first impressions; safety contexts)
• Why usability engineering is hard (draws on psychology/cognitive science/aesthetics/art; engineers ≠ audience)
• The three quotes (Joel: program behaves how user thought; "GUI should provide GUIdance"; Google: focus on the user)
• The four minimalist-design principles (contrast, repetition, alignment, proximity)
• The five user-test planning elements (subjects, system, tasks, session, measures)
• Pre-test improvement methods (checklists, heuristic evaluation, cognitive walkthrough)

18. Wrap-Up and Memory Framework

Week 6 knowledge structure
|
+-- Where we are
|   +-- Requirements -> Architecture -> Design -> USER METHODS -> Code
|   +-- Question this week: how do we make software that
|       meets the USER's needs?
|
+-- Why usability matters (Lecture 11)
|   +-- Stakes: from MRI/cockpit safety to web conversion
|   +-- Payoffs: simple, inexpensive, sales+, satisfaction+,
|   |            efficiency+, loyalty over time
|   +-- Famous quotes:
|   |   +-- Joel: UI is well-designed when program behaves
|   |   |        exactly how user thought it would
|   |   +-- "GUI should provide GUIdance"
|   |   +-- Google: focus on the user, all else follows
|   +-- Why it's hard:
|       +-- needs psychology, cognitive science, aesthetics, art
|       +-- engineers are NOT the audience -> need methods
|
+-- The 8 User-Centered Design Methods (Lecture 12)
|   +-- 1. Interviews and observations
|   |       -> direct data from real users
|   +-- 2. Personas
|   |       -> photo + demographics + quote + bio +
|   |          goals + tasks + tech skill + environment
|   |       -> sets cover multiple user roles
|   +-- 3. Scenarios
|   |       -> short narrative: persona + goal + context
|   |       -> in plain English, third person
|   +-- 4. Storyboards
|   |       -> comic-strip visualization of a scenario
|   |       -> thought bubbles surface confusion
|   +-- 5. Wireframes / Mockups
|   |       -> low-fi drawings of actual screens
|   |       -> Balsamiq-style sketchiness signals
|   |          "comment on structure, not polish"
|   +-- 6. Design guidelines
|   |       -> color palette + typography + components +
|   |          wireframes + code
|   |       -> US Web Design Standards as canonical example
|   +-- 7. Heuristic Evaluation (Nielsen) **
|   |       -> process: select tasks, play user,
|   |          evaluate per heuristic, take notes
|   |       -> 10 heuristics (memorize):
|   |          1. Visibility of system status
|   |          2. Match between system and real world
|   |          3. User control and freedom
|   |          4. Consistency and standards
|   |          5. Error prevention
|   |          6. Recognition rather than recall
|   |          7. Accelerators (flexibility & efficiency)
|   |          8. Aesthetic and minimalist design
|   |             (contrast, repetition, alignment, proximity)
|   |          9. Help users recognize/recover from errors
|   |         10. Help and documentation
|   +-- 8. User testing
|           -> improve first (checklists, heuristic eval,
|              cognitive walkthrough)
|           -> plan: Subjects, System, Tasks, Session, Measures
|           -> formal lab OR informal (beta, analytics, A/B)
|
+-- Quiz 6 study guide
    +-- 8 user-centered design methods
    +-- all 10 Nielsen heuristics
    +-- main ideas of online readings

One-sentence summary

User-centered design exists because a well-architected system that ignores its users still fails — and software engineers, who are not their own audience, need explicit methods to bridge that gap; those methods proceed from understanding users (interviews and observations) to describing them (personas, scenarios, storyboards) to drafting the system (wireframes/mockups, design guidelines) to evaluating it (heuristic evaluation against Nielsen's ten principles, then user testing with real users in labs or via beta/analytics/A/B), and the operational definition of "good" running through all of it is Joel's: the interface is well-designed when the program behaves exactly the way the user expected it to.