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.<p>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.<p>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.<p>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.
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.<p>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.
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.<p>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.
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.<p>A design system should reduce decisions out of both.<p>Layout is far more impactful and difficult to get right than colors and fonts.<p>This is why I love Every Layout [1]. I just wish that there was some open source version of those ideas.<p>[1] <a href="https://every-layout.dev/" rel="nofollow">https://every-layout.dev/</a>
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.<p><a href="https://css-tricks.com/leading-trim-the-future-of-digital-typesetting/" rel="nofollow">https://css-tricks.com/leading-trim-the-future-of-digital-ty...</a>
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.
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.