Hi HackerNews,<p>As an early stage Product & Tech Founder, we often wonder what is the good timing to have a Design System.<p>- Do you think it's too soon during the early days?
- How do you manage product consistency without it?
- Do frontend engineers complain about not having one?<p>Our Founding Designer & Product Manager, Mike, took the mic and tell us why he thinks you should have a design system from day 1: https://www.getlago.com/blog/how-soon-should-you-have-a-design-system<p>Happy to have your thoughts on this!
As frontend engineer, I've used a DS in my current and previous companies.<p>I would say it's even better to have a DS if you don't have your PMF, as you want to save time instead of discussing about design implementation details and fix inconsistencies.<p>The sooner is the better IMHO. I've experienced the pain to build a DS on top of an existing app and it was a real nightmare.
The effort to add the usage of the DS in our routine and the time spent to implement components and switch existing code to use them was not bringing any value to the business.<p>Also, it was very hard to advocate for its necessity while teams were not focus on feature build.
I know we all love to say values does not only comes from what you ship but also from the code quality. However many companies in facts only look at KPIs, and building a DS on an existing product only have mid-long term impacts. Nothing you can notice soon.<p>You can base you DS on existing libs like materialUI or such. No need to build everything from 0. Iterating over already existing components and adjusting details is not that much an effort.<p>I don't see myself building a product anymore without one. It's such a time saver.<p>That said, I don’t think I would join a company that does not have a DS implemented.
Depends on your people and what you define "design system" as. For most startups I'd highly recommend using off the shelf component libraries so that you don't waste time reinventing the wheel, and have your ux designers use those to assemble bigger patterns that can be reused. (Here's how we list things out, here's our tables, etc). Pick a framework that can easily use your branding colors and fonts, boring tech like Bootstrap, etc can go a long way here.<p>Developing a "Design System" can be a time sink in the wrong hands though, your people shouldn't be more interested in making that vs your product.
In my experience not having a design system will produce so much overhead that investing in it early is warranted. It depends on how design-y your product is, though.
What's the alternative? Cutting and pasting instead of using masters in Figma, or repeating styles everywhere rather than using variables in your CSS? The results either way are inconsistent UI everywhere.<p>Yes you should have consistent design. That doesn't mean you can't change your design, it just means you make that button change in one place rather than 94.
Like all things, it depends. (Disclaimer: I do this full time and have implemented at 2 different public companies now)<p>If your goal is to figure out PMF, Im not convinced you need a design system.<p>If your goal is to scale once you have PMF, I think its really important. Helps a lot with speed as you go from 3 engineers to 30 to more.
I have no experience with big projects and infrastructure but I believe that having a design system from the beginning can avoid a lot of headache in the future. I personally always make a "mini design system" for my personal projects. Besides, it's kinda cool to make design systems.
When do you think it's too late though?<p>In some of the companies I've worked at, design was the last priority and at some point, making the effort to switch to a proper design system and do the front-end migration seemed too daunting. So it was never prioritized, until the exit.
> - Do you think it's too soon during the early days?<p>No, but you can just take one off the shelf and adjust colors / fonts.<p>- How do you manage product consistency without it?<p>You'll need experienced designer that knows how to gradually build it. Otherwise I can't see a way without.<p>- Do frontend engineers complain about not having one?<p>No, because we have one, but they complain when components could be used but something slightly different was designed.<p>A friend runs a consultancy and we recently spoke about it. They build e-commerce type of websites, they start with a simple mockup, once they are ready they build style guide/components. All other pages are just assembled from these components - don't think this works for completely bespoke software, but it demonstrates that in some cases it's integral to the rest of the process.