UNIT 3: DESIGN PRINCIPLES, PROTOTYPING, AND EVALUATION
3.1 Core Design Principles for Interactive Systems
Based on established HCI frameworks (Norman, Nielsen).
| Principle | Core Idea | Key Exam Points |
|---|---|---|
| Affordances | Perceived & actual properties of an object that determine how it can be used. | Example: A button affords pressing. Design must make affordances perceptible. |
| Signifiers | Marks or signals that communicate where an action should take place. | Example: A label, icon, or cursor change. Signifiers are crucial when affordances are not obvious. |
| Mappings | Relationship between controls and their effects in the world. | Good mapping uses spatial layout (e.g., steering wheel turns car). Principle: "The best mapping is natural." |
| Feedback | Immediate communication of the result of an action. | Must be instant, informative, and unobtrusive. |
| Feedforward | Information about what will happen before an action is performed. | Example: Hover effect on a button. Helps users predict outcomes. |
| Constraints | Limiting the possible interactions. | Physical (shape), Logical (rules), Cultural (conventions). |
| Consistency | Similar operations use similar elements; same terminology & gestures. | Internal (within a system) vs. External (with other systems). |
| Error Prevention | Design to minimize errors. | Better than good error messages. Use constraints, confirmations for critical actions. |
| Recognition over Recall | Minimize memory load by making options visible. | Example: Menus vs. command lines. |
| Flexibility & Efficiency | Cater to both novices and experts. | Accelerators (keyboard shortcuts), tailoring (customization). |
| Aesthetic & Minimalist | Avoid irrelevant information. | Aesthetics enhance usability and user satisfaction. |
| Help & Documentation | Necessary but indicates a design failure. | Should be easy to search, task-focused, and concise. |
[!TIP] Common Pitfall: Students often confuse Affordance (what you can do) and Signifier (what you should do). Affordance is a property; signifier is a signal.
3.2 Prototyping in the Design Process
Purpose: Explore ideas, communicate design, test usability before expensive development.
| Fidelity | Definition | Techniques | When to Use |
|---|---|---|---|
| Low-Fidelity | Rough, quick, non-interactive models. | Sketches, Storyboards, Paper Prototyping, Card Sorting (for IA). | Early stages. Explore many ideas quickly. Test concepts and workflow. |
| High-Fidelity | Detailed, interactive, close to final product. | Interactive Wireframes, Digital Mockups (Figma, XD), Functional Prototypes (HTML/CSS/JS). | Later stages. Test visual design, detailed interaction, performance. |
Choosing Fidelity:
-
Goals: Concept testing → Low-fi. Usability testing of details → High-fi.
-
Resources: Time, budget, team skills.
-
Context: Stakeholder presentation may need high-fi visual polish; internal team brainstorming can use low-fi.
3.3 Evaluation of Interactive Systems
Goals: Assess Usability (effectiveness, efficiency, satisfaction), User Experience (UX), Accessibility.
Paradigms:
-
Formative Evaluation: "How can we improve?" Conducted during design. Identifies problems.
-
Summative Evaluation: "How good is it?" Conducted after design/development. Measures success against criteria.
-
Laboratory Studies: Controlled environment. High control, low ecological validity.
-
Field Studies: Natural environment. High ecological validity, low control.
Evaluation Methods:
| Category | Method | Key Characteristics |
|---|---|---|
| Inspection-Based | Heuristic Evaluation | Experts review UI against Nielsen's 10 Heuristics. Fast, cheap, finds many problems. |
| Cognitive Walkthrough | Experts step through tasks asking: Will user know what to do? Will they see the correct action? Will they understand feedback? Focuses on learnability. | |
| Action Analysis | Predict user performance using GOMS or KLM (see below). | |
| User-Based | Observational Studies (Think-Aloud) | Users perform tasks while verbalizing thoughts. Reveals mental models and unexpected issues. |
| Interviews & Questionnaires | SUS (System Usability Scale), UEQ (User Experience Questionnaire). Quantify subjective satisfaction. | |
| Controlled Experiments | Test hypothesis by manipulating independent variable(s) and measuring dependent variable(s). Requires random assignment, control groups. | |
| Field Studies / Ethnography | Observe users in context over time. Understand real-world work practices and environmental factors. | |
| Analytical | GOMS (Goals, Operators, Methods, Selection rules) | Predictive model of task execution time. |
| KLM (Keystroke-Level Model) | Quantitative time prediction. Sum of operator times: T_task = T_M + T_K + T_H + T_P + T_D + T_R |
|
Key Operators: T_M (Mental), T_K (Keystroke), T_H (Home hand to mouse), T_P (Point), T_D (Draw), T_R (System response). |
[!TIP] Exam Focus: Be able to compare & contrast methods. E.g., Heuristic Evaluation (expert, cheap, quick) vs. Usability Testing (user, expensive, realistic). Know Nielsen's 10 Heuristics and KLM operator times (e.g.,
T_K ≈ 0.2s,T_P ≈ 1.1s,T_M ≈ 1.35s).
3.4 Accessibility and Inclusive Design
WCAG 2.1 Principles (POUR):
-
Perceivable: Info & UI components must be presentable in ways users can perceive.
- Text alternatives, time-based media, adaptable presentation.
-
Operable: UI components and navigation must be operable.
- Keyboard accessible, enough time, no seizures, navigable.
-
Understandable: Info & UI operation must be understandable.
- Readable text, predictable, input assistance.
-
Robust: Content must be robust enough to be interpreted reliably by various user agents, including assistive technologies.
- Valid, semantic markup (ARIA).
Designing for Diverse Users:
-
Permanent: Blindness, deafness.
-
Temporary: Broken arm, cataract.
-
Situational: Bright sunlight (low vision), noisy environment (deaf).
Assistive Technologies (AT): Screen readers (JAWS, NVDA), screen magnifiers, voice control, switch devices. Design must be AT-compatible.
Inclusive/Universal Design: Design for the full range of human diversity (ability, language, age, etc.) from the start.
3.5 Design for Different Platforms and Contexts
| Platform | Key Considerations |
|---|---|
| Desktop | Large screen, precise input (mouse/keyboard), multitasking. Complex workflows. |
| Web | Browser inconsistencies, responsive needs, SEO, varying connection speeds. |
| Mobile | Small screen, touch input, fat fingers, limited attention, context (on-the-go), sensors (GPS, camera). |
| Responsive Design | Single codebase that adapts layout to screen size (fluid grids, flexible images, media queries). |
| Adaptive Design | Multiple fixed layouts for specific breakpoints. Server-side detection. |
| Context-Aware Computing | System adapts based on: Location, Social context (who's with user), Task context, Device context. |
Cross-Platform Consistency: Maintain brand identity and core interaction patterns while adapting to platform conventions (e.g., iOS vs. Android navigation).
3.6 Iterative Design Process (User-Centered Design - UCD)
Core Cycle:
Specify Requirements → Design → Prototype → Evaluate → (Repeat)
-
Specify Requirements: Identify user needs and context of use.
-
Design: Create solutions based on principles & requirements.
-
Prototype: Build representations at appropriate fidelity.
-
Evaluate: Test prototype with users or experts.
-
Redesign: Integrate findings. Iterate until usability goals are met.
Managing Trade-offs:
-
Usability vs. Aesthetics: A beautiful but unusable design fails.
-
Functionality vs. Simplicity: More features increase complexity. Prioritize core tasks.
-
User Needs vs. Business Goals: Find the sweet spot.
[!TIP] Exam Answer Structure: For "Explain the iterative design process," describe the UCD cycle, emphasize that evaluation drives redesign, and give a concrete example of a trade-off (e.g., adding a "advanced search" feature increases functionality but may clutter the interface for novices).