During one of the Hackathon events hosted at the office, a friend from the engineering team and I started a small project that would become the Umbrella Design System later on. Also, since our daily job was not accounting for us to become the sole owners of any design system we would have to find ways to manage our time efficiently so that we had extra time to work on it.
The main reason why we were so interested in starting this project was that by unblocking ourselves, we would unblock the entire product team and give them a lever for producing better quality work more efficiently. Although we know that the share of the lion would have to be done by ourselves in order to encourage other teams to consume our system.
There was an initial perception from both the engineering team and the design team that this initiative would waste too much time and would not make work more efficient. After all, we could just share our source sketch files with each other, and engineers could just copy and rehash the code from other parts of the dashboard.
So, our main focus was to create a lean process that gave us the flexibility to encourage other teammates to participate and collaborate by adding their own components in the codebase or UI kit as they were creating them.
As new team members (designers) joined the company, and the veteran designers, the ones who worked on most of our current UI, moved on to new adventures, the need was clear. We required clear, documented guidelines to make informed design decisions. We required these guidelines to also be flexible enough to make the components reusable throughout the application, and we needed a lean process that allowed other designers to create, submit, review, approve and oversee the implementation process for components to be added (or updated) to the new Design System.
Designers and engineers were no brainers, but we wanted to expand and create a sense of ownership within all the product teams working in Umbrella. Of course, if you design or touch code you will be a user of a design system, but what if you are a copywriter? So, we decided to involve them in the creation of our copy and accessibility guidelines. What if you are a Product, Project or Program Manager? We wanted them to feel confident to tell a designer or engineer why they thought that the elements that they were using in the mockups or prototypes were not meeting quality expectations, and we wanted everyone in our organization to know that our product team cared about being transparent with our processes.
We adopted Brad Frost's Atomic Design methodology as a guideline for our System. Our core principles were (and still are):
This was reflected both in our UI Kit and in the React library that we called DPL, and we also revamped the old CSS guidelines that take effect on our entire platform that were designed when Umbrella was OpenDNS so that they adhere to Cisco Design guidelines and our new set of principles.
Every component in our system needed to be flexible enough to be used in multiple parts of our dashboard without having to go through specific use case transformations.
Developers working in React, which is our core front-end framework, would make use of the new Design System in their work and could rely on the componentization strategy to create toolkits that allowed for consistent, repeatable code.
In an effort to keep our products in greater sync, the Product Design UX Team and the Design Pattern Library Engineering Team have worked together to create a single source of truth for the visual records of components. This encompassed doing a preliminary audit of the current state of our React Components so that we could replicate the list in the UI Kit.
The goal of this activity was, in one week, get the UI kit up to 1:1 parity with the existing components with the intention of moving forward allowing the design team to be ahead of development for components.
In an effort to keep our products in greater sync, the Product Design UX Team and the Design Pattern Library Engineering Team have worked together to create a single source of truth for the visual records of components.
The goal of this activity was, in one week, get the UI kit up to 1:1 parity with the existing components with the intention of moving forward allowing the design team to be ahead of development for components.
We established a new process for adding, modifying or deprecating any component on the library. The main goal for doing this was the need to have consistency, context of use for each component, and approval by the feature team designers.
One of the things I enjoyed the most was working with the Design Engineers at Cisco. As mentioned above, the project was started by a group of passionate employees who wanted to make the system better. Every designer who contributed a new component, or if changes needed to be made to one, worked with a Front End Engineer in charge of the React components of the system.
The purpose of the UX Guidelines is to provide documentation of rules, behaviors, naming, descriptions and statuses of the various elements, components and patterns used in Cisco Umbrella. This is intended to facilitate the process of evaluating, promoting, updating and deprecating assets between the UX team and the DPL team and aid in bringing consistency to the application.
The Umbrella UI Sketch Library is a set of Sketch symbols used by the Umbrella UX Design Team to create user experiences.
Design Pattern Library and Core CSS are the primary references for UI engineers who are building user interfaces for Cisco Umbrella. The developer resources are owned by the DPL Team, which is lead by engineering.
The Style Team is a cross-departmental team of writers and editors that is chartered to set and maintain standards of readability, usage, correctness, and consistency for Cisco’s technical content. The Cisco Technical Content Style Guide provides writers and editors of Cisco’s technical content with style guidelines. Adhering to the Cisco Technical Content Style Guide ensures that Cisco’s technical content across all business units remains consistent in style, organization, and terminology.
As a company that was born in the Cloud, and with an agile culture, we have been able to influence (and lead) the way the Cloud Security unit and the Security Business Group (SBG) within Cisco. Today I collaborate with the SBG to build "Atomic", a Design System that will be used to unify all products falling under our business unit.
No product would be good if we are not in consistent touch with our users, no matter if you are simultaneously a consumer. In the effort of making the design system really usable for everyone me and my team have come up with some processes to gather feedback.