1.9.4 released - Preparing for styles - Blog

We just released another minor update to our shadcn/ui kit: 1.9.4. As always, you can see detailed changes in our changelog.

In 1.9.3 and 1.9.4 we continued to move customizations on the component level into the OC (Obra Custom) layer.

Examples include the Extra Large marketing button becoming an OC component in 1.9.3 and moving the rounded versions of inputs to the OC layer in 1.9.4.

For clarity, the 3 layers in the kit are:

Official shadcn/ui components
OC (Obra Custom) components: additional components we use in the Pro Blocks
Custom components: an empty layer for your own customizations

In this blog post, we expand on why we’re making this move.

Who the kit gets used by#

Our Figma shadcn/ui kit gets used for very different design needs. Roughly:

Hi-fi wireframers — people who use the kit as-is to put together polished screens fast.
Design system designers — people who use the kit as the starting point for their own system.
Technical designers and developers — people on the receiving end, turning the result into code.

The “right” way to set up the kit is in the eye of the beholder. When designing the kit, we always have to balance these needs against each other.

For the wireframer: completeness and workflow#

For the first type of user, choice is great. They generally won’t make sweeping changes to the kit itself — they’ll use the components as they are. So they evaluate the kit on two things:

Completeness — does it have all the shadcn components?
Workflow — can I work with it smoothly?

I once got a huge compliment from a design leader at a FAANG-type company. He said he had evaluated all the kits and ours was the closest to how he actually worked, in the way components were set up.

For the design system designer: it’s essential to be able to remove things#

For the second type of designer — the design system designer — being able to remove things is just as important as having things to start with.

Shadcn/ui is built around a small set of variables, and those variables can be the start of your system. It deliberately makes few design choices for you.

We’ve spent specific time making it clear how to strip the kit back. A few examples:

The color palette can easily be reduced to only the colors that are actually used.
The icon set has markings for which icons are in use and which aren’t, so it’s easy to swap out the ~30 icons that are wired in by default.
The set of typographic styles is intentionally small: headings 1–4, paragraph styles in four sizes, and (recently) a few monospace styles. It’s easy to grasp and easy to start customizing.

In contrast, we’ve seen competing kits that throw 100+ type styles on your plate. We don’t love that approach.

For the design system designer, the question is “can I actually fit my design vision into this kit?” A lot of our deliberate choices come from looking through that lens.

We’ve also gone as far as building a custom component documentation plugin to have full control over how component documentation looks. That plugin has plenty of workflow tricks — you can use it to migrate away from Propstar, document different variable modes, and make complex component selections easily.

For the developer: alignment with shadcn/ui#

The third group is the people who turn the kit’s output into code — and ultimately, this matters for everyone handing work off to development.

In 1.8.0 we removed every unofficial variable that had snuck into the kit, in favour of aligning 100% with shadcn/ui from a development standpoint.

Moving unofficial additions to shadcn/ui to the OC layer makes it clear what is official and what is not. We are now preparing for releasing the React version of our Pro Blocks. The more unofficial parts we have, the less easy it is to integrate with shadcn/ui. At the same time, those unofficial parts often were made for a reason: we felt we could make an improvement on what shadcn/ui provides. We’re thinking deeply about how we can provide our opinion layer without breaking workflows. One way we do it is filing issues on shadcn/ui when we don’t agree with a design choice.

Last month, on April 11, we published our CSS Export plugin. It took a few weeks to review, but it’s on the Figma Community now. It lets a designer make changes to the kit and a developer sync those changes back into their system. We support several output formats — from a standard Tailwind setup to token-based formats like Design Tokens 1.0.

Why we move customizations into the OC layer#

Coming back to the spark for this post.

At the component level, we used to lean towards choice — providing extra sizes and variants on top of the default shadcn ones, baked into the components themselves.

I’ll repeat the primary examples:

An extra large version of the button
Rounded variants of the input
A required marker on the label

Now, we realized these extra choices that we provided would also create a downstream problem when developing with those components. If we have a rounded version of an input, and shadcn/ui doesn’t have it, a designer uses it, a developer might be puzzled where to find it.

The kit today is built around the Vega style. We’ve been thinking for a while how to support the new shadcn/ui styles (see: shadcn/ui create) in our kit. We currently ship the Vega style, and offer customization services where we customize our own kit to customer’s brands.

We would love to find a maintainable way to support all styles, but so far, haven’t found a realistic way to do so.

The move we’re making now, where we are keeping the base components clean of our own additions, is what eventually lets us support Nova and other styles.

This helps both types of designers:

The wireframer can still use the extra sizes and variants — they’re right there in the OC components.
The design system designer can delete the entire OC layer cleanly and start from a kit that’s purely shadcn.

This move, while small, lays the philosophical groundwork for where customizations live, and how we will eventually support all styles.

One thing we want to know is who is running into this problem. Do people actually use the shadcn/ui styles like Sera and Luma? Since Nova has been the docs default since late 2025, we are pretty sure Nova has a high usage. If you have any details about this, or your team is struggling with Nova vs Vega issues, we’d love to know.

Last call: 25% off in May#

The May launch discount is the final one — from June, full pricing kicks in. Use LAUNCHMAY at checkout.