Example
How to redesign a personal website without rebuilding it twice in the same month
Ivy's problem is not a lack of effort. It is that Ship a site that puts three case studies on the first screen before the talk, without requiring a new stack unless it fits the date 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.
Ivy is an explicitly fictional portrait, not a customer or testimonial.
The Site before the talk Board gives one mission a visible field; the Choose restyle, one-migrate, or one-page 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.
Ivy's pressure is ordinary—and still heavy
Ivy is a fictional 28-year-old designer updating a personal site in Kamloops, British Columbia. Ivy’s current site is five years old. A new stack is tempting. The work samples that get her hired are buried. A talk next month needs a URL that does not 404. She keeps choosing typefaces instead of moving the case studies.
Ivy can design. The month fails if a framework choice, buried work, and the talk URL never share a page list.
A Figma file, a repo, and a speaker URL all think they are the site.
Rebuilding on a new stack feels like craft and would miss the talk.
A new stack is not a case study, and a talk date is a ship date
The mission is specific: Ship a site that puts three case studies on the first screen before the talk, without requiring a new stack unless it fits the date
The consequential choice is not something a board or an AI should quietly make: Whether to restyle the current site, migrate one case study to the new stack, or ship a one-page site and postpone the rebuild
That distinction matters. Superboard can make the work, evidence, waiting, and decision visible. Ivy still owns the purpose, tradeoff, and final call.
Available today
Site before the talk: one Board shape to adapt
A useful Board gives this mission one durable operating picture. Ivy 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 | Talk URL and three case studies |
| Content | Work samples that get hired |
| Design | Type, layout, and what is only taste |
| Build | Current stack versus new stack |
| Waiting | DNS, screenshots, and the talk listing |
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 Ivy would need to see to run this mission without carrying every open loop in memory.
| Card | List | Job |
|---|---|---|
| Three case studies on the first screen | Mission | Keep the talk date beside the buried work |
| Choose restyle, one-migrate, or one-page | Build | Compare restyle-current, migrate-one-study, and one-page-postpone-rebuild |
| Buried case study: library wayfinding | Content | Name a sample that is not currently findable |
| Typeface exploration | Design | Hold taste work so it cannot outrank content |
| Talk listing URL next month | Waiting | Keep a public date from depending on an unfinished rebuild |
| New stack spike | Build | Mark a tempting rebuild as extra until the date allows it |
Available today
Available today: Choose restyle, one-migrate, or one-page becomes a Room
Opening the Card gives the visible item durable depth. Stage can hold Ship-path brief: Place talk date, buried case studies, and restyle / one-migrate / one-page options on one page. Chat keeps the request and response beside that artifact instead of in a detached thread. Pulse can show Waiting for Ivy to choose a ship path that hits the talk. Activity preserves the attributable Card record supported by the current product.
A useful Card Chat request would be: “Using only this Board, compare restyling the current site, migrating one case study, and shipping a one-pager. Do not deploy 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.
Ivy's call remains explicit: Ivy chooses the stack, writes the pages, and owns the deploy
| Surface | Job in this example |
|---|---|
| Stage | Ship-path brief: Place talk date, buried case studies, and restyle / one-migrate / one-page options on one page |
| Chat | Keep Ivy's request and Ava's attributed response with the work |
| Pulse | Waiting for Ivy to choose a ship path that hits the talk |
| 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.
Ivy owns design, content, and deploys. Ava does not publish the site or write the case studies in her place.
The modest outcome is not that Ava lives Ivy's life. The modest outcome is a URL that works: three case studies are findable, a new stack is a chosen extra, and typefaces are not the project.
- Request idea: summarize content, design, and build Cards already on the Board
- Request idea: compare ship-path options using the talk date Ivy captured
- Request idea: help keep typeface exploration from outranking case studies
A Figma file plus a half-started new repo may still be enough
A Figma file plus a half-started new repo is enough when the work is already on the first screen
It starts to break when a talk URL, buried case studies, and a new stack all claim the month
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 Ivy'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. Write the talk date | A URL that must not 404 |
| 2. List three case studies | The work that gets hired |
| 3. Cap taste work | Typefaces are not content |
| 4. Park the new stack | Until the date allows it |
| 5. Choose a ship path | Open a Room before rebuilding twice |
Direction
Direction, not a current promise
Later, Ava may help this Board notice when a talk Card is close and no case-study Card is on the first screen, still leaving every deploy with Ivy.
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
- Ivy is fictional and is not a customer, testimonial, research participant, or disguised real person.
- This is not a hiring, SEO, or traffic claim.
- It does not show Ava deploying a site or writing case studies.
- It is not a measured career result.