All intellectual property presented in this portfolio case is owned by Sift.com.
Role: product designer
Team: me, frontend engineer, design team (workshops and feedback sessions), main product PM
Timeline: 3 months to pilot in Sketch, 1 year to 15 components in Figma and 10 developed and tested components, still being designed and developed
1. UI inventory and roadmap
First things first. I've spent several weeks poking around to better understand how the product work, how design is being done, how handoff looks and how it gets coded.
I've come up with a set of crucial components in prioritized view, based on usage frequency and potential usage on products' roadmaps.
Current components list and pipeline view
I've also spent some time researching how the system works and what entities we have that can be componentized in UI.
This usually looks like this and most components like this fall into organisms group:
For example, team members from this scheme turned into people selector component later.
Team members from this scheme turned into people selector component later.
Atomic approach
I'm usually sceptic about giving too much attention to atomic approach, but it's the only suitable analogy to address some basic principles for building design systems:
-
Components should be as reusable as possible to prevent overwhelming complexity in future (atoms)
-
Complex components should be built reusing smaller ones (molecules)
-
There should be a shared library of not only generic components, but the ones that have business logic behind them (organisms)
This leads to my approach to naming what is what:
Atom — anything that can be coded with a single html tag (in most cases, there still are dozens of ways to overengineer things).
Molecule — any generic component that is built with atoms.
Organism — any component that is built based on business logic (decisions selector) or has any logic in it (search field).
According to Brad Frost, there is no only right way to categorize components when using atomic approach. Each team should just sync on what makes the most sense for them and stick to it. I've come up with this logic because it's clear to both engineering and design because everyone knows how HTML works.
2. Visual exploration
After a month of visual explorations, a dozen of feedback meetings with product and marketing design teams, I’ve come up with several final visual concepts.
Interim explorations
👇👇👇
Final design concepts
3. Design principles
I’ve run a design principles workshop to align on how we make design decisions and how to approach tradeoffs.
Design principles workshop
We’ve come up with these design principles:
4. Tokens
I have pretty straightforward approach to design tokens. They should be put in one of 3 buckets using this logic:
This leads us to storing 3 sets of variables in code and at least 2 in design library, but this way of structuring design tokens allows us control component’s design on any level. Also, we don’t need to make all the tokens shareable, for example, 1st level tokens were enough to built Sift’s website without going too deep into reusability, but still preserve new Sift’s visual identity.
Sift’s token set
5. Components
All the components were built using every feature Figma suggests: auto-layout, variants, properties.
My approach to component documentation:
-
Show properties
-
Animate
-
Teach
6. Code
We had regular meetings with engineering team to make sure all the components were coded right. We’ve set up the process of transferring and QA of the components using Chromatic+Storybook.
7. Documentation
All the materials are documented using Zeroheight to have the one and only source of truth for Product, Marketing and Engineering.
8. Results
✏️ After launching Focus design system pilot, team of 4 Product Designers redesigned the whole product during Console 2.0 initiative.
🖥️ Sift.com website was redesigned by Marketing team using tokens from Focus.
👨💻 Sift’s engineering team established rules and processes around frontend. They’ve never needed to sync on right component or styles usage.
🚀 Focus design system is still being developed and evolving into organization-wide tool that is used not only by designer and engineers.
9. What's next?
We've set up a process that helps any designer or developer contribute to the design system. It includes components database, dashboards, and request forms.
