Crafting the Rapidly Evolving Design System

My Role

Product Designer II


2 product designers

1 UI manager,

3 UI developers

Sr. Product Design Manger


Sep 2022 - July 2023


Blueprint 2.0 Design System faced several challenges, including transitioning to design system and ensuring scalability, all while being understaffed.

I took charge of managing and redesigning the system, restructuring components, automating component documentation, and streamlining the process from component requests to design handoff with cross-functional teams.

Within 10 months, I successfully completed the transition. The design system is now used by 7 Cisco data center products, significantly increased efficiency for both design and frontend teams, and ensuring a seamless and cohesive user experience across Cisco's ecosystem.


Blueprint 2.0 Design System

Blueprint (BP) 2.0 is a revamped system that integrates elements from another Cisco design system, updating and improving upon our original BP 1.0 framework.

Previously, our team's design system lacked the cohesive and consistent visual identity found in other products within the organization.

This gap highlighted the need to adapt a new design system widely used in the organization to establish a unified look and feel across our products.


So, what’s the issue?

When adapting to a new design system, how might we optimize existing components, decide which ones to retain, and ensure efficient component update flows?


Navigating the Challenges of BP 2.0 Overhaul

Drawing on my previous experience and deep interest in design systems, I proactively took on the task of revamping our design system. After consulting with other designers in the group and reflecting on my own experiences, I identified the following key pain points:

“It's frustrating to break the instance every time I need to make a change... I waste a lot of time fixing the component.”

— Designer A

1 /

Non-scalable Components

BP1.0's components were not scalable and couldn't accommodate different use cases, requiring a thorough restructuring.

example of non-scalable component

2 /

Inconsistency Between Design and Implementation

Ensuring consistency between design and implementation was difficult, leading to discrepancies and inefficiencies.

example of discrepancy between design and implementation

3 /

Lack of a Standardized Components Redesign Process

Without a dedicated design system team, it was challenging for me to juggle component design requests alongside other responsibilities.

Hey@Charlotte, can you add one more variant to the card component?


Guiding Principles for a Robust Design System

In redesigning the design system, I integrated product needs and identified pain points to develop the following design principles, guiding me towards achieving the goals of the new design system.


Reduce complexity through scalable and adaptable templates


Built trust by consistently delivering quality products and unified solutions


Provided thoughtful solutions that reduce system complexity.


Scope and considerations

Working as a one of the two designers meant I had limited time to develop the Design System alongside other rapid UX work. The Design System had to scale fast, as I was discovering new use cases and constantly rethinking and expanding the library.

To approach this challenge strategically, I conducted heuristic evaluations, prioritized components, and worked with my manager and front-end engineers to establish short-term and long-term priorities.

Heuristic Evaluation


Step 1

Step 2

Step 3

Step 4






Scoping process

Understanding the Pain Points

I began with mini-research sessions by asking other designers about the most frequently used components. This helped me identify the key areas needing attention.

I then conducted heuristic evaluations to understand the pain points in detail. These evaluations highlighted issues with usability, accessibility, and scalability in our existing components.

Component Prioritization

Component prioritization and redesign status tracking board

Setting Priorities for

Maximum Impact

After identifying the components needing improvement, I collaborated with my manager and front-end engineers to establish a set of short-term and long-term priorities.

I created a JIRA board to track the progress of component updates and share visibility with cross-functional teams, including design and engineering.

This systematic approach ensured that we addressed the most critical components first and maintained a clear roadmap for continuous improvement.

CHALLENGE 1: Non-scalable components

Atomic Design

How I build the design system by atomic design?

“Atomic design provides a clear methodology for crafting design systems.”

Since our team was maintaining the same layout and adopting the color palette from another Cisco team, my primary focus was on restructuring components to enhance consistency and reusability.

Example of Atomic Design

Color Tokens

Take check box for example, one of the most commonly used component in tier 1 category. The color first converted from hex code color tokens that is used to build the foundational sub-variants. From there, I build the check box core component paired with Text to come up with the check box template.


At the atomic level, the checkbox is created as a simple, reusable component. This includes the base checkbox and its various states (checked, unchecked, disabled).


The checkbox is paired with text to form a molecule. This combination allows for the creation of labeled checkboxes, providing essential context for users.


These molecules are then used to build more complex organisms, such as a settings panel with multiple labeled checkboxes.


The organisms are integrated into templates, demonstrating how they are structured within a layout. This includes forms, settings panels, and other common UI patterns.

Not Just Components

Incorporating User Research

I worked with UX researchers to ensure that user research was integrated into the Design System. We organized prototype usability studies and other design activities to drive the development of the component library and interaction patterns. This user-centric approach ensured that our components met real-world needs and improved overall usability

Scalability Considerations

Another consideration was designing with real data in mind. While building components, I also took edge cases into consideration. This minimizes the risk of running into difficult “what if” roadblocks at a later date:

What if the text if overflowing?

What if we have 100 data in a table?

CHALLENGE 2: Design-implementation inconsistency

Streamlined Documentation with Automation

Keeping components documentation up-to-date was challenging, especially with a fast-evolving design system. To address this, I decided to document component usage starting with the most commonly used components, including do's and don'ts, best practices, and more. This approach saved me a lot of time dealing with component-related questions.

However, this process took a lot more time than I thought.

Documenting and updating each component required significant effort, not just in writing and labeling but also in ensuring accuracy and relevance. This meticulous process was more time-consuming than I had initially anticipated.

So, I was thinking about how to work smarter

example of “in-line notification” design specification


After research, I found a Figma plugin called "EightShapes Specs" to help automate the process of generating design specs with just a few clicks. This greatly saved time and improved the speed of updating design documentation, making it convenient for developers to inspect and implement.


Because our new design system largely refers to another broder Cisco design system, people can refer the documenation from there for most of the common componenst such as button and input fields, etc

CHALLENGE 3: Lack of a standardized components redesign process

Standardized Workflow

Design system is iterative

A set of components is not enough to maintain a successful Design System. There needs to be enough context to make it accessible for a range of internal users. I aimed where possible to: 


Design critique

Share out



Office hour




example of components request process

  1. Set up weekly design system office hour to solve questions

The twice-weekly office hours are open to anyone, including but not limited to designers and developers on our team and other design teams that reference our design system. This setup is convenient for developers to inspect and implement.

  1. Components request

If an existing component cannot meet the requirements, the designer needs to submit a component update request. This process ensures that all components are evaluated for their relevance and updated as necessary.

  1. Evaluation

Once I receive a request, I start evaluating the situation and usage with the submitter to determine if there is a need to update or create a new component. This step is crucial to ensure that updates are necessary and beneficial.

  1. Design critique

Depending on the scope of the update, I set up critique sessions to bring designers on the team together to gather feedback. This collaborative approach ensures that multiple perspectives are considered, leading to more robust component designs.

  1. Design share out

Upon completion of the updates, I send out an update or hold a short session to demonstrate the changes. This keeps everyone informed and ensures that the new or updated components are correctly understood and implemented.


Lesson learned

Through this redesign process, I learned the importance of coordinating with cross-functional teams and taking the initiative on projects. This experience not only increased my visibility within my team but also across the entire organization. It underscored the value of collaboration, proactive problem-solving, and the impact of a well-structured design system on the overall success of our products.