I’ve been building an AI video generation pipeline using AI agents, and I wanted to share a project I just finished.

I used it to turn Designing Data-Intensive Applications into a chapter-by-chapter podcast/video series.

The pipeline currently handles things like:

• breaking source material into chapter-level inputs
• generating scripts/storyboards
• creating long videos, shorts, and podcast-style episodes
• rendering audio/video assets
• packaging everything for upload

I’m still improving it, and I’d really love feedback from people who know content creation, agent workflows, automation, or media pipelines.

Podcast link:
https://www.youtube.com/playlist?list=PL2vsUH3csN48f3Js6SBgmIeymYzuFdyw-

A few things I’d especially love feedback on:

• what looks or sounds weak right now
• what parts of the pipeline feel overengineered
• what you’d fix first if you were building this
• how you’d make the audio/pacing more engaging
• whether there are better ways to structure the agent workflow

Also curious:
Would you want podcasts/videos like this for other technical books too?

I made this one for Designing Data-Intensive Applications, but I’m considering doing more if people find it useful.

If anyone has ideas on how to make this better, I’m all ears.

Also doing this for leetcode.

Today I’m launching Designry on Product Hunt 🎉

Over the last few months, I’ve been building a browser-based design system tool focused on one thing:

Making design systems faster and easier to create.

Because honestly:
setting up tokens, variables, typography, exports, and documentation manually still takes way too much time.

With Designry, you can start with a single brand color and generate:

• OKLCH color palettes
• Typography & spacing tokens
• Figma Variables export
• Tailwind export
• Full component documentation

—all directly in the browser.

No Figma plugin. No installation. Free to start.

Would genuinely love your feedback and support 👇

Product Hunt → https://www.producthunt.com/products/designry?launch=designry
Live Demo → getdesignry.com

#designsystem #designtokens #buildinpublic #figma

Accessibility has been at odds with design practice. I’m building the fix, but I need your help to bring it forward.

I’m Santiago Bustelo. I’ve spent my career volunteering for the Design community, including serving as a regional coordinator for IxDA since 2010. I’ve also helped drive Accessibility Laws because I believe technology should empower, not exclude.

I’m not here to sell a product; I’m a colleague who has spent decades trying to improve our craft and would like to finish what I started.

For decades, I’ve seen accessibility treated as a bureaucratic checklist that designers resist because it’s forced upon them and leads to poor design outcomes.

To solve this, I spent months building IPAX.

It’s not another 'contrast checker'. It’s a model that rewards great design instead of just legal compliance, integrating WCAG, APCA, and ergonomics like halation, glare, and chromatic fatigue.

The model is solid and the first tools (Sandbox, Font checker, Color System designer) are live (please forgive the experimental settings and rough corners). But I’ve hit a financial wall and can no longer carry this development alone.

I’m currently looking for sponsors, research partners, or grants to close the gap between accessibility theory and real-world design practice.

If you work at a university, an organization, or a company that actually gives a damn about the European Accessibility Act (EAA 2025) and wants to support a tool that makes compliance operationally transparent, let's talk.

And if you're just a curious UX colleague, check it out: icograma.com

You've seen a bunch of specs plugins. Hear me out on this one 😄

I took some time to create Ogiso Docs for Figma. Select a component, generate full documentation in one click. No (complex) setup. No AI.

✔️ A documentation suite, not one-off frames with drift detection.

It has a registry that tracks every component you've documented in the file. No hunting scattered frames. It detects drift when a component API changes so you know when docs might be stale
It also has a history timeline (created, updated, recreated) gives you a full audit trail per component.

✔️ Built for real component complexity

People created components in different ways. This really tries to work with how you work:

• Simple components and component sets with props
• Components with embedded masters and nested structure
• Inner props that surface at the outer API
• Related-but-separate pieces (Button/Primary, Button/Secondary as different sets, not one mega-set). Family docs tie those together without pretending they're one fictitious component.

✔️ Prop logic and dependencies

It surfaces non-obvious rules automatically. e.g. "secondary action only applies when primary action is enabled." The doc reflects how the API actually behaves, not just a flat property list.

✔️ Lock in your manual work across regenerations

Extend or rewrite any section, rename the layer with ::lock and that subtree survives updates. AI prose + human polish? Update refreshes what's unlocked. Recreate when you want a full reset.

✔️ Other hits/features worth knowing

• Two profiles: Standard (overview, anatomy, properties, prop logic, showcases) and Minimal (overview + properties)
• Showcases: visual grids over enum axes and boolean toggles, not just tables. Responsive layout adapts to component size
• Export: Markdown and JSON when you need the same truth outside Figma
• Quick nav: jump from registry to docs frame or back to the source component in one click
• Privacy-friendly: runs against your file, no external API required

The core engine is pure TypeScript with zero Figma coupling. So the same analysis logic can power a CLI, codegen, or MCP hooks later.

Try it here: https://www.figma.com/community/plugin/1628339309563064946
It's free. Let me know your feedback, happy to go deeper on any part of it. 🙌

Hey all 👋

After a lot of feedback on my previous icon workflow post, I kept iterating on the idea.

What started as:
scan → organize → export
is slowly turning into something closer to a reusable icon system inside Figma.

Some of the recent improvements:
• Favorites now sync locally across Figma projects
• Smarter icon naming and organization
• Better handling for large icon sets
• Reusable icon libraries via import/export
• Cleaner, ready-to-use outputs
• Keeping the whole flow inside Figma without jumping between tools

The interesting challenge stopped being “exporting icons” and became more about:
consistency, reuse, and keeping things manageable at scale.

Curious:
How are you currently managing icon systems across projects?

What does your icon workflow usually rely on today?
libraries manual?
organization inside Figma?
or custom workflows?

Kore

The default design system in Compose Multiplatform is Material, and honestly, it's great.
But it doesn't allow a lot of deep customization without fighting the framework.

There are also libraries that let you build your own design system completely from scratch but not everyone wants to spend weeks designing UI foundations or writing every component manually.

That's why I created Kore.

Kore is a Compose Multiplatform design system that comes with beautiful pre-styled components which are fully customizable and extensible.
You can use it as-is, customize the theme, or even copy-paste components directly into your project for full control.

One of Kore's biggest advantages is that every component lives in its own isolated file, making it super easy to understand, modify, and extend.
If you want complete ownership over a component, you can simply copy it and rename a few things.

Features

• Beautiful pre-styled UI components
• Easy customization & extensibility
• Theme support
• Isolated component architecture
• Accessible (mostly still working on it )
• Companion theme builder app

Kore also includes a companion app similar to Material Theme Builder for generating themes and customizing your design system visually.

Currently, the companion app is available for Windows and Linux.
A web version will be released in a future update.

Links

• GitHub Repository:
• Kore GitHub Repository
• Quick Start Guide:
• Kore Quick Start Guide
• Releases (Companion App):
• Kore Releases

Hey r/FigmaDesign,

How are you handling design token updates from your dev team right now? In my opinion, tokens should live in code and land in Figma without anyone retyping a hex value.

I just published an update to the Styleframe Figma Plugin. It integrates seamlessly with Styleframe, the Design Systems Styling Engine.

How does it work? You export a W3C DTCG compliant JSON from your Styleframe config, and then import it into Figma using the plugin.

Free and Open Source - styleframe.dev/figma

One of the issues I have with Storybook is that it felt... bare. No docusitey polish, no anatomy diagrams, none of that Zeroheight or Supernova feel. While setting up DS documentation not so long ago, I decided to supercharge and transform my Storybook, with minimal change needed to existing components and done in a scalable way. Not touching the core or SB so I can update it safely in the future. 🧩

I'll get into the other customisations and automation separately, but one part I enjoyed was component anatomy.

Why bother?

To know the key constituent parts, where the affordance lives, what's optional chrome versus core structure. The goal wasn't decoration. It was shared mental models between design and engineering.

The old ways

1. Static diagrams that go stale the moment the component changes
2. A parallel metadata sheet of coordinates, labels, and relationships stored next to the UI instead of grounded in it

The approach

Stamp data-slot or data-part attributes directly onto the live DOM. Two ways to get there depending on your setup:

• You own the component code. Wire the attributes in internally, proceed with core anatomy code.
• You don't (third party lib, or you'd rather not "pollute" component code with doc metadata). This was my case. What I did was have a patcherRegistry maps each component to a small function that walks the DOM of the *live component instance rendered in Storybook*, and patches the slots in e.g. "the label is the second child of the first child of the button." It writes data-slot attributes onto the right nodes, runs on mount, and a MutationObserver keeps it live for anything that portals outside the specimen container.

Once slots are stamped, layout kicks in. ✅

• Measure each labelled element's bounding box
• Compute which side of the component it sits on
• Position a numbered pill in the gutter (top, bottom, left, or right)
• Stitch each pill back to its element with an SVG L-path connector

Everything remeasures on resize and font load, batched through requestAnimationFrame.

The escape hatch 🎯

Anatomy layout is half-algorithm, half-taste. Pills overlap. Things land awkwardly for certain component shapes. Rather than chasing every edge case algorithmically, there's a secret URL parameter. Hit it and every pill becomes draggable. Drop it where it looks right, offsets POST to a local dev endpoint, get saved to JSON, and production reads them back automatically. Reset button if you want a clean slate.

It means the diagrams can always look intentional, without the layout algorithm needing to be perfect. 😊