The way Intelligaia does UX.

1.1 Where the term came from

The term user experience was coined by Don Norman in the early 1990s, when he joined Apple as a "User Experience Architect." Norman was a cognitive psychologist frustrated that the field had no name for what he was practising — designing not just the product, but everything around it: the packaging, the unboxing, the moments of confusion, the small wins.

His point was simple: a user doesn't experience a product in isolation. They experience it inside their life. UX is the design of that whole experience.

1.2 UX vs UI vs Product Design

These terms get confused constantly. Here's the clean distinction:

• UX is the overall experience — how the product feels to use, end to end. Research, problem-framing, flows, content, interactions, and the visual surface.
• UI is one part of UX — the visual and interactive surface. Colours, typography, buttons, icons, layouts.
• Product design is UX done inside a product team — responsible not just for the experience but for the product's success in the market.

If UX is the entire meal, UI is the plate it arrives on. The plate matters — but it's not the meal.

1.3 Two myths to retire on Day 1

1.4 Why UX matters in business

UX is not a cost. It's an investment that pays back in three ways: fewer support calls (when the product is clear, fewer people get stuck), higher conversion and retention (people stay if they're not frustrated), and shorter development cycles (testing prototypes is cheaper than testing built features).

Companies that take UX seriously consistently outperform those that don't. That's not opinion — it's measured in dozens of studies (Forrester, McKinsey, Stanford, all show the same pattern). When you join a UX team, you're not just designing — you're saving the business money and time, and earning users' trust.

1.5 Norman doors are everywhere

A Norman door is a door whose handle suggests one action (pull) but the door requires another (push). They're famous because they teach a deep UX lesson: when a product is hard to use, it's not the user's fault — it's a design failure.

• The microwave button that does two things depending on how long you hold it.
• The form that says "submit" but doesn't tell you what happens next.
• The volume control that's too small to grab on a phone.
• The close button that's three pixels wide.

2.1 The shape of the 5D process

Five phases, in order, with an explicit evolution moment at the end of each — a checkpoint where the team reviews what was learned, sharpens the direction, and decides what carries forward.

2.2 What each phase is for

• Discover — understand the product, the business, and the user. No designing yet. This is where you build the context that everything else depends on.
• Define — synthesise Discover into a sharp problem statement, personas, and journey maps. Narrow from "we know a lot" to "we know what to solve."
• Design — ideate, sketch, wireframe, mock up. Move from the problem to a real, visible solution.
• Develop — turn designs into interactive prototypes, components, and design tokens. Make it real enough to test.
• Deliver — test, iterate, hand off to engineering, launch, measure. The phase that turns "good design" into "shipped product."

2.3 The evolution moment at the end of each phase

This is what makes 5D different from a checklist. At the end of every phase, the team pauses for an evolution review — a short, structured conversation:

• What did we learn that we didn't know before?
• What changed about our hypothesis?
• What do we carry into the next phase, and what do we drop?

Skipping evolution is the most common reason design projects drift. Discover into Define without evolution and you carry every assumption forward unexamined.

2.4 5D is iterative, not linear

The diagram looks linear. In practice, you'll cycle through 5D many times — once at the start of a project (long), and many times during the project (short, focused sprints on specific features). The phases are tools, not steps on a Gantt chart.

3.1 What Discover is for

Discover answers three questions before any design starts:

1. What is the product, really? Not the marketing version — the actual product, the actual business model, the actual stage of maturity.
2. What is the business context? Who are the stakeholders, what are the constraints, what does success look like?
3. Who are the users, really? Not "everyone" — the specific people, their actual pain, their existing workarounds.

If you can't answer these three questions in sharp sentences after Discover, you haven't finished Discover.

3.2 Product overview — going wide on the product

Start with the basics. Get these on paper before you do anything else:

3.3 Business context — who else is in the room

Most design failures aren't design failures — they're stakeholder failures. The design might be right, but it gets killed in review because the team didn't surface a constraint earlier.

Stakeholder map

List every person who has a say in this product. For each, capture:

• Their role — founder, PM, engineering lead, customer success, legal, marketing, investor.
• Their goals — what does success look like for them, specifically?
• Their veto power — what can they say "no" to, and what's the cost of overriding them?

Business goals vs product goals

These are not the same. Business goal: "Grow paid subscribers by 30% this quarter." Product goal: "Reduce drop-off in the signup flow." A good designer connects the two — the product goal is the lever that moves the business goal.

Constraints

Capture what you can't change before you start designing:

• Time — when does this need to ship?
• Budget — what's the team size, the engineering capacity?
• Tech — what platform, what existing systems must we work with?
• Regulatory — finance, health, government products have strict compliance rules.
• Brand — fonts, colours, voice — what's locked?

Constraints aren't enemies. They're the boundary of the puzzle. Pretending they don't exist just means you discover them late.

3.4 Target audience — going deep on the user

"The user" is the most expensive lie in product design. There is no "the user." There are specific users with specific lives, and your job is to find them.

User segments

Most products have 2–4 meaningful user segments. For a school lunch app, that might be: students placing orders, parents paying, school admins managing menus. Don't try to design for all of them at once — pick one segment as your primary.

Pain points (where to dig)

For each segment, find the real pain — not the polite pain people tell surveys, but the real friction that makes them swear at their phone. Ask in interviews:

• "Walk me through the last time you used something like this."
• "Where did you get stuck, even if just for a moment?"
• "What did you do as a workaround?"

Workarounds are gold. If a user has a hack — a spreadsheet on the side, a screenshot kept on the desktop, a sticky note on the monitor — that's a sign the product isn't solving their real problem.

Goals and motivations

People don't use products. They use products to do things. For each segment, capture what they're trying to accomplish — at the task level (book a doctor) and at the life level (feel in control of my family's health).

Behaviour patterns

Notice how they actually use products in their category today. Mobile-only? Mostly during commutes? In a hurry, or relaxed? With kids in the room? These details shape every screen you'll design.

3.5 Discover methods

• Stakeholder interviews — 30–45 min with each key stakeholder. Same five questions, different answers — that's where misalignment surfaces.
• User interviews — 30 min with 5–8 users per segment. Open questions, story-based.
• Field observation — watch users in their natural environment. Sometimes 30 minutes of observation beats 3 hours of interviews.
• Competitive audit — what do the top 3 competitors do well? Where do they fail? Look for patterns nobody breaks.
• Analytics review — if the product is live, the existing data tells you where users actually go vs where the team thinks they go.
• Heuristic baseline — quick Nielsen-style audit of the existing product. Cheap, fast, surfaces low-hanging issues.

3.6 Outputs of Discover

At the end of Discover, you should have a Discover brief — a short document (not a slide deck — a document) that captures:

1. Product overview (domain, what it does, business model, stage)
2. Stakeholder map with veto power and goals
3. Constraints (time, tech, regulatory, brand)
4. Top 2–3 user segments with pain points, goals, behaviours, current workarounds
5. Top 3 hypotheses (what you think the real problem might be) — to test in Define

Then the evolution moment: review with the team. What surprised you? What did you assume that turned out to be wrong? Carry those answers into Define.

4.1 Types of research

Define is mostly about synthesising the research from Discover. But it helps to know what kind of research you have:

• Generative — opens up the problem space. Interviews, observation, diary studies. Used early.
• Evaluative — tests a specific design or hypothesis. Usability tests, A/B tests, surveys. Used later.

• Qualitative — words, stories, observations. Tells you why.
• Quantitative — numbers, frequencies, percentages. Tells you how many.

Mix them. Qualitative without quantitative is anecdote. Quantitative without qualitative is numbers without meaning.

4.2 Synthesising research

Affinity mapping

Take every note, observation, and quote from Discover. Put each on a sticky (digital or physical). Cluster them by theme. Don't pre-decide the themes — let them emerge from the stickies. After 30–60 minutes of clustering, you'll see 5–8 patterns you didn't see in any individual interview.

Finding themes

For each cluster, write a short theme statement. "Parents check the app multiple times before the appointment because they don't trust the ETA." One sentence, specific.

From themes to insights

Themes describe what's happening. Insights explain why and what to do. Theme: "Parents check the app multiple times." Insight: "Trust isn't built by the app's claim — it's built by visible progress signals that match real-world cues." That's the kind of insight that drives design choices.

4.3 Personas — hypothetical and real

Hypothetical (early-stage)

When you don't have research yet, you build hypothetical personas from logic and existing knowledge. They're guesses. Label them as such. Use them as scaffolding — but plan to replace them with data-grounded personas after research.

Data-grounded

After Discover, replace your guesses with personas built from actual interview patterns. A good data-grounded persona names:

• Behaviour — what they do, when, how often.
• Goal — what they're trying to accomplish (at the task and life level).
• Pain — what's friction-y about their current solution.
• Workaround — what they do today to compensate.
• Quote — one verbatim line from a real interview that captures their voice.

4.4 Problem statements

The artefact that earns its weight in every Define phase. The formula:

For [user], [task] is [problem] because [reason]. We want it to be [outcome].

If your problem statement is more than two sentences, it's too broad. If it doesn't name a real user, a real task, a real cause, it's not done.

4.5 How Might We (HMW) questions

Once the problem is sharp, reframe it as an HMW to invite ideation. "How might we help first-time parents see their child's next vaccination without scrolling through three lists?"

HMW is open enough to invite many solutions, specific enough to keep you on track. It's the bridge from Define into Design.

4.6 Journey maps

A journey map plots a user's steps over time with three rows: action (what they do), emotion (how they feel), friction (what gets in the way).

Map the current state journey first — what happens today. Mark every friction. Then optionally map the ideal state journey — what could happen if the friction were gone. The gap between current and ideal is where the design opportunity sits.

5.1 Ideation — quantity beats quality early

Your first three ideas are almost always derivative. The interesting ones show up at idea #15. Generate many, prune later.

Crazy 8s: fold a sheet of paper into 8 squares. Set a timer for 8 minutes. Sketch 8 ideas. Some will be bad. That's fine — the bad ones unlock the good ones.

5.2 Information architecture

Before you arrange pixels, arrange the content. What screens exist? What's the hierarchy between them? What's the primary nav? What's hidden one level deeper?

A simple sitemap or flow diagram done early saves dozens of hours of rework later.

5.3 Wireframes — structure before style

A wireframe is the structural blueprint of a screen — what goes where, in what order, without colour or fancy typography. Just grey boxes, black text, clear hierarchy.

Working low-fi first is a feature, not a bug. Roughness invites criticism. People give honest feedback on a sketch they'd never give on a polished mockup.

5.4 The four principles — CRAP

From Robin Williams' design book:

• Contrast — make different things look different.
• Repetition — repeat visual elements throughout for cohesion.
• Alignment — every element should have a visual connection to another.
• Proximity — group related items, separate unrelated ones.

5.5 Visual hierarchy

Tell the user where to look first, second, third. Tools: size, weight, colour, space. If everything is emphasised, nothing is. Pick one element to be the loudest on every screen.

5.6 Typography

Type is 95% of design. Pair at most two typefaces — one for headings, one for body. Set a scale of 4–6 sizes and stick to it. Body text minimum 16px. Line length 50–75 characters.

5.7 Colour & contrast

A small palette beats a large one. One or two brand colours, one neutral scale, three semantic colours (success, warning, error). Body text contrast must hit WCAG AA (4.5:1) — non-negotiable.

6.1 Prototyping fidelity

Match fidelity to question. Testing flow? Low-fi clickable wireframes are enough. Testing visual polish or micro-interactions? High-fi is worth the time.

6.2 Interactive prototypes in Figma

• Frames as screens.
• Prototype connections between hotspots and target frames.
• Smart Animate for transitions that match real behaviour.
• Interactive components for hover/active/disabled states without manual setup.

6.3 Micro-interactions

Small motions and feedback signals that make a product feel responsive: button press states, loading shimmers, success checkmarks, gentle haptics. They communicate "the system heard you."

6.4 Components & variants

A component is a reusable design unit (button, input, card). Variants are different states of the same component (default / hover / disabled / loading). Build once, reuse everywhere. Edit the master, propagate to every instance.

6.5 Design tokens

Named design values that match what developers use in code. Tokens for colours (color/primary/500), type sizes (text/heading/lg), spacing (space/md), and radii. Tokens are the contract between design and code.

6.6 Design systems thinking

At scale, every project's components and tokens add up to a design system — a single source of truth across products. You don't need a full system on Day 1, but think in this direction: every component you build is a potential system contribution.

7.1 Nielsen's 10 heuristics

Jakob Nielsen's 1994 usability principles — still the cheapest design-quality check anywhere:

1. Visibility of system status — always show what's happening.
2. Match to the real world — speak the user's language.
3. User control and freedom — easy escape, undo.
4. Consistency and standards — same word, same colour, same place.
5. Error prevention — design out the conditions that cause errors.
6. Recognition over recall — show options, don't make people remember.
7. Flexibility and efficiency — let experts go fast, beginners go slow.
8. Aesthetic and minimalist design — every element earns its place.
9. Help users recover from errors — plain-language messages with a way out.
10. Help and documentation — searchable, focused on tasks.

7.2 Heuristic evaluation

Walk through your design. For every screen, check each heuristic. Note any violations with a severity rating (minor / major / critical). A solid heuristic eval takes 1–2 hours and surfaces dozens of issues. Do this before user testing — fix the obvious stuff first.

7.3 Usability testing

Give a user a real task. Watch them try to complete it. Take notes on where they get stuck. Five users find ~85% of major usability issues. Don't wait for a perfect test — small, frequent tests beat one big study.

Use the think-aloud protocol: ask them to narrate their thoughts. That narration is gold.

7.4 A/B testing basics

Once a product is live, A/B testing lets you compare two designs with real users. Useful for narrow questions (button copy, layout choices). Bad for big strategic questions — those need qualitative research.

7.5 The iteration loop

Test → learn → change → test again. Every product you respect today ran this loop thousands of times. The willingness to keep iterating is what separates products that get loved from products that get abandoned.

7.6 Handoff to development

A clean handoff includes:

• Organised Figma file — named layers, named frames, components.
• Written spec for any non-obvious interactions (especially edge cases and error states).
• Design tokens (colours, type, spacing) named consistently with code.
• A working prototype showing the intended flow.

The phrase to remember: "Design with the developer in the room." If they can't be in the room, write the spec as if they were.

7.7 Launch and measure

Shipping is not the end. Capture three metrics post-launch: task success rate, time on task, support ticket volume. They tell you whether the design worked. If it didn't, you're back to Discover — that's the loop.