Pickers
Pickers is a creators network that provides publishing, payment, and design infrastructure to support subscription newsletters. It allows writers to send digital newsletters directly to subscribers.
2022
Pickers
Design System Lead
Style Guides
UI Components
Pattern Libraries
Design Templates
Documentation


Starting point
Back in 2022 I was tasked to collaborate with Engineering Lead and Design Head to design and document the Pickers design system.
In order to formulate a well-structured plan, I needed a comprehensive understanding of our objectives and to moving forward, I would like answers to the questions below.
What is our goal?
Why is it important for us?
How it will help us?
How many resources can we put into building it?
Who is the design system for?
Do we want to build a public design system?
Will our design system be static or dynamic?
Talking with stakeholders and having an answers to all those questions I could scope the objectives we wanted to achieve.
One source of truth
Maximized effectiveness
Increased ROI
More time for important stuff
A systematic compilation of reusable elements, governed by well-defined guidelines.
Improved collaboration and more efficient teamwork.
Accelerated productivity, minimized redundancies, and significant cost savings
Efficient structure frees up time for the team to concentrate on higher-level tasks.
Research and audit
As there was already something designed I started auditing and collecting materials.
Questions I tried to find answers are:
What are the reasons behind incomplete key user flows?
How would you describe the overall identity of the project?
What messages do the visuals convey, and do they align with both our target audience and business goals?
Is there consistency in design, color palette, and typography across all materials?
I captured screenshots of everything that comes my way. Subsequently, I consolidated all these elements in Figma, where I annotated extensively and meticulously scrutinized the visuals and functionality to identify any potential flaws.
Compiled a comprehensive report detailing the issues I discovered, their severity. This report served as a roadmap to guide the team through the current state of the product.


Design and documentation
Creating a design system is challenging and can feel overwhelming, as there is no universal approach that suits every situation.
A design system goes beyond a collection of reusable assets, so it has to be an adaptable system of foundations, patterns, guidelines, components, and tools.
It's worth noting that design systems can vary significantly, ranging from relatively basic ones to highly advanced and comprehensive frameworks.


It's worth noting that design systems can vary significantly, ranging from relatively basic ones to highly advanced and comprehensive frameworks.
Foundation
In order to make a design system scalable, I decided to use design tokens. But before starting to do so I needed to communicate to engineering lead the following benefits:
Use of the same language.
Synced files.
Solid foundations.
Easy maintenance.
Less design and technical debt.
Brand consistency.
Improved communication between teams.
One source of truth, consistency on all platforms.
Steady design system brings value.
Edit in one place, update all at once.
Fewer resources are spent.
Creating new products, maintaining uniformity, and managing a brand are becoming more accessible, faster, and cheaper.
These token names or variables, store design details in a simple, easy-to-read way. They work with all style files in our system, making design consistent and easy to scale.


As a result, I have built all the foundational tokens that has become the backbone of our design system and has helped us maintain a consistent visual style that is easy to manage and maintain.


Components
After developing the foundational design tokens, I created a set of components that represented different design elements.
I wanted to avoid having an excessive number of components, especially with only minor differences between them, as it would add complexity and, ultimately, lead to a lot of technical debt.
And to understand if the component is valuable enough to be part of the design system, I asked myself:
Is it used across multiple flows?
Is it used by many brands/products?
How does it align with our design principles?
Does it solve a specific problem?
Is it reusable?
Is it flexible?
I started with the most impactful steps first so begun with the commonly used components and moved from the smallest building blocks to the bigger ones.




Documentation
Defining foundations is pretty straightforward, but the magic and hard work for me lies in shared understanding and unified language.
In order to provide a single source of truth for coordinating assets, code, design principles, and guidelines, I used Bit.dev.


I have added details of where, when, and why to choose it. Explained how the component can be combined with others to make the user flow as smooth as possible.
Metrics
Metrics are the language of stakeholders and the evidence that we are maximizing the usage of our design system.
To be able to measure results I needed to know three simple things.
Is the investment paying off?
Did we increase the component adoption?
Are we providing value with the design system?
Results
After implementing design system for 3 months, significant results were achieved.
74.8%
design system adoption
28%
reduction in task completion time