Lecture overview:

• Total time: ~55 minutes
• Prerequisites: Students understand requirements analysis (L9), domain modeling (L12)
• Connects to: User-centered design (next lecture), Safety and Reliability (L35)

Structure (~32 slides):

• Arc 1: Why Usability Matters (~10 min) — five aspects building incrementally, trade-offs
• Arc 2: Stakeholders and Personas (~10 min) — who we're designing for, trade-offs explicit
• Arc 3: Mental Models (~4 min) — Marcus vs Dorothy expectations, strategies
• Arc 4: Usability and Safety (~5 min) — error taxonomy, safety risks
• Arc 5: Evaluating Usability (~3 min) — approaches overview
• Arc 6: Nielsen's 10 Heuristics (~16 min) — systematic evaluation, one slide each
• Key Takeaways (~2 min)

Running example: SceneItAll IoT/smarthome control platform (familiar from L2, L8, L9)

Narrative spine: There's a gap between software that works and software people want to use. This lecture gives students the vocabulary (five aspects), the mindset (personas and trade-offs), and the tools (Nielsen's heuristics) to close that gap.

Transition: Let's start with the learning objectives...

CS 3100: Program Design and Implementation II

Lecture 24: Usability

©2026 Jonathan Bell, CC-BY-SA

Context from previous lectures:

• L9: Requirements analysis — we learned to identify stakeholders and their needs
• L12: Domain modeling — we learned to structure our understanding of the problem
• Today: We ask — can users actually use what we build?

Key theme: Technical correctness is table stakes. Usability determines whether anyone actually wants to use your software.

Transition: Here's what you'll be able to do after today...

Learning Objectives

After this lecture, you will be able to:

1. Define usability and describe the five key aspects of usability
2. Identify stakeholders and their usability concerns
3. Create personas to make design trade-offs explicit
4. Recognize the relationship between usability and safety
5. Apply Nielsen's 10 Usability Heuristics to evaluate an interface

Time allocation:

• Objective 1: Five aspects of usability (~12 min)
• Objective 2-3: Stakeholders and personas (~10 min)
• Objective 4: Usability and safety (~5 min)
• Objective 5: Nielsen's heuristics (~18 min)

Why this matters: Most software projects don't fail because of bugs — they fail because users can't figure out how to use them, or hate using them.

Transition: Let's start with a fundamental question...

Working Software Is Table Stakes — Usable Software Wins Users

The key insight:

• You can build software that passes every test, implements every requirement, and never crashes
• And still end up with software that users hate, avoid, or misuse

SceneItAll example:

• Technically: all device commands work, state syncs correctly, scenes execute
• But if users can't figure out how to turn off their living room lights, they'll use the physical switch instead

Connection to L9:

• In requirements analysis, we identified who the users are
• Now we ask: can they actually use what we build?

Transition: Let's define usability more precisely...

Usability Measures How Well Software Serves Humans Achieving Their Goals

Usability is a measure of how well an artifact (software, device, interface) supports humans in achieving their goals.

It's not a single property but rather a collection of related qualities:

• Can users figure out how to use it?
• Can they accomplish their actual tasks?
• How much effort does it take?
• Will they remember how to use it later?
• Do they enjoy the experience?

Connection to L9: We identified stakeholders and their needs. Usability asks: can they actually meet those needs using our software?

Definition unpacked:

• "Supports humans" — not just technically correct, but human-centered
• "Achieving their goals" — users have purposes; software should serve those purposes
• "Collection of qualities" — not a single metric, but multiple aspects

The questions preview the five aspects we'll cover next.

Transition: Let's break down these five aspects...

Learnability and Effectiveness: Can Users Figure It Out and Succeed?

Learnability ●

How easy is it for users to accomplish tasks the first time?

SceneItAll test: Can a new user turn off living room lights without a tutorial?

• ✓ High: See "Living Room" → tap → adjust
• ✗ Low: See "Area Hierarchy Browser" → confused

Effectiveness ●

Can users successfully complete their intended tasks?

SceneItAll test: Can users create a "Movie Night" scene?

• Working ≠ Discoverable
• Attempted ≠ Completed
• Completed ≠ Correct

Relationship: Users must first learn the interface before they can be effective. First impressions matter — users who fail early may never try again.

Learnability:

• First impressions matter enormously
• Depends on mental models — matching user expectations
• Connection to L12: Domain vocabulary should align with user vocabulary

Effectiveness:

• Feature exists but hidden → discoverability problem
• User tries but gets stuck → workflow problem
• User thinks done but isn't → feedback problem

The relationship:

• Learnability is the gateway to effectiveness
• Can't be effective if you can't figure out how to start
• But being learnable doesn't guarantee effectiveness (user might learn wrong thing)

Transition: Once effective, how much effort does ongoing use require?

Productivity and Retainability: Efficiency Over Time

Productivity ●

How efficiently can users accomplish tasks once learned?

SceneItAll test: Turn off all downstairs lights

• Low: 12+ taps through nested menus (2 min)
• High: One "Downstairs Off" button (3 sec)

Same outcome, vastly different effort.

Retainability ●

How well do users maintain proficiency over time?

SceneItAll test: Guest returns next holiday — can they still use it?

• Seasonal features (holiday lights yearly)
• Rare operations (adding new device)
• Occasional users shouldn't re-learn

Relationships: Effectiveness leads to productivity through practice. Learnability enables retainability — interfaces matching mental models are easier to remember. Retainability feeds back into productivity.

Productivity:

• Users do tasks repeatedly; small inefficiencies compound
• Productive systems "disappear" — users focus on goals, not the tool
• Design: shortcuts, batch operations, smart defaults

Retainability:

• Most users are "occasional" users of most features
• Muscle memory fades; arbitrary procedures are forgotten
• Design: consistent patterns, visual cues, natural structure

The relationships:

• Effectiveness → Productivity: Once you CAN do it, how FAST can you do it?
• Learnability → Retainability: Easy to learn = easy to remember
• Retainability → Productivity: Remembering means no re-learning overhead

Transition: Finally, how do users feel about all this?

Satisfiability Connects Everything: The Complete Picture

Satisfiability ●

How pleasant is the experience?

• Satisfied users explore more features
• Satisfied users forgive occasional issues
• Frustrated users abandon for alternatives

The feedback loop: Satisfaction → willingness to learn more → deeper effectiveness → greater productivity → more satisfaction

Design Decision	Helps	Hurts
Detailed onboarding tutorial	Learnability	Satisfiability (impatient users)
Voice command shortcuts	Productivity	Learnability (more to discover)
All options on one screen	Productivity	Learnability (overwhelming)

You can't maximize everything — good design requires knowing which aspects matter most for your users.

Satisfiability:

• Might seem "soft" but matters enormously
• Satisfied users recommend; frustrated users leave negative reviews
• Includes aesthetics, responsiveness, delight — small touches matter

The complete picture:

• Five aspects form a reinforcing cycle
• But they also create trade-offs (table examples)
• Tutorial: Great for newbies, annoying for experts
• Dense screens: Experts want it, beginners get lost

The question becomes:

• Who are we designing for?
• Which trade-offs are right for them?
• This leads us to personas...

Transition: Here's a concrete example of these trade-offs...

CLI vs. GUI: Neither Is Universal — Context Determines the Right Choice

Command-Line Interface

> sceneitall set living-room lights 50%
Living room lights set to 50%
> sceneitall activate "Movie Night"
Activating scene: Movie Night...

Aspect	Rating
Learnability	Low (must learn commands)
Effectiveness	High (if you know commands)
Productivity	Very high (for experts)
Retainability	Low (forget syntax)
Satisfiability	Varies (some love CLIs)

Graphical Interface

Visual room layout with sliders, buttons, and scene cards

Aspect	Rating
Learnability	High (visual, explorable)
Effectiveness	High (guided interactions)
Productivity	Medium (more clicks)
Retainability	High (visual cues)
Satisfiability	Generally higher

Neither is "better" — it depends on who's using it and for what.

The lesson:

• Tech-savvy homeowner managing 50 devices might prefer CLI
• Visiting grandparent just wants to turn on lights
• Same system, different interfaces for different users

Design implication:

• Maybe provide both?
• GUI as default, CLI for power users
• This is an example of flexibility (Nielsen H7)

Connection to Lab 9:

• Students worked with SceneItAll CLI
• They've experienced both sides of this trade-off

Transition: But who are we designing for? Different stakeholders have different priorities...

Different Stakeholders Prioritize Usability Aspects Differently

Remember from L9: stakeholders are anyone who affects or is affected by the system. Different stakeholders care about different usability aspects.

Stakeholder	Usage Pattern	Usability Priorities
Primary owner	Daily, 10+ times	Productivity, Satisfiability
Family members	Daily, didn't choose system	Learnability, Effectiveness
Guests	Occasional (holidays)	Learnability, Retainability
Installer	One-time configuration	Effectiveness, Productivity
Neighbors	Indirect (affected by outdoor lights)	Safety implications

Same system, same features — but you can't optimize for everyone. You must make intentional choices about priorities.

Connection to L9:

• We already identified stakeholder categories
• Now we analyze which usability aspects each category cares about most
• This drives design decisions

Stakeholder breakdown:

Primary owner (daily):

• Uses app constantly, wants maximum productivity
• Priority: "Make common operations fast"

Family members (daily):

• Didn't choose the system but must live with it
• Priority: "Don't make me feel stupid"

Guests (occasional):

• Visit once, then months later
• Priority: "Intuitive for strangers"

Installer (professional):

• Configures system once, needs efficiency
• Priority: "Don't waste my time"

Neighbors (indirect):

• Can't use the app, but impacted by its usability failures
• Priority: Usability problems shouldn't create safety/nuisance issues

Transition: These stakeholders are still pretty abstract. Let's make them more concrete with personas...

Personas Make Stakeholders Concrete: Meet Marcus and Dorothy

Persona: A fictional but realistic user that makes trade-off discussions concrete — "Would Marcus find this useful? Would Dorothy be confused?"

Features Marcus loves (automations, shortcuts) overwhelm Dorothy. Simplicity Dorothy needs frustrates Marcus.

Why personas over stakeholder categories?

• "Occasional user" is abstract — hard to reason about
• "Dorothy, Marcus's 72-year-old mother visiting for the holidays" is concrete
• You can imagine her reactions, frustrations, needs
• Good personas come from user research, but even educated personas help

Marcus represents:

• Power users who invested in the ecosystem
• Users who want depth and control
• Priority: Productivity, Flexibility

Dorothy represents:

• Occasional users who didn't choose the system
• Users who want simplicity above all
• Priority: Learnability, Retainability

The tension:

• Features Marcus loves overwhelm Dorothy
• Simplicity Dorothy needs frustrates Marcus
• How do we decide which needs win when they conflict?

Transition: Let's see how personas help us make trade-off decisions...

Personas Reveal Which Trade-offs Matter

Design Decision	Marcus	Dorothy
Add onboarding tutorial	Skip it (wastes time)	Needs it (can't figure out otherwise)
Expose automation rules	Essential feature	Hidden complexity (confusing)
Voice command shortcuts	Daily use, loves them	Confusing ("what do I say?")
Simple big buttons	"Childish, wastes space"	Accessible, easy to tap
Nested area hierarchy	Powerful organization	"Where is the guest room??"

You can't optimize for everyone. Personas force you to choose primary users and make intentional trade-offs.

Connection to L9: Remember stakeholder analysis? Personas are the usability-focused refinement of that work.

Key insight:

• The trade-offs are real and unavoidable
• But with personas, they're explicit and intentional
• "We chose to optimize for Marcus at the expense of Dorothy" is honest
• "We tried to make everyone happy" usually makes no one happy

How to use this:

• Define primary persona (who are we really designing for?)
• Secondary personas (we'll try to accommodate if we can)
• Anti-personas (explicitly not designing for, and that's okay)

SceneItAll example:

• Primary: Marcus (power users who chose the system)
• Secondary: Dorothy (guests, occasional users)
• Decision: Default to simple mode, with easy access to power features

Transition: Can we actually serve both personas?

Design Flexibility Can Serve Multiple Personas

Good design often means designing multiple experiences within one product.

Progressive disclosure:

• Show simple options by default
• More appears as users drill down
• Experts find what they need; novices aren't overwhelmed

Guest mode example:

• Marcus adds Dorothy's phone with guest permissions
• Dorothy's app shows: Living Room, Kitchen, Guest Room, Bathroom
• Big "Lights On/Off" buttons, nothing else
• Marcus's app shows all 50 devices, automations, schedules, etc.

Connection to L9:

• Requirements revealed different user types
• Now we design interfaces that serve each type appropriately

Trade-off:

• Flexibility adds complexity to implementation
• But it's often the right answer when personas have conflicting needs

Transition: Marcus and Dorothy don't just have different priorities — they have different mental models...

Marcus and Dorothy Have Different Mental Models

Whatever SceneItAll actually does, it violates someone's mental model.

Connect to personas:

• Marcus (power user) might expect cascade down — he thinks hierarchically
• Dorothy might expect only this room — simpler, more literal interpretation
• The installer might expect something else entirely!

The fundamental problem:

• Different users bring different expectations based on their backgrounds
• All three mental models are reasonable based on prior experience
• Each user has seen apps that work each of these ways!

Design dilemma:

• You can only pick one actual behavior
• Some users will be surprised/confused no matter what you choose

Transition: So what can we do about this?

Good Design Either Matches Mental Models or Makes Behavior Visible

Strategy 1: Match the most common mental model

• Research which expectation is most prevalent
• Design behavior to match that expectation
• Accept some users will need to adjust

Strategy 2: Make actual behavior clearly visible

• Show cascade indicators: "This will affect 3 other areas"
• Preview affected devices before confirming
• Use animations that reveal what's happening

Strategy 3: Both

• Choose sensible defaults that match common expectations
• AND provide clear feedback about what's happening

When you can't match expectations, at least don't surprise users silently.

Strategy 1 example:

• If 80% of users expect "edit Living Room only affects Living Room", do that
• The 20% who expected cascade can learn

Strategy 2 example:

• When user edits Living Room, show: "✓ Living Room (editing) | Downstairs (unchanged)"
• Now even users with different mental models understand what's happening

Strategy 3 is best:

• Defaults match common expectations
• But interface always shows what's actually happening
• No invisible side effects

Connection to L12:

• Domain modeling helps us understand the system's model
• Mental models are the users' model
• Usability is aligning these two

Transition: When mental models are wrong, it's not just annoying — it can be dangerous...

Usability Failures Create Real Safety Risks

Safety isn't just physical:

Category	SceneItAll Example
Physical	Stairway lights off while someone's on stairs
Security	Outdoor lights "always off" creates vulnerability
Privacy	Guest can see all family schedules
Financial	Accidental bulk purchase of smart bulbs
Operational	Disabling smoke detector integration

Many "usability" issues are actually safety requirements:

• "Confirm before locking all doors" — enhancement or safety?
• "Show who is home before Away mode" — convenience or preventing lockout?
• "Re-authenticate to share access" — friction or security?

⚠ Ask: "What could go wrong if a user misunderstands?"

Forward reference: We'll return to safety-critical systems in L35 (Safety and Reliability).

The escalation:

• Traditional software: Usability failure → user frustration
• Software with real-world effects: Usability failure → actual consequences

Safety is broader than physical:

• Security: Accidentally exposing access, disabling protections
• Privacy: Unintended data sharing, visibility to wrong users
• Financial: Accidental purchases, subscription changes, billing errors

Design responsibilities:

• Safety-critical actions need confirmation
• Dangerous operations should be hard to do accidentally
• Undo should be available for reversible operations

The insight:

• Requirements analysis (L9) should have caught these
• But safety requirements often hide until we think about usability
• "What could go wrong if a user misunderstands?" reveals safety needs

Transition: These failures happen because of human error — but what kind?

Human Error Has a Taxonomy: Reason's Classification

Apply taxonomy to examples from previous slide:

Stairway lights off (Physical safety):

• Slip: Meant to tap "Bedroom" but hit "Stairway" (adjacent buttons)
• Lapse: Forgot stairway lights were part of the "Upstairs" group
• Mistake: Thought "Away mode" only affects first floor
• Violation: Turned off manually to save energy, ignoring safety

The fix depends on the error type!

• Slips: Better button spacing, confirmation for "All Off"
• Lapses: Show affected areas before confirming, state indicators
• Mistakes: Clearer mental models, preview consequences
• Violations: Understand why — maybe add "Energy Saver" mode that excludes safety lights

Guest privacy issue:

• Probably a Mistake — guest thought "view schedule" meant their own
• Fix: Clearer scope labels, progressive disclosure

Key insight: Same outcome, different causes → different solutions

Transition: Now let's talk about how we evaluate usability systematically...

The Usability Evaluation Dilemma: Best Evidence Comes Late

The fundamental trade-off:

• Early evaluation: Cheap to change, but feedback is lower quality
• Late evaluation: High-quality feedback, but expensive to change

Why it's a dilemma:

• The best way to know if users can use your software is to watch them use it
• But by the time you have working software, changes are expensive
• Paper prototypes are cheap to change, but users react differently to real apps

Sweet spots:

• Clickable prototypes: Real enough to test, cheap enough to change
• Lab studies with mockups: Controlled observation, moderate cost
• Heuristic evaluation: Expert review, no users needed

Transition: Let's look at the three main approaches...

Three Approaches to Usability Evaluation

User Studies

Watch real users accomplish tasks

✓ Gold standard — direct evidence

✗ Expensive, time-consuming

Surveys & Feedback

App reviews, in-app feedback

✓ Large samples, real context

✗ Self-reported, no observation

Heuristic Evaluation

Experts check against principles

✓ Fast, cheap, works on prototypes

✗ May miss domain-specific issues

Today's focus: Heuristic Evaluation — experts systematically check interface against established principles. Nielsen found 3-5 evaluators catch ~75% of usability problems.

Nielsen's 10 Usability Heuristics: a 30-year-old framework that remains remarkably effective.

Common approach:

• Heuristic evaluation early and often (cheap)
• User testing at key milestones (validate assumptions)
• Ongoing feedback collection (track real-world issues)

Why heuristics?

• You can start evaluating immediately
• Don't need working software
• Paper prototype → apply heuristics → find problems → fix → iterate

Connection to L9: Similar trade-offs to requirements elicitation methods (interviews vs. surveys vs. observation).

Research backing:

• Nielsen found 3-5 evaluators catch ~75% of usability problems
• Each evaluator finds different subset
• Multiple evaluators provide coverage

Transition: Let's dive into Nielsen's 10 heuristics...

Nielsen's Heuristics: A 30-Year-Old Checklist That Still Works

H1: Visibility of system status

H2: Match between system and real world

H3: User control and freedom

H4: Consistency and standards

H5: Error prevention

H6: Recognition rather than recall

H7: Flexibility and efficiency of use

H8: Aesthetic and minimalist design

H9: Help users recognize, diagnose, and recover from errors

H10: Help and documentation

Developed in the 1990s by Jakob Nielsen, these heuristics capture recurring patterns in usability problems. Their relevance to modern apps (including mobile, IoT, voice interfaces) is a testament to the stability of human cognitive factors.

Pronunciation: Jakob Nielsen = "YAH-kob NEEL-sen" (Danish)

Why these still work:

• Based on how humans think, not specific technologies
• Humans haven't changed since the 1990s
• The same cognitive limitations apply to modern interfaces

How to use them:

• Systematic checklist for evaluation
• Go through each heuristic, ask: "Does our interface violate this?"
• Document specific violations, not just "yes/no"

Overlap:

• The heuristics aren't perfectly independent
• A problem might violate multiple heuristics
• That's okay — use them as a framework, not a taxonomy

Transition: Let's examine each heuristic with SceneItAll examples...

H1: Keep Users Informed About What Is Happening

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Why this matters:

• Users can't see inside the system
• Without feedback, they assume the worst (broken, frozen, lost data)
• Good feedback builds confidence and trust

SceneItAll specifics:

• IoT devices have real latency (network, device processing)
• Users need to know: Is it working? Which devices responded? Any failures?
• Progress indicators are essential for multi-device operations

Common violations:

• No loading indicators during network operations
• No confirmation after save/submit
• No progress for long-running operations

Transition: Good feedback uses user language, not developer language...

H2: Speak the Users' Language, Not Developer Language

The principle:

• Use words, phrases, and concepts familiar to users
• Follow real-world conventions
• Information should appear in natural, logical order

Why developers mess this up:

• We think in terms of our implementation
• DeviceStateManager makes perfect sense to us
• But users think about "lights" and "rooms"

Domain modeling connection (L12):

• Good domain models use ubiquitous language
• If your model says "LightEntity", your UI probably does too
• Fix the model vocabulary, fix the UI vocabulary

SceneItAll example:

• "brightness=127" is implementation (0-255 range)
• "50%" is user-understandable
• Same information, different framing

Transition: Users also need clear escape routes...

H3: Provide Clear Emergency Exits

Users often choose system functions by mistake and need a clearly marked "emergency exit" to leave the unwanted state.

SceneItAll applications:

• "All Lights On" panic button when a scene goes wrong and everything's dark
• Undo for accidental scene deletions — don't permanently destroy user work
• Cancel during long operations — stop mid-execution if something's wrong
• Easy mode switching — stuck in advanced view? Clear path back to simple mode

Connection to L12: Did our domain model capture "deleted" scenes as recoverable or truly destroyed? This is a design decision with usability implications.

Why emergency exits matter:

• Users explore by trying things
• If mistakes are costly, users become afraid to explore
• Confident users try more features → better productivity

Two types of exits:

• Undo: Reverse what just happened
• Cancel: Stop something in progress

Implementation questions:

• How do we implement undo? (State history, soft deletes)
• How long should undo be available? (Session? Forever?)
• What can't be undone? (External effects — already-fired device commands)

SceneItAll challenge:

• Can't "undo" a light that already turned on
• But can restore deleted scenes, undo schedule changes, etc.

Transition: Consistency makes emergency exits (and everything else) more discoverable...

H4: Consistency Builds Trust and Reduces Cognitive Load

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

SceneItAll consistency requirements:

• Tapping a device should always show its controls, everywhere in the app
• Same gestures for same actions — swipe to dismiss, long-press for options
• Consistent terminology — don't call it "Scene" in one place and "Routine" in another
• Platform conventions matter — iOS users expect different patterns than Android users

Consistency is internal (within your app) and external (with platform norms).

Why consistency matters:

• Reduces what users need to learn
• Builds predictable mental models
• Makes new features easier to discover (patterns transfer)

Internal consistency:

• Same action → same result, everywhere
• Same terminology throughout
• Same visual patterns (icons, colors, layout)

External consistency:

• Follow platform conventions (iOS vs Android)
• Match common patterns (hamburger menu, swipe to delete)
• Users bring expectations from other apps

Trade-off:

• Sometimes consistency conflicts with optimal design for one feature
• Usually, consistency wins (predictability > local optimization)

Transition: Even better than consistent recovery is preventing errors entirely...

H5: Design to Prevent Errors, Not Just Handle Them

Prevention vs. recovery:

• H3 (emergency exits) is about recovering from errors
• H5 is about preventing errors from happening at all
• Prevention is always better when possible

Types of prevention:

• Constraints: Don't allow invalid states (grayed out options)
• Warnings: Alert before problematic actions
• Confirmations: "Are you sure?" for destructive actions
• Smart defaults: Pre-fill sensible values

SceneItAll examples:

• Can't save scene with no devices (constraint)
• Warning when schedule order seems wrong
• Confirm before deleting scenes with active schedules
• Default brightness to 100% (not 0%)

Trade-off:

• Too many warnings → users ignore them
• Reserve warnings for meaningful problems

Transition: Another way to prevent errors is reducing memory burden...

H6: Recognition Over Recall Reduces Memory Burden

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

SceneItAll applications:

• Show current device states in scene editor, not just target states
  • "Currently: 75%" when setting brightness — user knows starting point
• Display which scenes affect which devices
  • Don't make users remember that "Movie Night" controls living room shades
• Show recent choices
  • Last-used scenes, recent devices, common operations

Recognition is easier than recall. Seeing "Living Room" is easier than remembering it.

The cognitive principle:

• Recognition: "Is this the one?" (see options, pick one)
• Recall: "What was that thing?" (generate from memory)
• Recognition is much easier and less error-prone

Design implications:

• Show options rather than requiring users to know them
• Display current state alongside controls
• Provide visual cues that remind users what things do

SceneItAll example:

• Bad: Empty brightness slider — what's it set to now?
• Good: Slider shows "Currently: 75%" — user has context

Connection to retainability:

• Recognition-based interfaces are easier to return to after time away
• Dorothy doesn't have to remember — she recognizes

Transition: But power users need more than recognition...

H7: Flexibility Serves Both Novices and Experts

Accelerators — unseen by the novice user — may speed up the interaction for the expert user, allowing the system to cater to both inexperienced and experienced users.

SceneItAll flexibility spectrum:

User Level	Interaction Style
Novice	Tap room → tap device → adjust slider
Intermediate	Use scene buttons for common operations
Expert	Voice command: "set office lights to 30%"
Power user	CLI: sceneitall set office lights 30%

Connection to earlier: This is the CLI vs. GUI trade-off — the answer is often "both."

Multiple pathways to same goal:

• All roads lead to "office lights at 30%"
• Different roads for different users
• Novice path is discoverable; expert path is efficient

Accelerators include:

• Keyboard shortcuts
• Voice commands
• Gestures
• Automation rules
• CLI access

Design principle:

• Don't force experts through novice path
• Don't overwhelm novices with expert features
• Progressive disclosure bridges the gap

Marcus vs. Dorothy again:

• Dorothy: Simple path, always available
• Marcus: Fast path, once he learns it

Transition: But more features means more potential clutter...

H8: Every Extra Element Competes for Attention

Interfaces should not contain information that is irrelevant or rarely needed. Every extra unit of information competes with the relevant information and diminishes their relative visibility.

SceneItAll prioritization:

Emphasize	De-emphasize
On/Off toggle	Firmware version
Brightness slider	Network address
Color picker	Last-updated timestamp
Room name	Device ID

Minimalist ≠ minimal features. It means every visible element earns its space by serving user goals.

The attention economy:

• Users have limited attention
• Everything visible competes for that attention
• Important things get lost in visual noise

Information hierarchy:

• What do users need most often? (Front and center)
• What do they occasionally need? (One tap away)
• What do they rarely need? (Settings/advanced)

SceneItAll example:

• Device screen: 90% of users just want on/off and brightness
• Firmware version matters once a year (during updates)
• Don't give them equal visual weight

Common violation:

• Developer dashboards showing everything
• "Power users might want it" → clutter for everyone

Transition: When errors do happen, messages matter...

H9: Error Messages Should Explain Problems and Suggest Solutions

Bad Error Message

DeviceConnectionException: 
timeout at IoTBridge.sendCommand()
line 247

• Technical jargon
• No explanation of cause
• No path forward
• Makes user feel stupid

Good Error Message

Couldn't reach Kitchen Light

The light isn't responding. Try:
• Check if it's plugged in
• Move closer to reduce distance
• Wait a moment and try again

[Try Again]  [Skip This Device]

• Plain language
• Likely cause explained
• Actionable suggestions
• Clear next steps

Error messages are UI:

• They're not debugging output — they're communication with users
• Users encountering errors are already frustrated
• Bad messages add insult to injury

Good error message formula:

1. What happened (in user terms)
2. Why it might have happened
3. What user can do about it
4. Clear action buttons

SceneItAll context:

• IoT devices fail often (network, power, range issues)
• Users need to understand it's often not their fault
• Give them troubleshooting steps, not stack traces

Transition: Sometimes users need more than error recovery...

H10: Help Should Be Searchable, Task-Focused, and Concise

Even though it is better if the system can be used without documentation, it may be necessary to provide help. Such information should be easy to search, focused on the user's task, list concrete steps, and not be too large.

SceneItAll help patterns:

• Contextual help: "How do I create a scene?" appears on scenes screen
• Task-focused: Steps to accomplish specific goals, not feature descriptions
• Searchable: "How do I..." queries return relevant results
• Not a PDF manual: No 50-page document about IoT protocols

The best help is available where and when users need it.

Help as last resort:

• If users need help constantly, the interface has failed
• But complex systems inevitably need some documentation

Good help characteristics:

• Contextual: Appears where users encounter confusion
• Task-oriented: "How to do X" not "What is X"
• Concise: Answer the question, don't explain everything
• Searchable: Users can find what they need

SceneItAll example:

• On "Add Device" screen: "What devices work with SceneItAll?"
• On "Scenes" screen: "How do I create my first scene?"
• Not: Link to generic smart home documentation

Modern patterns:

• In-app tooltips
• Contextual help buttons
• Smart search that understands questions

Transition: Let's wrap up with key takeaways...

Key Takeaways: Building Software People Actually Want to Use

1. Five aspects of usability (learnability, effectiveness, productivity, retainability, satisfiability) — and they trade off against each other

2. Personas make trade-off decisions concrete and explicit — "Would Marcus find this useful? Would Dorothy be confused?"

3. Different stakeholders have different priorities (L9 connection) — you can't optimize for everyone

4. Poor usability has safety implications — physical, security, privacy, financial, and operational risks

5. Nielsen's heuristics provide a systematic evaluation framework — a 30-year-old checklist that still works

6. Mental models bridge domain understanding to interface design (L12 connection) — when system matches expectations, it "just works"

The meta-message:

• Technical correctness is necessary but not sufficient
• Usability determines whether software succeeds or fails
• It's not just "nice to have" — it's core to product success

For your projects:

• Think about who your users are (personas)
• Consider their varying needs (five aspects)
• Evaluate against heuristics (systematic review)
• Don't wait until the end to think about usability

Transition: What's coming next...

Looking Ahead

Next up: Exam Review → Exam

• Today's usability content is not on the exam
• Focus your exam prep on material through last week

After the exam: User-Centered Design (UCD) Process

• How to integrate usability throughout development
• Prototyping techniques (paper, wireframe, interactive)
• Iterative testing and refinement

Later this semester: Safety and Reliability (L35)

• When usability failures cause real harm
• The intersection of usability and safety requirements

Today we learned to evaluate usability. After the exam, we'll learn to design for it from the start.

Exam logistics:

• Next class: Exam review session
• Usability (today's content) is NOT on the exam
• Exam covers material through last week

Preview of UCD (after exam):

• Today: How to recognize usability problems
• UCD: How to prevent them through process
• Prototyping, user feedback loops, iterative refinement

Connection to L35:

• Today: Poor usability → frustrated users
• L35: Poor usability → safety incidents
• Same principles, higher stakes

Homework connection:

• Think about usability in your SceneItAll work
• Which personas are you designing for?
• Apply heuristics to your own interfaces

That's it for today. Questions?