ABCD

ABC of Product DesignA field guide for turning ambiguous briefs into sound product decisions. Start real assignments with confidence, choose UX methods with intent, see worked examples, prepare for design interviews and build toward AI product practice.

Built for the moment between knowing design theory and having to apply it in a real brief, take-home assignment, interview task or product team.

Start here

What brought you here today?

Choose the closest situation. You can jump directly to the part of the handbook built for it.

Start a Brief · Core product-design practice

A new brief landed. Start here before you open Figma.

Turn the request into a clear decision, separate evidence from assumptions, identify what could make the team wrong, then choose the smallest credible next move. This is the reusable starting logic for almost every design problem.

Information / research Validated / good signal Caution / assumption Risk / failure Advanced / intelligent systems
“The process is not the deliverable. Better decisions are.”

A new designer often asks, “Which UX process should I follow?” A stronger question is, “What could make this decision wrong, and what is the smallest credible way to learn before we commit?”

That question is the spine of this handbook. Methods change with the problem. Sound design judgment stays portable.

01FrameBrief → decision → constraints
02InvestigateEvidence → diagnosis → insight
03ShapeIA → flows → interaction → UI
04ProvePrototype → test → measure
05Ship & learnHandoff → QA → outcomes → iteration
01

What decision are we making?

What to build, why something is failing, how a flow should work, whether a concept is understood, or whether a build is accessible?

02

What do we actually know?

Separate evidence from stakeholder opinion, inherited assumptions, competitor envy and “this feels outdated.”

03

What is the riskiest unknown?

Uncertainty × consequence determines the depth of research and validation you need.

Brief → process router

Three rules that save months of rework

Do not manufacture deliverables

A persona, journey map, service blueprint or wireframe is useful only if it improves a decision.

Do not confuse polish with certainty

A beautiful prototype can still represent the wrong problem, unsupported logic or missing states.

Do not “handoff” thinking

Product, engineering, content, data and accessibility should enter the process before the final Figma link.

Methods · Reference library

Know the question? Find the method that can answer it.

This is a reference library, not a chapter to read in order. Search by the uncertainty you need to reduce, then inspect when to use the method, what evidence it creates and where it can mislead you.

Methods are tools. The craft is knowing which one not to use.

Each method below is framed by the question it answers, the evidence it creates, its limits and the common mistake to avoid.

Research

Stakeholder interview

Talk to the people who own the business, product or delivery context so you understand goals, constraints, assumptions and politics.
Use it when

Use at the start of ambiguous work, especially when different teams want different things.

Typical output

A clearer brief, constraints, assumptions and decision criteria.

Time / effort

30-60 min per stakeholder

Tools

Notes, Docs, FigJam/Miro, Claude for synthesis

How to do it
  1. Ask what problem they believe exists
  2. Ask why it matters now
  3. Ask what evidence they have
  4. Ask what cannot change
  5. Ask how success will be judged
Common misuse

Do not treat stakeholder opinion as user evidence.

Research

User interview

Talk with representative users to understand behaviours, goals, context and why things happen.
Use it when

Use when you know what is happening but not why - or when the problem is still poorly understood.

Typical output

Behavioural evidence, needs, pain points, language and hypotheses.

Time / effort

30-60 min each; 5-12 often enough for focused discovery

Tools

Zoom/Meet, notes, Dovetail/Notion, Claude for assisted synthesis

How to do it
  1. Recruit people who actually match the target user
  2. Ask about recent real behaviour
  3. Probe examples, workarounds and consequences
  4. Avoid pitching the solution
  5. Synthesize patterns, not just memorable quotes
Common misuse

Do not ask users to design the product for you.

Research

Contextual inquiry

Observe users doing the real work in the real environment while asking questions.
Use it when

Use for complex workflows where people forget steps, shortcuts or environmental constraints when interviewed from memory.

Typical output

Observed workflow, hidden constraints, workarounds and opportunities.

Time / effort

45-120 min per session

Tools

Video/notes, photos with permission, journey/workflow map

How to do it
  1. Choose a real task
  2. Observe before interrupting
  3. Ask why only when needed
  4. Capture tools, artefacts, interruptions and workarounds
  5. Map the real workflow afterward
Common misuse

Avoid when the task is trivial or context adds little.

Research

Survey

Collect structured responses from many people.
Use it when

Use when you already know what you need to ask and want breadth, prevalence or segmentation.

Typical output

Quantified attitudes or self-reported behaviour.

Time / effort

1-3 days to design + collection time

Tools

Google Forms, Typeform, Qualtrics

How to do it
  1. Define the decision the survey should inform
  2. Keep questions single-purpose
  3. Use neutral wording
  4. Pilot the survey
  5. Analyze by useful segments
Common misuse

Weak for discovering deep unknowns or causality.

Research

Diary study

Ask participants to record relevant experiences over time.
Use it when

Use when behaviour is intermittent, longitudinal or context-dependent.

Typical output

Patterns across days/weeks, triggers, context and changing behaviour.

Time / effort

Several days to several weeks

Tools

Diary tool, forms, chat, Dovetail

How to do it
  1. Define what to record and when
  2. Keep entries lightweight
  3. Send reminders
  4. Add periodic check-ins
  5. Synthesize patterns across time
Common misuse

Not for a one-session usability question.

Research

Support / review mining

Analyze support tickets, reviews, sales calls, complaints and success notes.
Use it when

Use when direct research access is limited or you need fast evidence from existing customer conversations.

Typical output

Pain-point clusters and authentic customer language.

Time / effort

2-8 hours for a focused pass

Tools

Zendesk/Intercom exports, spreadsheets, Claude

How to do it
  1. Collect a representative sample
  2. Tag problem, frequency and severity
  3. Separate product bugs from comprehension problems
  4. Look for repeated user language
  5. Cross-check against analytics
Common misuse

It overrepresents people motivated enough to complain or contact support.

Research

Analytics review

Look at behavioural data to understand what users actually do.
Use it when

Use for funnels, feature usage, activation, retention, repeated failure or segment differences.

Typical output

Behaviour patterns, baselines and measurable hypotheses.

Time / effort

2 hours-several days

Tools

Amplitude, Mixpanel, GA4, SQL, BI tools

How to do it
  1. Start from a question
  2. Check tracking quality
  3. Segment meaningfully
  4. Find the point of change/drop-off
  5. Pair with qualitative evidence to explain why
Common misuse

Analytics rarely explains why by itself.

Diagnose

Heuristic evaluation

An expert inspection of an interface using established usability principles.
Use it when

Use when an existing product or prototype needs a fast usability review before or alongside user testing.

Typical output

Prioritized list of likely usability issues with rationale.

Time / effort

2-8 hours for a focused flow; 1-3 days for a product area

Tools

Nielsen heuristics, screenshots, issue tracker

How to do it
  1. Choose a heuristic set
  2. Walk important flows independently
  3. Record issue, evidence and violated principle
  4. Assign severity
  5. Consolidate duplicates and prioritize
Common misuse

It predicts likely problems; it does not prove users are experiencing them.

Diagnose

UX audit

A broad diagnosis of product experience using multiple evidence sources - not just interface taste.
Use it when

Use for redesigns, inherited products, “improve UX” mandates or products with many unexplained issues.

Typical output

Evidence-backed issue and opportunity map with priorities.

Time / effort

2 days-2+ weeks depending on scope

Tools

Heuristic checklist, analytics, research repo, WCAG tools

How to do it
  1. Clarify goals and scope
  2. Review key flows and heuristics
  3. Inspect analytics and known research
  4. Check content, accessibility and consistency
  5. Prioritize by severity × evidence × business/user impact
Common misuse

Do not turn it into a screenshot beauty critique or 100 unranked observations.

Diagnose

Cognitive walkthrough

Step through a task from the viewpoint of a new or infrequent user.
Use it when

Use when learnability, first-time use or unfamiliar workflows matter.

Typical output

Breakpoints in discoverability, comprehension and feedback.

Time / effort

1-3 hours per flow

Tools

Flow map, prototype, checklist

How to do it
  1. Define the user and task
  2. At each step ask if the goal is clear
  3. Ask if the correct action is visible
  4. Ask if the user will understand the result
  5. Record where knowledge or feedback is missing
Common misuse

Less useful for expert-only repetitive workflows.

Diagnose

Accessibility audit

Evaluate the product against accessibility requirements and actual interaction behaviour.
Use it when

Use for any digital product; especially public, regulated, high-stakes or design-system work.

Typical output

Violations, severity, remediation guidance and reusable system fixes.

Time / effort

Half-day to several days

Tools

axe, Lighthouse, WAVE, VoiceOver/NVDA, contrast tools

How to do it
  1. Automated scan
  2. Keyboard-only task pass
  3. Screen-reader/semantic review
  4. Contrast, focus and target-size checks
  5. Zoom/reflow and error handling
  6. Prioritize reusable fixes first
Common misuse

Automated scanners alone are insufficient.

Diagnose

Content audit

Inventory and evaluate interface/content for usefulness, accuracy, duplication, clarity and structure.
Use it when

Use for content-heavy products, migrations, help centers, onboarding or major redesigns.

Typical output

Content inventory and action plan.

Time / effort

1 day-several weeks

Tools

Spreadsheet, CMS export, content model

How to do it
  1. Inventory content
  2. Define evaluation criteria
  3. Mark keep/rewrite/merge/remove
  4. Identify gaps
  5. Align content to user tasks
Common misuse

Do not reduce the audit to word count or tone alone.

Diagnose

Competitive analysis

Study how relevant alternatives solve a similar user or market problem.
Use it when

Use to understand patterns, expectations, positioning, feature models and gaps.

Typical output

Pattern map, principles, gaps and questions to validate.

Time / effort

3 hours-2 days

Tools

Browser, screenshots, spreadsheet, FigJam

How to do it
  1. Choose direct and adjacent competitors
  2. Compare the same task across products
  3. Separate surface pattern from underlying principle
  4. Record strengths/constraints
  5. Translate into opportunities, not copies
Common misuse

Do not create screenshot collages with no synthesis.

Diagnose

Design-system audit

Inspect components, tokens, variants, accessibility, duplication and real usage.
Use it when

Use when UI has drift, inconsistent behavior, component sprawl or scaling problems.

Typical output

System debt, consolidation plan and governance needs.

Time / effort

1-5 days

Tools

Figma libraries, Storybook, codebase, spreadsheets

How to do it
  1. Inventory actual product patterns
  2. Map to library components
  3. Find duplicates and variants
  4. Check accessibility and responsiveness
  5. Prioritize high-frequency/high-risk components
Common misuse

Do not optimize library purity at the expense of real product needs.

Synthesis

Affinity mapping

Group related observations so patterns become easier to see.
Use it when

Use after interviews, observations or large qualitative datasets.

Typical output

Theme clusters and candidate insights.

Time / effort

1-3 hours

Tools

FigJam, Miro, sticky notes

How to do it
  1. Write one observation per note
  2. Group by similarity
  3. Name groups after patterns emerge
  4. Keep contradictory evidence visible
  5. Translate clusters into insights
Common misuse

Do not cluster opinions that were never evidence.

Synthesis

Thematic analysis

Systematically identify recurring themes across qualitative data.
Use it when

Use when you need more rigor than a casual affinity map.

Typical output

Themes supported by traceable evidence.

Time / effort

Several hours-days

Tools

Dovetail, spreadsheets, qualitative coding tools

How to do it
  1. Familiarize yourself with the data
  2. Code observations
  3. Build candidate themes
  4. Check themes against source data
  5. Write evidence-backed interpretation
Common misuse

Do not let AI-generated clusters become findings without source checking.

Synthesis

Jobs To Be Done

Frame the progress a person is trying to make in a particular situation.
Use it when

Use when feature requests or existing product structure hide the underlying need.

Typical output

A user-centered job framing that survives beyond one feature.

Time / effort

1-4 hours after research

Tools

Interview notes, canvas/worksheet

How to do it
  1. Define the situation
  2. Describe the progress sought
  3. Identify push/pull forces and anxieties
  4. Map current alternatives
  5. Use the job to evaluate solutions
Common misuse

Do not force every problem into a generic job statement.

Synthesis

Persona / archetype

A shared model of a meaningful user type based on behaviour, goals and context.
Use it when

Use only when different user groups genuinely need different product decisions.

Typical output

Shared user model for decisions.

Time / effort

2-6 hours after research

Tools

Docs, Figma/FigJam

How to do it
  1. Segment by meaningful behaviour/need
  2. Ground in evidence
  3. Describe goals, context and constraints
  4. Show implications for the product
  5. Keep the model lightweight and usable
Common misuse

Avoid decorative demographic posters and invented certainty.

Synthesis

Journey map

Map the experience across stages and touchpoints toward a goal.
Use it when

Use when the problem unfolds over time or across channels.

Typical output

Shared view of the end-to-end experience and opportunity areas.

Time / effort

3-8 hours

Tools

FigJam, Miro

How to do it
  1. Choose a user and goal
  2. Define stages
  3. Map actions, touchpoints and evidence
  4. Add pain/opportunity only when supported
  5. Mark moments that matter
Common misuse

Not a substitute for a detailed in-product flow.

Synthesis

Service blueprint

Map frontstage experience together with backstage people, processes and systems.
Use it when

Use when user experience depends on operational complexity.

Typical output

Frontstage/backstage service model.

Time / effort

Half-day-several days

Tools

Miro, FigJam

How to do it
  1. Map user actions
  2. Map visible service interactions
  3. Add backstage roles/systems
  4. Add handoffs and dependencies
  5. Locate failure points and ownership
Common misuse

Overkill for a small self-contained UI change.

Synthesis

Problem statement

Turn evidence into a clear problem worth solving.
Use it when

Use before ideation or when the original brief is already prescribing a solution.

Typical output

A focused design challenge and shared framing.

Time / effort

30-90 min

Tools

Docs, workshop

How to do it
  1. Name the user/context
  2. Describe the obstacle
  3. State the consequence
  4. Connect to evidence
  5. Keep the solution out of the statement
Common misuse

Do not write “users need our new feature.”

Synthesis

Assumption mapping

List what must be true for the idea to work, then rank by uncertainty and impact.
Use it when

Use for new products, risky features, AI and ambiguous bets.

Typical output

Prioritized validation plan.

Time / effort

1-2 hours

Tools

FigJam, spreadsheet

How to do it
  1. List desirability, viability, feasibility and usability assumptions
  2. Score uncertainty
  3. Score consequence
  4. Prioritize high-high items
  5. Choose a test for each
Common misuse

Do not spend equal time validating low-risk assumptions.

Structure

Task flow

Show the steps required to complete one task.
Use it when

Use for simple action logic before worrying about screens.

Typical output

Clear task sequence.

Time / effort

30-90 min

Tools

Paper, FigJam, Figma

How to do it
  1. Write start and goal
  2. List user actions in order
  3. Remove unnecessary steps
  4. Add required system feedback
  5. Check failure/recovery points
Common misuse

Insufficient for complex branching products.

Structure

User flow

Map screens, actions, decisions and states through a larger journey.
Use it when

Use for multi-step workflows with branches, roles or alternate paths.

Typical output

Shared logic for the experience.

Time / effort

1-4 hours

Tools

FigJam, Figma

How to do it
  1. Define entry and exit
  2. Map happy path
  3. Add decisions and alternate paths
  4. Add error/empty/loading states
  5. Review with engineering/product
Common misuse

Do not show only the happy path.

Structure

Information architecture

Organize and label content/functions so people can find and understand them.
Use it when

Use for navigation, large content sets, enterprise products and complex products.

Typical output

Hierarchy, taxonomy, labels and navigation model.

Time / effort

Half-day-several days

Tools

Spreadsheet, FigJam, Optimal Workshop

How to do it
  1. Inventory content/functions
  2. Group by user mental model
  3. Define labels/taxonomy
  4. Model hierarchy/navigation
  5. Validate with users
Common misuse

Do not mirror the company org chart unless users think that way.

Structure

Card sorting

Ask users to group items to reveal mental models.
Use it when

Use when categories, labels or grouping logic are uncertain.

Typical output

Grouping patterns and label clues.

Time / effort

1-3 days including setup/recruiting

Tools

Optimal Workshop, Miro, cards

How to do it
  1. Select representative cards
  2. Choose open/closed/hybrid sort
  3. Give neutral instructions
  4. Run with representative users
  5. Look for repeated clusters and labels
Common misuse

Not a final test of navigation usability.

Structure

Tree testing

Give users tasks against a text-only hierarchy to test findability.
Use it when

Use to validate IA before visual design.

Typical output

Findability success and wrong-path data.

Time / effort

1-3 days

Tools

Treejack/Optimal Workshop

How to do it
  1. Create realistic hierarchy
  2. Write realistic findability tasks
  3. Run with enough participants
  4. Measure success/directness
  5. Revise weak branches
Common misuse

Cannot diagnose visual placement problems.

Ideate

How Might We

Turn a defined problem into an open, actionable opportunity question.
Use it when

Use to open solution space without losing connection to the need.

Typical output

Focused ideation prompts.

Time / effort

15-45 min

Tools

Workshop, FigJam

How to do it
  1. Start from evidence
  2. Keep the user/job visible
  3. Avoid solutions in the question
  4. Make it narrow enough to act on
  5. Generate several variations
Common misuse

Avoid “How might we improve the product?”

Ideate

Crazy 8s / sketching

Generate several rough concepts quickly before attachment forms.
Use it when

Use early in ideation, especially with teams.

Typical output

Diverse rough concepts.

Time / effort

20-60 min

Tools

Paper, FigJam

How to do it
  1. Set one clear prompt
  2. Sketch many directions quickly
  3. Suspend critique during generation
  4. Share rationale
  5. Combine promising ideas afterward
Common misuse

Do not polish the first idea while others are still exploring.

Ideate

Design studio

Individuals sketch, share, critique and combine solution ideas.
Use it when

Use for fast cross-functional exploration.

Typical output

Shared solution directions and trade-offs.

Time / effort

60-120 min

Tools

Paper, FigJam

How to do it
  1. Align on problem and criteria
  2. Sketch independently
  3. Present without interruption
  4. Critique against criteria
  5. Combine and refine
Common misuse

Do not let seniority silently choose the winner.

Design

Low-fidelity wireframe

Rough screen structure with minimal visual styling.
Use it when

Use when hierarchy, content and flow are still changing.

Typical output

Cheap structural design.

Time / effort

30 min-several hours

Tools

Paper, Figma

How to do it
  1. Use real-ish content
  2. Show hierarchy
  3. Focus on task and states
  4. Keep styling deliberately simple
  5. Test structure before polishing
Common misuse

Do not spend hours beautifying grey boxes.

Design

High-fidelity UI

Detailed visual and interaction design using realistic content and system rules.
Use it when

Use once core logic is stable enough to evaluate the real experience.

Typical output

Production-intent screens/states.

Time / effort

Hours-days

Tools

Figma

How to do it
  1. Apply design system
  2. Use realistic content/data
  3. Design all important states
  4. Check responsive behavior
  5. Check accessibility and interaction detail
Common misuse

Do not use polish to hide unresolved flow logic.

Design

UX writing / content design

Design labels, instructions, messages and content as part of the interaction.
Use it when

Use everywhere; especially forms, onboarding, errors and high-stakes actions.

Typical output

Interface content and voice.

Time / effort

Continuous

Tools

Figma, docs, content guidelines

How to do it
  1. Write for user intent
  2. Put important information at the right moment
  3. Use plain language
  4. Make errors actionable
  5. Test comprehension
Common misuse

Copy cannot rescue a fundamentally confusing flow.

Design

Design system

Reusable foundations, tokens, components, patterns, documentation and governance.
Use it when

Use when multiple teams/features need scalable consistency.

Typical output

Reusable system plus operating model.

Time / effort

Ongoing

Tools

Figma, Storybook, code repo

How to do it
  1. Start from repeated product needs
  2. Define foundations/tokens
  3. Build accessible components
  4. Document usage and boundaries
  5. Create contribution/review model
Common misuse

A Figma component library alone is not a design system.

Prototype

Clickable prototype

Link screens to simulate navigation and basic interactions.
Use it when

Use to test comprehension, navigation and flow cheaply.

Typical output

Testable simulated experience.

Time / effort

30 min-1 day

Tools

Figma, ProtoPie

How to do it
  1. Prototype only what needs testing
  2. Set realistic starting state
  3. Include important branches
  4. Use realistic copy/data
  5. Give users tasks, not a tour
Common misuse

Poor for complex data/model behavior.

Prototype

Coded prototype

Build real interaction logic, data states or model behavior.
Use it when

Use when behavioral fidelity matters more than static visuals.

Typical output

Functional proof-of-concept.

Time / effort

Hours-days

Tools

Cursor, Claude Code, Figma Make, local dev stack

How to do it
  1. Define the hypothesis
  2. Build only the critical path
  3. Use safe sample data
  4. Add realistic states and latency
  5. Test with users and engineering
Common misuse

Do not assume prototype code is production-ready.

Prototype

Wizard of Oz prototype

Let users experience automation while a human secretly operates part of the service.
Use it when

Use to test whether automation/AI creates value before building the full system.

Typical output

Evidence about desired automated behavior and value.

Time / effort

1-5 days

Tools

Prototype + manual operator

How to do it
  1. Define the behavior being faked
  2. Set safe boundaries
  3. Operate consistently
  4. Observe where users rely on the system
  5. Debrief appropriately
Common misuse

Be careful about research ethics and high-stakes deception.

Prototype

Concierge MVP

Deliver the proposed service manually and transparently.
Use it when

Use when you need to learn the workflow before automating it.

Typical output

Workflow knowledge and value evidence.

Time / effort

Days-weeks

Tools

Manual service tools

How to do it
  1. Choose a small customer set
  2. Perform the service manually
  3. Record every step and exception
  4. Learn what people value
  5. Automate only after patterns stabilize
Common misuse

Not scalable; that is the point.

Validate

Concept testing

Test whether a proposed idea or value proposition is understood and relevant.
Use it when

Use before detailed UI when the bigger question is “is this idea worth pursuing?”

Typical output

Concept comprehension, value signals and objections.

Time / effort

1-3 days

Tools

Concept boards, prototypes, interviews

How to do it
  1. Prepare 2-3 distinct concepts when possible
  2. Explain enough to understand, not sell
  3. Ask for interpretation
  4. Probe value and concerns
  5. Compare patterns across concepts
Common misuse

Do not use visual preference as proof of market demand.

Validate

Usability testing

Watch representative users attempt realistic tasks.
Use it when

Use whenever you need evidence that people can use the design.

Typical output

Observed usability issues, task outcomes and evidence.

Time / effort

5-8 sessions can reveal major issues in a focused flow; larger samples for measurement

Tools

Prototype, meeting tool, testing platform

How to do it
  1. Define tasks and success
  2. Recruit representative users
  3. Let them try without teaching
  4. Observe behavior and errors
  5. Ask follow-up questions after the task
  6. Prioritize findings
Common misuse

Do not turn the session into a demo or ask only “do you like it?”

Validate

First-click testing

Test where users click first for a given task.
Use it when

Use for navigation, hierarchy and page-level orientation.

Typical output

First-action success and attention clues.

Time / effort

A few hours-1 day

Tools

Maze, Optimal Workshop, static prototype

How to do it
  1. Show one screen
  2. Give one realistic task
  3. Record first action
  4. Measure correctness/confidence
  5. Investigate common wrong targets
Common misuse

Does not test the entire flow.

Validate

A/B experiment

Randomly compare variants on a measurable outcome.
Use it when

Use when you have enough traffic and a clear causal hypothesis.

Typical output

Causal performance comparison.

Time / effort

Days-weeks

Tools

Experiment platform, analytics

How to do it
  1. Write the hypothesis
  2. Choose one primary metric
  3. Check sample/traffic feasibility
  4. Change the minimum necessary
  5. Run to a valid stopping point
  6. Interpret with guardrail metrics
Common misuse

Do not use it to answer questions that require qualitative understanding.

Validate

Design critique

Structured peer review against goals, evidence and constraints.
Use it when

Use while work is still changeable.

Typical output

Sharper decisions and unresolved questions.

Time / effort

30-60 min

Tools

Figma, meeting

How to do it
  1. State context and decision needed
  2. Show evidence and constraints
  3. Ask targeted questions
  4. Separate problem feedback from solution preference
  5. Record decisions and open questions
Common misuse

Avoid taste-only feedback such as “I prefer blue.”

Measure

Funnel analysis

Measure progression and drop-off across key stages.
Use it when

Use for conversion, onboarding and multi-step journeys.

Typical output

Drop-off baseline and priority points.

Time / effort

1-4 hours

Tools

Analytics/BI

How to do it
  1. Define stages precisely
  2. Validate event tracking
  3. Segment by meaningful dimensions
  4. Find largest/strangest drop
  5. Investigate with qualitative evidence
Common misuse

A funnel tells where, not necessarily why.

Measure

Product metrics

Define measurable user and business outcomes such as activation, adoption, retention or task success.
Use it when

Use before launch and after launch.

Typical output

Success model for the feature/product.

Time / effort

1-3 hours

Tools

Analytics plan, dashboards

How to do it
  1. Choose the user outcome
  2. Connect it to a business outcome
  3. Pick leading/lagging metrics
  4. Define baseline and target direction
  5. Add guardrails
Common misuse

Avoid vanity metrics disconnected from user value.

Delivery

Design handoff

Transfer product intent, behavior, states and rationale into implementation collaboration.
Use it when

Use once a direction is validated enough to build.

Typical output

Shared implementation understanding.

Time / effort

Ongoing during build

Tools

Figma, Storybook, tickets, code

How to do it
  1. Review with engineering before finalizing
  2. Specify behavior, states and constraints
  3. Link reusable components
  4. Explain edge cases
  5. Keep questions open during build
Common misuse

Do not throw Figma over the wall.

Delivery

UX QA

Review the built experience for behavior, content, responsive, visual and accessibility quality.
Use it when

Use throughout development and before release.

Typical output

Implementation issues and fixes before launch.

Time / effort

Hours-days

Tools

Browser, device testing, issue tracker

How to do it
  1. Check critical flows in the real build
  2. Compare behavior, not just pixels
  3. Test responsive states
  4. Check keyboard/semantics
  5. Log issues by severity
Common misuse

Do not wait until the final day.

Delivery

Decision log

Record important product/design choices, evidence and trade-offs.
Use it when

Use for long projects, complex teams and repeated debates.

Typical output

Traceable product rationale.

Time / effort

10-20 min per major decision

Tools

Docs, Notion, tickets

How to do it
  1. Record the decision
  2. Capture why
  3. Link evidence
  4. Note trade-offs and owner
  5. Record what would cause reconsideration
Common misuse

Do not log every tiny pixel tweak.

No methods match this filter.
Worked Examples · See the reasoning applied

See how the right process changes with the problem.

Each example starts from a different uncertainty, so the first move and the methods change too. Notice what is deliberately skipped and what evidence actually moves the decision forward.

01
Conversion problem

Checkout completion suddenly falls

Weak startDo not redesign because it looks cluttered.
1

Check the funnel to locate the exact break

2

Segment by device, market, payment method and new/returning users

3

Inspect errors, support issues and recordings

4

Run a targeted heuristic/form review

5

Form a narrow hypothesis and experiment

A strong designer tries to explain the drop before changing the interface. If the problem is an unexpected fee plus a poor address-error state, brand exploration and personas are noise.

02
Enterprise UX

“This dashboard has too much information.”

Weak startDo not simply remove charts until it looks clean.
1

Identify user roles

2

Ask what decision each role must make

3

Separate daily, weekly and exception tasks

4

Organize information around decisions/actions

5

Prototype with realistic data and test scenarios

The key question is not “which chart looks better?” It is “what does this person need to notice, decide and do next?”

03
Information architecture

Users cannot find the right policy

Weak startDo not restyle the menu and call it solved.
1

Inventory the content

2

Look at search terms and failed searches

3

Use card sorting if grouping is uncertain

4

Use tree testing to validate hierarchy

5

Then test the visible navigation with realistic tasks

Card sorting helps reveal mental models; tree testing tests the hierarchy; first-click testing evaluates the visible interface. They solve different questions.

04
Accessibility

Automated scan says the form is fine, keyboard users disagree

Weak startDo not equate a scan score with accessible task completion.
1

Run keyboard-only task completion

2

Check visible focus

3

Review labels and announcements with a screen reader

4

Test error association and recovery

5

Check zoom/reflow, contrast and target size

Automation catches machine-detectable failures. Human evaluation is required to know whether the task actually works.

05
0→1 product

Build an AI-powered research assistant for clinicians

Weak startDo not start with chat UI or model choice.
1

Understand the clinical/research job

2

Identify where AI creates real advantage

3

Map sources, provenance and uncertainty

4

Decide what the AI may suggest vs do

5

Prototype the highest-risk behavior

6

Evaluate correctness, usefulness, latency and failure recovery

The design surface comes after the authority, evidence and risk model.

06
AI agent

AI schedules candidate interviews

Weak startDo not treat the chatbot as the product.
1

Define the burden being removed

2

Choose authority level: suggest / draft / prepare / act

3

Model missing data and time-zone conflicts

4

Design confirmation and undo for consequential actions

5

Evaluate harmful-error rate as well as task success

Low-risk: draft time slots. Medium-risk: prepare an invite for approval. Higher-risk: changing commitments without clear context or recovery.

Assignments · Take-homes, design challenges and interview tasks

Got an assignment? Decode the brief before you start designing.

Choose what your brief sounds like and get the literal first move, the ideal reasoning sequence, methods worth using, methods to skip, expected artifacts, language for explaining your decisions and a final readiness check. Depth changes rigor, not the order of thinking.

Classify the assignment by the uncertainty the company wants you to resolve, not by the number of screens they asked you to make.A polished Figma file can still answer the wrong question. Strong candidates show that they understood the hiring signal, separated evidence from assumptions, and chose methods deliberately.
Use this before opening Figma

Read the brief once without designing. Identify the problem state, the hiring signal, the evidence provided, and the expected output. Then choose the smallest credible process that answers the important uncertainty.

Ideal sequence

Open any step to see exactly how to do it.
Real assignment • PaisaPop

Existing end-to-end journey refinement - not a blank-sheet fintech app.

The supplied assignment asks the candidate to refine a provided mobile lending journey, improve aesthetic quality, interaction, hierarchy and IA, produce a prototype, a concise rationale, component states and a Loom walkthrough. The journey spans phone/consent, PAN, personal information, document upload, bank verification, employment/salary information, video/Aadhaar verification, review and an under-review state.

Primary type
Journey refinement / existing-flow UX + UI redesign
Hiring signal
Diagnosis, interaction design, visual craft, hierarchy, component/system thinking, communication
Modifiers
Fintech/KYC, mobile-web, sensitive data, high-trust/high-consequence
First move
Reconstruct the current-state journey before styling any screen.

Audit first

  • Progress and orientation across a long journey
  • Form comprehension, validation and error recovery
  • Consistency of verification states
  • Hierarchy of primary vs secondary actions
  • Trust/context around sensitive-data requests
  • Accessibility of labels, focus, errors and controls

Do not assume

  • That a field or verification can be deleted
  • That observed friction is a validated user pain point
  • That your redesign will increase conversion
  • That every regulatory/compliance rule is visible in the PDF
  • That a visual rebrand is the assignment
  • That random classmates equal representative borrowers

Strong methods

  • Current-state task-flow / journey inventory
  • Focused heuristic evaluation
  • Cognitive walkthrough + form friction audit
  • State/error/edge-case mapping
  • Lightweight competitive/pattern scan
  • Prototype + task-based usability validation where feasible
High-trust domain rule

Separate UX observations from legal or compliance claims. If a requirement affects consent, KYC, underwriting, data use or an irreversible financial action and the assignment does not specify the rule, label it “requires product/compliance confirmation” rather than inventing a requirement.

Final readiness check

Before you hit Send.

This combines universal checks with items specific to the assignment type and context you selected above.

Research basis for this section: public design-hiring guidance from Intercom, Atlassian, Shopify, Slack and Spotify; UX method guidance from Nielsen Norman Group; accessibility guidance from W3C/WAI; human-AI guidance from Microsoft HAX; relevant RBI digital-lending context for the PaisaPop example; and the supplied PaisaPop Journey Overview. The handbook treats external context as context - not as a substitute for evidence inside the assignment.

AI Product Practice How product design expands when intelligence becomes part of the workflow and the product
Read early. Build progressively.

Design with AI. Then design products that think, talk and act.

Two shifts are happening at once. AI changes how designers make products, and it changes what users interact with. Learn those shifts separately, then combine them with the product judgment you already use.

When should you start? Start using AI as a craft multiplier as soon as you can judge the quality of your own work. Move into conversational, generative and agentic product design once you can frame a problem, structure flows and states, prototype critical behavior, validate a risky assumption and explain trade-offs with evidence.

Foundation checkpoint

You do not need mastery. You need enough craft to know when AI is helping your judgment and when it is replacing it.

Use this as a readiness check, not a gate. If these foundations are usable, begin the progression below and strengthen them in parallel.

01FrameTurn a vague request into a user problem, outcome and explicit assumptions.
02StructureMap tasks, states, errors and recovery before polishing the surface.
03ValidateChoose a credible way to test the riskiest assumption.
04ExplainDefend trade-offs with evidence instead of taste or tool output.
If these are usable, start here.Learn the progression in order. The tools will change faster than the interaction principles.
01
Learning direction

Five layers to learn, in the order they become useful.

01
WORKFLOW

Design with AI

Use models and coding agents to accelerate research processing, critique, exploration, content and prototyping without outsourcing the decision being evaluated.

Learn Context framing · source discipline · critique loops · AI-assisted prototyping · vibe coding · design engineering
Proof of practice A faster functional prototype plus a clear record of what the AI produced, what you changed and why.
02
INTERACTION

Conversational and multimodal UI

Design turn-taking, clarification, memory, files, voice, images and generated responses as a real interaction system, not a chat-shaped mockup.

Learn Intent · dialogue flow · clarification · history · memory visibility · streaming · uncertainty · fallback
Proof of practice A conversation flow that handles ambiguity, interruption, correction, failure and mode switching.
03
ASSISTANCE

Copilots, generative UI and adaptive interfaces

Move AI inside the user’s existing workflow. Decide when it should suggest, draft, transform content, generate UI or adapt the experience while the user remains meaningfully in control.

Learn Progressive assistance · steering · provenance · generated states · direct manipulation · adaptive behavior
Proof of practice A before-and-after workflow showing exactly where AI reduces work and where human review remains valuable.
04
AUTONOMY

Agentic AI

Design systems that can plan, use tools and take multi-step action. The core design object becomes the authority model, not the chat box.

Learn Tool use · plans · progress · permissions · approval · stop · undo · exceptions · audit trail · blast radius
Proof of practice An authority map plus an action-state model that shows what the system may do, when it must ask and how recovery works.
05
QUALITY

Evals, trust and behavior governance

Move beyond a convincing demo. Define good behavior, unacceptable behavior and repeatable scenarios that reveal regressions before users do.

Learn Evals · failure taxonomy · human review · observability · regression · trust calibration · guardrails
Proof of practice A compact eval set, failure matrix and behavior specification tied to product outcomes.
02
Vocabulary without confusion

Know whether a term describes your workflow, the interface, or the underlying system.

HOW DESIGNERS WORK

Workflow and making

Design with AI
Using AI to assist reasoning, exploration, content, prototyping or production.
AI-assisted design
A broad label for AI-supported design work. The designer still owns the decision.
Vibe coding
Using coding agents to create or modify software primarily through natural-language direction and iterative review.
Design engineering
Working across design and implementation so interaction ideas can be tested in functioning code.
WHAT USERS EXPERIENCE

Interface and product paradigms

Conversational UI
Interaction organized around turns in text, voice or multimodal conversation.
Copilot
AI assists inside a task while the user remains the primary decision-maker.
Generative UI
The interface or its content is composed dynamically in response to context and intent.
Multimodal UX
Users move between text, voice, images, files, camera, gesture or direct manipulation.
Adaptive interface
The experience changes based on context, behavior or inferred need.
WHAT THE SYSTEM CAN DO

System capabilities

Context and memory
Information the system can use now and information that may persist across interactions.
Tool use
The model can call software, search, APIs, files or other systems to complete work.
Agentic AI
The system can pursue a goal through multiple steps, tool calls and decisions within defined boundaries.
Autonomy
How much action the system may take without immediate user confirmation.
Evals
Repeatable tests used to measure whether intelligent behavior meets the intended quality bar.
03
When the system can act

Design a control loop, not an overlapping orbit diagram.

SuggestUser acts
DraftUser edits
PrepareReady to execute
Act after approvalExplicit confirmation
Act within boundariesScoped authority
AutonomousHighest trust requirement

The higher the consequence and the harder an action is to reverse, the stronger the need for visible scope, permission, progress, review, stop, undo and escalation.

04
Evaluation is part of the interface

Design the behavior spec before you trust the demo.

05
Assignments and portfolios

Show judgment, not tool fluency.

IF THE BRIEF ALLOWS AI

Use acceleration deliberately

  • Clarify the brief and surface assumptions.
  • Critique your own flow for edge cases.
  • Explore content and interaction variants.
  • Build realistic functional prototypes faster.
  • Document what AI helped with and what you decided.
IF THE BRIEF LIMITS AI

Protect the work being evaluated

  • Do not generate the core visual concept when prohibited.
  • Do not invent research findings or user quotes.
  • Do not outsource unique branding the assignment asks you to originate.
  • Do not present generated reasoning as observed evidence.
  • Follow the company’s disclosure rules exactly.

The portfolio signal is not that you used the newest tool. It is that you expanded what you could test while keeping authorship, evidence and accountability clear.

About

Why this handbook exists.

Fresh designers are often taught a procession of artefacts - persona, journey map, user flow, wireframe, prototype, usability test - as if each brief requires every step. Real product work is messier. A two-hour expert review may be the correct response to one brief; several weeks of discovery may be irresponsible to skip on another.

The editorial principle here is simple: choose methods based on the uncertainty and consequence of the decision. The handbook therefore treats process as a routing problem rather than a ritual.

The goal is not to look like a designer doing UX. The goal is to help the team make a better product decision.

The advanced learning track, AI Product Practice, extends the same product-design judgment into workflows and products shaped by models, conversation, generation, tool use and bounded autonomy. It is intentionally positioned after the foundations because faster execution is only useful when the designer can frame the right problem, recognize uncertainty, preserve human control and evaluate behavior with discipline.

Ashutosh Gupta - Editor

A product and UX design practitioner working across complex digital products and multidisciplinary teams. This edition reflects a practice-oriented view of design: understand the problem deeply, connect user value with product outcomes, choose process deliberately, collaborate early with engineering and product, and use emerging AI tools to increase learning speed rather than merely produce more screens.

Resources · Trusted learning banks

When you get stuck, go to the source that answers the kind of uncertainty you have.

College teaches concepts. Early practice gets difficult when you have to decide which concept applies now, how deeply to use it, and what good execution looks like. These seven knowledge banks are useful when you need a reliable next reference rather than another random design post.

Before opening a resource, name your question. “Do I need research?” “Is this a usability problem?” “What is the platform convention?” “How should this form behave?” “Is this accessible?” The clearer the question, the more useful the reference becomes.
01

Nielsen Norman Group

One of the most useful bridges between UX theory and day-to-day product decisions. Its library covers usability heuristics, research-method selection, journey mapping, interviews, testing, information architecture and interaction principles.

Go here whenYou know the UX problem broadly, but you are unsure which method to use or how to evaluate an interface rigorously.

nngroup.com

02

GOV.UK Service Manual + GOV.UK Design System

A practical example of research, content, service design, prototyping, delivery and interaction patterns working as one operating system. Particularly strong for forms, long journeys, error recovery and designing around real user needs.

Go here whenYou need to turn classroom methods into an end-to-end product or service workflow and want concrete patterns with rationale.

gov.uk/service-manual · design-system.service.gov.uk

03

W3C Web Accessibility Initiative

The standards-backed place to understand accessibility beyond contrast scores. Use its WCAG material, tutorials and design guidance for structure, forms, keyboard interaction, semantics, feedback and inclusive content.

Go here whenYou need to know whether an accessibility decision is a preference, a best practice or a standards requirement.

w3.org/WAI

04

Apple Human Interface Guidelines

Apple’s platform guidance for hierarchy, layout, accessibility, navigation, components, input and interaction conventions across its ecosystem.

Go here whenYou are designing for iOS, iPadOS or macOS and need to distinguish a clever custom idea from a platform-native interaction.

developer.apple.com/design/human-interface-guidelines

05

Material Design 3

Google’s design system is useful for understanding component anatomy, interaction states, layout, adaptive patterns and consistent UI behavior at scale.

Go here whenYou are uncertain about component states, interaction feedback, responsive behavior or how a visual system becomes a usable product system.

m3.material.io

06

Interaction Design Foundation

A broad learning library that connects foundational concepts such as research, usability, interaction design, information architecture and design thinking with structured explanations and examples.

Go here whenYou remember the term from college but need to rebuild the concept, understand where it fits and compare it with adjacent methods.

interaction-design.org/literature

07

IBM Carbon Design System

A mature enterprise design system with detailed guidance for components, content, accessibility and states. It is especially useful for seeing how design decisions are documented for teams that must ship consistently.

Go here whenYou are moving from isolated screens to enterprise workflows, reusable components, state matrices and design-system thinking.

carbondesignsystem.com

Use knowledge banks as decision support, not as authority theatre. Cite the principle that changes your decision. Do not add frameworks or jargon simply because a respected source contains them.