Case study: building a Taste Profile for Rosie

Rosie is an AI answering service. The premise of the product is the opposite of the premise of most AI products: the customer shouldn't notice it's AI. The voice on the other end of the phone should feel like a capable office manager who actually likes people, not a robot reading a script.

That premise puts the brand on a collision course with every AI design tool on the market. Ask Claude Design, v0, or Lovable to build Rosie a settings page and what comes back is exactly what the generic AI UI looks like: indigo-on-white, Inter throughout, 8px rounded corners, three glassmorphism cards, the same "trusted by" greyscale row. Confident, clinical, indistinguishable from a YC demo. The opposite of "the friendly person at your front desk."

So Rosie became the first Taste Profile we shipped. This is a walkthrough of what we built, why, and what changed about their AI-tool output once it landed. You can browse the result at rosie.tasteprofile.io.

The brief in one line

Every Taste Profile starts with a tension. Two adjectives that pull in opposite directions, joined by the word but. Whoever wrote them is forced to defend both sides, which is where a brand actually lives.

Rosie's tension was clear before we started: capable BUT warm.

That single line did more work than any other artifact in the project. Every later decision (the accent hue, the radius on a button, the line height on a headline, the wording of an empty state) was tested against it. Does this read as both capable and warm? If not, which side did we lose, and is it worth losing? You can write it on a Post-it. The team can quote it back. So can the model.

By contrast, here is what Rosie did not start with that most companies assume is a brand:

• A 40-page PDF brand guide
• A Figma library of finished components
• A token JSON file
• Any persistent context an AI tool could read

What they had was good taste, a colour they liked (a warm purple), one logo, and an existing product that, sentence by sentence, sounded like Rosie. Nothing structured. Nothing portable. Nothing an AI tool could load.

That gap is the entire job.

What we built

A Taste Profile is six artifacts. For Rosie they look like this:

1. DESIGN.md in the Stitch format. YAML front matter for tokens, prose body for the rationale. Roughly 580 lines.
2. tokens.json in W3C DTCG format, generated from the DESIGN.md front matter.
3. tokens.css, flat CSS variables, also generated, for non-Next contexts.
4. SKILL.md, a portable Claude Design skill. Drop it in the skills folder; reach for it by name in any new chat.
5. Three themed primitives (Button, Input, Badge) implemented against the tokens, so the team has a known-good starting point for production code.
6. A hosted viewer at rosie.tasteprofile.io. Fourteen sections (essence, principles, palette, contrast grid, type, shape, elevation, spacing, components, voice, agent exports, and more), live-rendering from the DESIGN.md.

The viewer matters more than it looks like it should. It is the place a designer or a new hire or a vendor lands when someone says "what does Rosie look like?" It is also the page Rosie's founder can send to a contractor in two seconds with a single URL. Until the brand has one canonical home, every conversation about it is re-litigated from scratch.

A token decision, in detail

Most of the craft of a Taste Profile is invisible. It lives in the gap between the four or five colours a founder picks and the forty colours a model actually consumes when it renders a screen. Here is one example from Rosie's palette to show what that gap looks like.

Rosie's accent is purple-600 (#9332E0). That's the headline number. But purple-600 alone gets you about 30% of the way to on-brand output. The other 70% is what surrounds it.

The full purple scale, lifted from Rosie's existing Figma, runs from purple-25 (#FBF7FF, the lightest tint you can put under a card without it disappearing) to purple-950 (#3D0B60, deep enough for text on a pale purple chip). Twelve stops. Every one of them named. Now when Claude Design or v0 reaches for "a slightly lighter version of the accent for hover," it doesn't sample the corpus. It picks purple-500. When it reaches for "a faint purple background," it picks purple-50 or purple-25. There is no decision to drift on.

The same goes for grey. Tailwind's default greys lean slate-blue, which fights the warm purple at every step. So Rosie's grey scale is tinted. gray-600 becomes #94899F instead of Tailwind's #475467. gray-900 becomes #544B5B instead of #101828. Two values, linearly interpolated between their warm-tinted neighbours. The eye barely registers the change on any single swatch. The eye absolutely registers the cumulative effect across a whole page.

Then the semantics. accent resolves to purple-600. accent-hover resolves to purple-700. accent-subtle resolves to purple-100 (the secondary-purple button fill). accent-light is purple-200 (the hover state of that secondary button). background-subtle is purple-25 (the card surface you can use when white reads too clinical). The model gets a vocabulary, not just a palette.

And the seams. Rosie's primary button uses a gradient: linear-gradient(180deg, #A83FC1 14.286%, #9332E0 100%). Top-lit accent-highlight fading into accent. That value is in the token file as gradients.primary-button. The top-stop colour (#A83FC1) is intentionally outside the scale; it exists for one job, and the job is keeping the primary button from going flat. Without that token, a model would render a flat purple rectangle. With it, the button feels lit from above and seats on the page properly.

This is what we mean by "tokens, all the way down." Brand colour is the easy part. The work is everything around it.

The five nevers

A nevers list is the cheapest, most effective brand instrument we know. Five short rules, each one eliminating a swath of the corpus mean before the model starts sampling. Rosie's nevers, verbatim from the DESIGN.md:

1. Cold blues or grays as primary colors
2. Robotic or clinical UI aesthetics
3. Sharp corners on buttons or cards
4. Dense, overwhelming layouts
5. Corporate jargon over conversational tone

Each one of these is doing work in production. The cold-blue never knocks out roughly half of all generated colour palettes. The clinical-aesthetic never disambiguates the word modern (which lands the model in the centre of B2B SaaS UI by default). The sharp-corners never enforces the pill-button language across every interactive element. The dense-layouts never gives the model permission to leave space. The corporate-jargon never reshapes microcopy on its own, without any other instruction.

We could have written ten more nevers. We deliberately did not. Five fits in working memory. Ten gets paraphrased.

Shape and depth

Rosie has three radii and three jobs.

50px on buttons is unusual. Most AI tools land between 6px and 12px because that is the corpus mean. Rosie's pills are a deliberate push to the warm side of the tension. They read as friendly. They read as approachable. They read as nothing-like-Linear, on purpose.

Concentric rule: when nesting rounded elements, outer radius equals inner radius plus padding. This is the rule that keeps a card with a button inside from looking off. Most models miss it. Stated as a one-liner, they catch it.

Depth is where Rosie's craft signature is loudest. Surfaces lift with a layered shadow-card:

0 0 0 1px rgba(0, 0, 0, 0.05),     ← hairline (replaces 1px border)
0 1px 2px -1px rgba(0, 0, 0, 0.04), ← contact shadow
0 8px 24px -6px rgba(0, 0, 0, 0.08) ← diffuse lift

Three layers, one token. The hairline replaces the 1px border on every card, panel, and palette. The contact shadow seats the surface on the page. The diffuse lift gives it body. Without those three together, a card looks either flat (no lift) or floaty (no contact). With them, surfaces feel placed.

Borders are still in the system, but only for internal rules: table dividers, sidebar rails, the header underline, the dashed treatment on a "Never" card. Form inputs keep a 1px border because the convention says "this is editable." Small pill controls (badges, the copy button) keep theirs because shadows read too heavy at that scale. That is two paragraphs of guidance in the DESIGN.md, and it stops every model from defaulting to a 1px border on a card.

Voice as a token

The half of a brand most token files leave out is voice. Rosie's DESIGN.md treats voice as canonical, with the same authority as a colour. From the file:

The right column is what a tool produces by default. The left column is what Rosie sounds like. Once that table is in context, every chat session inherits the difference. Empty states stop being "No data available." Errors stop blaming the user. Buttons start sounding like Rosie hired the copy.

The rules under the table do the rest:

• Active over passive
• Contractions are fine
• Numbers, not adjectives ("Answered in 2 rings" beats "lightning-fast pickup")
• Address the reader directly
• No exclamation marks unless something is genuinely worth celebrating
• No "synergy," "leverage," "robust," or other corporate filler

Six lines. Every model can quote them back. We have watched Claude Design talk itself through "the user told me no exclamation marks, so I'll cut this one" in the chain of reasoning on a fresh prompt.

What changed in the AI-tool output

The headline result, in one sentence: Rosie's team can ask Claude Design for a new screen and get a screen that already looks like Rosie. No purple-to-pink gradient. No Inter. No 8px corners. Pill buttons by default. The right purple, with the right hover. The voice rules respected from the first reply.

It is not a miracle. The model is still doing maximum likelihood. We have just changed the distribution. The most-likely output for "a settings page for Rosie" is now Rosie's settings page, because the DESIGN.md and SKILL.md are loaded into context and the corpus mean has been replaced by a much smaller, much more specific cloud of possibilities.

What that unlocks operationally:

• First-prompt fidelity. No re-pasting the brief. No five rounds of "warmer, please."
• Team-wide consistency. Every founder, contractor, freelancer, and intern who opens Claude Design with the skill installed produces the same Rosie.
• Portability. The same DESIGN.md lands in Cursor for production code, in v0 for landing-page prototypes, in Lovable for app concepts. The seams between tools stop showing.
• A canonical home. When a vendor asks "what are your brand colours," the answer is a URL: rosie.tasteprofile.io. The Figma file isn't the source of truth any more. The DESIGN.md is.

What it doesn't do, to be honest: it doesn't guarantee output. The model is still probabilistic. We have moved the centre of gravity by a long way; we have not abolished it. On a hard prompt, a one-in-twenty result still drifts. The fix is the same as the original work: tighten the most-relevant token, sharpen the relevant never, ship the update. Compounds the next time.

Numbers

Time from kickoff to delivered Taste Profile: six working days.

That includes:

• 90 minutes of brand discovery with the founder
• Two days writing the DESIGN.md and tuning the tokens against Rosie's existing Figma
• One day setting up the hosted viewer (rosie.tasteprofile.io)
• Two days implementing the three themed primitives and the SKILL.md
• One day of revision after a first review with the team

Cost: $999 intro pricing. Rosie was the first Taste Profile we shipped, so they got the introductory rate; the next nine clients will too, then it lifts to $2,500.

Effort the Rosie team put in: roughly four hours, total. The 90-minute workshop, two rounds of asynchronous review, and the click to merge.

Where this lives, and what's next

The artifacts live in a repo Rosie owns. The hosted viewer lives at rosie.tasteprofile.io and updates whenever the DESIGN.md changes. The SKILL.md lives in any Claude Team workspace that needs it. The tokens flow through to production code through lib/tokens.ts, which means a colour change in the DESIGN.md changes the rendered product on the next build. Single source of truth, one edit propagates everywhere.

Roadmap from here:

• v1.1 adds a dark-mode variant when Rosie ships theirs.
• v1.5 adds edit mode to the viewer so non-engineers can tweak tokens and export a new tokens.json without leaving the browser.
• v2.0 wires the viewer to Firebase + GitHub writeback so edits become real PRs.

None of that is the point of a Taste Profile in v1. The point of v1 is that the team and their AI tools both read the same source, in a format the tools were built to consume.

Related reading: Why AI-generated UI looks generic, and what fixes it, DESIGN.md: the AI-era brand guide, and W3C DTCG design tokens: a practical guide.