Example
How to run product-design discovery without turning interviews into a pitch
Tess's problem is not a lack of effort. It is that Leave discovery with one chosen problem, visible contradictory evidence, and a next-sprint ask that is not secretly a dashboard by default has outgrown scattered reminders, tabs, and memory. This fictional playbook shows a concrete Board, the Cards inside it, one consequential Room, and the line Ava does not cross.
This fictional example was created with AI assistance from a structured editorial brief and reviewed by the You.one Editorial Team for usefulness, distinctness, and product truth.
Tess is an explicitly fictional portrait, not a customer or testimonial.
The Discovery month Board gives one mission a visible field; the Choose next sprint’s problem Room keeps its evidence, conversation, state, and decision together.
Current Superboard provides the durable structure and explicit, bounded Ava paths described here; broader proactive or external work is not a current promise.
Tess's pressure is ordinary—and still heavy
Tess is a fictional 31-year-old product designer on a four-week discovery in San Francisco, California. Tess has eight interviews, a stakeholder who already wants a dashboard, and an engineer asking what to build next sprint. Notes are in a doc. Clips are in a drive. The problem is still a pile of pain.
Tess can synthesize. If the stakeholder’s solution becomes the brief, the interviews were theater.
Interview notes, a slide of quotes, and a sprint board all want to be the brief.
Two interviews contradict the dashboard. Those notes are in a different doc than the one being prettied for Friday.
A requested dashboard is not the problem statement
The mission is specific: Leave discovery with one chosen problem, visible contradictory evidence, and a next-sprint ask that is not secretly a dashboard by default
The consequential choice is not something a board or an AI should quietly make: Whether the next sprint tests a scheduling pain, a handoff pain, or pauses build to run three more interviews
That distinction matters. Superboard can make the work, evidence, waiting, and decision visible. Tess still owns the purpose, tradeoff, and final call.
Available today
Discovery month: one Board shape to adapt
A useful Board gives this mission one durable operating picture. Tess does not have to convert life into project-management jargon or decide the perfect taxonomy first. Lists separate kinds of attention; Cards keep each meaningful item visible and movable.
The Cards are deliberately mixed. Some are tasks, some are decisions, some hold a person or promise, and some are reference points. Current Superboard supports that flexibility without flattening the mission into one long to-do list.
| List | What belongs here |
|---|---|
| Mission | Four weeks and the no-solution-first rule |
| Evidence | Interviews and clips with sources |
| Tensions | Contradictions that must stay visible |
| Problem candidates | Problems, not features |
| Waiting | Remaining interviews and stakeholder review |
Available today
The Cards make the operating picture concrete
A Board becomes useful when the Card titles sound like the actual situation. These are not generic placeholders; they show what Tess would need to see to run this mission without carrying every open loop in memory.
| Card | List | Job |
|---|---|---|
| Choose a problem, not a dashboard | Mission | Keep the stakeholder request visible as a request, not as the brief |
| Choose next sprint’s problem | Problem candidates | Compare scheduling pain, handoff pain, and more-interviews options |
| Interview 6 contradicts the dashboard | Tensions | Keep inconvenient evidence on the same Board as the pretty slide |
| Stakeholder: we need a dashboard | Waiting | Hold a solution ask until a problem is chosen |
| Clip: night-shift handoff | Evidence | Attach a clip to a person and a date |
| Engineer ask: what do we build | Problem candidates | Translate a sprint question into a problem choice, not a feature list |
Available today
Available today: Choose next sprint’s problem becomes a Room
Opening the Card gives the visible item durable depth. Stage can hold Problem-choice brief: Place contradictory interviews, the dashboard request, and the three problem paths on one page. Chat keeps the request and response beside that artifact instead of in a detached thread. Pulse can show Waiting for Tess to choose which problem next sprint is allowed to touch. Activity preserves the attributable Card record supported by the current product.
A useful Card Chat request would be: “Using only this Board, compare scheduling pain, handoff pain, and pausing to interview more. Do not write a spec or choose for me.” When live AI is configured, current Ava can respond to an explicit Card mention using supported context and can make limited reversible product changes. She does not deeply reason over the whole Board by default, and she does not gain authority over the decision merely because the context is organized.
Tess's call remains explicit: Tess chooses the problem, talks to stakeholders and engineers, and owns what gets designed
| Surface | Job in this example |
|---|---|
| Stage | Problem-choice brief: Place contradictory interviews, the dashboard request, and the three problem paths on one page |
| Chat | Keep Tess's request and Ava's attributed response with the work |
| Pulse | Waiting for Tess to choose which problem next sprint is allowed to touch |
| Activity | Preserve attributed Card changes and the supported record around the request |
What to ask Ava—and what not to assume
These are useful requests to adapt, not claims that current Ava automatically surveys the whole Board, prepares every comparison, or follows up on her own. The relevant facts must be present in supported Board/Card context, and the human still checks the result.
Tess owns synthesis, stakeholder conversations, and design judgment. Ava does not interview users, write specs, or pick the problem.
The modest outcome is not that Ava lives Tess's life. The modest outcome is a chosen problem: the dashboard remains a request, the contradicting interview stays visible, and next sprint has a job.
- Request idea: summarize evidence, tensions, and problem candidates already on the Board
- Request idea: compare next-sprint options using contradictory notes Tess captured
- Request idea: help keep solution requests in Waiting until a problem is chosen
A quotes slide plus a sprint board may still be enough
A quotes slide plus a sprint board is enough when the problem is already agreed
It starts to break when contradictory interviews and a requested dashboard both want to be the brief
Superboard earns a place only when the responsibility needs a durable picture around the list: the reason, artifact, conversation, current state, decision, and history.
A starter recipe to adapt, not obey
Use the names that already make sense in Tess's world. The recipe is successful when the Board reduces remembering and exposes the real decision—not when every Card is perfectly categorized.
| Step | Action |
|---|---|
| 1. Capture evidence with sources | Clips and notes, dated |
| 2. Put contradictions on the Board | Do not hide them in the other doc |
| 3. Separate requests from problems | A dashboard is a request |
| 4. Name problem candidates | Pains, not features |
| 5. Choose before sprint | Open a Room instead of letting the slide decide |
Direction
Direction, not a current promise
Later, Ava may help this Board notice when a sprint ask has no chosen problem Card, still leaving every product call with Tess.
The unified You.one and Superboard runtime, cross-product personalized Memory Spine, broad proactive coordination, realtime shared editing, and general external execution are not available today. Future actions would still require the applicable capability, connection, grant, and human authority.
What this realistic example does not claim
- Tess is fictional and is not a customer, testimonial, research participant, or disguised real person.
- This is not a user-research finding or a product-market claim.
- It does not show Ava interviewing users or writing a specification.
- It is not a measured product result.