UX research and usability

Design (Fashion / Product / Communication / UI-UX) (B.Des) · Communication and digital · free study notes for exams, placements and interviews

In short

UX research is the systematic study of users — their goals, contexts, tasks and difficulties — to decide what to design and whether the design works; usability is the measurable quality of that design in use (effectiveness, efficiency, satisfaction, as defined in ISO 9241-11). Design students are examined on method selection, study planning, sample sizes, heuristic evaluation and usability metrics, and on the ethics and accessibility rules that govern research with Indian users. Indian employers — Flipkart, Zomato, Swiggy, Paytm, PhonePe, Razorpay, Zoho, Freshworks, TCS/Infosys design studios, Titan, Tata Digital, UIDAI/NPCI-linked product teams — run portfolio reviews and whiteboard rounds almost entirely on research reasoning, not visual polish. In practice it decides roadmap priorities for products used by hundreds of millions of low-bandwidth, multilingual, first-time smartphone users. It is assessed through design-research papers, studio juries, UCEED/CEED-style reasoning questions and placement case rounds.

Explained

What usability is, and the standards that define it

Usability (ISO 9241-11): the 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*. All three italics matter in exams — usability is never an absolute property of a product.
Effectiveness = did they finish the task correctly (task success, error rate). Efficiency = resources spent (time on task, clicks, steps). Satisfaction = perceived comfort and attitude (SUS, CSAT, NPS-adjacent measures).
ISO 9241-210 defines human-centred design (HCD): four iterative activities — understand and specify the context of use → specify user requirements → produce design solutions → evaluate against requirements; iterate until requirements are met.
Nielsen's five usability components: learnability, efficiency, memorability, errors, satisfaction. Utility (does it do what is needed) + usability (is it easy) = usefulness.
UX vs usability vs user interface: UX is the whole experience including brand, service and after-sales; usability is a quality attribute of the interaction; UI is the visible/interactive layer. Usability is necessary but not sufficient for good UX.
Accessibility in India: the Rights of Persons with Disabilities Act, 2016 and its Rules make accessible ICT a legal obligation for government and public services; GIGW 3.0 (Guidelines for Indian Government Websites, Apps and Digital Services, MeitY/NIC) is the governing compliance document and aligns with WCAG 2.1 Level AA; IS 17802 (Parts 1 and 2) is the Indian Standard on accessibility of ICT products and services. IS/ISO 9241 parts are adopted by BIS for ergonomics of human–system interaction. Data collected in research is governed by the Digital Personal Data Protection Act, 2023 — consent must be free, specific, informed and unconditional, with notice in English or any Eighth Schedule language; enforcement rules were being notified in phases, so check current status before quoting deadlines.

Classifying research methods

Qualitative vs quantitative: qualitative answers *why* and *how* (interviews, contextual inquiry, think-aloud); quantitative answers *how many / how much* (analytics, surveys, benchmark tests, A/B tests).
Attitudinal vs behavioural: attitudinal captures what people *say* (interviews, surveys, focus groups); behavioural captures what they *do* (usability tests, analytics, eye tracking, clickstream). The say–do gap is a standard interview topic.
Generative (discovery) vs evaluative (validation): generative research precedes design (field study, diary study, interviews, competitor analysis); evaluative research tests a design (usability test, heuristic evaluation, A/B test, accessibility audit).
Moderated vs unmoderated: a moderator probes and adapts (richer, costlier); unmoderated remote tests (UserTesting, Maze, Lookback) give volume cheaply but no probing.
Lab vs remote vs field: field/contextual studies catch the real Indian context — 2G patches, shared phones, screen glare, interruptions, help from a shopkeeper — that a Bengaluru lab hides.
Formative vs summative evaluation: formative runs during design with few users to *find* problems; summative runs at the end with many users to *measure* against a benchmark.

Core methods and how each is run

Stakeholder and secondary research: business goals, existing analytics, support tickets, app-store reviews, prior studies — always first, because it is free.
User interviews: 5–12 participants per segment, semi-structured guide, open non-leading questions, laddering ("why is that important?") to reach needs behind stated wants.
Contextual inquiry: observe and ask in the user's own setting under a master–apprentice stance; outputs flow models, sequence models and artefact models.
Diary / experience sampling studies: participants log usage over 1–4 weeks via WhatsApp or a form; captures longitudinal and infrequent behaviour.
Surveys: closed questions for scale; needs sample-size thinking, randomised option order, and vernacular translation plus back-translation for Indian panels.
Card sorting: users group content labels — open (they name the groups) or closed (groups fixed); analysed with a similarity matrix/dendrogram. Builds information architecture; 15–30 participants typical.
Tree testing: reverse of card sorting — users find a task's answer in a text-only hierarchy; measures success, directness and first-click.
First-click testing: records where a user clicks first; strongly predictive — a correct first click greatly raises eventual task success.
Usability testing: realistic tasks, think-aloud (concurrent or retrospective), measure success, time, errors, assists; probe after each task, never during if measuring time.
Heuristic evaluation: 3–5 experts independently judge the interface against Nielsen's 10 heuristics — visibility of system status; match between system and the real world; user control and freedom; consistency and standards; error prevention; recognition rather than recall; flexibility and efficiency of use; aesthetic and minimalist design; help users recognise, diagnose and recover from errors; help and documentation. Each issue is rated 0–4 for severity.
Cognitive walkthrough: for each step, ask — will the user try to achieve the right effect, notice the right control, associate it with the effect, and see progress? Best for learnability of new users.
A/B and multivariate testing: randomly split live traffic, change one variable, compare a primary metric at a declared significance level and pre-computed sample size; never peek and stop early.
Analytics and instrumentation: funnels, drop-off, retention cohorts, session recordings, heatmaps (Clevertap, MoEngage, GA4, Hotjar) — tells you *where* users fail, not why.
Eye tracking / attention studies: fixations, saccades, gaze plots and heatmaps; expensive, used for dense dashboards, packaging and retail shelf studies.
Accessibility evaluation: automated scan (axe, Lighthouse, WAVE) + manual keyboard-only run + screen-reader pass (NVDA, TalkBack, JAWS) + colour-contrast check against WCAG 2.1 AA (4.5:1 for normal text, 3:1 for large text and UI components).

Process: running a study end to end

Frame the question — one decision the study must inform; avoid "let's test everything".
Choose the method on the qualitative/quantitative and generative/evaluative axes; state what evidence would change the design.
Define participants and recruit — screener questionnaire, quotas by segment (first-time vs power user, Android budget vs premium, Tier-1 vs Tier-2/3 city, language), incentive (typically ₹500–₹2,000 for an hour in India, more for professionals), recruited via panels, field recruiters, user base emails or in-store intercepts.
Write the protocol — scenarios and tasks phrased as goals ("book the cheapest sleeper ticket to Nagpur for Friday"), not instructions ("click Trains"); success criteria defined in advance.
Ethics and consent — plain-language consent for recording, right to withdraw, pseudonymised IDs (P1, P2), data stored only as long as needed, DPDP-compliant notice; institutional ethics approval where the college requires it.
Pilot with 1 participant to fix wording, timing and tech.
Run — 45–60 minutes, one facilitator plus one note-taker, think-aloud, minimal intervention, record screen and audio with permission.
Analyse — transcribe, tag observations, affinity mapping into themes, rainbow spreadsheet to count how many participants hit each issue, severity rating.
Report — findings ranked by severity with evidence clips, metrics table, and specific redesign recommendations; include what was *not* a problem.
Iterate and retest — fix, then re-run the same tasks to confirm the fix and measure the delta.

Deliverables and artefacts

Personas: evidence-based composite users with goals, behaviours, context and pain points; proto-personas are assumption-based and must be labelled as such. Jobs-to-be-done statements are an alternative framing when segmentation by attributes is weak.
Empathy map: says / thinks / does / feels. User journey map: stages, actions, touchpoints, emotions, pain points, opportunities. Service blueprint: adds frontstage/backstage actors and systems.
Task analysis / HTA: hierarchical decomposition of a goal into sub-tasks and plans. User flow and IA sitemap.
Research repository: tagged, searchable store of findings (Dovetail, Notion, or a shared sheet) so insights outlive the project.
Usability report: objective, method, participants table, metrics, severity-ranked findings, recommendations, appendix of tasks.

Sampling, validity and bias

Why five users: Nielsen–Landauer model — problems found = N(1 − (1 − L)ⁿ), with L ≈ 0.31 per user; 5 users reveal about 85% of problems for one homogeneous segment. Run 5 per segment and more small iterations rather than one big test.
Quantitative benchmarks need roughly 20+ participants per cell for usable confidence intervals; A/B tests need thousands of sessions depending on baseline rate and effect size.
Biases to control: leading questions, social desirability (Indian participants often praise to be polite — reframe as "what would you tell a friend to avoid?"), confirmation bias in analysis, sampling bias toward English-speaking urban users, Hawthorne effect, recency and primacy in surveys, moderator acquiescence.
Validity: internal (did the design cause the result), external (does it generalise), ecological (does the setting resemble real use). Reliability = repeatability; check inter-rater agreement when two analysts code the same sessions.

Indian context constraints that change research design

Language and literacy: test in the user's language; icon-plus-label beats icon-only; voice and vernacular flows for low-literacy users; test numerals and date formats.
Device and network: budget Android, 2–4 GB RAM, intermittent 4G; test on a throttled connection and a real low-end device, not only an iPhone simulator.
Shared and assisted use: one phone shared across a family; assisted digital use (shopkeeper, agent, family member) is a legitimate user model — recruit the assistant too.
Payments and trust: UPI flows, OTP, failure and refund states; trust cues matter more than aesthetics in first transaction. Test failure paths — they are the most-used screens on a bad network.
Public digital services: DigiLocker, IRCTC, income-tax and GST portals, UMANG, Aadhaar-linked journeys — bound by GIGW 3.0 and RPwD Act accessibility duties.

Key points

Usability (ISO 9241-11) — effectiveness, efficiency and satisfaction for specified users, goals and context.
ISO 9241-210 — human-centred design cycle: context → requirements → solutions → evaluation, iterated.
Generative vs evaluative — research before design to decide *what*; research after design to check *whether*.
Attitudinal vs behavioural — what users say versus what they do; prefer observed behaviour for interaction decisions.
Formative vs summative — few users to find problems versus many users to measure a benchmark.
Nielsen's 10 heuristics — expert checklist; cheap, fast, finds many issues but no real user behaviour.
Think-aloud — the core usability-test technique; concurrent inflates task time, retrospective risks memory loss.
Five users per segment — finds roughly 85% of issues; add segments, not participants.
Task success rate — primary effectiveness metric; define partial success rules before the test.
Time on task and error rate — efficiency metrics; report median and spread, not just mean.
SUS — 10-item, 5-point questionnaire; score 0–100; about 68 is average, above 80 is good (SUS is not a percentage).
Severity rating — frequency × impact × persistence; drives what gets fixed first.
Card sorting and tree testing — build and then verify information architecture.
A/B testing — one variable, pre-set sample size and significance, no early stopping.
Affinity mapping — groups raw observations into themes; the standard qualitative analysis move.
Personas and journey maps — synthesis artefacts; worthless if not grounded in real data.
WCAG 2.1 AA via GIGW 3.0 — the accessibility bar for Indian government digital services; RPwD Act, 2016 makes it a legal duty.
DPDP Act, 2023 — consent, notice and purpose limitation for any user data or recordings you collect.
Say–do gap and politeness bias — the two biggest threats to validity in Indian field research.

Formulas and examples

Task success rate = (number of participants completing the task correctly / total participants) × 100, in %. Partial credit (e.g. 0.5) must be defined before the study.

Error rate = total errors observed / total task attempts (errors per task, dimensionless).

Efficiency (time-based) = Σ(task success_ij) / Σ(time_ij), in successful tasks per second (Nielsen's "time-based efficiency"), where i = task, j = participant.

Problems found (Nielsen–Landauer) = N × (1 − (1 − L)ⁿ); N = total existing problems, L = proportion found by one user (≈ 0.31), n = number of users.

SUS score = 2.5 × Σ(adjusted item scores); odd items (positive): score = response − 1; even items (negative): score = 5 − response; each adjusted item is 0–4, so Σ is 0–40 and the final score is 0–100.

Single Ease Question (SEQ) = mean of a 7-point post-task difficulty rating (1 = very difficult, 7 = very easy).

Conversion rate = conversions / visitors; relative lift = (rate_B − rate_A) / rate_A × 100, in %.

Confidence interval (proportion, large sample) = p ± z√(p(1−p)/n); z = 1.96 for 95%.

Adjusted Wald interval (small samples) = p′ ± z√(p′(1−p′)/n′) with x′ = x + z²/2, n′ = n + z², p′ = x′/n′ — use this for usability tests with under about 15 users.

Contrast ratio (WCAG) = (L1 + 0.05)/(L2 + 0.05); L1, L2 = relative luminance of lighter and darker colours; minimum 4.5:1 for normal text at AA.

Example 1 — Task success and confidence interval, IRCTC-style booking test. 12 participants attempt "book a sleeper ticket to Nagpur". 9 complete it correctly, 1 books the wrong class (counted 0), 2 abandon.

Success rate = 9/12 = 75.0%.
Simple 95% CI: √(0.75 × 0.25/12) = √0.015625 = 0.125; 1.96 × 0.125 = 0.245 → 75% ± 24.5%, i.e. 50.5% to 99.5% — far too wide to call a benchmark met.
Adjusted Wald: z² = 3.8416; x′ = 9 + 1.9208 = 10.9208; n′ = 12 + 3.8416 = 15.8416; p′ = 0.6895. √(0.6895 × 0.3105/15.8416) = √0.013515 = 0.11626; 1.96 × 0.11626 = 0.2279 → 68.9% ± 22.8%, i.e. 46.2% to 91.7%.
Conclusion: with 12 users treat 75% as directional only; a formal benchmark needs a larger sample.

Example 2 — SUS calculation for a UPI payment app. One participant's responses on the 10 items (1 = strongly disagree, 5 = strongly agree), odd items positive, even items negative: 4, 2, 5, 2, 4, 1, 5, 2, 4, 3.

Odd items (1,3,5,7,9): responses 4, 5, 4, 5, 4 → adjusted 3, 4, 3, 4, 3 = 17.
Even items (2,4,6,8,10): responses 2, 2, 1, 2, 3 → adjusted 3, 3, 4, 3, 2 = 15.
Σ = 32 → SUS = 2.5 × 32 = 80.0.
Interpretation: 80 is clearly above the 68 average — roughly "good", about the 85th percentile band. It is not 80% usable.

Example 3 — How many users to test (Nielsen–Landauer). With L = 0.31 and N = 100 latent problems:

n = 1: 100 × (1 − 0.69) = 31 problems.
n = 3: 0.69³ = 0.3285 → 100 × 0.6715 = 67.
n = 5: 0.69⁵ = 0.1564 → 84 (about 85%).
n = 10: 0.69¹⁰ = 0.02448 → 97.6.
Marginal gain from user 6 to 10 is about 13.6 problems for 5 extra sessions — cheaper to fix the 84 found and retest with 5 fresh users.

Example 4 — Time-based efficiency comparison, two checkout designs. Four participants, one task each; success = 1, failure = 0.

Participant	A: success	A: time (s)	B: success	B: time (s)
P1	1	95	1	60
P2	1	120	1	72
P3	0	150	1	85
P4	1	110	0	140

Design A: successes = 3; Σtime = 95 + 120 + 150 + 110 = 475 s → efficiency = 3/475 = 0.00632 tasks/s; success rate 75%; mean time of successful tasks = (95+120+110)/3 = 108.3 s.
Design B: successes = 3; Σtime = 60 + 72 + 85 + 140 = 357 s → efficiency = 3/357 = 0.00840 tasks/s; success rate 75%; mean successful time = (60+72+85)/3 = 72.3 s.
B is about 33% more efficient (0.00840/0.00632 = 1.33) at equal success; with n = 4 this is a signal to pursue, not proof.

Example 5 — A/B test on a Hindi-language onboarding screen. Variant A: 4,000 visitors, 320 sign-ups. Variant B (icon + Hindi label): 4,000 visitors, 400 sign-ups.

p_A = 320/4000 = 0.0800 (8.00%); p_B = 400/4000 = 0.1000 (10.00%).
Absolute lift = 2.00 pp; relative lift = (0.10 − 0.08)/0.08 = +25.0%.
Pooled p = 720/8000 = 0.0900; SE = √(0.09 × 0.91 × (1/4000 + 1/4000)) = √(0.0819 × 0.0005) = √0.00004095 = 0.006399.
z = 0.02/0.006399 = 3.13 → p ≈ 0.0017, significant at 95% (and at 99%). Roll out B, then verify with a qualitative session on *why* the label helped.

Method	Type	Users needed	Gives you	Main limitation
User interview	Qualitative, attitudinal	5–12 per segment	Goals, mental models, vocabulary	Reported, not observed behaviour
Contextual inquiry	Qualitative, behavioural	6–12	Real context and workarounds	Time- and travel-intensive
Usability test (moderated)	Mixed, behavioural	5 per segment	Specific failure points with reasons	Not statistically generalisable
Heuristic evaluation	Expert, no users	3–5 evaluators	Fast issue list, cheap	Misses domain-specific user failures
Survey	Quantitative, attitudinal	100+	Prevalence, segmentation	Question wording bias; no "why"
Analytics	Quantitative, behavioural	Whole base	Where users drop off, at scale	No reasons, no non-users
A/B test	Quantitative, behavioural	Thousands	Causal effect on one metric	Needs traffic and a live product
Card sorting / tree testing	Mixed	15–30	Information architecture validation	Labels only, no visual context

Where it is used

Consumer internet and fintech: Flipkart, Myntra, Zomato, Swiggy, Paytm, PhonePe, Groww, Razorpay run continuous research teams on vernacular onboarding, UPI failure states and returns/refund flows.
Enterprise and SaaS design: Zoho, Freshworks, Postman, Infosys and TCS design studios and Wipro/Accenture experience practices research complex workflow tools where efficiency and error cost dominate.
Public and civic digital services: IRCTC, DigiLocker, UMANG, income-tax and GST portals, state e-governance portals — accessibility audits against GIGW 3.0 and WCAG 2.1 AA, and usability testing with low-literacy and assisted users.
Hardware, appliances and automotive HMI: Titan, Tata Motors, Mahindra, Godrej, Whirlpool — ergonomic and usability studies on touch HMIs, remote controls and in-car interfaces, alongside anthropometry.
Healthcare and medical devices: usability engineering files for devices (IEC 62366-1 process) in diagnostics and hospital software; CDSCO-regulated device documentation expects use-related risk analysis.
Job roles: UX researcher, design researcher, usability analyst, product designer, accessibility specialist, service designer, CX analyst, and research-ops roles at design consultancies (Lollypop, Think Design, Fractal, Quovantis).

Interview questions

Q: What is usability, formally? A: Per ISO 9241-11, the extent to which specified users achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use — so it is always relative to users, goals and context.
Q: Why do five users suffice in a usability test? A: With about 31% of problems surfacing per user, five users reveal around 85% of issues in one segment; it is cheaper to fix and retest than to add users. Add segments, not participants, and use larger samples for quantitative benchmarks.
Q: Difference between a heuristic evaluation and a usability test? A: Heuristic evaluation is experts judging an interface against principles — fast and cheap but predictive; a usability test observes real users attempting real tasks, which is the only way to see actual failure. Use both.
Q: When would you choose a survey over interviews? A: When you already know the questions and need prevalence or segmentation across many users; interviews are for discovering unknown reasons and vocabulary.
Q: What is the say–do gap and how do you handle it? A: Users misreport their behaviour from memory, aspiration or politeness; you handle it by observing tasks, asking about the last concrete instance instead of generalities, and triangulating with analytics.
Q: A SUS score of 72 — is the product good? A: It is above the ~68 average, roughly "good", but SUS measures perceived usability only, is not a percentage, and tells you nothing about which tasks failed — pair it with task-level metrics.
Q: Stakeholders insist a feature is needed but research says users ignore it. What do you do? A: Present the evidence by severity with session clips and metrics, separate the business goal from the proposed solution, and offer a cheap A/B test or smaller variant to settle it with data rather than opinion.
Q: How would you test a payments app for a Tier-3 user on 3G? A: Recruit in that city, use a real budget Android on a throttled network, test in their language, include OTP and payment-failure paths, and observe assisted use if a family member usually helps.
Q: How do you rate severity? A: Combine frequency (how many users hit it), impact (how badly it blocks the goal) and persistence (does it recur after learning), typically on a 0–4 scale, then rank fixes by severity against effort.
Q: What accessibility checks are mandatory for an Indian government website? A: GIGW 3.0 compliance aligned to WCAG 2.1 Level AA, as a duty flowing from the RPwD Act, 2016 — covering keyboard operability, screen-reader labels, 4.5:1 text contrast, captions and accessible forms, verified by automated scan plus manual and screen-reader testing.
Q: Can you run an A/B test with 50 users? A: No meaningfully — detecting a small lift on a low base rate needs thousands of sessions; with 50 users run a moderated usability test and compare qualitatively instead.
Q: What consent must you take before recording a research session in India? A: Free, specific, informed consent with a plain-language notice of purpose, retention and withdrawal rights under the DPDP Act, 2023 (binding from 13 May 2027 under the DPDP Rules 2025; research ethics require it already), plus pseudonymised storage and a separate permission for sharing clips.
Q: What is the difference between a persona and a proto-persona? A: A persona is synthesised from actual research data; a proto-persona is an assumption-based placeholder created before research and must be validated and labelled as provisional.

Common mistakes

Treating SUS as a percentage, or quoting a score without the ~68 benchmark and without task-level metrics.
Writing leading tasks ("click on the Trains tab and book a ticket") so the test measures instruction-following, not findability.
Reporting usability-test percentages from 5 users as if they were statistically reliable, with no confidence interval or caveat.
Intervening or coaching during a timed task, then reporting the time as valid.
Building personas and journey maps from team assumptions and presenting them as research findings.
Sampling only English-speaking urban users on premium phones, then claiming the product works for India.
Running heuristic evaluation alone and calling it "usability testing", or skipping manual keyboard and screen-reader checks after a clean automated accessibility scan.
Analysing by counting opinions instead of severity — a single blocking failure outweighs several cosmetic complaints.