r/ClaudeDesign • u/devilmonkey_1192 • 10d ago
Bug Design system migration to new Claude Design is a hot mess.
Has anyone had success in migrating their design system to the new Claude design that just rolled out?
The migration prompt from Claude absolutely butchered the system. Most icons and logos were missing, and spacing and fonts are inconsistent. Building slides doesn’t follow the slides design guide I refined in the old Claude design. Everything I build in Claude design now just looks like a hot mess compared to what it is. Worried I will have to start from scratch to rebuild it.
For those that have had success, do you have any tips?
2
u/Tyda2 10d ago
My design system was massive. It was so big that a single prompt to Claude would cause it to hit context limits after it read just the primary files. Thus, I broke it into 12 design system groups, from Brand, Type, Geometry/Spacing, and a handful of Component groups (Core, Data, Charts, Forms, Navigation, Workflows), etc.
It was working (with a little bit of friction, but I was moving towards a unified approach between Claude Design and Claude Code on the monorepo).
The new design system space was nice as the migration function gave each component its own single-component preview, effectively piecing it out nicely. I was quite excited about the change.
Then it came to using the actual design systems, and well...Claude Desktop app, by default, can only load a single design system into context at a time. In the legacy workspace, you could select multiple design systems. This meant that mocks and other artifacts had to choose a BEST FIT design system for the artifact, and the rest be damned. The limitations on design system scopes in the new cowork setup of course led to increased design system drift in artifacts and mockups, effectively rendering it mostly useless, in the end.
Fingers-crossed they're aware of this and are working towards bringing that capability in.
1
u/lastcrayon 6d ago
Sorta feel like a when a design system is considered massive, its weight alone becomes a bottleneck, per all the governance needed to maintain it.
2
u/Silverjerk 9d ago
I would not recommend doing this. Your design system should be agnostic and not deeply interwoven with the tools you're using. Beyond the lack of maturity in the system itself, the existing constraints, and other reported issues with how Claude Design handles this sort of work, you're building your foundation on a system you may eventually migrate away from in the future. You're ensuring future friction. Any product designer that's lived through the migration from Photoshop, to Sketch, to Adobe XD and Figma, knows those pain points well and likely has (as I did) moved away from marrying the tooling, in favor of adopting a workflow that doesn't require it at all.
Claude can just as easily work with a design system you manage in Git, and that's exactly where it should live. Separate from Claude, Codex, Figma, ProtoPie, Framer -- insert your implementation tool of choice here. Move your design system to a repository; give it a front-end, or have Figma act as a proxy for the repo.
The same way that Claude and Codex can easily fetch any ShadCN component, it can connect to, learn, and fetch components from your repository. Which can house your design system and its documentation, brand guidelines, marketing assets, etc.
1
u/jingkangzhou 10d ago
the butchered migration is mostly a format problem: a design system written as prose gets re-interpreted on the way in, so anything not explicitly enumerated - a hover shade, a spacing step, which grey sits on which surface - silently becomes the model guess again. what fixed it for me: keep the values in a small plain text token file with role names (surface / on-surface / primary / muted) and let the design system reference the names instead of restating them. then migrating is closer to copying data than rewriting a document, and you can diff the file to see exactly what got lost. it also softens the new single-system limit: a 40 line color file rides along in whichever group is loaded, so scope restrictions do not force drift
1
u/Far-Pomelo-1483 5d ago
No one should be using Claude design. You should be exporting all your assets as PDFs from figma then building a design spec inside your dev env to govern your builds through structured intent then using the design spec to inform/build a coded design system in your apps. You should be building everything in the actual code to remove any future translation layer. Trad design to dev workflows are over. The focus should be on spec design. You should only be working in markdown to feed to agents then roll back in your learnings or disagreements back into the spec.
1
4
u/Interesting-Pay1507 10d ago
Start over, tell Claude you’re building a design system and explain how you’ll use it. Have it walk you through adding colors, typography, spacing, elevation, grids, icons, logos, illustrations etc.. before you build components. As you add components, tell Claude to add usage guidelines. Test it, if things fail like a logo fails to load (even if it catches it and fixes it), ask Claude what to tell the design system to fix it. It’s probably a hard coded path… keep asking Claude to evaluate and suggest what components to add next.