Live data from Hacker News

Building a Design System at a Startup

medium.com

11–20 of 21 posts

Re: Building a Design System at a Startup

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

Re: Building a Design System at a Startup

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

Re: Building a Design System at a Startup

#13

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 de…

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.

Re: Building a Design System at a Startup

#14

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 de…

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.

Re: Building a Design System at a Startup

#15

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 desi…

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.

Re: Building a Design System at a Startup

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

Re: Building a Design System at a Startup

#17
post #2

Don't. There are many existing systems to choose from. Very unlikely another design system the user has never encountered before will add value.

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.

Re: Building a Design System at a Startup

#18
post #16

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 proje…

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

Re: Building a Design System at a Startup

#19

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 desi…

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.

Re: Building a Design System at a Startup

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

[1] https://every-layout.dev/

Post reply on HN