The role changed
The title used to describe a generalist who could do a bit of everything visual: brand, marketing site, product UI, the deck the night before the raise. That person still exists — but the job underneath the title has been rebuilt, and both sides of the hiring table are working from outdated specs.
In AI products, the founding designer shapes behavior, trust, onboarding, and narrative — not just screens. Stated plainly: shape the product around the intent of its audience, design trust into every surface, keep the experience simple enough to protect user motivation, and write your design decisions down so that humans and coding agents build the same product.
Founder takeaway: you're not hiring "a designer." You're hiring a product partner who can make ambiguity usable.
Designer takeaway: your finished screens are the least persuasive evidence you own. Your reasoning, your writing, and your working prototypes are the most.
What founders actually need
Not a pixel department. A partner who can:
- Separate a cool AI demo from durable user value
- Design what happens when the model is wrong — not just when it's impressive
- Turn founder intuition into product structure
- Make the product easier to explain and sell, not just easier to use
- Work at founder speed, without a perfect brief
The scorecard
Rate a candidate — or yourself — 1–5 on each:
| Capability | What it looks like in practice |
|---|---|
| Product judgment | Separates "cool AI demo" from durable user value; knows what to design next and why |
| Systems thinking | Designs flows, states, edge cases, and feedback loops — not just screens |
| AI behavior fluency | Understands how model behavior changes UX, trust, and control; designs for wrong, slow, and partial outputs |
| Founder-speed execution | Makes useful progress in ambiguity without waiting for a perfect brief |
| Taste + craft | Makes an early product feel clear, credible, and emotionally right |
| Narrative skill | Helps the company explain what it is, who it's for, and why now |
| Shipping range | Moves between prototype, product, website, pitch, and onboarding |
| Writing for machines | Produces instructions — markdown skills, specs, conventions — that agents and developers build from faithfully |
| Research instinct | Knows what to validate before the team overbuilds |
A score below 3 on product judgment, AI behavior fluency, or writing is a real risk in a founding seat. Taste alone can't carry the role anymore.
Green flags and red flags
Green flags when hiring
- They ask about the user's job before suggesting UI.
- They want to see real prompts, outputs, failure cases, and edge states.
- They can explain how the product should behave when the AI is wrong.
- They care about onboarding, activation, and trust — not just interface polish.
- They turn founder intuition into product structure.
- They're comfortable with messy zero-to-one ambiguity.
- They can show you something they wrote that other people — or agents — built from.
Red flags
- The portfolio is mostly beautiful surfaces with little product reasoning.
- They treat AI as feature garnish instead of a behavior system.
- They over-index on "magic" and under-index on control, review, and recovery.
- They need a mature PM/brand/UX-writing function around them to do good work.
- They can't explain tradeoffs.
- They talk about "delight" before they understand the user's anxiety.
The interview kit
Questions that reveal the thinking
- "Show me a product decision you made with incomplete information."
- "Walk me through an AI experience where the model can be wrong. How would you design for that?"
- "How would you explain this product to a skeptical user in one sentence?"
- "What would you try to learn in the first two weeks?"
- "What would you not design yet?"
- "Where would you want founder input, and where would you push back?"
Example
what strong vs. weak sounds like
Ask: "How would you design for the model being wrong?"
Weak: "I'd add a disclaimer and a feedback button."
Strong: "Depends on the stakes. For a draft, I'd show sources and flag low-confidence claims inline. For an action, I'd stage the change behind a preview with one-step undo — and the error message should protect the user's work and offer a specific recovery, not apologize vaguely."
The weak answer decorates failure. The strong one designs it.
Portfolio prompts — ask candidates to bring:
- One messy early-stage project (not the polished case study)
- One example of simplifying a complex flow
- One example of product narrative or onboarding
- One example where they changed the team's mind
- One thing they wrote that others built from — a spec, a component doc, an instruction file
Go deeper: a trial project that actually predicts performance
Give them one real feature and realistic dummy data, and ask for two artifacts: a working vertical slice, and a one-page instruction file for how the feature should behave — states, voice, what must be reversible. Two things become obvious fast: whether they can make ambiguity usable, and whether their judgment survives being written down. Pay them for the work.
For designers: how to become this
Build proof in five areas:
- Product clarity — can you explain what the product does, who it's for, and why it matters?
- AI behavior design — can you design around uncertainty, confidence, user control, and recovery?
- Founder-speed execution — can you make useful progress without perfect inputs?
- Narrative and market sense — can you help the product become easier to sell, not just easier to use?
- Taste under constraints — can you make the product feel credible before the company has a full brand system?
Portfolio checklist
- Show the before/after, not just final screens
- Include the strategic problem — and what you clarified
- Show what you intentionally did not build
- Include product copy, flows, states, and decision logic
- Explain how AI behavior shaped the UX
- Include something you wrote that a team — or an agent — built from
Try this month: build one vertical prototype with an AI coding tool and feel where your Figma habits stop translating. Write an instruction file for a component you've designed — states, vernacular, what must never happen. Audit one AI product's trust surfaces until you can name exactly why you do or don't believe its outputs. None of this requires permission, a new title, or a bigger team.
The first 30 days
What good looks like after the hire:
Week 1 — understand the system. Talk to founders, engineers, users. Review the demo, deck, current product, and roadmap. Identify the core user job. Map the product's trust gaps.
Week 2 — clarify the product story. Tighten positioning. Define the primary user path. Identify the activation moment. Cut confusing concepts.
Week 3 — design the first usable version. Flows, states, and core screens. Prototype the key AI interactions in working code with realistic dummy data. Define failure and recovery patterns.
Week 4 — help the team ship and learn. Support the build — humans and agents. Test with users. Refine onboarding and product language. Translate learnings into next bets.
The real test
One question decides both the hire and the career: can this person make the product clearer, more trustworthy, and easier to ship? Everything else — tools, titles, taste — is in service of that.
The defining trait of a founding product designer hasn't changed: they don't wait for the product to be handed to them. They go build the missing parts. What's changed is which parts are missing.