Interaction Design

Course Map

Interaction design is the design of interactive products that support how people communicate, work, and act in everyday life. The course takes a user-centred design view: understand users and stakeholders, derive requirements, explore alternative designs, prototype, implement, evaluate, and iterate.

User-Centred Design

UCD provides a structured way to build empathy for people affected by software. It helps with building the right software by discovering useful purpose and priorities, and building the software right by making the product usable for the intended users.

Its return on investment comes from early correction: misunderstandings become increasingly expensive as a product moves from idea to backlog, implementation, staging, and release.

Types Of Design Context

Context	Typical Concern	Design Implication
Consumer apps	Users can leave at any time.	Prioritise walk-up-and-use usability, clear onboarding, and immediate value.
Enterprise/government apps	Users may be required to use the system.	Prioritise productivity, reliability, and support for trained expert use.
Socio-technical services	Users may have little alternative access to a service.	Balance usability, fairness, access, stakeholder effects, and operational constraints.

User Research Methods

User research uses empirical methods to learn about people, their activities, contexts, needs, and constraints. It can collect quantitative data such as counts, timings, ratings, and demographics, and qualitative data such as words, images, observations, stories, and explanations.

Method	Useful For	Risks / Limits
Interviews	Experiences, opinions, knowledge, goals, pain points. Semi-structured interviews often balance richness and focus.	Large data volume, interviewer bias, leading questions, off-target discussion.
Focus groups	Similarities/differences between people, group reactions, comparing stakeholder views.	Dominant participants, group pressure, conflict between stakeholder groups.
Observation	Actual behaviour, context, workarounds, tacit activity. Can be field or lab based.	Intrusion, privacy issues, artificial lab context, large data volume.
Questionnaires	Specific answers from many participants; closed questions support quantitative analysis.	Rigid, impersonal, question order effects, ambiguous wording.
Card sorting	Terminology, categories, relationships, information architecture.	Needs careful item choice; categories may not translate directly into final navigation.
Documentation study	Procedures, rules, legislation, background when stakeholder access is limited.	May be idealised, incomplete, or outdated; insufficient alone.
Similar-product research	Features, competitor differences, reviews, pain points, design opportunities.	Can prompt requirements but may constrain creativity.

Interviews, focus groups, and observation collect primarily qualitative data and give a holistic understanding of users and their context; questionnaires and card sorting can yield more quantitative, specific answers.

Interview Structure

Type	Definition	Trade-off
Unstructured	No prepared questions; interviewee-led.	+ rich data   − too much data, off-target.
Semi-structured	Some questions prepared in advance.	+ rich and targeted   − still a lot of data.
Structured	All questions prepared in advance.	+ straightforward collection   − rigid.

Observation Protocols

Observation can be in the field (ethnography — realistic but intrusive, privacy/reliability concerns) or in the lab (less intrusive but artificial). It can be paired with a verbal protocol:

• Concurrent ("think-aloud"): users say what they are doing and why while performing the task. Good for understanding the nature and context of a task; produces a lot of data.
• Retrospective: users explain what they did and why after finishing (e.g. reviewing recordings/logs). Good for cognitively demanding tasks since the user can focus, but users may forget what they did.

Card Sorting Variants

• Open: no pre-set groups; participants create groups and then describe each one. Best for discovering categories and terminology.
• Closed: a pre-established set of groups; participants place cards into them. Tests an existing structure.
• Hybrid: a combination — some pre-set groups plus freedom to create new ones.

Questionnaire Question Types

• Open: respondent writes a free-form answer.
• Closed: respondent selects from given options — numerical input (age, hours), simple checklist (yes/no/don't know), multi-point rating scale, or ranked order of preferences.

Guidelines: word statements so all respondents interpret them the same way; consider an "open" answer after a list of closed options; don't make assumptions about the respondent; remember question order affects responses; decide whether phrasing is all-positive, all-negative, or mixed; keep questionnaires short.

Mixed Methods

Combining methods and data types helps triangulate findings. Creswell & Plano Clark (2011) distinguish several designs:

Design	How it combines QUANT and QUAL
Triangulation	Collect QUANT and QUAL in parallel; interpret based on both together.
Embedded	One type is dominant with the other embedded as support (e.g. QUANT + small qual).
Explanatory	QUANT first, then qual to explain the numbers (QUANT → qual).
Exploratory	QUAL first, then quant to test/generalise (QUAL → quant).

Choosing A Research Method

The choice of method(s) depends on:

• The amount of time, level of detail, and risk associated with the method.
• The knowledge required by the researcher to run it well.
• The context for design (consumer, enterprise, service).
• The kind of activities users perform: sequential vs overlapping subtasks; simple vs complex information; layman vs skilled practitioner.

Research Guidelines

• Focus on users' and stakeholders' needs, not preferred implementation first.
• Involve all relevant stakeholder groups and more than one representative per group.
• Pilot research methods to discover practical and ethical problems early.
• Use informed consent; consider confidentiality, anonymity, power differences, incentives, and risk.
• Decide how data will be analysed before collecting it.
• Use mixed methods where useful: multiple methods and multiple data types help triangulate findings.

User Research Data Analysis

Data does not automatically create empathy. Analysis and interpretation are what let a team discuss implications, keep users in mind, and make defensible design decisions.

In practice, combine all qualitative techniques: look for critical incidents to focus on, find themes (inductive), and categorise against a scheme (deductive).

Raw Data By Method

Method	Example Qualitative Data	Example Quantitative Data
Interviews / focus groups	Audio/video recordings, interviewer notes, open-question responses.	Demographic and closed-question responses.
Observation	Observer notes, photos, recordings, think-aloud, task descriptions.	Time on task, number of people in an activity, demographics.
Questionnaires	Responses to open and "further comments" fields.	Demographic and closed-question responses.
Card sorting	Categories developed, items in each category, comments.	List of categories and counts of items in each.

Presenting Findings

How to present depends on the audience, the purpose, and the data gathering/analysis done. Use graphical representations as needed. It is good practice to present an evidence chain showing how findings arise from underlying data — this adds richness and protects against over-interpretation.

Tools — quantitative: spreadsheets, SPSS/STATA, RAWGraphs/Tableau/Power BI, card-sort tools (OptimalSort, UXtweak). Qualitative: paper & markers, spreadsheets, NVivo, Atlas.ti.

Keeping Users In Mind

Research findings need representation. Stakeholder maps, personas, scenarios, and journey maps make findings concrete enough to guide design discussions.

Stakeholder Analysis

Stakeholder analysis is used to identify everyone with a stake in the system, track their interests, and prioritise product and business development. A stakeholder is anyone who is affected by, influences, supports, maintains, buys, or receives output from the system — not only the people who type on the keyboard.

Target users vs other stakeholders

First separate the target users — who you are designing for — from everyone else.

• Target users (the "primary stakeholder"): the intended user group(s). There can be more than one — e.g. CamCORS serves students, supervisors, and Directors of Studies.
• Other stakeholders: people who may influence the user's interaction (e.g. a parent managing a child's device use), be affected by it (e.g. friends of a runner using a trail-map app), or support it (e.g. help-desk staff).

Taxonomy 1 — starting from the product/system (Eason, 1987)

Type	Meaning	Example (a hospital booking system)
Primary	Frequent, hands-on users of the system.	Receptionists booking appointments.
Secondary	Produce input for, or receive output from, the system — occasionally or via someone else, but don't directly operate it.	Doctors reading the schedule; patients receiving a confirmation text.
Tertiary	Affected by the system's introduction, or influence its purchase, but are neither primary nor secondary.	Hospital management approving the budget; regulators.
Facilitating	Involved in the system's design, development, operation, support, and maintenance.	The dev team, IT support, trainers.

Taxonomy 2 — starting from the organisation

• Internal: people who work for the organisation — employees, managers, owners.
• External: groups outside it — customers/users, community/society, suppliers, shareholders/investors, government.

Stakeholder Mapping (Influence–Interest Matrix)

Plot each stakeholder on two axes — their influence/power over the project and their interest in it — to decide how much to engage each one.

	Low interest	High interest
High influence	Keep satisfied (e.g. a regulator, a budget holder).	Manage closely — your key players; involve heavily (e.g. primary users, sponsor).
Low influence	Monitor — minimal effort (e.g. the general public).	Keep informed (e.g. affected secondary users).

This lets the team prioritise engagement, manage expectations, and make sure the most important stakeholders' needs are met.

Challenges: finding the right people, balancing conflicting needs and priorities, and engaging each stakeholder at the right time.

Personas

A persona is a fictitious but specific archetype built from user research and field observations. It gives the team a concrete design target: would this work for this user, in this context, with these goals?

• Focal: primary users the design is optimised for. At least one persona must be focal; aim for fewer than three.
• Secondary: also use the product, satisfied where possible.
• Unimportant: low-priority users — infrequent, unauthorised, unskilled, or those who misuse the product.
• Affected: do not directly use the product but are affected by it (e.g. someone who receives reports from a user).
• Exclusionary: explicitly out of scope, preventing non-users creeping back into discussions.

Good personas include demographics only where relevant, plus goals, motivations, proficiency, frustrations, usage context, and quotes or details that connect to evidence. Weak personas are superficial stereotypes.

Creating a persona

1. Review the user research collected about the stakeholder group.
2. Identify the common attributes within the group.
3. Identify the differences between this group and others.
4. Describe a unified persona combining those attributes — it can be a collage of multiple users.

Start with name, photo, demographics, and a personality quote/slogan; then add product-specific attributes: goals/needs/motivations, knowledge/proficiency, frustrations (pain points), and context of usage. Challenges: superficial stereotypes, "what you see is all there is" bias, and cost.

Scenarios And Journey Maps

A scenario is a concise description of a persona using a product to achieve a goal. It helps validate assumptions and transfer abstract design into wireframes, user stories, or test tasks.

• Task-based scenarios: state the user goal and reason, without detailed steps.
• Elaborated scenarios: include richer context and user detail.
• Full-scale task scenarios: include the steps to accomplish the task.

A journey map combines persona, scenario, goals/actions, timeline, thoughts, emotions, pain points, and opportunities. It is useful for discussing how a product fits into real life, but it can become misleading if not grounded in research.

Requirements Development

A requirement is something the product must do or a quality it must have. Requirements analysis communicates what the system will do and how it should behave before implementation decisions dominate.

Requirement Type	Question Answered	Example Shape
Business requirement	Why is the organisation building this?	Business objective, benefit, market or policy goal.
Business rule	What policy/regulation constrains the business?	Not a software requirement itself, but the origin of several requirements (policy, standard, legislation).
User / stakeholder requirement	What must a user or stakeholder be able to achieve?	User goal, task, desired attribute, scenario, user story.
Functional (solution) requirement	What behaviour will the software exhibit?	Inputs, outputs, actions, data manipulation, system response.
Quality requirement	How well must it perform or support action?	Usability, performance, reliability, security, maintainability.
System requirement	What does a multi-system product need overall?	Top-level requirement spanning all software, or software + hardware.
External interface requirement	How does it connect to people, devices, or other systems?	APIs, hardware interfaces, import/export, platform conventions.
Constraint	What choices are restricted?	Technology, platform, deadline, regulation, legacy database.

The functional/non-functional split is useful but imprecise. Avoid treating functional requirements as automatically more important; usability, reliability, and accessibility requirements can be decisive for success.

Exploring The Design Space

The same user requirements can be implemented in many ways. UCD narrows this space by creating and comparing alternatives while keeping users, goals, and context visible.

Method	Purpose	Watch Out For
Brainstorming	Generate many ideas from a brief; later filter and develop them.	Groupthink, dominance, peer pressure, loss of focus.
Moodboarding	Capture the feel, style, tone, and visual direction of a design.	Subjectivity; harder to represent interaction than visual style.
Concept development	Define a central metaphor or idea that drives graphic and interaction choices.	Over-literal metaphors can distract or damage usability.
Product-specific design principles	Frame design decisions with values specific to the user group, product, and brand.	Principles must be few, memorable, differentiating, and actionable.
Storyboarding	Show user flow and task progress as sequential frames.	Should show interaction and context, not only a sequence of screens.

Brainstorming Approaches

Run with a facilitator and "house rules": set a time limit, start from a brief, withhold judgment, encourage wild ideas, aim for quantity, build on others' ideas. Two dimensions structure it:

Concept Development

A central concept or metaphor drives both graphic decisions (layout, colour, fonts, imagery) and interaction decisions (widgets, animation, navigation), giving a coherent design. Two forms:

• Verbal concept: word(s) describing the interface — tends toward the abstract; focused on the message.
• Visual concept: an image or colour scheme — more concrete; focused on how the message is conveyed.

Example: OneNote uses a "notebook" metaphor (coloured tabs as sections, pages grouped into sections). Risk: an over-literal metaphor can distract or harm usability.

Prototyping

A prototype is an incomplete early version of a product. Its purpose is not production quality; its purpose is learning.

Prototypes are classified along two independent axes: by fidelity (how polished — lo-fi vs hi-fi) and by interactivity (non-interactive like storyboards/wireframes, vs interactive — either click-through built in Adobe XD/Balsamiq/PowerPoint transitions, or coded). Lo-fi (hand sketches, post-its) is quick, cheap, and gets feedback on interaction and concepts rather than visual polish; hi-fi has realistic visuals and interaction (some content real, some simulated) and is used for usability, flow, investment, sales and marketing. Other forms: paper prototypes, wireframes (information schematic, layout only), video (tells a story; for costly/impossible demos), and form models (don't work but show physical form, allowing direct handling).

Cognitive Aspects For Design

Interfaces are interpreted through limited memory, perception, and attention. Good design reduces memory load, uses visual grouping deliberately, and guides attention without creating noise.

Memory

The multi-store (Atkinson–Shiffrin) model: sensory memory → (attention) → short-term memory → (rehearsal/transfer) → long-term memory, with retrieval back to STM.

Short-term memory

• Holds (but does not manipulate) a small amount of information, briefly.
• Limited duration: ~15–30 seconds, extendable by rehearsal.
• Limited capacity: ~7 items (Miller's "magical number 7±2"), varying by type (~7 digits, ~6 letters, ~5 words).
• Extended by chunking — grouping items, e.g. 756298622741 vs 756 298 622 741.

Long-term memory

• Explicit (declarative): episodic memory (events, experiences) and semantic memory (facts, concepts).
• Implicit (procedural): motor skills — e.g. tying shoelaces, riding a bike.
• We memorise by repetition, when something is surprising/unusual, and by association between pieces of information (this is why established conventions and familiar patterns are easy to learn).

Activation of content in memory is more likely with practice (how often used), recency (how recently used), and context (what else is in focus).

Recognition vs recollection

Two distinct processes: recollection (remembering the moment an item was encountered) and recognition (seeing something again prompts the memory). Recognition is faster than recollection, independent of it, and less sensitive to divided attention.

Attention

Attention is selectively concentrating on a discrete aspect of information while ignoring the rest. It is multimodal (visual, auditory, verbal, tactile) and incomplete, inaccurate, and limited (the "spotlight" model). Two types by trigger:

• Exogenous (reflexive): triggered by external cues.
• Endogenous (intentional): triggered by internal cues / goals.

External cues are more effective at drawing attention — they get more processing time and accuracy, are harder to ignore even under cognitive load, and draw attention even when unexpected. This makes notifications, motion, contrast, and warnings powerful but risky (cf. cluttered sites where a real problem hides in the noise).

• Use cues for important status changes, errors, and next actions.
• Avoid visual noise: every extra element competes with the task-relevant information.
• Use progressive disclosure to hide advanced or secondary material until needed.

Gestalt Principles

Principle	Design Rule	Example Use
Similarity	Make equal elements look equal.	Same typography for same content type; selected item as intentional anomaly.
Proximity	Group related things spatially.	Keep labels close to fields; separate unrelated controls.
Enclosure	Border or background related elements.	Panels, separators, cards, grouped settings.
Common fate	Elements moving together are perceived as related.	Expanding menus, carousels, grouped transitions.
Figure / ground	Make content stand out from background.	Modal overlays, strong contrast, clear foreground controls.
Closure	Users fill gaps to infer shapes.	Minimal icons can work, but missing detail can also mislead.
Good continuation	Users perceive lines and curves as continuous.	Flow diagrams, aligned navigation, visual paths through a layout.

Interactive Aspects For Design

Visual design suggests interaction through affordances. A button should look pressable; a link should look clickable; a partially cut-off list can suggest scrolling. Affordances are learned through conventions, so platform and domain expectations matter.

Interaction is also constrained by form factor and input modality. Phone, tablet, laptop, watch, speech interface, VR, tangible interface, and robot interface all change what users can perceive and do.

Constraint	Design Consequence
Screen size and ratio	Changes layout density, navigation pattern, number of visible controls, and typography scale.
Orientation	Portrait and landscape may require different hierarchy and task flow.
Input modality	Mouse hover, keyboard shortcuts, touch gestures, multi-touch, and speech all support different interactions.
Expertise	Novices need visible guidance; experts may benefit from shortcuts and customisation.

Designing Content

Information Architecture

Information architecture decides how parts of a system are arranged so users can understand where they are and find what they need.

1. Inventory existing and required content.
2. Establish a taxonomy: flat, hierarchical, faceted, or network/tag based.
3. Chunk content into logical units.
4. Diagram structures and navigation.
5. Test with users and revise.

Taxonomy types

Taxonomy	Relationship	Typical Presentation
Flat	Simple enumeration of things.	Single list.
Hierarchy	is-a between content and categories.	Sitemap, nested navigation.
Faceted	has-a between content and attributes.	Filters / facets.
Network	Content linked to categories by association.	Tags.

Card sorting is a good method for eliciting taxonomies from the users' perspective. When diagramming, focus on the structure rather than a fixed hierarchy (structure makes future change easy), keep processes logical, base it on user research, and update it as the system evolves.

Common page-structure patterns (mobile)

Hierarchy/Catalog · Nested Doll (flow) · Hub & Spoke · Dashboard · Tabbed View · Filtered View. At the page level, wireframes map out how elements are organised; match user expectations for where content lives, and move things only with a clear rationale.

Navigation supports movement through content: lateral movement at the same level, forward movement down a hierarchy or flow, reverse movement back chronologically or hierarchically, and search as a faster alternative for complex structures.

Data Modelling

UCD also applies to backend choices. Ask how and why data or logic will be used, then design structures that support user requirements end-to-end. Keep data structures flexible, balance frontend and backend needs, and avoid technically elegant models that make the user experience worse.

Patterns, UI Toolkits, And Design Systems

Practical design tools provide reusable solutions to common interaction problems and a shared vocabulary for teams.

Tool	Meaning	Use With Care Because
Interaction design pattern	Reusable solution with title, problem, context, solution, and examples.	Patterns solve problems in specific contexts; they are not a checklist.
UI toolkit	Styled collection of components/widgets for building applications.	Component consistency is not enough; the chosen component must fit the task and users.
Design system	Reusable components plus standards, rationale, usage rules, and often theming.	It supports scalable consistency but does not replace user research or design reasoning.

Examples of patterns include navigation tabs for stable top-level sections, breadcrumbs for hierarchy context, and carousels for browsing pictorial items in limited space.

Evaluation Map

Evaluation checks whether the team built the right thing and built it right. It can compare designs, test against requirements, reveal problems, and guide redesign.

Heuristic Evaluation

Heuristic evaluation uses a fixed set of usability principles to find common problems in sketches, prototypes, or production systems. Usually 3-5 evaluators inspect the interface independently, then combine findings and rate severity.

Nielsen Heuristic	Design Meaning
Visibility of system status	Keep users informed with timely feedback; use progress indicators for noticeable waits.
Match between system and real world	Use users' language and concepts, not internal jargon.
User control and freedom	Support undo, back, cancel, and clear exits from unwanted actions.
Consistency and standards	Follow platform and domain conventions.
Error prevention	Prevent mistakes before relying on error messages.
Recognition rather than recall	Make actions, options, and state visible.
Flexibility and efficiency	Support both novice users and expert shortcuts/customisation.
Aesthetic and minimalist design	Remove irrelevant information that competes with the task.
Error recognition and recovery	Plain language errors should indicate the problem and suggest a fix.
Help and documentation	Design should not need explanation, but help should be available when needed.

Process

1. Pre-evaluation training: bring evaluators up to speed on the heuristics and scenarios.
2. Evaluate: each evaluator works through the UI individually, twice — once for overview, once for detail.
3. Collate results.
4. Rate severity: rate individually, then discuss to reach agreement.
5. Feed back into design.

Severity Rating

Severity combines frequency, persistence, and impact of a problem, on a 0–4 scale:

Rating	Meaning
0	Don't agree it's a usability problem.
1	Cosmetic problem.
2	Minor usability problem.
3	Major usability problem — important to fix.
4	Usability catastrophe — imperative to fix.

Analysis

Heuristic evaluation is "discount usability": Nielsen reports a benefit-cost ratio of ~48. A single evaluator finds only ~35% of problems; ~5 evaluators find ~75%, after which adding evaluators costs more but finds few new problems (diminishing returns).

Pros: cheap, quick, easy to learn, finds many problems. Cons: not task-focused, no real users, not rigorous, can be too generic for novel products. You can also define your own heuristic set (e.g. Andy Budd's heuristics for web apps) within the same process.

Cognitive Walkthrough

Cognitive walkthrough is a task-centred expert evaluation for first-time use. It asks whether representative users can work out what to do, find the correct control, understand labels/prompts, and interpret feedback.

1. Define inputs: user classes, representative tasks, correct action sequences, and the interface artefact.
2. Gather analysts and train them in the method and user context.
3. Walk through each action sequence, telling credible success or failure stories.
4. Record user knowledge requirements, assumptions, side issues, and design-change ideas.
5. Revise the interface, using local fixes or global redesign depending on the pattern of failures.

Revision strategies by failure type

• User picks the wrong action → eliminate it, prompt for it, or signal it's available.
• User doesn't know the action exists → make it more obvious.
• User doesn't know which action is correct → relabel controls; check the action sequence makes sense.
• User can't tell things are going OK → add feedback saying what happened.
• Many problems showing a system/user-model mismatch → look for global redesign rather than local fixes.

Cognitive walkthrough is strong for learnability and task-specific severe problems, but it cannot cover every task or cross-task interaction (each task is evaluated separately). It pairs well with broader heuristic evaluation. It can even be applied to APIs (whether a developer can build an accurate mental model from the code alone).

Usability Testing

Usability testing observes representative users using a product or prototype to identify problems, understand satisfaction, and turn feedback into design recommendations. It is used to learn whether the product is usable and which features work, find out how satisfying it is (would they use it — why/why not?), make recommendations for modifying the product, and establish benchmarks for future comparison (have previously-identified issues been resolved?). It is usually cheaper than controlled experiments and yields more data to feed back into design.

Usability Test Process

1. Decide study objectives and what evidence is needed.
2. Prepare clear task instructions from the participant's perspective.
3. Recruit representative participants.
4. Choose a location with minimal distractions and adequate recording/observation.
5. Run each session: introduction, consent, optional background questionnaire, tasks, data recording, debrief.
6. Analyse findings and report design recommendations.

Ethical tests require minimal risk, informed consent, confidentiality, the right to withdraw, and clear explanation of how results will be used.

Variants

Variant	Use	Challenge
Think-aloud	Participant verbalises thoughts during tasks; useful for attention, frustration, and confusion.	Can distract from demanding tasks; participants need practice.
Cafe/guerilla testing	Quick public-place feedback for walk-up-and-use apps, first use, or onboarding.	Noisy locations, recruitment difficulty, less controlled conditions.
Wizard-of-Oz	Human simulates system behaviour; useful for testing systems not yet built, especially ML-like behaviours.	Risk of misleading users about readiness or automation.
Controlled experiment	Quantitatively compare designs on metrics like speed, accuracy, or error rate.	More expensive; only worth it when metrics matter enough.
Dogfooding	Employees use the product when external studies are hard.	Employees are rarely representative users and may not give honest or relevant feedback.

About five users often gives the best time-to-problem-discovery tradeoff. If there are multiple target user groups, test roughly 3-5 users from each group, and prefer iterating test -> fix -> test again.

Compare Methods

Question	Good Method Choice	Why
Who are the users and what matters to them?	Interviews, observation, questionnaires, stakeholder analysis.	Discovers goals, context, needs, constraints, and stakeholder effects.
How should content be grouped?	Card sorting, IA diagrams, user testing.	Finds user terminology and perceived relationships.
Which of several early concepts is promising?	Low-fidelity prototypes, storyboards, usability sessions.	Cheap enough to compare alternatives before commitment.
Will first-time users know what to do?	Cognitive walkthrough, onboarding usability test.	Focuses on learnability, visible controls, labels, and feedback.
Does the interface violate general usability principles?	Heuristic evaluation.	Cheap expert scan across common issue types.
Does the implemented flow work for real users?	Usability testing with representative participants.	Direct behavioural evidence and design recommendations.
Is design A faster or more accurate than design B?	Controlled experiment.	Quantitative comparison against defined metrics.

Practical Checklist

1. Define target users and stakeholders. State who is in and out of scope.
2. Use at least one qualitative and one quantitative source where feasible.
3. Analyse before designing: themes, key incidents, requirements, and evidence chains.
4. Create persona/scenario/journey artefacts that are grounded in data.
5. Separate user requirements from functional requirements and constraints.
6. Explore alternatives before committing to a single interface.
7. Use cognitive principles: recognition over recall, clear grouping, attention management, and reduced noise.
8. Choose navigation and content structure based on user tasks and expectations.
9. Evaluate early with cheap methods, then iterate and test again.
10. In reports, justify each design decision by tracing it to user evidence, a requirement, or an evaluation finding.