There isn’t a one-size-fits-all manual for building design systems that works flawlessly every time.
What consistently works for me, though, is cultivating a clear understanding of your team’s needs and constructing your design system with those needs in mind.
It’s crucial to remember that the ultimate goal is great product, not just impressive internal tooling. If the design system doesn’t help the team create a better product, what’s the point?
Starting as a new & only designer
Being a new hire, the best way to start building a design system is to roll up your sleeves and start solving real problems with product design projects.
I’m a sole designer at Archilogic. I have to focus on the bigger picture but also engage in the world of pull-requests where daily design problems are solved.
And, once you’re involved on both high-level and low-level sides, actively participating in releasing things you designed, you see where a design system can help.
I spotted inconsistencies, and thanks to devs, I understood why they existed. I witnessed teammates debating on things that shouldn’t be a debate at all from a designer’s point of view.
Trust me, working closely with developers on design implementation in their own environment is the absolute best thing you can do for your future design system.1
In our case, we needed to develop a new design system to help us build more efficiently in less time, unify the way we solve certain product problems, while also improving the overall look & feel of the product.
Due to the nature of the apps, I took time to polish value input components.
As a startup with a small product team (6-8 people), principles-level knowledge sharing wasn’t our goal. Start-ups usually don’t live that long to waste time on that.
Building foundations
I got to play around with ideas before committing to anything in the design system (we named it Honeycomb). Iana, an awesome engineer responsible for building it on the front-end side in our Storybook, joined the company four months after me.
Before she joined, I redesigned both our apps: the dashboard (for managing floor plans at scale) and the editor (for editing floor plans in a human-friendly way).
My goal was to make the apps:
- Unintimidating but professional,
- Build from recognizable blocks, and
- Powerful while remaining easy to control.
Experimenting intesively with new typeface, type scales, grids, and new condensed spacing helped me create the unseen scaffolding that provided much needed structure.
It also helped me be more intentional about which elements to include in the design system and what to leave out.
Eventually, I decided to implement foundational improvements:
- Use the Inter font for its tall x-heights, which make it easier to read at small sizes,
- Use four type scales for body text ranging from 11px to 14px to allow more flexibility in compact spaces,
- Use a simplified pallete of 16 colors to make it easier for developers to use and remember colors2 appropriately,
- Aim for AAA-level contrasts across the UI to improve readibility
- Use an 8pt modular grid with 8 as the default spacer, allowing exceptions for 4px and 12px to create more rhythm
All those decisions turned out to be spot on.
Giving yourself time to experiment before making decisions about the foundations of a design system is the best thing a designer can do.
I tested the changes on heavily loaded inspection panels.
Prioritizing components
Once you have a list of the main components in Figma you have to figure out which ones you should develop first.
Some teams start with components that are most frequently used and easiest to develop. Some even run the components prioritization workshops with this idea in mind.
However, my preference is to prioritize components that noticeably improve the product for customers and help the team building it. I have a good example for it.
While auditing our apps, I realized that we’ll need to do a better job of progressively disclosing features available in both the dashboard and the editor.
Our roadmap was full of great features, but there was a chance that we would add too much complexity to the UI without having a good strategy for showing options for these features upon request.
My solution was to use a proven tactic: an app menu and context menus.
Usability testing for right-click context menus turned out positive. I designed them in detail, and soon Iana started adding them, in all their complexity, to Storybook.
The impact of the menus was immense. It let us progress incredibly fast as now we had a pattern for storing secondary features. It saved the team tons of time in development.
I don’t think focusing on, for example, tooltips would have had the same effect.
We ignored the “easy” components that could help us with some problems in the product to carve out the resources to build a better solution that made those problems irrelevant.
The app menu working in the editor app.
Documenting strategies
Keeping my design system Figma project lean and easy to grasp for the team and maintain for myself has always proved to be incredibly helpful.
I often wonder why some designers opt for separate pages for each component type when beginning to document their design system.
That usually means that in the early stages, you work with nearly empty pages that demand excessive clicking to move between them. Navigating through comments in Figma becomes a nightmare for the team and you.
At Archilogic I’ve kept it flat again and it’s been a living and breathing Figma project ever since. Different cursors moving around at the same time — teammates working together to build something cool and useful.
It’s something you start caring about, especially when you’re the only designer and working remotely.
Another thing worth remembering is that at a startup, you constantly change contexts.
I sometimes design for future roadmap projects, review PRs for a project currently under development, and user test for already implemented projects all on the same day.
I simply don’t have enough time to meticulously design & document every component before marking it as “ready to develop”.
As long as the gaps are small enough for the developer to fill in on their own, and you, as a lone designer, can still control your chaos, IT’S OK.
You’ll always have time to make it right as your system grows.
Of course a typical product audit still makes sense. You'll just do it faster and already have a better understanding of edge cases (e.g., warning modals, error states, and loading states). ↩︎
There are different approaches to naming colors in design systems. I chose to mix actual color names with abstract names. For instance, we used Zurich, Warsaw, Athens, San Fran and New York to celebrate the fact that our team members worked from those cities. Plus, it made them easier to remember. ↩︎