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.
And 6 months later the blood shedders find a use case for interactive badges and have an existential crisis.
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 🤠
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.
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.
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.
Yup. Great for dialogues, panels, toasts, etc. anything that needs to exist on top of the base UI
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.
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.
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.
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.
Yup. Being ADA compliant is a core essential for our design system and Shadow DOM just presents too many complications for that.
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.
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.
As a developer, how do you determine where new functionality to a component necessitates a spin-off of that component instead of just being a prop?
Custom Selects are a good example. Filter, type ahead, single vs multi, select all and clear buttons…
Failed to execute 'insertBefore' on 'Node': The node before which the new node is to be inserted is not a child of this node.
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.
Gross.
What may be easy for you can be difficult for others. Both can be true.
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.
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.
Assuming you’re running macOS how is the text rendering? That’s been my biggest complaint with non-Apple monitors.
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.
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.
‘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.
I thought so too based on the documentation! But I kept getting an error that the pod file did not exist so 🤷♂️
Decided to setup React Native today on macOS and it was a nightmare. Install Ruby because macOS ruby is too old, install cocoapod, only to have the pod install constantly fail.
I don’t know how or why it eventually started working…
A design system is a living, evolving tool. Anyone thinking it will be right “up front” is setting themselves up for failure.
I enjoyed reading this! One of our constant pain points with OKRs is just getting the quantitative data from tools like Figma, or tracking SDK consumption.
There is no safety, security, or pattern argument I can think of that excuses separate steps for entering your username, and then password, in order to log into an account.
It's so damned annoying.
Over a decade and same. Constantly reminding myself how to loop through objects…
But as I always tell new developers; knowing everything isn’t the goal. Knowing how to find the solution is.
