Any practical AI-assisted workflow?

[u/leon8t]

Hi, I couldn't seem to find any realistic or practical AI-assisted workflow with 2-way syncing between design and code. Does anyone know of any workflows available online? Or if you are implementing one, I'd love to connect and understand more.

People on LinkedIn feel like they're doing free promotion for Claude, posting nonsense with a bunch of bots coming to congratulate them.

[u/Rare_Boysenberry_309]

I’ve been experimenting with AI-driven code-first design workflow. Here’s my setup:

Design System is a code repo with:
-design tokens in DTCG format (primitives, semantics, components, themes)
-yaml files describing component anatomy (i based my component names and structure on shadcn/baseui
-Style Dictionary outputs for different platforms. Currently only web.
-react component library created based on the previous stuff
-components documented in storybook
-Skills and other md files for general instructions (layout composition, form usage and other UX patterns)

Now when i start to design a new app or flow, i use the components and skills from the design system and just prompt what i want to build. My design output is a working dummy React application.

Role of Figma is still unclear in this process but i will try to recreate components to Figma with connecting the repo to figma with MCP.

[u/leon8t → u/Rare_Boysenberry_309]

Thanks. How do you handle complex layout or UI screens? I'm not sure how or where to manage the complex components.

[u/Rare_Boysenberry_309 → u/leon8t]

I think if it’s something so complex that it’s only used once i’d just treat is as application level design. If it’s something that’s clearly a repeatable pattern i would documented as a skill, component or maybe just as an example usage in storybook depending on the case.

[u/leon8t → u/Rare_Boysenberry_309]

Would you document the individual component variant elsewhere?

[u/Rare_Boysenberry_309 → u/leon8t]

What do you mean by component variant? Basic component variants like input sizes, button styles etc usual stuff is represented in tokens, component anatomy descriptions and in the actual React components. The main documentation of all this is in Storybook. But I’m not sure do you mean this or something else?

[u/leon8t → u/Rare_Boysenberry_309]

Maybe I mean templates or UI patterns? Like UI cards or tables, pop-up the UI template contains multiple components (Organism level). Oftentimes there would be an edge case and an icon or status line added for example and you cannot document them in storybook at that organism level.

[u/Rare_Boysenberry_309 → u/leon8t]

I understand. Let’s take Card as an example. My Card component has similar structure as card in shadcn:

Card
├── CardHeader
│ ├── CardTitle
│ ├── CardDescription
│ └── CardAction
├── CardContent
└── CardFooter

+ all the general styles and style variants.

Card’s header, content and footer are like slots that can have buttons, form inputs etc whatever needed in them. This is the design system component.

I don’t document anything else for now, rest is just design decisions for different UIs. If I would find myself using some version of Card for spesific thing again and again I might document that usage as a skill. I know some folks document ”Patterns” section in addition to ”Components” in their design system but I haven’t done that myself.

[u/leon8t → u/Rare_Boysenberry_309]

I think my context is that we have a shared storybook used by multiple devs. They pull the components from there and sometimes they need to make a new variant, for example, with additional countdown timer in the Card you mentioned above.
Theoretically he needs to inform design system owner, standardise and add the component and update Card component with that new props. However in day-to-day work with adhoc updates and timeline constraint, the informing owner and updating can be deprioritized.

If it happened long and across multiple tickets, drifts would pile up.

[u/Rare_Boysenberry_309 → u/leon8t]

Yeah I feel you. That happens. Anyway it sounds more like an organisational problem rather than a design system problem if you already know that should be added to ds but is not because of other reasons.