Building a Design System at a Startup

Building a Design System at a Startup(medium.com)

77 points by sunaden 5 years ago | 20 comments

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.

jimmont 5 years ago | |

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.

sunaden 5 years ago | |

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.

staysaasy 5 years ago |

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.

bastawhiz 5 years ago | |

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.

PragmaticPulp 5 years ago | |

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.

627467 5 years ago |

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.

sunaden 5 years ago | |

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

pdamoc 5 years ago |

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/

n0w 5 years ago |

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.

https://css-tricks.com/leading-trim-the-future-of-digital-ty...

nbzso 5 years ago |

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.

xnx 5 years 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.

soperj 5 years ago |

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.