Skip to content

Example

How to redesign a personal website without rebuilding it twice in the same month

Ivy can design. The month fails if a framework choice, buried work, and the talk URL never share a page list.

Superboard exampleSite before the talk

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

Mission1

Talk URL and three case studies

Three case studies on the first screen

Keep the talk date beside the buried work

Content1

Work samples that get hired

Buried case study: library wayfinding

Name a sample that is not currently findable

Design1

Type, layout, and what is only taste

Typeface exploration

Hold taste work so it cannot outrank content

Build2

Current stack versus new stack

Choose restyle, one-migrate, or one-page

Compare restyle-current, migrate-one-study, and one-page-postpone-rebuild

New stack spike

Mark a tempting rebuild as extra until the date allows it

Waiting1

The talk listing date next month

Talk listing URL next month

Keep a public date from depending on an unfinished rebuild

An illustrative Board built from this fictional scenario. Adapt the Lists and Cards to your own mission.
01

Ivy is an explicitly fictional portrait, not a customer or testimonial.

02

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.

03

Current You.one provides the Superboard structure and explicit, bounded Ava paths described here; broader proactive or external work is not a current promise.

Why Site before the talk needs an operating picture

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.

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.

In You.one's Superboard view, Ivy can give “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” a Board of its own. That Board connects the project's purpose, materials, experiments, and the maker's judgment; opening “Choose restyle, one-migrate, or one-page” creates a Room for its evidence, discussion, state, and decision.

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.

You.one can keep the work, evidence, live dependency, and “Choose restyle, one-migrate, or one-page” decision visible through its Superboard view. The Owner boundary stays explicit: Ivy chooses the stack, writes the pages, and owns the deploy.

Available today

Site before the talk: one Board shape to adapt

The Site before the talk Board gives this mission one durable operating picture. Ivy can use familiar language instead of translating the situation into project-management jargon. Its five Lists separate the kinds of attention this situation actually requires.

Its Cards deliberately distinguish actions, evidence, a live dependency, and decisions. A Waiting List is useful here only because a named request or outside condition is already in motion. That separation makes the current choice, evidence, and next move easier to scan.

Site before the talk Board shape
ListWhat belongs here
MissionTalk URL and three case studies
ContentWork samples that get hired
DesignType, layout, and what is only taste
BuildCurrent stack versus new stack
WaitingThe talk listing date next month

Available today

The Cards make the operating picture concrete

These Card titles come directly from Ivy's situation: “Choose restyle, one-migrate, or one-page” is the live choice, “Buried case study: library wayfinding” holds evidence, and “Talk listing URL next month” names something genuinely in motion outside Ivy's control. The point is recognition, not a perfect taxonomy.

Example Cards for Ivy
CardListJob
Three case studies on the first screenMissionKeep the talk date beside the buried work
Choose restyle, one-migrate, or one-pageBuildCompare restyle-current, migrate-one-study, and one-page-postpone-rebuild
Buried case study: library wayfindingContentName a sample that is not currently findable
Typeface explorationDesignHold taste work so it cannot outrank content
Talk listing URL next monthWaitingKeep a public date from depending on an unfinished rebuild
New stack spikeBuildMark 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 “Open decision: Ivy will choose a ship path that hits the talk.” Activity can preserve this attributed receipt: “Ava compared the options in Card Chat using the Ship-path brief and this Card Room's visible notes and left “Choose restyle, one-migrate, or one-page” with Ivy.”

A useful Card Chat request would be: “Using only the context visible in this Card Room, 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 Room context and can make limited reversible changes inside this Card Room after an explicit request. She uses only supported Room context; she cannot summarize the Board, watch other Lists, or act outside this Card Room. 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.

Inside the Choose restyle, one-migrate, or one-page Room
SurfaceJob in this example
StageShip-path brief: Place talk date, buried case studies, and restyle / one-migrate / one-page options on one page
ChatKeep Ivy's request and Ava's attributed response with the work
PulseOpen decision: Ivy will choose a ship path that hits the talk
ActivityAva compared the options in Card Chat using the Ship-path brief and this Card Room's visible notes and left “Choose restyle, one-migrate, or one-page” with Ivy

What to ask Ava—and what not to assume

These requests use the visible supported context inside the “Choose restyle, one-migrate, or one-page” Card Room. They do not imply that current Ava automatically surveys the whole Board or follows up on her own; Ivy must provide the relevant facts and check the result.

Current Ava can reply in this Room to an explicit Card mention using supported Room context. She cannot summarize the Board, make the choice, represent Ivy, watch other Lists, or act outside this Card Room.

Ivy owns design, content, and deploys. Ava does not publish the site or write the case studies in her place.

A URL that works: three case studies are findable, a new stack is a chosen extra, and typefaces are not the project.

  • Request idea: using only the context visible in this Card Room, compare restyling the current site, migrating one case study, and shipping a one-pager. Do not deploy or choose for me.
  • Request idea: use only the Ship-path brief and notes the Owner has placed in this Card Room to separate facts, assumptions, and unanswered questions
  • Request idea: name which visible Room note could most change the comparison; do not watch other Lists or follow up autonomously

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.

The Site before the talk Board earns its place only when the familiar tool—a Figma file plus a half-started new repo—can no longer keep the reason, Ship-path brief, conversation, current state, decision, and history connected.

A starter recipe to adapt, not obey

Ivy should rename every List or Card that feels artificial. This recipe succeeds when “Choose restyle, one-migrate, or one-page” becomes easier to decide and fewer open loops depend on memory—not when the Board looks tidy.

Start with the Site before the talk Board
StepAction
1. Write the talk dateA URL that must not 404
2. List three case studiesThe work that gets hired
3. Cap taste workTypefaces are not content
4. Park the new stackUntil the date allows it
5. Choose restyle, one-migrate, or one-pageOpen 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.

A future unified You.one experience could carry relevant context from “Choose restyle, one-migrate, or one-page” across guidance and the Superboard view. Broad proactive coordination, cross-surface personalized memory, realtime shared editing, and general external execution are not available today. Any future action 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.

Use this example as a starting shape—not a claim about your life.

Get early access