# A design system for everyone who designs Vibe.co · 2026 · Lead Product Designer · Case study Source: https://albancarmet.com/case-study/design-system Vibe’s design system rebuilt in Claude Design and opened to the whole company, so everyone who builds screens with Claude builds consistent ones. In one line: I gave everyone the system. Team: Me, then the other product designer for the documentation · Duration: Since June 2026 · AI: Built and documented in Claude Design ## At a glance - Problem: Engineers, marketing and PMs were building screens with Claude that looked like Vibe without using Vibe’s components. Nothing kept them consistent. - What I did: On my own initiative, I rebuilt the design system in Claude Design, opened it to the whole company, documented every component for the model, and built a QA skill to review what gets shipped. - Result: The other product designer and I now design only in Claude. Some PMs show ideas as high-fidelity prototypes and design small features themselves, then ask us for a design review. - Limit: No usage measurement, and the system isn’t tokenized yet, so some drift remains. ## The company Vibe is a self-serve advertising platform for connected TV. Brands of every size, from fast-growing direct-to-consumer labels to large advertisers, buy ads on the major streaming channels, target their audiences — including Walmart shopper audiences — and measure the sales they drive, the way they would on search or social. - Sector: Ad tech · connected TV - Customers: Thousands of brands, from DTC to large advertisers - My time there: Since Dec. 2023 · Lead Product Designer ## Process Claude Design is where the system lives and where it gets documented. The calls on what goes in it, and the reviews, stayed mine. - Rebuild the system: Vibe’s components rebuilt in Claude Design, where the rest of the company already builds screens. (with AI, Claude Design) - Open it to everyone: An alpha announced to the whole company on Slack, a Notion onboarding guide, and two Slack channels: design feedback, and sharing what people build. (without AI) - Document for the model: With the other product designer, one structure for usage notes, applied to every component. (with AI, Claude) - Test the output: Screens generated with the system, checked by hand: consistency clearly improved, some drift remains. (without AI) - Review what others design: PMs design small features with the system; I review them before they ship. (without AI) - Automate the QA: A skill that compares the design with the PR preview and writes up every difference for the developers. (with AI, Claude) ## The problem — Screens that looked like Vibe, without being Vibe Vibe runs on Claude. Engineers, marketing and product managers were already building their own interfaces with it, and those interfaces looked like Vibe without being Vibe: the components were redrawn, close but never the same. The clearest case is an internal sales tool built by a growth marketer to prospect, follow accounts and manage the pipeline. It’s useful, and it doesn’t use a single one of our components, so it doesn’t look like our product. I can’t show it. How often this happened, I can’t say: teams don’t share much of what they build. I saw enough of it to stop waiting. ## The decision — Put the system where people already design Vibe works in Claude every day, and Claude Design had just come out, so I didn’t compare tools: the right place was the one people already had open. Nobody asked me to do it. My lead PM saw the benefit straight away, so I didn’t have to convince anyone. ## The approach — Open it to everyone, then document it for the model At the end of June 2026, I announced it to the whole company on Slack, as an alpha. With it came a Notion onboarding guide on using Claude Design with the system, because the point was also to get people building tools for their own teams. I opened two Slack channels: one to ask for design feedback on anything made in Claude Design, one to share what people built. The alpha had components but no rules. With the other product designer and Claude, we first agreed on one structure for usage notes, then applied it to every component: a one-sentence definition that also serves as the summary in the index; when to use it and, for each neighbouring case, which component to use instead; then content, behaviour, placement, spacing, states, accessibility and test attributes. One idea per line, the reason inside the sentence rather than a “must”, and a source at the end of every line. Then we tested what the model produced. Consistency clearly improved. Some drift remains, most likely because the system isn’t tokenized: neither design nor engineering has had the time. When I generate screens for my own projects, I’d say about four in five come out right. The drift on the rest is small next to the speed it brings to a complex project. ## What changed — PMs design small features, and I review them The other product designer and I now design only in Claude. Some PMs show an idea as a high-fidelity prototype instead of a wireframe. Some design small features or fixes themselves, then ask us for a design review. Complex projects stay with the designers. Beyond product, I don’t know how far it went. Blocked creatives, in November 2026, are a good example. A creative gets blocked when it breaks the editorial guidelines, and until then the advertiser had to contact a CSM to learn why. The PM designed the first version with the system. In review, I reused the existing Alert component so the block reads at first glance, and switched the name and labels to their disabled variants, since a blocked creative can’t be edited. Part one, in production, explains the block inside the product. In part two, which the PM and I also worked on, a form lets the advertiser ask for details without going through a CSM, and an email warns them when a creative gets blocked. ## Reviewing at scale — A QA skill, so review doesn’t become the bottleneck More people generating screens means more to review, and I had become the bottleneck. On a project the size of the Creative Library, a manual visual review could take me several hours. And I generate my designs in Claude while running several projects in parallel: my own review sometimes missed how an element that isn’t a component actually renders. So I built a QA skill. It compares the design with the PR preview, puts them side by side, marks every difference, and writes the steps to reproduce it. The developers fix the issues on their own. I first used it on creative upload in the agent, in November 2026, a feature with many use cases and edge cases. The first pass found about a dozen discrepancies between the design and the build: most on the implementation side, some in details I had missed in my own review. It isn’t perfect: it sometimes flags a false positive. Two things make it better over time. The better my flows are documented in Claude Design, the less it gets wrong. And when I flag a false positive while it writes the report, it learns from it and produces fewer the next time. I’m the only one using it so far, and I’ve shared it with the other product designer. I later learned that a developer was building its counterpart on the code side: integration generated from Claude Design, with a skill that fixes missing component reuse and visual drift by itself. ## What’s next — A standalone site, for everyone who builds The system still lives in Claude Design’s settings, where few people look. I’m building a standalone site, to the standard of public design systems, that brings together the product system and the brand and website guidelines, which marketing owns. It isn’t online yet: a refresh of the system is under discussion, and we may wait for it. ## Constraints - Everyone already had Claude: Engineers, marketing and PMs were building their own screens. The point wasn’t to stop them, but to make what they built consistent. - A system that isn’t tokenized: Neither design nor engineering has had the time to tokenize it, so the model has less to hold onto. - Teams share little: I couldn’t measure how often inconsistent screens got built. I only saw some of them. ## Signals and research No formal discovery: I started from what I saw being built. - Internal tool — A sales tool built by growth: Useful, and built without a single one of our components, so it doesn’t look like our product. - Product design — Two designers, one look: The other product designer and I needed visually consistent screens from Claude as much as anyone. ## Decisions and trade-offs - Rebuild the system in Claude Design rather than keep it in Figma. Decided with: My own initiative, backed by my lead PM. Rejected: Keep the system in Figma — Where only designers could use it. Kept: Rebuild it in Claude Design — Where engineers, marketing and PMs already build screens, with a usage note behind every component that the model reads. Why: The right place was the one people already had open: Vibe works in Claude every day. What it cost: A comparison of tools. I bet on the one already open, without checking whether another would generate more consistent design. ## Results No usage metric yet, but the way people design around me has changed. (Since June 2026) - 2 of 2: Product designers who now design only in Claude - ~12: Gaps between design and build caught on the first QA pass What worked: - Some PMs prototype in high fidelity instead of wireframes - Some PMs design small features and ask for a design review - Developers fix QA issues on their own What didn't work: - Drift remains: the system isn’t tokenized - No view of usage outside product ## Still open Tokens first, then a way to see who builds what. The system isn’t tokenized, so the drift won’t go away on its own, and I have no measure of usage outside product. The next step is the tokens, then a way to see who builds what.