dan rotondo

dan rotondo

dan rotondo

Main Project Image
Main Project Image
Main Project Image

Magnetizing the Cisco Blueprint Design System

Design System

Design System

Design System

Overview

Cisco's unified design system, Magnetic, aimed to standardize and streamline the design process across Cisco’s Security and Networking products. While embracing Magnetic offered benefits like consistency and familiarity, it also presented challenges in accommodating unique product-specific needs. I and the team addressed these challenges by creating "Wrapper Components" to seamlessly integrate Magnetic into our existing design system, Blueprint.

Goal

The team initially attempted to update their existing components to match Magnetic's, but this proved time-consuming and unsustainable due to frequent changes in Magnetic. A more efficient approach was needed to maintain flexibility while adopting the unified design system.

Role

Design System Architect, Project Leader, Team Liaison (UX, UI, Magnetic teams)

Key Stakeholders

UX Team, UI Design System Team, Magnetic UX/UI team

Background

Our initial strategy of rebuilding Blueprint to closely match Magnetic proved unsustainable. Keeping pace with Magnetic's frequent updates was a significant burden for both UX and UI teams, hampered by inconsistent communication from the Magnetic team. This duplication of effort was inefficient, as many components were already available in Magnetic. We had several things to consider when deciding how to best move forward. Alignment with the UI React Team - Ensure a single, unified library for all product design files to simplify referencing. - Establish a strategy for updating Magnetic together with the React team to maintain consistency. - Allow for flexibility in selecting and implementing Magnetic updates to meet product-specific needs. Maintaining Flexibility: - Enable the creation of custom components and variants to address unique design requirements. - Utilize Magnetic components whenever possible to reduce duplication of effort and maintain consistency. Minimizing Maintenance: - Implement a streamlined process for updating Magnetic components to minimize maintenance overhead. - Leverage Magnetic's existing components to avoid unnecessary development. - Provide a mechanism for creating custom components to address product-specific use cases while maintaining alignment with Magnetic.

Process

Evaluating the options

To effectively integrate Magnetic into the existing design system, I carefully evaluated several options. There were three main paths we could take. Keep what we had and continue to rebuild Blueprint components to match Magnetic. As mentioned earlier, it was extremely difficult to keep up to date with updates from Magnetic (for both UX and UI teams). Plus, having to constantly check for updates from the Magnetic team proved to be very time consuming. I felt we were duplicating the effort for the same output. We were losing a lot of the benefits of a centralized design system with this approach. Use the Magnetic library directly and have a separate file for our products specific components and patterns. This approach allowed us to utilize Magnetic directly and be able to easily pull in the updates as they come. However, there were a couple important downsides to this. First, since the UI team was not able to use the Magnetic UI library, we needed a way to lock the version of Magnetic we're both using. We could just not pull in the updates on Figma, but that would only work with existing files, any new Figma file would automatically get the latest version of Magnetic and we would risk being out of sync with the UI team. Secondly, each product design file would need to pull in both the Magnetic library and Blueprint library files. While this wasn't a huge deal, educating the team on this would not be trivial. Also, if we had things built on top of a Magnetic component, such as a product specific variant of a button, then the button component would be in two different places. The last option was to have a single library file that pulls in all of the components from Magnetic and wraps them. This approach allowed us to still leverage the work that was already done by the Magnetic team, while still having the flexibility to add our product specific needs. It also allowed us to control what version of Magnetic we were on to better align with the development team. Lastly, having a single file for our designers to link in their Figma files and having all our components in a single place made it easier to consume and use our library.

Large Project Gallery Image #1
Large Project Gallery Image #1
Large Project Gallery Image #1

Building wrapper components in Blueprint

To integrate the Magnetic library into Blueprint, we first connected the two libraries. Next, we created a "Core" page where we pulled instances of all Magnetic components. For each instance, we built a local component wrapper. These wrappers were named using the format magnetic_<component_name> to identify them as wrapped components. While styles are typically referenced directly from the Magnetic library, we also imported them into our Blueprint component library for manual screens that are not components. Custom components and variants were organized into specific sections based on their functionality: "Networking" and "Data Visualizations." To improve efficiency, larger and more complex components, such as topology, were placed in separate files. This approach allowed for better organization and potential performance benefits.

Large Project Gallery Image #3
Large Project Gallery Image #3
Large Project Gallery Image #3

Outcomes

Impact and results

The wrapper component strategy significantly improved alignment between design and development teams. It also made maintaining the design system more efficient, as updates to Magnetic could be easily incorporated. Additionally, the team retained control over custom components while benefiting from the standardization provided by Magnetic.

Key Learnings

This case study highlights the effectiveness of the wrapper component approach for integrating design systems while maintaining flexibility. Close collaboration with the Magnetic team was crucial for understanding specific use cases and addressing challenges. Version-locking Figma files ensured consistency with the React team's Magnetic version. By adopting this strategy, the team successfully achieved a balance between standardization and customization, providing valuable insights for other organizations considering a similar integration.