Build a system that would improve our workflows, serve as a source of truth, and lay the groundwork for future designers as the team grew.
When I started working with Massdrop, there wasn't yet a design system or centralized process to keep all its components and styles documented and easily accessible. We often spent time rebuilding components and occasionally worked off screenshots of previous designs.
The other designer had started building an early system, but I took over growing and maintaining it when I joined. This is how I did it and lessons learned.
We started by aligning on a framework to organize components, beginning with atomic, and defining them further as simple, complex, structure, and feature-based.
I conducted platform audits, added components as we worked on projects, and reviewed regularly with the other designer for feedback and buy-in. Here are some key takeaways from the process:
First, not everything needed to be symbolized. For some components, it was enough to document patterns for reference as our source of truth like with username titles.
Also, while tempting to nest everything to the max, it was more efficient and straightforward to create unique symbols states for simpler components like buttons.
However, I did use more complex nesting to make it easy to customize highly variable components like menus and content cards.
For components with nuanced functions, I added brief notes on best practices when/how to use each. These would serve as educational tips to define standards and quickly onboard new team members how to use our system.
Though component audits and as we developed new features, I noted design inconsistencies and opportunities to standardize UI patterns. For example, as we added functionality for user generated content and moderation tools, I aligned our team around set padding and IA for all feature modals.
In our design team of 2, we could meet quickly and informally to reconcile inconsistencies, but I imagine larger teams would require more formal meetings and discussions.
As our system grew, we needed to be able to find frequently used components quickly and easily. So, I created...
- sticker sheets to find/view content cards, widgets, and banners
- a central file with all our latest page layouts to reduce time searching and rebuilding
The ultimate goal for this system was to make our workflows more efficient and create cohesive experiences. So, I created Sketch libraries and systems to make it easy to access and work off our latest components.
I based our naming structure around making it easy to find components in Sketch's libraries. Specifically, grouping them by platform and inspired by BEM (block, element, modifiers).
To ensure good usability, I regularly reviewed with the other designer to share new symbol and component updates, collect feedback, and make iterations.
As we constantly ran tests, we needed a way to distinguish between live, in-test or not built, and old components. To solve this problem, I used emojis to visually communicate states:
Not a perfect process
There were no doubt pros and cons building a design system in a small team of 2. While we were able to move fast and align around standards and processes, as I was concurrently working on other projects, its development took time and occasionally ran into issues.
Build, review, iterate...and repeat!
A design system is a living, breathing tool that's never perfect or complete. Talking and reviewing regularly was seriously key to building systems that worked for our specific needs.
Scaling pains
As your system grows in components and complexity, files can get big, naming confusing for teams, and remembering to check for library updates cumbersome. If using Sketch, leverage multiple libraries to keep file sizes down and be tough on what should be in your system.
In my next design system building life, I'd try out Figma for their better real-time collaboration tools and partner with engineering to get their feedback and buy-in to grow our system even further!
