Pallet Story #2 — How we build and scale our design system
Despite being a 3-year-old-only company, we have invested a lot of thoughts and efforts into our Design system that we have named ‘Pallet’. Get it? Pallet! We try and improve our design system during every project tackled from our roadmap. So, let me detail our workflow and how we contribute every day to the growth of our design system.
Component design is done while building a project. For example, when redesigning our navigation system, we needed tooltips. We created them on this occasion and so on. Once the design is validated on the project by front-end engineers and designers, we import it into Pallet.
To build and maintain our design system, we leverage several software:
How do we work on our design system?
Well, this is a good question. We currently only have 2 Product Designers on the team, and we need to be as efficient as possible to avoid wasting time on low value-added tasks while improving our design system every day.
So here is our method, how we work on Pallet. Of course, you can challenge it! So feel free to give us feedback at the bottom of the article and enjoy your reading.
1 • Set up Google Sheets, Abstract and Sketch
We built a spreadsheet that contains the list and the statuses of all our components, styles and layouts.
- Create a new line for your component, style or layout
At Everoad, if we don’t have an idea for the name, we will ask everyone in the tech team on Slack (based on that, we called our search component Lycos 🐕)
- Add 🛠️ WIP in the status column
On Abstract, we’ve created an environment called / Library Pallet with all the artboards corresponding to our components, styles, and layouts (which are in progress or ready).
- Create a new branch on Abstract
- Name it precisely
We follow this naming rule: Component: Component_Name or Layout: Layout_Name or Style: Style_Name
- Open the new branch on Sketch
Ok, now we are ready to add our new element to our Library on Sketch.
2 • Design on Sketch
At this stage, we add the new component we’ve designed during a project (if there are different states or styles do not forget to add it, engineers won’t guess it 🤭).
Here is what we add on our artboard to be as precise as possible:
- Design specs. and warnings if we need to specify something clearly
🙏 Bench some UX best practices to be sure that what you’ve designed is UX friendly
- A couple of words to explain the usage of what we have designed.
✏️ Always try to be very precise but also concise
- Commit to Abstract by adding some precisions about what we’ve done.
💡 Remember that you are not alone, anyone should understand what you’ve designed by reading a few words about your commit.
Pro tip: At each stage of the process, try to involve designers, engineers and product managers as much as possible to gather feedback in order to build the best design system!
Once the design is complete, we follow these 2 steps:
- Abstract: set the status by clicking on Request review
🖐 Ask a designer and a front-end engineer to review your design
- Google Sheets: change the status from 🛠️ WIP to 🔎 IN REVIEW
👀 Keep in mind that your teammates should know what has been done on the design system
3 • Engineering follow-up: Storybook 👀
Once the element is ready, it will be added to our Storybook. Magic doesn’t exist yet, so you will have to check all the work made by the frontend engineer to be sure that it fits exactly with what you’ve designed. That’s why we’ve created a special workflow with Storybook, Google Sheets and Slack.
We focus on the element we need to review, then:
- Go to inspect mode to check all the UI (font, paddings, size, etc.)
- Open Google Sheets and add a new line with the name of the element, set the status 🛠️ To do, then explain:
⚠️What is happening?
✅ What should be happening?
👷♂️ Assign the task to the front-end eng.
- Once the front-end engineer has made the changes and set the status of our element in 🚀To be approved we will receive an automatic message on Slack to inform us that we have to review them on Storybook — Read “Save time with this custom Google Sheets, Slack & Email test scoring bot” by Ben Collins
- If changes are good, we edit the status from 🚀To be approved to 🤩Done
Now our component, style or layout is ready for use in all of our projects! By working in this way, we saved valuable time for all members of the Everoad tech team. 🍾
Remember 4 important things:
- Always be conscientious
- Involve each stakeholder at each stage
- Communicate and give visibility as much as possible
- Adapt your framework to your team
Thanks for reading! 🙌 🚚 ❤️
Give some claps 👏 if you loved this article, why not up to 50 claps 🎉 🍾 This will encourage us to share more knowledge, methods, and ideas from Everoad!