Product Design & UX

Kaern Schools — Professional Track

Tutor: Iris Vandenberg, Lead Product Designer in residence

Format: 7 modules · in-class lessons · worked examples · hands-on studio time · capstone

Reference products: cycleWASH machines (Mini Platinum, Pro Platinum), the cyclewash.com and kaernschools storefronts, and the internal tools CyclePanel (operator dashboard) and cycleCAD (configurator).

---

Welcome from Iris

Hello, and welcome. Take a seat anywhere you like — I promise the front row doesn't bite.

For the next seven modules we are going to walk the entire road a product experience travels: from the very first confused customer standing in front of a bicycle washing machine, all the way to a shipped, measured, accessible product that people actually love to use. I've spent fifteen years doing this work — in agencies, in-house, on hardware and on software — and the one thing I want you to leave with is not a pile of techniques. It's judgment. Techniques are cheap; knowing which one to reach for, and when to put it down, is the whole job.

We'll keep our feet on the ground by using real products you can go and touch. When I say "imagine a user," I want you picturing a specific person at a specific cycleWASH machine in the rain, not an abstraction. Design lives in specifics.

Let's begin.

---

How this course works

| Element | What it is | |---|---| | Learning objectives | What you should be able to do by the end of the module | | Lessons | Iris teaches; each has a script, a worked example, and an exercise | | Worked example | A real cycleX product or storefront, designed in front of you | | Hands-on exercise | Studio time — you do the work | | Common mistakes | The three traps I see every single cohort fall into | | Check for understanding | Quick questions to prove the idea landed | | Capstone | One end-to-end project tying all seven modules together | | Rubric | Exactly how your capstone is assessed |

A note on tools: bring a pen and index cards. We do a lot on paper before anything touches Figma. Paper is the cheapest prototyping material ever invented, and it has never once crashed.

---

Module 1 — User Research & Problem Framing

Learning objectives

• Distinguish a problem from a solution and resist jumping to the second.
• Plan and run a generative interview without leading the participant.
• Synthesize raw research into personas, jobs-to-be-done, and a sharp problem statement.
• Choose the right research method for the question you actually have.
• Write a "How Might We" framing that opens design space rather than closing it.

---

Lesson 1.1 — Falling in love with the problem

Teaching script (Iris speaks):

"Right. First rule, and write it on the inside of your eyelids: fall in love with the problem, not your solution. Every designer in this room has, at some point, walked into a kickoff already knowing the answer. 'We need an app!' 'We need a bigger button!' And we spend three months building the wrong thing beautifully.

Here's why it matters. A solution is an answer to a question — and if you never examined the question, you're answering by luck. Think about our cycleWASH customer. A bike shop owner doesn't wake up wanting a 'fully-automatic washing system.' She wakes up because returned rental bikes are filthy, her one staff member spends two hours a day scrubbing chains, and customers complain the bikes smell. That is the problem. The machine is one possible answer. So is hiring a cleaner. So is a different rental contract.

When you frame the problem honestly, you keep all those doors open long enough to pick the best one. The analogy I love: a problem statement is a doorway, not a hallway. A good one lets many solutions walk through; a bad one is so narrow only your pet idea fits.

So before you sketch a single screen — what is the problem you think you're solving, and how confident are you that it's the real one?"

Worked example — cycleWASH Pro Platinum: The sales team's brief was "make the touchscreen easier." Research reframed it: operators weren't confused by the screen — they were anxious about damaging customer bikes during the cycle. The real problem was trust and visibility, not button layout. That reframing later produced the CyclePanel live-cycle camera view, not a screen redesign.

Hands-on exercise: Take any cycleX product. Write the brief as a solution ("add X"), then rewrite it three times as problems at increasing depth using "5 Whys." Bring your deepest problem statement to studio.

Common mistakes:

1. Writing the problem statement with the solution already baked in ("Users need a faster checkout button").
2. Researching to confirm a decision already made (confirmation theater).
3. Treating the loudest stakeholder's opinion as user data.

Check for understanding:

1. Why is "we need a configurator" a poor problem statement?
2. Give a one-sentence problem statement for a customer who can't tell whether the cyclewash.com checkout accepted their order.

---

Lesson 1.2 — Interviews that don't lie to you

Teaching script (Iris speaks):

"The interview is the most powerful and the most dangerous research tool you own. Powerful because nothing beats a real human telling you their real frustration. Dangerous because it is terrifyingly easy to make them tell you what you want to hear.

The cardinal sin is the leading question. 'Don't you think the Mini Platinum is easy to set up?' — congratulations, you've just taught your participant the answer you're hoping for, and politeness will do the rest. Instead: 'Walk me through the last time you set up a piece of equipment in your shop.' Notice the difference? Past behavior, not hypothetical opinion. People are wonderful storytellers about what they did and unreliable prophets about what they would do.

My favorite technique is the awkward silence. After they answer, count to three in your head before you speak. Nine times out of ten they'll fill the gap with the real answer — the one underneath the polite one. Silence is a tool. Get comfortable being a little uncomfortable.

And record the exact words they use. When a shop owner says the rental bikes are 'gross,' do not translate that into 'suboptimal hygiene.' Their words are gold; your paraphrase is fool's gold.

So: think of a question you'd want to ask a cycleWASH operator — is it about what they did, or what they think? And can you make it the first kind?"

Worked example — cyclewash.com storefront: Five interviews with bike-shop buyers. Instead of "Is the site easy to use?", the script asked "Tell me about the last B2B machine you bought online." Three of five described leaving a site because shipping cost to their country was hidden until the final step. That single recurring story drove the storefront's "shipping estimate on product page" feature — a finding a satisfaction survey would never have surfaced.

Hands-on exercise: Write a 6-question generative interview guide for a CyclePanel operator. Pair up, run it for 10 minutes, then swap. Afterward, highlight every question your partner asked that was secretly leading.

Common mistakes:

1. Asking about the future ("Would you use…?") instead of the past ("When did you last…?").
2. Talking more than the participant (aim for 20% you / 80% them).
3. Stopping at the first answer instead of probing with silence or "tell me more."

Check for understanding:

1. Rewrite "Do you find the configurator confusing?" as a non-leading question.
2. Why are past-behavior questions more reliable than opinion questions?

---

Lesson 1.3 — From raw notes to a sharp frame

Teaching script (Iris speaks):

"You've done your interviews. You have forty pages of messy notes and a slightly panicked feeling. Good — that's the right amount of mess. Now we synthesize, which is just a fancy word for finding the patterns that were always there.

We use affinity mapping. Every observation goes on its own sticky note — one idea per note, in the participant's words. Then we cluster: notes that feel related drift together, and slowly, themes emerge that you did not decide in advance. That bottom-up discovery is the point. If you walk in with five named buckets, you'll just sort notes into your assumptions.

Out of those clusters we build three artifacts. A persona — a believable archetype, like 'Marta, the rental-shop owner who values uptime over features.' A job-to-be-done — 'When my rental bikes come back filthy, I want them cleaned in minutes so I can re-rent them same-day.' Notice the job has no product in it; that's deliberate. And finally a How Might We — 'How might we let Marta return a bike to rentable condition without tying up staff?'

That HMW is your doorway again. Wide enough for many ideas, narrow enough to aim. So when you cluster your notes — are your themes things you expected, or things the data insisted on?"

Worked example — Mini Platinum: Affinity mapping of compact-shop interviews produced the persona "Marta," whose dominant job was uptime, not thoroughness. This reframed the Mini Platinum's UX around a single prominent "Quick Cycle" button rather than the granular program menu the engineers had specced — directly traceable to clustered notes about same-day re-rental pressure.

Hands-on exercise: Using your Lesson 1.2 interview notes, run a 20-minute affinity map. Produce one persona, one JTBD (no product words allowed), and one HMW.

Common mistakes:

1. Pre-deciding the clusters (top-down sorting instead of bottom-up discovery).
2. Personas that are demographic trivia ("32, likes coffee") instead of behavioral ("optimizes for uptime").
3. JTBD statements that secretly name a product ("…wants to use the washing machine").

Check for understanding:

1. What's wrong with the JTBD "When bikes are dirty, the user wants to use the Pro Platinum"?
2. Why one idea per sticky note?

---