DESIGN SYSTEMS
Role
Product designer
Collaborators
2 designers, 6 engineers
timeline
Dec 2022 - Sep 2024
In December 2022, Cisco decided to transition to a unified design system called Magnetic for all applications. My team (Particle) was tasked to figure out how to move from our dark theme, data-dense design to match Magnetic's light, airy style. I was in charge of figuring out the design side, creating components and templates, as well as discussing with engineering the best way to approach changing the UI. I also QAed the prototypes and provided guidance on tokens.
The first step to the theme switch is adjusting the values of our color tokens. Rather than creating a new set of tokens, this would allow our current components to automatically take the changes that we were making, instead of having to fix each component one by one. This is important because we were on a time crunch to have the theme switch done before a demo at Cisco Live. I started by comparing the color scales of our two systems. Two major issues arose:
✻
Color mode: Particle’s main theme was dark theme, and Magnetic only has a light theme.
✻
Color layering: Particle’s colors are based on an opacity scale, Magnetic only has full opacity colors.
Particle uses an opacity scale to convey elevation, show states, and switch between dark and light theme. The number value of a white opacity in dark theme would be the same as a black opacity in the same value in light. It is a core principle on how Particle is built and is used in nearly every component.
We started by changing the values of color variables of Particle’s most important colors that were similar, and then following the scale for the rest. These color styles then updated for our components, and significant time was put into accessibility testing components for WCAG compliance, as well as looking at full page templates to see how cohesive everything looked together. The color changes were presented to designers and engineers, explaining the swaps.
While the color change was important to get the demo looking like it belonged in the application family, a full change would have to happen. We talked to other teams in Cisco who transitioned to Magnetic before us and how they approached it. What we found was that creating a private library for our designers that wrapped the new library components would be beneficial for two reasons:
Code parity
It is unlikely that engineering could immediately switch to Magnetic’s React library fully. There is a lot of functionality missing and for the short term, stylizing existing components to look right would be the best option.
Managing updates
If an update that would break our designs is pushed, our wrapped components would not be affected unless manually updated.
We focused on wrapping the components, keeping properties by revealing nested instances, and also adding the components Particle had, but was missing in Magnetic. This new wrapped library was named COPPER , which stands for Cisco Observability Platform Product Experience Repository.
Creating wrapped components and Magnetic-compliant missing components is one hurdle passed, but how can we communicate the differences the change has made to our product to designers? The problem is more complex than just replacing every instance of a component with the new Magnetic one. Magnetic has its own set of laws – its own grid, guidelines, spacing, and layout. It was the job of Design Technology to create “ideal” templates of what the product would look like fully Magnetic, whether we were practically capable of reaching there or not. This would give engineers an idea of what the final product should look like and give designers an understanding of how Magnetic works. These templates were created knowing that they would most likely be the basis of designers’ work and be heavily referenced. It was a big visual design challenge, but we were up for it. I was responsible for the traces, logs, custom dashboards, and part of authorization templates.
