banner
rkieru.bsky.social
R
@rkieru.bsky.social
Sr. Developer with a passion for design systems.
We dropped our wireframe kit because it just wasn’t being used. Often our users need something closer to “real” to get actionable feedback.

Just today we were talking about drop downs with preset options and I asked WHY because this seems like overkill. But our users get stuck on the dummy data.
April 16, 2025 at 1:21 AM
And 6 months later the blood shedders find a use case for interactive badges and have an existential crisis.
March 29, 2025 at 11:26 PM
If you haven’t debated passionately about how to visually distinguish chips, tags, and badges (or if you need all of them) can you really say you have a design system 🤠
March 29, 2025 at 1:02 AM
This distinction seems a little blurry. Design/Dev also benefit; the DS shortens turnaround time/ effort, eases transition to new staff, etc.

Just like your target market uses your DS via the product. So the success / failure of a product can inform where the DS may be strong or have weak points.
March 22, 2025 at 4:41 PM
Eh, I’d argue they are one of a group of users. Developers, Designers, Users, and Stakeholders.

Need to satisfy all of them to have the design system succeed.
March 22, 2025 at 2:20 AM
Say you want to position a toast notice. Without teleport/portal you would have to have a toast component always active listening for a toast from some event bus / store. Because you need the toast to load in a specific area.

With it you can initiate your toast anywhere and tell it where to render.
March 16, 2025 at 9:15 PM
Yup. Great for dialogues, panels, toasts, etc. anything that needs to exist on top of the base UI
March 16, 2025 at 9:04 PM
Teleport / Portal are Vue and React components for moving content out of their virtual dom while still controlling them. A common use case is rendering a modal just before </body> for positioning, but without having to have the modal code already there.
March 16, 2025 at 8:46 PM
Our reason for doing so with Stencil was to support multiple frameworks from a single code base. Like most things it's a trade-off. You sacrifice Framework-specific tools but can more easily manage your SDK.

And like most things there is a point of diminishing returns.
March 16, 2025 at 7:45 PM
Great idea in theory; but in practice a non-starter. We HAVE to be backwards compatible with older versions as it's not feasible to update every React app in the enterprise to React 19 just to support web components natively.

And we'd still be w/o Portal and useContext without 3rd party shims.
March 16, 2025 at 7:40 PM
We also use Stencil to support web components, Vue, and react. But lately we are evaluation separate SDKS for each to take advantage of things like Teleport, useContext, etc.

That and current stencil updates are making weird changes to react output.
March 16, 2025 at 7:33 PM
Yup. Being ADA compliant is a core essential for our design system and Shadow DOM just presents too many complications for that.
March 16, 2025 at 7:31 PM
No slots. We build it all out via properties.

<my-input type=“text” label=“My input” tip=“Enter your name” invalid=“Error notice” />

Inside that the label, input, etc are built out with appropriate accessibility.
March 16, 2025 at 6:24 PM
We do the first, without shadow dom due to all its accessibility issues. This lets us connect the input to the label, and the support or error text to the input.

Developers really only need to give it a label.
March 16, 2025 at 6:14 PM
Failed to execute 'insertBefore' on 'Node': The node before which the new node is to be inserted is not a child of this node.
March 10, 2025 at 10:15 PM
One of the things our UX team has been doing is offering up our design system developer (me) to onboard teams to our SDK as well as just good practices with web apps in React / Vue.

I love it. I learn more about the business and its needs and strengthen best practices and increase DS adoption.
March 5, 2025 at 1:08 AM
Gross.

What may be easy for you can be difficult for others. Both can be true.
March 5, 2025 at 1:03 AM
I mean you jest but we recently decided to adjust our buttons to be 4px smaller, which means form fields also get adjusted. And colors get re-evaluated to ensure contrast is still valid.
February 25, 2025 at 3:53 AM
And depending on what this person is building and its audience that may be fine! Not every project needs Figma, or a design system.

There are tools to ensure the colors you prefer generate accessible contrast.

So let’s not shame someone for designing / developing different from you or me.
February 22, 2025 at 4:18 PM
Assuming you’re running macOS how is the text rendering? That’s been my biggest complaint with non-Apple monitors.
February 21, 2025 at 10:44 PM
Maybe it’s down to detail? HIG seems more describing the concept but you can sort of do your own thing.

A design system seems far more opinionated; down to the pixel.
February 21, 2025 at 4:15 AM
I’ve seen this article before and it’s really interesting and vibes with what my role actually is.

But I also wonder if it’s too niche a title to gain traction.
February 17, 2025 at 1:10 AM
‘Small’ generally wouldn’t warrant the investment in a design system. Scale is what makes a DS shine.

Ours includes a Figma kit, an SDK for multiple frameworks which feed back to Code Connect to reduce onboarding new devs to the SDK.
February 16, 2025 at 12:04 AM
I thought so too based on the documentation! But I kept getting an error that the pod file did not exist so 🤷‍♂️
February 14, 2025 at 12:49 PM