Building a Design System at a Startup

I'm not sure long timelines are a requirement. Finding product-market fit seems the aim and having components that facilitate quickly iterating makes sense--especially if the designers and developers can independently iterate in parallel (which is incidentally easily achieved with the right experience and management--and frankly the prior expertise is the time specific benefit). Startups as much or more than any group fail so I don't think anyone has found a formula otherwise the failure rate wouldn't be as high. If the staff can take the design system and leverage it for the next job that doesn't seem as poorly considered as many startup's direction. They did after all get hired to design something so if that system takes less and less time and becomes increasingly effective it might become their own automated side thing.

Author here, thanks for the feedback!

I fully agree - if I were to start a new project today, I would most certainly use an existing design system and tweak it.

We actually did use an existing system/framework at start called ant.design, but we slowly started replacing it. Many components had some kind of a quirk which did not let us use it the way we intended - resulting in various hacks on top of it. As I mentioned in another comment, the rest the design system "crafting" at Deepnote was mostly re-organizing elements and making sense of what we already had and unifying it. This reduced the scope of the work to be done by a lot.

So far maintaining the current design system and using it has not been a time sink, eager to see what the following months will bring.

Lots of companies fail with their design systems because they only commit design resources to them. If you send a perfect Figma mock to your engineers, they'll build it however they want. Unless you have common components that are treated with care and have dedicated engineering resources, it's an uphill battle to actually reap the benefits of the design system.

The whole point should be the DX and productivity benefits you get from the design system. If you don't invest in making it "the easy way" to build a product or feature, teams won't use it well, will see no benefit, will ship more slowly, and have a net negative effect on your customer's experience.

At a startup, a design system shouldn't require so much effort that it requires executive sponsorship. Ideally, the team would start with an existing design system and tweak it to match their target look.

For startups specifically, I suggest getting buy-in on the first few sets of UI screens first. Second, extract common elements into the design system to use as a guide for subsequent designs.

Focusing too much on the design system before the look and feel of the main app screens has been settled is a waste of time. People look at screens, not design elements.

Author here. Agreed, this is a great point. Fortunately, we did not need to craft all componnets from scratch at Deepnote (since they existed in various forms both in code and in designs), so we mostly polished the existing elements and unified them. This means the friction of hand off was significantly reduced and the engineering team was also very keen to look into it as they saw the immediate value in having a single source of truth e.g. for a Button.

Also, you mentioned the framework. We use mainly React + emotion on the frontend (along with Storybook from the article). Happy to answer any specific questions you might have - filip@<company-name>.com

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 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.

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.

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.

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.