Hacker News new | ask | show | jobs
by xnx 1935 days ago
Don't. There are many existing systems to choose from. Very unlikely another design system the user has never encountered before will add value.
5 comments

At a $LARGE_CO and we didn't start from scratch. We're building on top of an existing OSS design system. It didn't take much work to feel different enough as to avoid kneejerk "this is clearly a {bootstrap, material design, etc} website". Overriding the font and color palette goes a long way, though we certainly did more customization.

The challenging part is to get all UI teams to agree to one UI framework. To date, there aren't many a11y compliant web component implementations to build off of. And we have teams with strong preferences for Angular, Vue, and React. With bespoke components for each UI framework, the app feels glued together. Trying to get my director to put their foot down and force us all to align on one.

Which design system did you use as a starting point?
Most design systems solve things specific to that particular company. And the vast majority of available design systems (that is whose documentation or even components are opensourced or publicly available) are any combination of the following:

- abject shit. A material-ui or bootstrap wannabe with poorly thought-out colors, spacing, and interactions. And often has the same problems with sizes, affordances, contrast etc.

- underpowered. Contains too few components beyond the simplest of the simplest buttons and a tab control.

- underspecified (about 99.99999% of all design systems). Does not have any documentation on how elements interact, how they look and work together in complex layouts.

A design system will likely never solve the 'underspecified' problem. You need a visual design team that is holistically aware of all screens in the application, so they can make reasonable suggestions to engineers about how to group components in complex layouts.
That's not entirely true. Even if you use something as full-featured as Material UI, there's still opinions on how elements are composed, when to use font colors and sizes, etc. Without documenting what to do in common cases, every page will end up looking slightly different. I'm the only dev on my team but I already started a styleguide to help me see how CSS changes affect all components, and as a way to copy/paste common patterns.
Feels a little to strong for something that provides deep value for a company and must be unique to your brand in order to truly differentiate yourself.
Most of those existing systems are like a Catholic wedding. The investment of time with those implementations is overly complex and unwinding it from your product becomes that much more complex and costly. Delegate those decisions to the professionals who are hired for the related expertise and point them toward the higher level goals--then hold them to that. They'll optimize their own workflow.