Bad design kills. Good design disappears.
Before any technique, any heuristic, any method, you should know why human–computer interactionThe discipline concerned with the design, evaluation, and implementation of interactive computing systems for human use, and the study of major phenomena surrounding them. (ACM SIGCHI definition)التفاعل بين الإنسان والحاسوب exists as a field. The honest answer: because when designers ignore how humans actually think, perceive, and act, real people get hurt. Sometimes by frustration. Sometimes by far worse.
The Therac-25: when a software interface killed people.
Between June 1985 and January 1987, a computer-controlled radiation-therapy machine called the Therac-25 gave at least six patients massive radiation overdoses - sometimes more than a hundred times the prescribed amount. Several died. Several more were left with permanent injuries.
The root cause was not a single bug. It was a constellation of interface failures. Operators could edit the radiation mode using a cursor-up shortcut faster than the machine could re-validate the inputs - a classic race condition. When something went wrong, the screen showed only “Malfunction 54”: a code with no plain-language explanation, no clear consequence. Operators, trusting the software, pressed proceed and delivered the lethal dose.
Earlier Therac models had hardware interlocks that physically prevented the unsafe state. The Therac-25 removed them, on the assumption that software could do the job. The same software bug had existed in the Therac-20 for years, harmlessly, because hardware caught it. When hardware was gone, the bug became fatal.
The Norman door: why design failures are everywhere.
You have used one this week. A glass door with a vertical handle on both sides. You pulled. It said push. You felt stupid. You were not stupid. The door was badly designed.
Don Norman called these Norman doors: any door whose visible features (the handle) suggest the wrong action (pull) instead of the correct one (push). The handle is an affordanceA property of an object that suggests how it can be used. A handle affords pulling. A flat plate affords pushing.الإيحاء for pulling. Putting a handle on a push door is a design lie.
Norman’s observation was simple but radical: when people fail to use everyday objects correctly, it is almost never the user’s fault. It is the designer’s. Every Norman door blames a person for a designer’s mistake.
So what is HCI, exactly?
HCI is the study, design, and evaluation of interactive systems for human use. It draws on computer science (what we can build), cognitive psychology (how people think), design (how things should look and feel), and ergonomics (how bodies and minds tire). The field formed in the 1980s when computers escaped from specialists’ labs and met everyone else.
Its operational target is usabilityThe extent to which a system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. (ISO 9241-11)قابلية الاستخدام: not whether a system can be used, but whether it can be used well, by the people it’s for, in the situations they’re actually in. The newer concept of user experienceA person’s perceptions and responses resulting from the use or anticipated use of a product, system, or service. Includes emotion, belief, preference, perception, comfort, and behaviour. (ISO 9241-210)تجربة المستخدم (UX) extends this to include emotional, aesthetic, and social qualities that “usability” alone cannot capture.
The six measurable goals of usability
ISO 9241-11 (2018) breaks usability into six concrete attributes. You will use these in Phase 1 to write requirements and again in Phase 3 to measure whether your design met them.
Effectiveness
Can users complete the task at all? Did they get to the right outcome, accurately and completely?
Efficiency
How much effort, time, and resources does the task take? Speed matters once correctness is established.
Satisfaction
How does using the system feel? Frustration is itself a usability cost.
Learnability
How quickly can a new user become productive? Cliff or curve?
Memorability
If a user returns after a week, do they remember how it works, or start from zero?
Errors / safety
How often do users make mistakes, how serious are they, and how easily can they recover?
The elevator close-door button is often a placebo.
In many lifts in the United States and Europe, the close-door button is wired to do nothing. Disability legislation requires the doors to remain open long enough for a wheelchair user to enter, and overriding that with a button could be unsafe. The button stays on the panel because users expect a sense of control. It is a deliberate violation of visibility of system status - and we accept it.
Cognitive aspects: how people think, and what that means for design.
To design well, you need a working model of the mind on the other side of the screen. Cognitive psychology gives us six concepts that show up over and over in interface design: attention, perception, memory, learning, mental models, and cognitive load. Get these wrong and your interface fights the user’s brain.
Attention
Attention is selective and finite. People can’t process everything on a screen at once; they sample. The visual hierarchy of an interface decides what gets sampled and what gets missed.
Designers exploit attention with size, colour, motion, and isolation. They protect attention by removing competition: notifications grouped, ads boxed off, primary actions emphasised.
Perception
How we group and interpret what we see, governed by Gestalt principles: proximity, similarity, closure, continuity, common region. Things that look related are treated as related, even before reading.
These are not optional. The eye applies them automatically. Designers either work with them or fight them.
Memory
Working memoryThe system that holds and manipulates information for short periods. Capacity is famously about 7 ± 2 items (Miller, 1956), now thought to be closer to 4 ± 1 chunks.الذاكرة العاملة holds about 4 chunks at a time, briefly. Long-term memory is huge but unreliable: we recognise far better than we recall.
Good interfaces make memory the system’s job, not the user’s. Don’t make people remember the order number from screen 3 to type on screen 5; show it.
Learning
People form rules from patterns. The same control should always do the same thing. Break the rule and the user must re-learn. Most apps you use today taught you their language in 30 seconds.
Two phases: initial learning (first use) and relearning (after a break). Both matter; designers often optimise the first and forget the second.
Mental models
A mental modelAn internal representation of how a system works that a user constructs to predict its behaviour. Often inaccurate, but always influential.النموذج الذهني is the user’s working theory of how a system behaves. Designers have one model; users build their own from what they see. When they don’t match, the user is “confused”.
The fix isn’t a tutorial. It’s a clearer interface that shows its model.
Cognitive load
The total mental effort a task demands. Heavy load means slower, more error-prone behaviour. Every label to read, decision to make, and place to remember adds load. Good design strips it down.
Three flavours: intrinsic (the task itself), extraneous (caused by bad design), germane (effort spent learning). The first you can’t reduce. The second you must. The third you should support.
Recognition is cheaper than recall
A foundational result from cognitive psychology, with massive implications for interface design. Recognition (seeing something and knowing what it is) is psychologically much faster and more accurate than recall (retrieving something from memory unprompted). This is why Nielsen’s sixth heuristic (“recognition rather than recall”) exists, and why dropdowns, search-with-suggestions, and recently-used lists are so common.
Examples everywhere: Google search shows recent searches the moment you tap the box. Instagram shows recently-tagged friends as suggested mentions. iPhone shows recently-used emojis at the front of the picker. Each one converts a recall task (“what did I search for yesterday?”) into a recognition task (“is one of these it? Yes, that one.”).
Why phone numbers are 7 digits - Miller’s 1956 paper.
In 1956, psychologist George Miller published The Magical Number Seven, Plus or Minus Two. He showed people’s short-term memory holds about seven items. Bell Labs had already been using seven-digit phone numbers for decades. The two facts converged into a famous design principle: chunk by sevens.
Modern research suggests the real number is closer to 4 ± 1, which is why credit cards now break their 16 digits into four groups of four. Every chunking decision in an interface is paying respect to working-memory limits.
Norman’s three models, and the two gulfs between them.
Before introducing his six principles, Don Norman gives us a deeper diagnostic framework: three models that exist whenever a person uses a system, and the two gaps between them that cause every usability problem you will ever encounter. If you understand this section, you can diagnose interface failures with surgical precision.
The three models
Whenever a system exists in the world, there are three different mental pictures of how it works:
Designer’s model
How the designer intends the system to work. Built from requirements, technical constraints, business goals, and personal taste.
The designer is rarely a typical user. Their model is informed by knowledge users don’t have.
System image
What the system actually shows: the screens, the labels, the buttons, the documentation. The only channel through which users learn how it works.
Users see the system image. They do not see the designer’s model.
User’s model
What the user believes about how the system works, built entirely from the system image plus their previous experience.
Often wrong, always influential. Users act on this model, not on reality.
The job of design is to make sure the system image communicates the designer’s model clearly enough that the user’s model matches reality. When the user’s model and the designer’s model diverge, the system fails - even if the code is perfect. Most usability problems are not bugs. They are failures of the system image to convey the designer’s intentions.
The seven stages of action
Norman models any goal-directed action as seven stages: one of forming intention, three of execution (acting), and three of evaluation (sensing the result). This is what every user does, every time they touch your interface.
Form a goal
“I want to send Layla 200 shekels.”
Plan the action
“I’ll use the bank app, find her contact, type the amount.”
Specify the action sequence
“Open app → Send → Layla → 200 → confirm.”
Perform the action
Tap, tap, tap, tap, confirm.
Perceive the state
Did anything happen on screen?
Interpret the perception
Was that confirmation, error, or unclear?
Compare to goal
Is the money sent? Goal met or not?
The two gulfs
Between the user and the system there are two gaps where things go wrong. Norman called them the gulf of execution and the gulf of evaluation.
Diagnosing failures with the gulfs
Almost every usability problem is a failure on one side or the other. This is the most useful diagnostic tool Norman gives us.
- User can’t figure out how to do something: failure of the gulf of execution. Affordances missing, controls hidden, language confusing. Fix with visibility, mapping, constraints, and consistency.
- User did something but doesn’t know what happened: failure of the gulf of evaluation. Feedback missing, status invisible, error messages unhelpful. Fix with visibility of system status (Nielsen H1) and error recovery (H9).
- Therac-25: the gulf of evaluation was catastrophic. Operators perceived “Malfunction 54” but could not interpret it. They believed the system was fine. It was not.
Source: Norman, D. A. (2013). The Design of Everyday Things, Revised and Expanded Edition, chapters 2 and 3.
Norman’s six principles: how to design.
Norman’s six principles are generative - they help you create. They describe the universal rules where human cognition meets the designed world. Norman developed them analysing not just software but everyday objects: doorknobs, kettles, light switches. The principles transfer cleanly to digital interfaces because the underlying psychology is the same.
Visibility
The relevant parts of a system should be visible, communicating what the system can do and how to do it. Hidden options are unused options. If users can’t see it, they can’t use it.
Feedback
After every action, the system should communicate the result clearly and without delay. Feedback can be visual (a flash, colour change), auditory (a click), or haptic (a vibration). If feedback is absent or delayed, users repeat the action - and trust drops.
Constraints
Limit what the user can do at any moment to prevent errors. Constraints can be physical, logical, semantic, or cultural. The fewer wrong actions are possible, the fewer wrong actions are taken.
Mapping
The relationship between controls and effects should be intuitive. Push-up arrow = move up. Volume slider goes right = volume gets louder. Bad mapping is when up means down, or where the layout of buttons doesn’t match the layout of what they control.
Consistency
Similar things should look similar; similar actions should work similarly. Inconsistency forces re-learning every time, and breeds doubt about whether two things really are the same.
Affordance
Visual properties of an object that suggest how to use it. A button looks pressable. A slider looks draggable. A flat plate on a door affords pushing; a vertical handle affords pulling. The famous concept Norman borrowed from psychologist J. J. Gibson.
The Norman door is named after the man who hated them.
Don Norman is a cognitive scientist who worked at Apple in the 1990s (he was Vice President of Advanced Technology) and co-founded the Nielsen Norman Group with Jakob Nielsen. He became famous after publishing The Design of Everyday Things (1988), where he argued that bad design was not user error but designer error.
He never set out to have terrible doors named after him. The internet did that. He has since said he both loves and hates the legacy: he wishes his books were better known than the doors, but if it makes people notice bad design, he’ll take it.
↗ Vox · The Norman Door (4 min)Nielsen’s ten heuristics: how to judge.
Where Norman’s principles help you create, Jakob Nielsen’s ten heuristics help you evaluate. They were derived empirically: Nielsen and Molich analysed 249 usability problems and looked for the rules that, if followed, would have prevented them. The result is the most widely used inspection tool in HCI - and the basis for your individual assignment and Phase 1.
Nielsen’s research with Tom Landauer (1993) showed that three to five expert evaluators catch about 75% of usability problems. This is why heuristic evaluation is the most cost-effective method when users are not yet available. Click each heuristic to expand.
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. Users need to know whether their action worked, whether the system is busy, and where in a process they are.
Sending a message: a clock icon (sending), one tick (sent), two ticks (delivered), two blue ticks (read). Four distinct states for one operation. If the network drops, a red exclamation mark appears with “tap to retry”.
Tap “Send” on a transfer. Spinner for 8 seconds. Returns to home dashboard with no confirmation. Did it go through? Should I try again? Without status feedback, the user invents stress that the system created.
Speak the user’s language. Use words, phrases, and concepts familiar to the user, rather than internal jargon. Follow real-world conventions, making information appear in a natural and logical order.
The compose button is a pencil. The trash is a bin. Folders look like folders. The interface borrows real-world metaphors so deeply that even a first-time user can guess what each icon does.
“Error 429: rate limit exceeded” shown to a user who has no idea what 429 means. Plain language version: “Too many requests. Please wait 30 seconds and try again.”
Users often choose system functions by mistake and need a clearly marked “emergency exit” to leave the unwanted state. Support undo and redo. Don’t trap people. Don’t make them confirm forever.
After sending an email, a black bar appears with “Message sent · Undo · View message”. For 10 seconds, you can take it back. Gmail actually delays sending by that amount; a kindness implemented in code.
A multi-step checkout where pressing the browser back button loses everything. Users learn to never press back, then double-click submit instead, creating duplicate orders. The original sin compounds.
Users should not have to wonder whether different words, situations, or actions mean the same thing. Two flavours: internal consistency (your app uses the same word for the same thing everywhere) and external consistency (your app follows the platform’s conventions: iOS apps look like iOS apps).
The Human Interface Guidelines specify exact patterns for navigation, gestures, modals. Following them, your app feels “native”; ignoring them, it feels foreign. Most apps rejected from the App Store are rejected for inconsistency.
One screen says “Sign Out”, another “Log Out”, a third “Exit Account”. All do the same thing. Users wonder if they’re different.
Even better than good error messages is a careful design that prevents problems from occurring in the first place. Either eliminate error-prone conditions, or check for them and ask the user to confirm before they commit.
Before a transfer, you see the recipient’s name and the exact amount. You hold the phone next to the reader. You authenticate with Face ID. Three independent checks before money moves. The flow is faster than tapping a card, yet harder to do wrong.
A booking form accepts “31 February” without complaint. The error is only caught four screens later, after payment. The user must restart from scratch.
Minimise 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 interface to another. Recognition (seeing something and knowing it) is psychologically much cheaper than recall (retrieving something from memory unprompted).
The search box shows your recent searches as you focus it. You don’t need to remember what you looked up yesterday - Google offers it back. Suggestions appear after one letter. Recognition replaces recall.
On the payment screen, you can’t see your order details. You have to remember what you ordered to verify the price. The data exists; the interface just hides it.
Accelerators - often unseen by the novice - may speed up the interaction for the expert. Allow users to tailor frequent actions. Cater to both inexperienced and experienced users.
Beginners use the visible buttons. Experts use keyboard shortcuts (J, K to navigate; E to archive; / to search). Same software, two interfaces, no mode switch needed.
A returning user re-types their address every order. The system has stored it 47 times. It just never offers to save it.
Interfaces should not contain information that is irrelevant or rarely needed. Every extra unit of information competes with the relevant units and diminishes their relative visibility. Note: this is not about being decorative - it’s about relevance.
The home page is a white page with a logo and a search box. Anything else would be noise. Compare to Yahoo’s home page in 2002 - a wall of text and links. Google won by removing.
A news site where ads, banners, sidebars, video pop-ups, newsletter prompts, and cookie banners together occupy more screen than the article. The user must fight to read.
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. The three jobs of an error message: recognise something went wrong, diagnose what specifically, recover by acting on the suggestion.
“Your card was declined. This is often because of insufficient funds, an expired card, or a fraud-prevention check by your bank. Try a different card, or contact your bank to authorise this purchase.” Diagnosis, three likely causes, two concrete recovery actions.
“Invalid input.” Which field? Which input? What would valid look like? The user is left to guess. Or the famous Therac-25: “Malfunction 54”.
Even though it is best if the system can be used without documentation, it may be necessary to provide help. Such help should be easy to search, focused on the user’s task, list concrete steps, and not be too large.
Inline tooltips on every feature. A help icon next to obscure controls. A searchable docs site. Most importantly: contextual help - typing “/” in a Notion page shows you what you can do right where you are.
The only help link goes to a 60-page generic FAQ. The user’s actual question (“why won’t my card add?”) is not in it. The Help button is theatre.
Source: Nielsen, J. (1994). Enhancing the explanatory power of usability heuristics. ACM CHI ’94, pp. 152–158. The exact wording follows the canonical Nielsen Norman Group articulation, with examples added.
Norman’s principles, Nielsen’s heuristics: different jobs.
Students confuse these constantly. They are not the same kind of thing. One helps you build; the other helps you judge.
Norman’s principlesgenerative
Used to create designs. Describe how human cognition meets the designed world.
- OriginCognitive science & psychology. Don Norman, late 1980s.
- DomainAll designed objects: doorknobs, kettles, websites, cockpits.
- UseGenerative - they help you decide what to build.
- CountSix (visibility, feedback, constraints, mapping, consistency, affordance).
- Example use“The save button has no visible feedback when clicked. Let’s add a state change and a confirmation toast.”
Nielsen’s heuristicsevaluative
Used to judge existing designs. Empirically derived from real usability problems.
- OriginEmpirical analysis of 249 usability problems. Nielsen, 1994.
- DomainSpecifically interactive computing systems.
- UseEvaluative - they help you find what is broken.
- CountTen (above).
- Example use“This page violates Heuristic 1 (visibility of system status). The user clicks submit and nothing visible happens.”
The takeaway: in your Phase 2 design rationale you will cite Norman when justifying choices. In your Phase 1 and Phase 3 evaluations you will cite Nielsen when judging existing or proposed interfaces. Many concepts overlap (consistency appears in both lists) but the verb is what matters: are you making something, or marking something?
Two laws every designer should know by name.
Beyond principles and heuristics, two empirical laws from cognitive psychology have travelled into HCI and stayed there. They are predictive: given some inputs, they tell you what users will do. Use them when justifying design choices about menu length, button size, or navigation depth.
Hick’s Law (Hick-Hyman, 1952)
The time to make a decision grows logarithmically with the number of choices. Roughly: T = b · log2(n + 1), where n is the number of options.
Practical takeaway: doubling your menu items doesn’t double the decision time, but adding any items always slows decisions. When users hesitate, fewer choices help.
Fitts’s Law (1954)
The time to point at a target depends on its size and distance. Big, near targets are fast; small, far targets are slow. Bigger and closer = faster.
On mobile, this means thumb-reachable zones (lower half of screen) are golden. On desktop, edges and corners (especially the corners) are infinitely large because the cursor stops there - that’s why macOS puts the menu bar at the very top.
These two laws plus Miller’s ~4 chunks of working memory give you a quantitative toolkit. Most design intuitions can be back-justified with one of them. When evaluating a design, ask: are we asking too much (Miller)? Too many choices at once (Hick)? Targets too small or far (Fitts)?
Dark patterns: principles abused.
Everything you have learned can be inverted to manipulate users instead of help them. The term dark patterns was coined by Harry Brignull in 2010. Recognising them is part of being a responsible designer - and increasingly part of being legally compliant, as European Union and California regulations now ban several of these explicitly.
Confirmshaming
The opt-out option is worded to make the user feel guilty. “No thanks, I don’t want to save money.”
Spotted inNewsletter signup popups across e-commerce. Users learn to ignore them or, worse, click yes out of social pressure.
Roach motel
Easy to get into, hard to get out. Signing up takes 30 seconds; cancelling takes 30 minutes, three confirmations, and a phone call.
Spotted inStreaming services, gym memberships, telecoms. The asymmetry is the point.
Pre-checked boxes
Marketing consent or paid extras checked by default. The user must uncheck to opt out - betting they won’t notice.
Spotted inBooking flows, account creation, purchase confirmation. Now illegal under GDPR; companies still try.
Hidden costs
Final price reveals fees only at the last step. By that point, the user has invested too much effort to start over.
Spotted inAirline bookings, ticket marketplaces. “Service fee + tax + processing + handling” can add 30%.
Disguised ads
Ads styled to look like content. The line between editorial and commercial blurs deliberately.
Spotted inSearch engine results, social feeds, news sites. Required to be labelled, often barely.
Forced continuity
Free trial that silently converts to paid subscription. No reminder before charging. The card on file makes friction one-sided.
Spotted inSubscription services. EU now requires reminder emails before auto-renewal; the US is catching up.
Privacy zuckering
Trick users into sharing more than they meant to. Default to public, demand multiple confirmations to make private. Named for Facebook’s historical pattern.
Spotted inSocial platform onboarding, “import contacts” prompts.
Bait and switch
The user expects one thing to happen but a different action occurs. The classic Windows 10 “close this dialog” X that started the upgrade install.
Spotted inInstall dialogs, modal close buttons that confirm rather than dismiss.
Why study these in a design course? Because students will be asked, professionally, to implement them. Recognising the pattern means you can name the cost (regulatory risk, brand damage, user trust) and offer an alternative (the equivalent goal achieved through honesty). The interface you build will be measured by whether you used your skills for the user or against them.
The European Union now legally bans several dark patterns by name.
The EU’s Digital Services Act (2022) and the Unfair Commercial Practices Directive specifically prohibit pre-ticked boxes for paid extras, hidden subscription auto-renewals, and confirmshaming on cookie consent. The US Federal Trade Commission has issued similar rules. Designers need to know dark patterns not only ethically but for compliance.
User-centred design: a loop, not a line.
UCD is the process this entire course teaches. It is defined by ISO 9241-210:2019 as four iterative activities. Note the word iterative: you don’t do them once. You do them, find problems, do them again. Your project mirrors this loop directly: Phase 1 understand and specify, Phase 2 design, Phase 3 evaluate and revise.
Understand context of use
Who are the users? What are their goals? Where, when, with what device, under what constraints? Methods: interviews, observation, contextual inquiry.
Specify requirements
Translate context into specific, measurable requirements. Personas, scenarios, usability targets mapped to ISO 9241-11 goals.
Produce design solutions
Sketches, wireframes, prototypes. Low-fidelity first to test ideas cheaply; higher fidelity later when ideas survive.
Evaluate against requirements
Heuristic evaluation, usability testing with real users, think-aloud protocol, SUS scoring. Findings feed back into stage 1 or 2.
The loop continues until the requirements are met. In a commercial product, that means continuously, for the lifetime of the product. In your course project, it means three rounds: research, design, evaluate. You will close the loop visibly in your Phase 3 reflection.
The four guiding principles of UCD
ISO 9241-210 also gives us four principles that underpin the activities themselves:
- Design is based on explicit understanding of users, tasks, and environments. No assumption-based design.
- Users are involved throughout design and development. Not just at the end as “testing”.
- The design is driven and refined by user-centred evaluation. Real evidence, not opinion.
- The process is iterative. Loop, don’t march.
Source: ISO 9241-210:2019, “Ergonomics of human-system interaction - Part 210: Human-centred design for interactive systems”.
How users engage with systems.
Rogers, Sharp and Preece distinguish five fundamental interaction types - the verbs of human-computer interaction. A single product usually combines several. Knowing which type dominates helps you choose the right design idiom.
Instructing
The user tells the system what to do, command-style. Fast for experienced users; high precision; needs the user to know what to ask.
Conversing
Dialogue back and forth. The system asks, the user answers, refines, corrects. Mental model: the system is an interlocutor.
Manipulating
Direct manipulation of objects on screen: drag, drop, resize, swipe. Mental model: things in the interface behave like physical things.
Exploring
Moving through a space - physical or virtual - to find things. Spatial memory carries information.
Responding
The system initiates; the user responds (or doesn’t). Notifications, suggestions, prompts. Power: gets attention. Risk: annoys.
Most modern apps blend types. WhatsApp conversing + responding + manipulating (image edits). Google Maps exploring + conversing (search) + responding (traffic alerts). When designing, name the dominant type for each task - and ask whether the interaction idiom you’ve chosen actually matches it.
The families of interfaces you’ll meet.
Not all interfaces are screens with buttons. The history of HCI is partly a history of new interface paradigms, each opening new use cases and demanding new design rules. Here are the major families, with the example you probably have in your pocket.
Command-line
Type a command, get a response. Powerful, fast for experts, terrible for beginners. Discoverability is zero - you must already know the command.
Example: a developer terminal, git commands.
Graphical (WIMP)
Windows, Icons, Menus, Pointer. The desktop metaphor. Made computers accessible to non-experts.
Example: macOS, Windows, every desktop OS.
Touchscreen mobile
Multi-touch, gestures, contextual. Apps replace files; gestures replace menus. The iPhone redefined the genre.
Example: any app on your phone right now.
Voice user interfaces
Spoken commands, conversational responses. Hands-free, eyes-free. New design challenges: no screen to inspect, error recovery is harder.
Example: Siri, Alexa, Google Assistant.
Augmented & virtual reality
3D space, head-tracked, sometimes hand-tracked. Spatial computing breaks free from the rectangle. Still finding its native use cases.
Example: Apple Vision Pro, Meta Quest.
Wearables & on-body
Watches, fitness bands, smart rings. Tiny screens or no screens. Information glance-able; interaction minimal.
Example: Apple Watch, Garmin, Oura ring.
Chat interfaces
Text-based dialog with a system. Old (IRC bots) and now newly central with LLM chat. Mental model: a person you message.
Example: ChatGPT, Claude, customer-service chatbots.
Ambient & tangible
Computing embedded in the environment or in physical objects. Ideally invisible; you interact through everyday things.
Example: smart-home lighting, Nest thermostat.
Each interface family demands a different toolkit. A voice interface cannot use Heuristic 8 (aesthetic and minimalist design) literally - there is no aesthetic. But the spirit applies: don’t make the user listen to options that aren’t relevant. Heuristics translate; interfaces evolve.
The methods, at a glance.
A compact reference for the main HCI methods you’ll encounter in this course. Pick the one that matches your stage, your question, and your resources. Several of these will appear later in the textbook chapters on data gathering and experimental research.
| Method | When to use | What you get | Time cost |
|---|---|---|---|
| Heuristic evaluation | Early or late, no users available, fast feedback on an existing design or prototype. | List of usability violations with severity ratings. | ~1 day per evaluator |
| Cognitive walkthrough | Early design, focused on learnability for first-time users. Walk through specific tasks asking “will the user know what to do?” | Step-by-step list of confusion points. | ~half-day per task |
| Semi-structured interview | Phase 1 of any project. Understanding goals, frustrations, current behaviours. | Qualitative themes, quotes, persona material. | 30–60 min per participant |
| Contextual inquiry | Understanding real use, in real environments. Field observation plus questioning. | Rich qualitative data on actual behaviour vs reported behaviour. | 2–4 hours per session |
| Survey / questionnaire | Many participants, standardised questions, statistical claims. | Quantitative summaries; hard to get depth. | ~5 min per participant; analysis longer |
| Usability test (think-aloud) | Phase 3 of a project. Watching real users use a prototype, narrating their thoughts. | Specific failure points, time on task, error counts. | 45–60 min per participant |
| System Usability Scale (SUS) | After a usability test. 10 standard questions producing a 0-100 score. | Single comparable usability score. | ~3 min per participant |
| A/B test | Live product, comparing two variants on real users at scale. | Statistical evidence one variant outperforms the other on a metric. | days–weeks of live traffic |
| Diary study | Behaviour over time; long-term feature use; emotional context. | Longitudinal qualitative data; usage patterns. | days–weeks per participant |
A practical guideline: use heuristic evaluation first when no users are available; it’s the cheapest way to find the most problems. Then move to interviews to understand context, then to usability testing once you have a prototype. Surveys are most useful late, to validate findings at scale.
Heuristic evaluation: the method itself.
Knowing the heuristics is half the job. The other half is running the evaluation properly - the steps, who does it, how they aggregate, and how their findings are written up. Your individual assignment is one full evaluation; Phase 1 of the team project is another. Both expect the methodology below.
Why the method works: the Nielsen-Landauer curve
Nielsen and Landauer (1993) found that the proportion of usability problems detected scales with the number of evaluators following an exponential curve. One evaluator catches about 35% of problems. Three to five evaluators catch about 75%. Ten evaluators catch about 95%, but you pay diminishing returns past five - you find more, but mostly issues the first few already found, just confirmed.
The result has a sharp managerial implication: if you can afford five expert evaluations on your prototype, you can probably skip the first round of expensive user testing. That is why heuristic evaluation became the standard early-stage usability method.
The five steps
Each evaluator works alone
Independence is essential. Two evaluators discussing as they go contaminate each other’s findings. They will rediscover the same things, miss the same blind spots, and the “agreement” will be a single observation duplicated.
For your project: each team member evaluates the system alone first, takes their own notes, and only later compares with teammates.
Walk the system task by task
Don’t evaluate “in general”. Pick the realistic tasks a user would do (e.g. “register for a course”, “view my grades”, “reset my password”) and walk through each one screen by screen.
For each screen, hold each of Nielsen’s 10 heuristics in mind. Most won’t apply to most screens; that’s normal.
Document each violation completely
For each issue found, write five things:
- Heuristic violated (one of the 10, by number and name)
- Location (which screen, which element - with a screenshot)
- Description of what is wrong, in concrete terms
- Severity rating (0–4, see next section)
- Proposed fix (specific and feasible, not “make it better”)
Aggregate across evaluators
Once everyone has finished alone, the team merges findings. Issues spotted by multiple evaluators get higher confidence. Disagreement on severity is normal - discuss until consensus, or take the median.
Your Phase 1 deliverable is one consolidated list, not three separate lists.
Identify dominant patterns
The deliverable expects a paragraph on patterns. Look across all your violations: do five of them all relate to feedback (Heuristic 1)? Then your dominant pattern is “the system rarely tells users what is happening”.
Patterns matter more than individual issues, because patterns guide redesign priorities for Phase 2.
A common mistake: treating heuristic evaluation as a brainstorm of complaints. It is not. Each finding must be tied to a specific heuristic with a specific reason. “The colours are bad” is not an evaluation finding. “Heuristic 8 violated - the page has 17 sidebar widgets competing with body content; visual noise drowns the primary task” is.
Source: Nielsen, J., & Landauer, T. K. (1993). A mathematical model of the finding of usability problems. Proceedings of ACM INTERCHI ’93, pp. 206–213. And: Nielsen Norman Group, How to conduct a heuristic evaluation.
Rating severity, properly.
Nielsen’s 0–4 scale is not a feeling. It is a function of three sub-factors: frequency (how often does the user hit it?), impact (how bad is it when they do?), and persistence (does it stay annoying or do users adapt?). A rating of 3 needs at least two of these high; a rating of 4 needs all three.
Disagree it’s a usability issue at all.
Need not be fixed unless extra time available.
Fixing this should be given low priority.
Important to fix; high priority.
Imperative to fix before release.
Source: Nielsen, J. (1995). Severity ratings for usability problems. Nielsen Norman Group.
Practice tool
Pick a real-world violation and rate it. The tool computes the severity from your three sub-factor judgements and explains why.
A user tries to register for a course on Ritaj. After clicking “Register”, nothing visibly happens for 3 seconds. The user clicks again. The course is registered twice and the user must contact admin to fix it.
Conducting user interviews well.
The Phase 1 deliverable expects two to four exploratory interviews per team. The quality of your personas, scenarios, and requirements depends entirely on the quality of those interviews. Bad interview, bad data, bad design. Here is the method.
Before the interview
- Schedule realistically: 20–45 minutes is the sweet spot. Less and you miss depth; more and the participant tires.
- Two team members per session: one leads, one takes notes. The note-taker also catches body language and follow-up cues the lead misses.
- Get signed consent using the form in the spec document, before starting. Explain how data will be anonymised, stored, and deleted.
- Choose location carefully: a quiet room, a comfortable chair, no audience. The participant must feel safe to be honest.
- Pilot once: run the interview with a teammate first. You will discover questions that don’t make sense out loud.
The interview itself: focus on stories, not opinions
The single most important interviewing principle: ask about specific past experiences, not generic preferences. Opinions are what people think they should say. Stories are what they actually did.
Bad question: “Do you find Ritaj easy to use?” (yes, no, fine - useless)
Good question: “Walk me through the last time you registered for a course. Where were you, what device were you using, what happened?”
Specific stories surface real workarounds, real frustrations, and real moments of success. They also surface things the participant hadn’t thought to mention.
Probing techniques
After each substantive answer, follow up. The richest data is in the second and third answer, not the first.
- “Can you say more about that?”
- “What happened next?”
- “Why was that frustrating, specifically?”
- “Have you developed any tricks or workarounds?” (this question alone often unlocks the most valuable findings)
- Silence. Counting to five before speaking again often gets the participant to elaborate.
After the interview
- Write up notes within 24 hours. Memory degrades fast.
- Anonymise immediately. Replace names with codes (P1, P2). No phone numbers, ID numbers, or email addresses in any submitted material.
- Identify 3–5 themes per interview, then look for patterns across interviews. Two participants describing the same frustration is a real finding; one is a hypothesis.
- Quotes are gold. A direct quote in your persona or report carries more weight than a paraphrase.
The most common interview mistake.
Asking “would you use a feature that…” questions. Users will say yes to almost anything hypothetical. The 1986 Sony Walkman study famously found that focus-group participants overwhelmingly chose yellow Walkmans. When offered a free Walkman on the way out, almost all picked black. People are bad at predicting their own behaviour. Ask about what they did, not what they would.
Watching real users use your prototype.
Phase 3 of your project is a usability test. Each team runs at least three participants through realistic tasks on your interactive prototype, narrating their thoughts as they go. Done well, it’s the most informative method we have. Done badly, it’s theatre.
The think-aloud protocol
Developed by Ericsson and Simon (1980s) and adapted for HCI. The participant performs the tasks while continuously verbalising their thoughts: “OK, I’m looking for the register button… I see something that says enrol, that’s probably it… clicking… nothing happened, why?”
The narration reveals the user’s mental model in real time. Where they hesitate, you have a usability problem. Where they say one thing but click another, you have a label-mismatch problem. Where they go silent, they are confused.
How to run a session
- Prepare 3–5 realistic tasks. Aim for 30–45 minutes total. Don’t lead the user (“click on the register button”) - describe a goal (“you want to add an elective for next semester”).
- Do not help. If the user gets stuck, watch what they do. Helping defeats the test. After about 90 seconds of struggle, you can intervene to keep the session moving.
- Record measurable data: task completion (yes/no/with help), time on task, error count, severe-confusion moments.
- Capture quotes. “I have no idea what that button does” is gold for the report.
- Debrief at the end. A few open questions: what worked, what didn’t, what surprised them.
The System Usability Scale (SUS)
Developed by John Brooke in 1986 and now the most-used usability questionnaire in the world. Ten standard 5-point Likert items, alternating positive and negative phrasing. Produces a single number from 0 to 100. The math:
- Odd-numbered items (1, 3, 5, 7, 9): subtract 1 from the participant’s score.
- Even-numbered items (2, 4, 6, 8, 10): subtract the participant’s score from 5.
- Sum the ten adjusted scores and multiply by 2.5.
- Average across all participants for the final SUS score.
Bangor, Kortum and Miller (2008) gave us the interpretation grades:
- Below 50: poor usability
- 50–70: acceptable but needs improvement
- 70–80: good
- 80–90: excellent
- Above 90: best imaginable
Always report sample size with SUS. “SUS = 78” means little. “SUS = 78 (n = 4 participants), interpretation: Good (Bangor et al., 2008)” is what your Phase 3 report needs.
Sources: Brooke, J. (1986). SUS: A “quick and dirty” usability scale. Bangor, A., Kortum, P. T., & Miller, J. T. (2008). An empirical evaluation of the System Usability Scale.
Designing for everyone: accessibility and inclusive design.
About 16% of the world’s population - roughly 1.3 billion people - lives with significant disability (WHO, 2023). Designing only for the “average” user is not a neutral choice; it’s a choice to exclude. The Web Content Accessibility Guidelines (WCAG) 2.2 organise accessibility around four principles: POUR.
Perceivable
Users must be able to perceive the information, regardless of their senses. Includes captions, alt text, sufficient colour contrast.
Operable
Users must be able to operate the interface, regardless of input method. Includes full keyboard navigation, large enough touch targets.
Understandable
Content and operation must be understandable. Plain language, predictable behaviour, helpful error messages.
Robust
Content must work with current and future user-agents, including assistive technologies (screen readers, switch controls).
Specifically for your project
The Phase 2 rubric requires accessibility to be addressed meaningfully - not as an afterthought. For a Birzeit student project, that means at minimum:
Keyboard navigation
Every interactive element reachable by Tab. Visible focus indicator. Logical tab order matching visual order.
Screen reader labels
Buttons need text or aria-label. Form fields need associated labels. Icons-only buttons fail unless labelled.
RTL for Arabic
Text aligns right; UI mirrors (back button on right, navigation reversed). Mix LTR-RTL carefully when bilingual.
Colour contrast (WCAG 2.2)
4.5:1 minimum for body text, 3:1 for large text and UI components. Use WebAIM’s contrast checker to verify.
The wider concept is universal designDesigning systems to be usable by all people to the greatest extent possible, without need for adaptation. Coined by architect Ronald Mace.التصميم الشامل: design once, work for everyone. The famous example is the kerb cut - the slope between pavement and road, originally fought for by wheelchair users, that turned out to be useful to parents with strollers, travellers with suitcases, delivery workers with trolleys, and skateboarders. Designing for an edge case made the centre better.
Captions weren’t made for the deaf - but they ended up being for everyone.
Closed captions were originally developed for deaf and hard-of-hearing viewers in the 1970s. Today, surveys find that over 80% of viewers who use captions are not deaf: they watch with sound off in public, in noisy environments, while learning a language, or because they understand better with text reinforcing speech. Designing for accessibility ended up serving the entire audience.
Worked heuristic evaluations on apps you use every day.
Three short evaluations on familiar apps. The point is to see how the same heuristics surface in different shapes, and how each violation gets documented for a report. Switch between tabs; each evaluation walks one task.
iPhoto bubble overlaid with a static spinner. No percentage, no estimated time, no “cancel” affordance. On a slow network the user has no idea whether to wait or retry.
iiSend button shows no state. Compare with iOS Mail, where the send button briefly shows “Sending…” before transitioning to a success or failure state.
iiiThe header gives no “active upload” indicator. If the user navigates away from this chat while uploading, they lose the only visible progress hint.
Use this sketch to walk through the violations below. Each one corresponds to a specific element of this screen.
No way to schedule a message for later
A user wanting to wish a friend happy birthday at midnight has to either remember to do it then, or send it early. Competitor apps (Telegram, even iMessage on recent iOS) support scheduled messages. WhatsApp does not.
“Delete for everyone” window arbitrary and inconsistent across versions
The window in which a user can unsend a message has changed multiple times (originally 7 minutes, then 1 hour, then around 2 days). Long-time users don’t know the current limit. Once it expires, no recovery.
Forwarded message context is lost
When a friend forwards you a long article from a group, the new message shows only “Forwarded” with no source. The user must remember (or ask) where it came from. Misinformation thrives in this gap.
Photo upload progress unclear in poor connections
On a slow network, a sent photo shows a clock icon but no percentage, no estimated time, and no obvious way to cancel mid-upload. The user is left guessing whether to wait or retry.
Notice that WhatsApp gets many things right - message ticks, voice messages with waveforms, end-to-end encryption indicators. A heuristic evaluation finds violations, but a balanced report acknowledges what works.
iFriend post, suggested account, sponsored ad - visually almost identical. Only thin labels distinguish them. Users are trained to ignore the labels.
iiNo top-level “Saved” entry. The bottom tab bar shows home, search, post, reels, profile. To reach saved posts: profile (5th tab) → menu icon → Saved → All. Four taps deep.
iiiGestures on this screen are inconsistent with the “reels” tab and the “stories” circles at the top - three layouts, three interaction grammars.
Use this sketch to walk through the violations below. The visual confusion in the feed is itself the H8 violation.
Saved posts are buried four taps deep
Profile → menu → Saved → All posts. New users do not know they can save posts, much less how to find them again. The feature is invisible to recognition; you have to recall it exists.
The home feed mixes posts, reels, ads, and suggestions confusingly
What used to be a chronological list of friends is now an algorithmic mosaic. Posts from people you follow are interspersed with reels, sponsored content, and “suggested for you”. The visual treatment doesn’t always distinguish them clearly.
Cannot turn off “Suggested for you” permanently
You can “Snooze for 30 days”. After that it returns. There is no permanent off switch. The user’s choice is overridden every month.
Stories vs Reels vs Posts use different gestures
Stories: tap to advance, swipe up for actions. Reels: swipe up to skip, double-tap to like. Posts: scroll, double-tap to like. Three formats, three interaction grammars. New users frequently mistap.
Instagram is built and owned by Meta and has hundreds of UX researchers. Many of these “violations” are deliberate trade-offs against business goals (engagement, ad revenue). A good evaluator names the violation; understanding the trade-off comes next.
iThe orange info card claims “3 minutes” but the small grey line below admits the ETA is 19 minutes old. The big number is wrong; the truth is in the small print.
iiThe driver pin is shown in a fixed position on the map even though the location data is stale. False precision. The pin should be greyed out or surrounded by an uncertainty halo when data is old.
iiiNo way to refresh, no way to message the driver in-app. The only escape hatch is the “Call” button - which puts the driver on the phone while they’re riding a bike.
Use this sketch to walk through the violations below.
Driver location updates lag behind reality
The map shows the driver near your location, but the food has already been at your door for 4 minutes. The arrival estimate has been stuck at “3 minutes” for the last 20 minutes. Status is shown but not accurate, which is worse than nothing.
Wrong delivery address common because of vague map pins
Birzeit has many buildings without precise street addresses. Users drop a pin on a map; pins drift; drivers end up at the wrong gate. No system check warns the user that the pin location is ambiguous.
Frequent reorders require full re-customisation
If you order “chicken shawarma, no garlic, extra pickles, double bread” every Tuesday, you must select all four customisations every time. The app remembers past orders but not their customisations.
“Restaurant unavailable” with no explanation or alternatives
Selecting a restaurant during peak hours sometimes shows “currently unavailable”. No explanation (closed? overwhelmed? out of stock?) and no suggestion (similar restaurants nearby? open in 20 minutes?).
Local services like Talabat face context-specific challenges (vague addresses, peak-hour load) that global apps often handle better. Local context is also where a Birzeit team can add the most value in a redesign.
Personas, scenarios, requirements: turning interviews into design targets.
The trio that turns raw interview transcripts into specific, testable design targets. A persona is who you’re designing for. A scenario is how they’d use the system. A requirement is the measurable thing your design must achieve. All three must be grounded in evidence, not invention.
Why personas exist
“Design for our students” is not a design target. There is no “the student”. There is a first-year who’s never registered for a course, a third-year power-user who wants shortcuts, a commuter who only uses the system on her phone in 15-minute corridor windows, an international student whose first language isn’t Arabic. Each has different goals, different constraints, different frustrations.
Personas force specificity. When you’re deciding whether to add a feature, the question stops being “would users want this?” (always yes, in a vague way) and becomes “would Lina use this?” (specific, answerable, often no).
Crucially: personas are evidence-based, not invented. The phrase “let’s say she’s called Sara and she’s 20” is the wrong starting point. Personas come from interview data. Each field cites the participants who support it.
A. The persona
Built from interviews P1, P2, P3, P4. Every claim cites a participant code.
Lina Khoury
Second-year CS student who registers on her phone between classes
Demographics
19, second-year BSc CS, off-campus, 45-min commute from Ramallah P1
Tech literacy
Android user, prefers Arabic UI when offered, comfortable but not a power user P1P2
Goals
Register without timing conflicts; finish in under 10 minutes; get advisor confirmation in the same flow P1P2P4
Frustrations
System times out on slow Wi-Fi; timetable hard to read on a phone; vague “course full” messages with no alternatives P1P2P3
Context of use
Mid-morning, between classes, on her phone; sometimes asks her cousin via WhatsApp when stuck P1P2
Devices
Primary: Android phone (small screen). Secondary: friend’s laptop in the library when at home P1
B. A scenario for Lina
A scenario is a story, not a feature list.
Scenario 1 · Adding an elective between classes
It’s 10:45am on a Tuesday and Lina has 15 minutes between her algorithms tutorial and her next class. She opens the redesigned Ritaj on her phone. Her dashboard already shows three suggested electives that fit her timetable. She taps the first, sees its current capacity (“28 of 30”), and adds it. The system warns her that one elective in her plan now overlaps with the new one and offers to swap. She accepts the swap, confirms, and gets a push notification 90 seconds later: “Advisor approved. Schedule updated.” She closes the app and walks to her next class.
C. The measurable requirements that scenario implies
Each requirement is testable; each maps to one of the six ISO 9241-11 usability goals.
| # | Requirement | ISO goal |
|---|---|---|
| R1 | Users can complete the “add elective” flow in under 4 minutes with at most 1 error. | Efficiency |
| R2 | The system displays current course capacity (e.g. “28 of 30”) on every course card; never just “available”. | Effectiveness |
| R3 | When a schedule conflict is detected, the system offers a specific resolution within 1 second. | Effectiveness |
| R4 | Users can return to and complete a registration session up to 24 hours later without re-doing earlier steps. | Memorability |
| R5 | All primary actions are reachable on a 360px-wide screen without horizontal scrolling. | Effectiveness |
| R6 | Error messages name the failed field and suggest a concrete fix (no generic “invalid input”). | Learnability |
| R7 | SUS score ≥ 70 across at least 3 think-aloud participants in Phase 3. | Satisfaction |
The project, phase by phase.
Three phases mirroring the UCD cycle. Phase 1: understand and specify. Phase 2: design and prototype. Phase 3: evaluate and revise. Click each tab for what to deliver.
The team project described below is worth 30% of the course, distributed as Phase 1 (30% of the project), Phase 2 (35%), Phase 3 (35%). The individual heuristic-evaluation assignment - a 2–3 page report on a public website or app of your choice - is a separate piece of work worth 15% of the course on its own. It is not part of the project marks. The final presentation that defends Phase 3 is also separate, worth a further 15%. See the project specification document for current dates.
Single team-authored report, 5–7 pages plus appendix. The goal is to understand who the users are and what they need.
Team and topic
Half page. Members, working arrangements, chosen topic, scope statement, and why the problem matters.
Heuristic evaluation of the existing system
1–2 pages. Minimum 10 violations team-wide using Nielsen’s 10. Each: heuristic, screenshot, description, severity 0–4. Plus a paragraph on dominant patterns.
Exploratory user interviews
1–2 pages plus appendix. Minimum 2 interviews (3–4 better), 20–45 min each. Signed consent form. Notes per interview, key findings.
Personas
1–2 pages. Two personas grounded in interview data with full evidence trail. See part xx above.
Scenarios
Half to one page. Three short narratives showing how personas would realistically use the redesigned system.
Measurable usability requirements
Half page. 5–7 requirements as measurable targets, mapped to the six ISO 9241-11 goals.
Plus 5 points for clear writing and structure within the page limit. Total: 100.
Goal: produce a design that addresses the requirements from Phase 1. Decisions must be justified with reference to course concepts, not intuition alone.
Design rationale document
3–4 pages. Conceptual model; how the design addresses each persona’s goals; references to Norman’s principles in 3+ places; references to 5+ of Nielsen’s heuristics; cognitive-load considerations; accessibility (keyboard, screen reader, RTL Arabic, WCAG 2.2 contrast).
Low-fidelity wireframes
Paper sketches or digital wireframes of at least 8 screens covering all three Phase 1 scenarios. Annotations explaining key decisions.
Interactive prototype
Built in Figma, Adobe XD, Sketch, or equivalent. Functional enough for a user to complete the three scenario tasks. Shareable link plus PDF export. Realistic content, not placeholder text.
Accessibility addressed meaningfully
Not as an afterthought. Documented contrast ratios, RTL behaviour, keyboard order, alternative text strategy.
Plus 15 points for a coherent conceptual model. Total: 100.
Evaluate the prototype against the requirements from Phase 1, demonstrate the ability to close the UCD loop by iterating.
Usability test report
3–4 pages plus appendices. Test protocol; at least 3 participants distinct from Phase 1; think-aloud protocol; signed consent; quantitative measures (task completion, time, errors); SUS averaged across participants; qualitative findings organised by theme.
Heuristic re-evaluation and comparison
Apply Nielsen’s 10 to the new prototype. Direct comparison table (original vs redesign). Severity ratings for remaining issues.
Revision plan
One page. Prioritised list of what you would change next, with rationale. Shows you understand iterative design.
Reflection
One page. What you learned by going through the full UCD loop. What was harder than expected. How real research differed from initial assumptions.
Plus 20 points distributed across rigour of methodology and quality of qualitative analysis. Total: 100.
What loses marks.
These are what cost teams marks in past iterations. Pre-empt them.
Personas without evidence trails
Every claim about a persona must cite a participant code (P1, P2). Empty fields are honest; invented fields are dangerous.
All severities rated 3
Use the three sub-factors. A 3 needs at least two of frequency, impact, persistence to be high. A 4 needs all three.
Heuristic violations that aren’t violations
“The colours are ugly” is not Heuristic 4 (consistency). Pick the most specific heuristic that fits, or don’t list it.
Scenarios that read like feature lists
Scenarios are stories. “At 10:45am, Lina opens Ritaj on her phone, wanting to add an elective…” - not bullets.
Convenience-sample interviews
Real users, not roommates. Mix of contexts (year, department, device, commuting status).
Unmeasurable requirements
Numbers, time, error rates. “Easy to use” is not a requirement. “Complete in under 4 min with ≤1 error” is.
Redesigning the whole system
You have 8 weeks. Three user journeys done well will score higher than ten done badly.
Inventing a persona
“Let’s say she’s called Sara and she’s 20” is the wrong starting point. Personas come from data, not before it.
Citing Norman where you mean Nielsen
Norman = generative (designing). Nielsen = evaluative (judging). Use the right list for the right activity.
Accessibility as one paragraph at the end
If the WCAG section reads like an afterthought, it loses points. Bake it into design decisions throughout.
SUS reported without sample size
“SUS = 78” means nothing without N. Always: “SUS = 78 (n = 4 participants), interpretation: Good (Bangor et al., 2008)”.
Reflection that’s generic
“We learned a lot about UCD” is empty. “We assumed users wanted X but found in interviews that they actually do Y because Z” is a real reflection.
Hypothetical interview questions
“Would you use a feature that…” gets meaningless yeses. Ask about specific past behaviour instead: “Walk me through the last time you…”.
Helping users during testing
If a participant gets stuck during a usability test, watch them struggle. The struggle is the data. Helping defeats the test.
Bilingual glossary.
Core vocabulary in English and Arabic. Use these in your team discussions and written reports.
Usability
The extent to which a system can be used effectively, efficiently, and satisfyingly by specified users in a specified context.
User-centred design
An iterative design approach centred on real users and their tasks, defined by ISO 9241-210.
Heuristic evaluation
An expert inspection method using rules of thumb to find usability problems before users see the system.
Severity rating
A 0–4 score combining frequency, impact, and persistence of a usability problem.
Persona
An evidence-grounded portrait of a user pattern, used to make design decisions concrete.
Scenario
A short narrative showing how a persona uses the system to achieve a goal.
Affordance
A visual property suggesting how an object can be used (a button looks pressable; a door handle looks pullable).
Mapping
The relationship between controls and their effects (steering wheel right = car turns right).
Feedback
The system’s communication of what is happening or what just happened.
Conceptual model
The user’s mental picture of how the system works, ideally close to the designer’s model.
Mental model
The user’s working theory of how a system behaves, built from observation and experience.
Gulf of execution
The gap between what a user wants to do and how the system says to do it.
Gulf of evaluation
The gap between the system’s actual state and the user’s perception of it.
Working memory
The system that holds and manipulates information for short periods. About 4 ± 1 chunks.
Cognitive load
The total mental effort a task demands. Heavy load means slower, more error-prone behaviour.
Think-aloud protocol
A usability-test method where participants verbalise their thoughts as they perform tasks.
Accessibility
Ensuring people with disabilities can perceive, understand, navigate, and interact with a system.
Universal design
Designing systems to be usable by all people, to the greatest extent possible, without need for adaptation.
System Usability Scale (SUS)
A 10-question survey producing a 0–100 score representing overall perceived usability.
User experience (UX)
A user’s perceptions and responses from using or anticipating use of a product, including emotion and aesthetics.
Dark pattern
An interface designed to manipulate users against their interests, often by abusing their trust or attention.
References.
Sources used in this handbook and across the course. Cite these when drawing on their ideas in your reports.
Interaction is social and emotional.
People don’t use software in a vacuum. They use it with other people, in front of other people, and they feel things while doing it. A design that is technically usable but emotionally cold, socially awkward, or culturally tone-deaf will lose to one that isn’t.
Social interaction: designing for groups
From the moment computers got networked, interaction became collaborative. Today most apps are social by default. Three concepts you should know:
Presence and awareness
The cues that tell you who else is here, what they’re doing, when they last appeared. Designers shape these intentionally.
Telepresence and shared space
The feeling of being together when physically apart. Video, voice, shared cursors, real-time editing.
Social norms in design
Conventions of polite behaviour the system encodes. Read receipts. Online indicators. Group-add permissions. These shape what feels rude vs normal.
Emotional interaction: designing for feelings
Emotion is not the icing on the cake. It influences attention, memory, decision-making, and whether someone returns. Don Norman’s book Emotional Design (2004) breaks the design’s emotional impact into three levels.
Visceral
The first immediate reaction. Beauty, novelty, threat. Decided in milliseconds, before any thinking.
Behavioural
The pleasure of using something well. Smooth, fast, predictable, satisfying. The level designers can most directly engineer.
Reflective
The story you tell yourself about the product later. Identity, status, meaning. The level brands compete most fiercely for.
The cultural angle
What feels warm in one culture feels presumptuous in another. Right-to-left layouts, address conventions, name fields that assume a Western format, calendar systems, gender pronouns - these are all design decisions, not defaults. For your project, consider Arabic users specifically:
None of this is exotic. It is the norm for the users your project will interview. Design that doesn’t take it seriously will be marked accordingly.