Cisco Blueprint Design System 2.0

A cohesive design system to help teams build enterprise-level digital products

Tools

My Contribution

Team

Figma, FigJam, Maze,

JIRA, Adobe Illustrator

Components redesign, Usability testing, Design documentation, Project management

3 Core Designers, 2 UX Researches

Introduction

Blueprint 2.0 is a refactored/revamped/rebranded design system based on 1.0 that provides a neat design, and a whole new coherent experience to help teams in Cisco to elevate their digital products. This is an ongoing project that started in December 2021 with a team of 3 core designers and 2 UX Researchers.

The Process

Design Principles

Key Components

General

Breadcrumb
Previous
Previous
...
Current
First alone
Previous
Dropdown
Show History
Snapshots
Actions
Tag
Archive
Disabled
Export
Dropdown
Overview
Configure
Analyze
Admin
Dropdown
1
Step 1
2
Step 2
3
Step 3
Problem Context and Background
With the increasing design requests of the our new products - Cisco Nexus Cloud, our design team decided to leverage our existing design system to cater the new product needs. When I was given this task, I thought to start by changing the most basic thing that will affect the overall design - the design system. In Blueprint 1.0, we received feedback from end users on our features and components from time to time. Therefore, after communicating with the marking team, we decided to start with the most controversial component - Matrix.
Audience
These components are currently using in Cisco’s enterprice level products, so our main users are IT professionals. Enterpece products are not meant to be full of techinical jargons and obscre user interface. Therefore, we decided to take this opportunity to engage folks from both technical and marketing team to testout the current design.
Objective
Marix is a component that is designed to how the relationship between two objects. In the usability testing, we wanted to understand how Matrix works from user’s perspetive and how do users usaully check th connectivity between two objects. We created a list of research questions to gain more insights about their current experience, their frequemcy with Matrix comcomponent and their opinions about forming new connections.
Which are the main Cisco Application Centric Infrastructure (ACI) objects that are connected to each other and the details of the connections are meaningful?
What are the goals of users w/r to the connection between such objects.
What does the respondent use today to explore connectivity between such objects and in which systems.
If they are using something other than Matrix component, what is the experience, positives and negatives?
Methods & Procedures
To answer these questions, we used three research methods: design research, semi-structured interviews, and heuristic evaluation to gain information from our targeted audience.
Desk Research (Ledend interview recordings)
To starting off, we decided gather data from the existing Martix component and outside of my organization. This cost-effective and quick research is to help us deterfine what still need to be investigated before test our component.
We reviewed and analye the usability testing data of Martix view conducted by Cisco DNA Center.
Refine our problem statement and determaine what are the questions that need to be furthur investigated.
Semi-structured interviews (Conducted over Webex, ~ 60 minutes)
Interviewed 2 internal users and 2 external testers who have technical and non-technical backgrounds
We encourage testers to use Think Aloud Protocol while completing tasks
Hurestic Evaluation (Conducted over Webex, 3 designers, ~ 60 minutes )
Interviewed 2 internal users and 2 external testers who have technical and non-technical backgrounds
We encourage testers to use Think Aloud Protocol while completing tasks
Key Desk Research Results
To starting off, we decided gather data from the existing Martix component and outside of my organization. This cost-effective and quick research is to help us deterfine what still need to be investigated before test our component.
All participants could accuratly interprete Matrix table, and successfully completed the given tasks.
Having filter feature in a dropdown was not intuitive, it tend to be neglected.
None of the participants thought to click the lable to select the entire row or column
Semi-structured interviews Results
Based on th quantative data we gathere from desk research, we decided to came up a few more questions about the filter feature on our product, and focus more on the interactions of using Martix that has been exist in the existing products.
Participant tent to omit the ledgends on the right size due to the size of the ledgends.
Matrix view is suppose to be the an alternative way to hlep users to visualize the connectivity between two objects, but participants said they still prefer to view it in table view because it does not provide a rich and useful information in the popover box.
Two participants pointed out that it would be hard to navigate if there are a lot of data, and the prototype didn’t provide an example of how they should interact with a bigger matric view.
Inconsist design between table view and matrix view - missing filter function.
Redesign Recommendations
The qualitative data we gathered through user interviews allowed me and the UX researcher to narrow down those user painpoints in to 2 categories: interaction design and informtaion architecture. Therefore, we decided brainstormed a few redeisgn recommendations based on these two categories.
Interaction Design
Keep the design consistant - adding filter feature.
Edge case - How to handle data overflow.
Increse the accessibility: color contrast, font size.
Informtaion architecture
The logic workflow behind filter feature

Foundation

General

Navigation

Data Entry

Data Display

Feedback