#DesignSystems #UIDesign #UIUX #FrontEnd #BuildInPublic #WebDesign #ComponentLibrary #DesignToCodebase
👇🏻 Join the waitlist:
https://genstyl.ovidiu.works/?utm_sou...
Even before I started building Genstyl, I knew that a foundational feature of the application was going to be the ability to track changes over time. This is extremely useful in understanding what is happening in your (design) system as time goes by: you add a new colour, you edit a primitive, you delete a component, you update a layout.
Delete: a hard word with a softer meaning. Since we’re keeping track of everything that’s changing, a delete is not the removal of data, but instead a “marking as removed” intent (also known as soft-delete). For custom components, I’m referring to this operation as archiving.
When archiving a component, it’s not gone, it’s there in the background, having its whole history intact, and can still be rendered in layouts—or unarchived—otherwise we could end up with lots of holes in our designs, which would break existing layouts.
Archived components will be rendered with custom indicators informing the user of their state. Components that use archived components in their template will also display warnings to get the user’s attention and kindly nudge them into addressing the issue.
This brings us to one of the tricky parts of managing a design system / component library. Things get added, removed, duplicated, edited and replaced. It’s an organically grown system that is inherently unpredictable. We can have built-in reporting and auditing in our design tools: with a single click we can generate reports about unused variables, colours, components, etc.—a health check, if you will—and then decide what to do about it.
This becomes vital as we convert the design to a production-ready codebase, where an engineer needs to know exactly what changed in order for them (or an LLM) to have a painless migration to a new version.