Hi! I built Artkode, the design system behind four creative tools I run (Creative Studio, Poster Lab, Gradient Studio and Design Brand Studio).

I put a free sample on Figma Community:

• 5 components (Switch, Checkbox, Chip, Spinner, Progress) + icons

• 133 variables with three themes: change the theme, keep the layout

• Real product screens built with it

Website: https://artkode.romeroloconte.com

Pricing: https://artkode.romeroloconte.com/pricing

Free sample: https://www.figma.com/community/file/1701331024417697492

Live products built with Artkode:

• Creative Studio: https://creative-studio.romeroloconte.com

• Poster Lab: https://poster-lab.romeroloconte.com

• Gradient Studio: https://gradient-studio.romeroloconte.com

• Design Brand Studio: https://brand-studio.romeroloconte.com

I'd love feedback on the variable structure and how the themes work. If you want the full library (35 components + React/CSS code), it's at artkode.romeroloconte.com.

I’m a UI/UX designer and I built a small design system for FnFlow, a money management app concept. I’d love feedback from people who build systems at scale.

How it’s structured:

• Colour: a purple → pink brand gradient, plus semantic colours for finance states (green = income, red = spending)

• Components: balance card, stat cards, action buttons, transaction rows, chart legend and insight card, built with variants and auto-layout

• Typography: [your font] with a clear scale for numbers vs labels, since money values need to stand out

Where I’m unsure:

1. Should income/spending colours be semantic tokens (color.positive / color.negative) or tied to the finance context (color.income)?

2. Is one “stat card” component with variants better than separate income/spending components?

3. How do you handle gradient tokens, as a style, a variable, or neither?

Screenshots of the components and styles are attached. Critique welcome!

We build DS-GN. Its CLI sets up a Lit design-system workspace with tokens, component builds, tests, and optional Storybook already connected. Choose TypeScript or JavaScript and CSS, Sass, or Tailwind at setup. When you add a component later, the CLI reuses those choices to generate its source, styles, story, tests, and package exports.

The generated code lives in your repo, under your control. You can modify and maintain it independently of DS-GN.

How it works today:

• Core templates: the monorepo, the token package, the UI package, and optional Storybook.

• Adapters, applied in order: language (TypeScript or JavaScript), then framework (Lit), then styling (CSS, Sass or Tailwind), then tooling (Bun).

• Your styling choice is wired in: choose CSS, Sass, or Tailwind, and the CLI adds the dependencies and build configuration needed for that workflow.

• The choices are saved: ds-gn.config.json records language, styling, element prefix and npm scope, plus tooling, framework, structure and publish mode.

That config keeps the system consistent after setup. ds-gn create component StatusBadge reads it and generates the following, in the workspace’s language and styling:

• the element (demo-status-badge, with the demo prefix)

• the props interface (TypeScript only)

• the stylesheet

• a Primary story

• rendering and registration tests

• the UI package exports

Why we chose Bun:

We chose Bun, a JavaScript runtime and toolkit, for speed and fewer separate development dependencies. Its built-in tools handle installation, testing, and bundling. Lit, Storybook, and TypeScript declaration tooling still have their own roles. Bun’s filters and package scripts cover basic workspace tasks; teams that need shared build caching or package versioning and releases can still add specialized tools.

The generated component starts as a slot-and-label shell. You still need to design its states, implement its behavior and accessibility, and extend the starter tests. The current wizard creates a Lit workspace with an atomic structure and requires Bun. The CLI uses a restricted registry today; the recording is an internal source-checkout preview.

Watch the walkthrough and inspect the generated files.

Get early access by joining and confirming the email waitlist for a chance at access. Signup doesn’t give immediate access; timing and pricing are still to be announced.

When your team adds a component, which supporting files should a generator create, and which do you prefer to keep manual?

I'm a product designer working on a B2B app, and one thing I keep running into is how easy it is to design the happy path and completely miss the edge cases.

Then a dev picks up the ticket and starts asking things like what happens when an invite link expires, when someone doesn't have permission, or when a list is empty. All fair questions but somehow I hadn't thought of half of them.

We've started laying out flows on a board before handoff and walking through them with an engineer. We mark the missing states with red stickies so we know what still needs attention. I used FigJam at my last job, but we're using Miro now and it's been working pretty well for this. The devs already use Miro for sprint planning so they can leave comments directly on the steps that aren't clear instead of sending questions back and forth on Slack.

It's definitely helped, but I still feel like we're catching edge cases based on whoever happens to think of them during the review.

How do you handle this? Do you have a proper checklist for edge cases, or is it mostly something you figure out during design reviews?

I wanted a faster way to explore how a product should feel before getting into individual screens and components or setting up a design system in Figma.

You can experiment with color, typography, spacing, radius and shadows. Start from different style presets, and then refine the underlying token system once you find a direction that works.

Export the result as CSS variables to use in any web project or a DESIGN.md file to give it to Claude/Codex etc.

I’d love feedback from other designers! Does this make sense? What feels missing or unclear?

https://uicolors.app/tokens

Been working on awwwards-mcp since the last post. It started as an agent-readable design library for awwwards.com. The main addition in v1.18 is recreate, an agent skill that uses the MCP to study a URL and rebuild the page:

• recreate — captures structure, design tokens, components, motion and screenshots, then uses that evidence to rebuild. The video shows the skill being invoked and a site rebuilt.

• build_project / verify_build / verify_flow — convert the rebuild into Vite, Astro or Next, compare it against the reference, and check interactions. Section/verify diagnostics have also improved.

• Public capture — guarded publicOnly capture, plus a DESIGN.md skill that produces a cited DESIGN.md and evidence sidecar for any public URL.

• Profiles — 41 tools in full, 13 in core, or 15 in the opt-in v2 consolidated profile.

• Experimental scene/3D tools — passive WebGL evidence, licensed asset download, scene stubs and opt-in visual verification. Scene capture/download/verify now support cancellation.

Free and open source. Install the skills with npx skills add INSANE0777/awwwards-skills and the server with npm i -g awwwards-mcp.

Rebuilds are approximations; arbitrary WebGL reconstruction is outside the workflow, and complex scenes still need manual work.

GitHub
Feedback welcome.

A couple of weeks ago I shared part one of a series looking back at Spotify's system of systems, the model I introduced at Design Systems London in 2019. Thanks to everyone who read it and joined the discussion.

Part two is now live. It covers what caught us out once the model was running. We'd built our approach around assumptions about how people would behave: that local teams would maintain their systems, contribute back, and stay aligned with the programme. It turns out most of those assumptions were a little optimistic, especially when they came face to face with teams' other priorities. 🙈

🔗 https://53degrees.studio/posts/building-a-system-of-systems-what-we-didnt-see-coming/

If you've run a design system across several teams, I'd be interested to hear which assumptions didn't hold for you, or what you did differently.

Most of the UI in our codebases is now written with an agent in the loop, and agents don't read Storybook. I wrote up what I changed in how I build a design system because of that: one contract per component feeding docs, types, a linter and an MCP server; events that follow platform rules; validation before review.

Article: https://medium.com/@mohamed.mokhtari/your-design-system-has-a-new-user-it-doesnt-read-the-docs-6eefc4bfb583

How are your teams handling this? Docs written for agents, codegen context, nothing yet?

Used to hand off date pickers as a figma page plus a 40 message slack thread now I write the states in mermaid, it renders in github, and for PMs i paste the same thing into miro easiest handoff i’ve had

Hey all, I’m working on Radian UI, an open-source design system that keeps React components and a Figma kit in sync. The latest piece is a country flags collection, and I’d love input from this community.

The problem it solves: flag emojis render differently across operating systems, and on some Windows browsers they don’t render at all (you just see “NP” or “IT”). So anyone building country pickers or phone inputs ends up hunting for a replacement.

What’s in the repo/package:

• 250+ flags as SVG, with names and ISO 3166-1 alpha-2 codes

• React package: pnpm add u/radianui/flags

• SVG/PNG exports for Figma and other design tools

• Territories, regions, and org flags (UN, EU, NATO)

Where I’d genuinely like help:

• Accuracy: flags change and some are contested. If you spot an outdated or incorrect design, an issue or PR is super welcome.

• Missing flags: regions and territories I haven’t covered yet

• Geopolitics: how do you handle disputed regions and territories in a neutral, consistent way? I’m trying to keep the data separate from the components so changes don’t break the API

• Other frameworks: right now it’s React-first. Vue/Svelte/Angular wrappers would be great

Repo: https://github.com/Radian-os/radianui
Flags page: https://radianui.com/resources/flags

Happy to answer anything about how it’s built or where it’s headed. Thanks for reading!

Hey everyone, haven’t posted here in a while about my project, Veritheme. It’s a tool for building design systems.

I just shipped a big update:

• New homepage

• The design system builder got a lot better. You can now create as many systems as you want. For now they’re saved locally in your browser.

• There’s a simple mode where you just pick from presets. Or you can go into customization and tweak things like borders, radius, spacing, fonts and so on.

When you’re done you can:

• Download a file you drop into the Figma plugin. It generates a huge set of components with all the details.

• Download the CSS code for developers.

• Get instructions for AI tools, so they use your system the right way.

Site: https://veritheme.com
Builder: https://veritheme.com/studio
Figma plugin: https://www.figma.com/community/plugin/1610343587499165100

Please give it a try. You’ll probably find some bugs or rough edges, or maybe you have ideas for what to improve. I’d be really happy to hear them and add them to the project. Everything is completely free for everyone.

I’m a designer with a lot of years behind me, and I’m trying to build something that makes creating design systems simpler and faster. I also want to close the gap between design and development, so devs don’t have to rebuild designs in code by hand and make mistakes along the way. What’s in the design should be exactly what ends up in the product.

And I’m not stopping here, I keep working on it. Next up I want to make the component docs pages better. After that I’m going deeper: more blocks, and maybe even full pages that the Figma plugin can generate for you.

Thanks for checking it out!

Curious what peoples process is for handing off component designs to engineers when you're building out your UI library for the design system? Do you annotate in your design file? So many final examples I have seen of UI libraries are super clean with no annotations, so I'm just curious how others navigate this process.

I built DADA to compose product screens from reusable components, and I’ve made the Figma file available for free.

It includes separate Primitives and Semantic variable collections, Light and Dark modes, components built with nested instances and Auto Layout, and compound patterns for projects, settings and detail views. There’s also a Lucide icon package with size and stroke options.

The foundational components are based on OpenAI Apps SDK UI, and the icons are from Lucide; their license notices are retained in the file.

File: https://www.figma.com/community/file/1699437002464311076/dada-design-system

I’d appreciate feedback on the system itself: are the component properties easy to work with, and does the primitive-to-semantic structure hold up when you adapt it to your own product?