Création of Sellsy design system
Initiator, Product designer
Research, conception, tests
We were the first to designers since the creation of Sellsy in 2009. As soon as we arrived, we started to work on our first projects while organisatig the brand new design team
In the beginning, we started to organize our files in different projects by creating our firsts local component libraries. Every week, we met to list our latest creations and advances.
As the projects progressed, these points became more and more time-consuming and sharing our files became more and more complicated.
We had to find a solution to better structure ourselves within the design team but also to be fully integrated within the product team and its stakeholders.
Initially, we met only between designers to study our own needs and look for initial solutions.
Then, we started to integrate the developers (back-end and front-end) as well as the product managers in order to collect their needs to create a design / development / management bridge as efficient as possible.
From our first exchanges, two main needs were born for all stakeholders:
Shared in real time, with automatic updates for everyon
Versioned, in order to allow a follow-up of the evolutions for all the teams.
So we turned to a solution that was beginning to emerge at the time: A product design system.
This design system had to meet all the needs. Regarding its content, we first divided it into two main parts:
A style guide
Combining our graphic and typographic assets as well as our spacing system
A component library
Inspired by Brad Frost's Atomic design approach
This design system was hosted in the Abstact versioning software, to allow project tracking for the entire product team. Each time Sketch or Abstract was updated, we took the opportunity to improve the structure of the design system (e.g. shared libraries).
00.Icons : File apart from the rest, this one gathers all the icons we have created for the software.
01.Atoms : This file gathers all the isolated elements present on the platform. Some are only intended to be assembled, others to be used directly.
02.Molecules : Adding several Atoms, the Molecules will generally be declensions of the same element giving different information.
03.Organisms : Associating Molecules and Atoms in order to form more complex and modular elements by modifying the Atoms and Molecules linked to the component thanks to the Overrides function.
04.Templates : Gathering the different page templates available on the software
The component library: inspired by the Atomic design approach, adapted to our needs
The naming conventions of the components have been worked out together with the developers in order to speak the same product language.
A few months and two other versions later we could see several things:
Continuity and consistency in interface design
Because our components are documented and factorized in shared files, all creation comes from the same source, the slightest change has an immediate impact on projects.
Time saving in interface creation:
Because the components are available and adaptable to the context, the UI is created faster. We could therefore concentrate more on research and experiment work.
Collaboration with other teams made easier:
Developers and product owners only had to access Abstract to find all the components and their documentation