Unit 5: Testing, Validation and Customer Experience

I. Orientation: Evidence-Centred Design Thinking

Testing and validation convert a proposed solution into evidence about what users can do, understand, and experience. In design thinking, testing is not merely a final quality check; it is an iterative learning activity that may reveal incorrect assumptions, unmet needs, usability barriers, or opportunities for improvement.

Defining characteristics:

• User-centred evidence: Decisions are based on observed user behaviour, task performance, and feedback rather than the design team’s preferences.
• Iteration: Findings feed back into prototyping, problem definition, and ideation; a failed assumption is useful if discovered early.
• Realistic context: Representative users attempt credible tasks using a prototype or working product under conditions resembling actual use.
• Neutral facilitation: Researchers avoid teaching, persuading, defending, or leading participants toward expected responses.
• Measurable outcomes: Evidence may include completion rate, time on task, error count, satisfaction ratings, and recurring qualitative observations.
• End-to-end perspective: Customer experience covers the entire relationship, while usability evaluates interaction with a particular product or interface.
• Inclusive access: Digital products should accommodate differences in vision, hearing, mobility, cognition, language, device, and environment.

II. Testing and Validation Methods — Learning from User Behaviour

Testing methods expose users to a design and collect evidence about whether it solves the intended problem. The aim is not to prove that a design is good, but to identify what works, what fails, and what should change.

A. User Testing and Design Validation

User testing examines how representative users interact with a design, while design validation determines whether the proposed solution addresses the intended need.

• Distinction:
  1. Usability testing: Asks whether users can use the solution effectively, efficiently, and satisfactorily.
  2. Design validation: Asks whether the right solution has been designed for the right problem.
• Test plan: Defines the research objective, participant profile, prototype fidelity, tasks, setting, facilitator script, and measures before sessions begin.
• Representative participants: Recruitment should reflect relevant characteristics such as experience level, accessibility needs, device use, or purchasing role; five convenient classmates may not represent banking customers.
• Behavioural measures:
  • Task success: Completed, partially completed, or failed.
  • Efficiency: Time, clicks, screens, or steps required.
  • Errors: Wrong selections, invalid entries, or requests for assistance.
• Validation evidence: A meal-planning prototype may be easy to navigate yet invalid if users do not consider meal planning an important problem.
• Iteration: Recurring findings are translated into design changes, followed by another test rather than treated as final approval.

B. Principles of Neutral User Testing

Neutral testing reduces bias so that participant behaviour reflects the design rather than the facilitator’s expectations.

• Non-leading language: Ask “What would you do next?” rather than “Would you click the green checkout button?”
• Consistent procedure: Use the same introduction, task wording, prototype state, and follow-up prompts across sessions so observations remain comparable.
• Limited intervention: Allow reasonable struggle before helping; record the point at which assistance became necessary.
• No defence or praise: Statements such as “That feature took months to build” or “Excellent choice” can pressure participants to respond positively.
• Balanced probing: Use prompts such as “What were you expecting?” and “What made that difficult?” without suggesting a preferred answer.
• Role clarity: Explain that the product—not the participant—is being tested, reducing fear of making mistakes.
• Observer discipline: Separate observation from interpretation:
  • Observation: “The participant selected ‘Profile’ three times.”
  • Interpretation: “The participant may expect billing settings under ‘Profile’.”
• Think-aloud limitation: Verbalisation reveals expectations, but it can slow performance; time-on-task results should therefore be interpreted cautiously.

C. Task Scenarios and User Testing

Task scenarios give participants realistic goals without revealing the interface steps needed to achieve them.

• Scenario structure: Include a believable context, motivation, goal, and relevant constraints; omit button names and navigation instructions.
• Weak task: “Click ‘Filters,’ choose ‘Under ₹2,000,’ and press ‘Apply’” tests obedience rather than discoverability.
• Strong task: “You need a pair of running shoes for under ₹2,000 that can arrive before Friday. Find a suitable option.”
• Task order: Begin with a simple orientation task, then test critical or risky workflows; randomise order when learning from one task could affect another.
• Success criteria: Define completion before testing—for example, selecting an eligible item and reaching the order-review screen without moderator assistance.
• Scenario realism: Use plausible names, prices, dates, and constraints, but avoid unnecessary detail that increases memory demands.
• Post-task probing: Ask about expectations, confidence, and difficulty only after observing behaviour so questions do not interrupt the natural workflow.

D. Show, Don’t Tell Testing Approach

The “show, don’t tell” approach evaluates what users actually do with a prototype instead of relying on descriptions, pitches, or hypothetical opinions.

• Concrete interaction: Present a paper sketch, clickable wireframe, role-played service, or functional build and ask the participant to attempt a goal.
• Behaviour over prediction: “Would you use this?” often produces polite speculation; watching whether a user locates and uses the feature provides stronger evidence.
• Demonstration prompts: Ask “Show me how you would reschedule the appointment” instead of explaining the rescheduling process.
• Minimum necessary context: Provide only information that a real user would possess; hidden explanations can mask poor labels or navigation.
• Prototype fidelity: Use low fidelity for concepts and structure, medium fidelity for flows, and high fidelity for visual detail or realistic interaction.
• Evidence boundary: Prototype interaction indicates usability and desirability, but does not by itself prove long-term adoption, technical feasibility, or commercial viability.

E. Feedback Capture Matrix

A feedback capture matrix organises observations and comments so that a testing session produces actionable learning rather than an unstructured list.

• Four common quadrants:
  • Likes: Elements users valued or found clear.
  • Wishes: Changes or missing capabilities users requested.
  • Questions: Uncertainties raised by users or researchers.
  • Ideas: New concepts prompted by the session.
• Evidence recording: Capture a short quotation, observed action, task, participant code, and context; “P3 searched for a back button on the payment screen” is more useful than “navigation bad.”
• Pattern detection: Cluster repeated notes across participants, but preserve unusual findings when they indicate a severe accessibility or safety risk.
• Prioritisation: Rate findings by frequency, impact, and urgency; a rare inability to submit an emergency request may outrank a common cosmetic complaint.
• Action conversion: Rewrite findings as design decisions or hypotheses—for example, “Test a persistent ‘Back to cart’ link on the payment screen.”
• Limitation: The matrix supports synthesis but does not replace raw notes, recordings, performance measures, or researcher interpretation.

III. Customer Experience Analysis — Understanding the End-to-End Relationship

Customer experience concerns a person’s overall perception of an organisation across time and channels. It includes product interaction, expectations, emotions, service encounters, communication, and outcomes.

A. Customer Experience and Usability

Usability is a component of customer experience, but the two differ in scope and measurement.

• Usability focus: Evaluates effectiveness, efficiency, and satisfaction for specified users, goals, and contexts—for example, completing mobile check-in without errors.
• Customer-experience focus: Includes discovery, purchase, delivery, support, cancellation, trust, and memory of the relationship.
• Key contrast: A ticket-booking interface may be usable, yet the overall experience may be poor because of hidden fees or unhelpful customer support.
• Usability measures:
  • Task-completion percentage.
  • Median time on task.
  • Error or assistance count.
  • Post-task ease rating, such as a seven-point scale.
• Experience measures: Customer satisfaction, retention, complaint themes, repeat purchase, support resolution, and recommendation measures provide different perspectives.
• Context dependence: Efficiency may dominate an emergency application, while trust and reassurance may matter more in healthcare or financial services.
• Design implication: Teams should improve both interface performance and the surrounding policies, communications, and service processes.

B. Customer Experience and Journey Mapping

Journey mapping visualises the stages through which a customer pursues a goal, making fragmented interactions and emotional changes visible.

• Defined perspective: A map represents one user group, goal, and scenario; combining every customer into one map produces misleading generalisations.
• Typical stages: Awareness, consideration, purchase, onboarding, use, support, renewal, and exit may be adapted to the service.
• Map layers:
  • Actions: What the customer does at each stage.
  • Thoughts and emotions: Expectations, confidence, anxiety, or delight.
  • Touchpoints and channels: Website, store, email, app, telephone, or delivery.
  • Pain points and opportunities: Breakdowns and possible interventions.
• Evidence base: Interviews, observation, analytics, complaint logs, support transcripts, and diary studies should inform the map.
• Example: A delayed delivery may create anxiety not only at arrival but earlier, when tracking information remains unchanged for several days.
• Operational value: Journey maps align departments by showing how marketing promises, software, logistics, and support collectively shape one experience.
• Limitation: A journey map is a model, not proof; it must be updated when user behaviour, channels, or services change.

C. User Touchpoints and Pain Points

Touchpoints are moments of interaction with a product or organisation, while pain points are obstacles that create effort, confusion, delay, risk, or negative emotion.

• Touchpoint categories:
  • Human: Sales staff, delivery personnel, or support agents.
  • Digital: Search results, websites, applications, chatbots, or emails.
  • Physical: Packaging, stores, forms, receipts, or installed equipment.
• Direct and indirect contact: A company website is direct; a review site or social-media comment may be indirect but still shapes expectations.
• Pain-point types: Functional failure, excessive time, unclear information, unexpected cost, emotional stress, accessibility barriers, and repeated data entry.
• Root-cause analysis: “Customer called support” is an event; the cause may be an unclear invoice, failed password reset, or missing order status.
• Prioritisation: Compare severity, frequency, journey importance, and affected users; payment failure usually has greater impact than an inconsistent icon.
• Opportunity framing: Convert “users hate verification” into a testable aim such as “reduce verification steps while maintaining required security controls.”
• Ownership: Assign each improvement to a responsible team because pain points often cross software, policy, and service boundaries.

IV. Digital Interaction Quality — Usability, Navigation, and Inclusion

Digital quality depends on whether users can understand the interface, move through it predictably, recover from errors, and access it through different devices and assistive technologies.

A. Software Usability and Navigation

Software navigation should help users know where they are, what options exist, and how to reach or leave a destination.

• Information architecture: Group content according to user expectations; card sorting and tree testing can evaluate categories before visual design.
• Clear labels: Use familiar, specific terms such as “Order history” rather than internal labels such as “Transaction repository.”
• Consistency: Keep navigation position, terminology, icons, and interaction patterns stable across screens.
• Location cues: Page titles, selected menu states, breadcrumbs, and progress indicators communicate current position and remaining steps.
• User control: Provide back, cancel, undo, and exit options; destructive actions such as deleting an account should require clear confirmation.
• System feedback: After “Save,” show an immediate status such as “Changes saved”; for longer operations, provide progress or loading feedback.
• Error handling: Place specific messages near the problem—“Password must contain at least 12 characters”—and preserve valid entries.
• Responsive testing: Check keyboard, touch, small screens, slow networks, and interruptions rather than evaluating only an ideal desktop path.
• Navigation evidence: Track first-click success, path deviation, abandonment, search refinements, and repeated backtracking alongside participant explanations.

B. Accessibility in Digital Products

Accessibility ensures that people with disabilities can perceive, understand, navigate, and operate digital products, while often improving usability for everyone.

• POUR principles:
  • Perceivable: Information is available through alternatives such as text equivalents and captions.
  • Operable: Controls work by keyboard and do not demand precise gestures.
  • Understandable: Language, navigation, and error guidance remain clear and predictable.
  • Robust: Content works with current and future browsers and assistive technologies.
• Semantic structure: Use genuine headings, lists, labels, buttons, and landmarks so screen readers can interpret relationships and controls.
• Visual access: Maintain sufficient contrast; WCAG guidance commonly uses at least 4.5:1 for normal text and 3:1 for large text.
• Keyboard access: Ensure logical focus order, visible focus indicators, skip links, and no keyboard traps.
• Media alternatives: Supply captions for spoken audio, transcripts where appropriate, and meaningful alternative text for informative images.
• Forms and errors: Associate labels programmatically with fields and identify errors through text, not colour alone.
• Motion and timing: Allow users to pause movement, avoid harmful flashing, and extend time limits when the task permits.
• Evaluation: Combine automated checking with keyboard review, screen-reader testing, zoom testing, and sessions involving people with disabilities; automated tools cannot judge clarity or task success.