Do startups really need a design system?
should a startup rally build a design system?
Lately, I’ve been diving deep into the world of component-based design systems. It’s somewhat of a chaotic world, where designers use tools like Sketch to build designs that need to find their way to GitHub in real code.
It involves organization-wide planning, standardization, enforcement, collaboration, and joint work from multiple teams and stack holders. Even for companies like Uber and Airbnb, this can be easier said than done.
However, if done right, the value is great and you gain more than just a consistent UI; you gain your brand. You also improve the R&D’s ability to reuse code, ship faster, reduce technological debt, and make it easy to plan and deliver new features. The benefits will be discussed below.
But…
For a small startup or shop, this kind of project is simply too much of an effort and cost to be practical. The result is that the problem gets pushed back until there’s no choice left, thinking that it should be dealt with at a later time.
But every day that passes means you don’t get to reuse code. It means that you keep creating different variations of components over and over again. It means you confuse users and make it harder for your startup to succeed.
But it doesn’t have to be. You can try going about it the other way around. Meaning, design and write components first, then collect them together, then align the design, and create an ecosystem where everything else follows. Let’s dive deeper, and see how.
Do startups really need a design system?
Airbnb is building a design system. Should you?
Basically, the same benefits that apply to Uber apply to your startup, with a few minor changes based on your different needs. While scaling problems of UI differences or multi-project code standardization might be less painful, every day that passes without shipping is more painful, and the creation of your brand and voice are that much more important.
Simply put, you need to:
- Create a consistent visual language
- Form a brand
- Reuse standard code
- Speed development
- Collaborate to ship faster and better
- Set a foundation to scale UI design and development
We won’t dive into this here, and you can find some great articles on this subject here, here, here, here, here and here. I hope you’ll be convinced.
Can you afford a design system? Should you?
It depends. Let’s say you’re a 15 person startup that is building a web + mobile app for finding and hiring dog walers in New-York.
You’ve launched your product, raised some money, and are working very hard to produce results that will get you to the next funding or grow revenues.
You clearly don’t have the luxury to stop everything and focus on a multi-stage process for building your design system. The branding process alone took Asana a whole year to design. For your startup, this can be a bit too much.
But, this equation changes once you reduce the cost and effort of building a design system and a reusable component system. If you change the way you look at it, reverse the order of actions, you can make it worthwhile. Let’s see.
Adopting a reverse approach
So traditionally, you’d have to go through this process:
- Design your visual language through visual elements
- Produce a style guide, rules etc
- Build a GitHub component library
- Enforce the library upon all app builders
- Establish ongoing communication and regulation, hopefully leading to adoption. This is super hard without collaborative tools.
But, as a startup, you -as always- need to be willing to think and operate differently than you traditionally would.
Since you don’t have the time to stop everything and design your system or build a library, you can go the other way around. In today’s component-oriented world, using tools like Bit for developers, and tools like Sketch libraries/Figma/Invision DMS for designers, you can reverse the order of events and build your components first, then collect them into a system:
- Design the components you need as part of your app
- Implement components as part of your app
- Isolate and collect them to your library
- Audit design to form a design system as components accumulate
- Bring everyone to collaborate and adopt components
Using this methodology you can make sure you only write each component once to reuse and evolve, and that designers can instantly and ongoingly view and monitor UI implementation through the actual components in your apps.
Gradually, you will collect all buttons, sliders, item-lists etc into a collection that becomes your library of components, which is also visualized for designers and everyone else to see and collaborate on. Then, all you need is to take a little time to standardize the design, produce a simple style guide and… you have a design system made of the components already built in your apps.
Design and build components in your apps, then collect your library on the fly
So how does that work, on both the designers and developer sides?
Basically, you can just go ahead and build your app. If you are using a modern stack, i.e. React/Vue etc, your app will probably have components in it. These components will be designed as part of the general design of your app.
Once built, export the components from your app into a reusable system. Using open-source tooling like Bit (didn’t find any other alternative; please feel free to suggest some) you can rather quickly decouple these components from their projects, and let each run as a standalone reusable component.
Gradually collect existing components into a reusable system
You can then gather all your components into a component hub. You can build your own hub, create a local remote Bit collection on your own server, or freely set up your team’s collection on bit.dev- whatever works for you.
Through your hub components can be shared, reused and updated across projects and applications. Each component can be visualized for designers to view and monitor continuously as changes are made to the code. Components can be shared and synced across different apps, to create a consistent UI/UX (modern components hold the power of both, don’t they?).
Standardizing design, as you go
Uber’s primary flexible component example; Your are not yet Uber :)
So once you have your components collected, a designer can view a visual collection of all the UI elements as implemented in your actual apps. You didn’t have to give up a single day’s work, and all your components are visualized in one place for review.
Then, a visual language can be formed based on the implementation of the components, which in turn is based on your actual design…
Now you just have to audit your collection, standardize and organize the rules and guidelines for your visual language, and watch as the collection aligns. As these components are already used in your apps and are now made reusable, chances are pretty high that developers will use them in their next project.
Ongoing collaboration ensures UI consistency
Designer-developer collaboration has always been a major pain-point. There is a huge gap between canvas oriented design tools and GitHub/Gitlab.
Some tools try to generate code from design, but IMO this approach will not get truly adopted by developers any time soon. Software is just too complex.
The only way I see to collaborate is over the real code itself, written by developers. So, collaboration platforms should be chosen to bring designers (and product, marketing etc) closer to the developer and their code.
A few quick tips for ongoing collaboration, that can fit small startups:
- View and monitor exactly how components look and work every time a developer changes them, or just one in a while anyway. It’s easier to prevent mistakes than it is to fix a large bunch of them in production.
- When you as a designer say “design system” a developer hears “component library”. That means a lot of work for them, and time they don’t have.
- You don’t have to wait for a design system. You can design components, have developers implement them, visualize all of them in a collaborative shared collection containing the actual code, and then align the design.
- Create discussions over components, between developers and designers. Have a dedicated Slack channel, or anything else. It’s important.
- Don’t forget that components are the key to both UI and UX consistency. This consistency translates into the feelings of your users. These feelings are your brand. This is more important than the logo you design.
Final words
Small teams and startups often prioritize survival and delivery over what they perceive as “nice to have” values such as UI consistency or preventing bugs.
As a designer, you’d have to worth within these limitations to ensure that while your team delivers and functions at a high pace, it also builds the foundations for a UI design system and a scalable frontend infrastructure to match it from the developer’s end.
Collaboration is the only way to ensure consistency over time. Collaboration is about communication, but also about creating a single system where everyone can collaborate over components. Accept that this system must be developer-first since the code they write is the source of truth that your users will experience. Not your visual element Sketch/Figma/InVision library.
Thanks for reading and please don’t hesitate to share below from your own experience, ask anything or just say hi. Cheers, and stay consistent! 🍻
Suggest:
☞ Top 4 Programming Languages to Learn In 2019
☞ Introduction to Functional Programming in Python
☞ Dart Programming Tutorial - Full Course
☞ Ecommerce Furniture App UI Design - Flutter UI - Speed Code