🍳 Breaking the Mold: Fixing What Ain't Broken
“Don’t fix what ain’t broken.” This is what we usually say when something is currently working, however in the case of Kumu’s design system, this is exactly what we didn’t do.
Client
Kumu
Duration
Ongoing
April 2022 - Present
My Role
Product Designer
Design System Point of Contact/Owner
Scope of Work
Figma Componentization
Design System Management
Documentation
Prototyping
Stakeholder Management
Introduction
For roughly a year before I was hired, the Kumu design team already initiated a design library housing their most used components. However, as most lean design teams go, feature designs that needed shipping took precedence in priority.
As an eager new hire, one of the things I wanted to do was take over the design system and revive paused efforts.

One driving force I had in hindsight was the experience of not having a working design system. Frustration seeps through in an unstructured design file when there are no consistent or if there are poorly constructed components unusable for the rest of the team.

It wouldn’t be easy taking over a design system and convincing our design manager/lead to give me reigns of the endeavor. So I did the most reasonable thing I could: I asked.

He said “Have at it.” (Or something along those lines)
Objectives
Complete the design system.
This include the design library components, guidelines, and workable repeatable code. This also means rebuilding existing components to make use of variant properties

Streamline design process.
We do this by reducing time looking for components in the existing library using universal naming conventions. This mean understanding what designers call the components and agreeing on what refers to what. (i.e. Snackbars vs Banners vs Alerts)

Enhance collaboration across functional teams.
This means having the developers have a say in how components are built, having Project and Product Owners understand which design patterns to solve problems.
Documentation and Audit
Creating an audit of the existing design library of what’s missing, what’s usable, and what is unaddressed. Collating screenshots of existing components in the app, often with redundant functionalities.
Prioritizing
Determining the most-used components across product teams/squads, which is used as-is, frequently detached, etc. 

Conducted a survey within the design team to identify what components to prioritize first. 
ARTIFACT: A templated Design System Work Plan including a priority list of components to tackle in succession. 
Rebuilding Components
For components that already existed, I prioritized recreating them using variant properties and adjusted auto layout as necessary. We used the same principles in designing and recreating all other components.
🧩 When applied
For instance, we had an existing bottom sheets component, but it needed improvement. The existing component was not optimized to resize across different mobile sizes, and its variants were incomplete.

To address the issues with the bottom sheets component, we undertook a recreation process that would preserve the design while improving functionality.

Using Figma's auto layout feature, we recreated the container and connected text and color styles to each component. To reduce the need for additional variants, we also established relevant variant properties.
Here's a video detailing the work done for the bottomsheet component
🧩 When applied
Another example is when we reduced the variants for the Tabs component by utilizing the variant properties. In doing so, we managed to significantly reduce the number of variants used.
Before using variant properties
After using variant properties
Writing Guidelines
We established component standards in the guidelines, which covered the component's usage, content, and behavior.

Usage guidelines specify when to use the component, when not to use it, alternative components, and variant requirements.
Content guidelines detail visual specifications, such as redlines, size, spacing, and fonts as necessary.
Behavior guidelines document interaction behaviors and affordances of the component.
Snippet of the bottom sheet guidelines
Snippet of the button guidelines
Iterating
Whenever a component is finished, a video walkthrough would be posted in the internal Slack channel for the designers’ review. An actual review is then conducted during a separate design system workshop following a design critique format.
After using variant properties
Results
Restructuring our design system has transformed our team's workflow. Designers now dedicate more time to actual design work, thanks to a streamlined component library that minimizes manual building. Clear guidelines have slashed communication gaps between designers and developers.

While our project is ongoing, the component library is steadily advancing, ensuring unfinished components don't compromise the overall design system consistency, deeming them lower priority. The positive impact on efficiency is evident, marking a significant improvement in our team's quality of life, proving that sometimes breaking the mold is the key to unlocking greater success.
Some much appreciated kudos from teammates re: the design system work
Key learnings
đź’ˇ Learning
Delegating
‍‍
Since designers are spread out across pods, managing the assignments on component work was tricky to manage. Fortunately, designers who utilize components specific to their pod’s use case volunteer to create those components. We would then organize huddles so I could teach them how to organize and structure their components using variant properties, auto layout, etc. These 1:1s helped foster deep work and collaboration with the assigned designer.
đź’ˇ Learning
Exposing the work to the other stakeholders.
‍
To effectively communicate our progress to stakeholders beyond the design team, we used Product Weekly sessions, held every Friday, where all pods and relevant departments share updates. This approach successfully ensured that the product team was well-informed of our design team's activities.

However, to further improve our efforts, we recognize the need to involve more developers working on the implementation of the Design System Workshops. By encouraging their participation, we could gather valuable feedback and insights on the feasibility of the designed components while also facilitating open communication channels for them to ask questions.
đź’ˇ Learning
Usability testing with components.
‍
Involving the rest of the designers in the feedback loop was crucial in ensuring that the team are aligned with component requirements and guidelines. Having them test out the components during an organized workshop helped identify what to fix and how the components performed when used by different designers. Hearing their feedback at the same session helped foster transparency in the design system.
🙇‍♀️Acknowledgements
I'm immensely grateful to the remarkable design team I had the pleasure of working with at Globe Telecom, particularly to Dan Tamayo whose guidance at Globe helped me understand design systems better and housing it on Figma. These newfound skills have proven instrumental in my collaboration with the Kumu design team.
‍
I wish to extend a resounding shout-out and heartfelt thanks to my exceptional colleagues at Kumu, starting with our design lead, Leroy Almeida, who entrusted me with this undertaking and provided invaluable feedback. To our skilled designers, Anezka, Clarizza, Kath, Arvin, Denise, Cabs, and our incredible illustrator, Annie,  I express my utmost appreciation for their collaboration and input in developing our design system.