Some experience from dealing with this recently: Unless you have a very large design team and long timelines, it's best to start with an existing design system and tweak it. Adjust it to your liking, get buy-in, and then agree to keep it locked in place except for minor adjustments. Save the big goals for a V2 design to be launched at a later date.
A design system is only as valuable as the time it saves. If the design team spends months perfecting a design system and associated sandbox demo before they can even get to the core design work, it's unlikely that it's actually helping deliver the product on time.
It's also dangerous to let the design system become a moving target, where the design language changes from week to week. Each change will burn developer time integrating the changes, which will inevitably turn into multiple sprints dedicated to creating a theming system for your products, none of which really moves the product forward.
In a true startup environment, if you can't get the design system 90% complete in the first week or two, it's at risk of becoming more of a liability than a benefit.
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.
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.
The hardest part of building a design system is getting the organizational willpower to commit to it. There will always be another high priority feature to build, so to get it done you generally need executive level sponsorship.
Design systems are valuable but ultimately best tackled as an accelerant (/luxury) investment at scale. Your customers are unlikely to buy your product or churn from it due to not having a design system in place, so you really need to look at overall design/dev productivity as the benchmark of whether the investment is worthwhile.
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.
I'm surprised this post didn't mention the ui components (front end code in whatever framework they use) in the system. in my experience, a design system thag only caters to designers will get little adoption, particular in larger organizations that could benefit from having a system in place.
in my experience the designers built a sophisticated system they used to streamline the design process across teams and projects, but it felt short during handoff with those teams that didn't have the resources to build new components.
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
In my mind, there are two distinct aspects to an UI. The skeleton and the surface. The skeleton deals with the layout of the various elements while the surface deals with colors, font families and sizes.
A design system should reduce decisions out of both.
Layout is far more impactful and difficult to get right than colors and fonts.
This is why I love Every Layout [1]. I just wish that there was some open source version of those ideas.
Line heights are still a pain for consistent spacing in the browser. I'm really hoping for more progress on CSS Inline Layout Module Level 3 and the `leading-trim` property.
I am well established designer. I never worked for startups and probably never will. Why?
As a professional you know already how to do your work. My personal problem is the growing trend in which designers are decorators but they are called "product designers". To be effective at design, you have to grasp fully the product technology and core values. Where are those professionals?
The Answer: They work at established businesses and companies. Startups have to focus on speed and iteration. I have advice for them: Invest in well designed templates/design systems and focus on core business functionality. When you have real business with ROI - this is the time for hiring professional designer and get more from your product.
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 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.
As someone who has done this at work, build it in such a way that your documentation is also your sandbox. That way whenever you go to design something new, you do it in your sandbox, and then the documentation is already done.
A design system is only as valuable as the time it saves. If the design team spends months perfecting a design system and associated sandbox demo before they can even get to the core design work, it's unlikely that it's actually helping deliver the product on time.
It's also dangerous to let the design system become a moving target, where the design language changes from week to week. Each change will burn developer time integrating the changes, which will inevitably turn into multiple sprints dedicated to creating a theming system for your products, none of which really moves the product forward.
In a true startup environment, if you can't get the design system 90% complete in the first week or two, it's at risk of becoming more of a liability than a benefit.
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.
Design systems are valuable but ultimately best tackled as an accelerant (/luxury) investment at scale. Your customers are unlikely to buy your product or churn from it due to not having a design system in place, so you really need to look at overall design/dev productivity as the benchmark of whether the investment is worthwhile.
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.
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.
in my experience the designers built a sophisticated system they used to streamline the design process across teams and projects, but it felt short during handoff with those teams that didn't have the resources to build new components.
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
A design system should reduce decisions out of both.
Layout is far more impactful and difficult to get right than colors and fonts.
This is why I love Every Layout [1]. I just wish that there was some open source version of those ideas.
[1] https://every-layout.dev/
https://css-tricks.com/leading-trim-the-future-of-digital-ty...
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.
- 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.