top of page

Olist Design System

Olist is a startup focused on sales solutions for sellers. We had the mission of empowering olisters to create universal experiences faster, more scalable and more consistently.

Decorative banner with blue olist in the background and system olist design logo inside a white box.

context

Olist is a Brazilian startup focused on creating an ecosystem of e-commerce solutions for retailers and digital brands. In 2021, when I joined the company, I was the first person focused on working in the Design System. At the time, there was already a library in React made collaboratively between some developers and designers.

Print screen of United library of components. The active page shows button options.

discovery

As the team's first steps, we conducted a series of interviews and surveys to understand the main pains that the company suffered in relation to the current library and what should be the team's priority. From these researches, we understood that the lack of documentation of the rules for using the components and their lack of accessibility was the biggest need. That's why we've made the decision to be documentation driven. You can read more about this process in the article I wrote about it.

Pie chart of the with the most used word in the research

documenting

After some research, we decided to combine a content management solution (CMS) with a Front-End developed by the team. Thus, we were able to transmit the standards of our design system, such as:

  • Accessibility

  • Theme change

  • Use design system components

  • Free customization

  • Cost

  • Easy maintenance

Webpage of olist design system. Blue banner in the top and 3 cards in the bottom.

foundation

As the foundation of our design system, we created an elaborate token structure that met some of our needs:

​

  • Enable the use of themes;

  • Be able to test in specific contexts;

  • Be able to quickly change broad contexts;

​

To achieve these goals, we have divided the tokens into 3 layers: base tokens, theme tokens and component tokens. Therefore, every time we needed to make a change, we would know exactly how much it would affect the products.

Infographic of the design token' structure.

For the color tokens, we also added accessibility guidelines to guarantee that a standard color contrast would always be applied (WCAG 2.0, level AA).

Graphic of the color palette, each with a caption inside marking AA level or higher contrast.

components

After finishing the first version of the foundations, we started creating the first components of the design system. We prioritized components that would be used in new emergent products, so they could be created using 100% of the new library. All components were created by the Design System Team, with feedback and collaboration from product teams.

​

Since the lack of guidance was a previous pain from our users, we decided that the component would only be available when it was possible to use it in code and had its usage guidelines documented.

Gif of the documentation page, with preview of a modal component and its guidelines of usage.

summary

Creating a Design System from scratch is an opportunity that is not always viable in companies, but it certainly has its value. It was possible to build a solid foundation so that the products can scale and evolve over time. At olist, there is still the barrier of adoption and migration of legacy libraries, but with the advantages brought by the new design system, these obstacles will soon be overcome.

bottom of page