Design Systems
Challenge: Defining, documenting and generating design systems.
Methodology: Kanban
As a product designer in the different companies I have worked for, I have helped audit and test the design systems in use, as well as define and document them alongside the developing team.
Because of my background in color theory and accessibility, I have analyzed the components of the design systems I have worked on, and helped iterate and adjust to the WCAG standards. While working for TrustYou, a data-heavy platform, I helped generate a color palette that was accessibility-proof to help them generate compliant color combinations. While doing that exercise I also proposed a modular illustration system to help the different teams generate compelling visuals with little effort that were consistent throughout the company. That modular system was intended to be software agnostic, generating elements that could be easily used by people on marketing with the adobe suite, people in product with sketch/figma and even product people using Microsoft office. The illustration system would also be accessible using the defined color palette.
One of the main challenges I have faced when building design systems is keep consistency in the component architecture. When a lot of different people have been working with a design system over time, you end up with a product that lacks naming convention and aligned structure. That is especially bad for the end user of the DS –our designers– as they will struggle to know where to find certain components and how to use them. So, very important to pay close attention to structure and naming convention.
For My Investor I put the design system in place and set up the foundations from scratch and defined the structure for the definition of the components.
I am currently working with another colleague in helping align and define the entire structure and logic for my current company DS and putting a meaningful token system in place with the help of a team of developers.
Working closely with devs is a must, to align the DS with the library and to make sure components are well defined from the design side.
Design systems profit from documentation about how components behave (for devs) and their usage and limitations (for design). That documentation and patterns can be set up in the same file or in another tool like Notion.
If you’d like to know more about the project: