What is Mountaineer?
Mountaineer is Spectrum Enterprise’s design system that services multiple internal and external products. Mountaineer is built on design principles of inclusivity, innovation, and collaboration. It is built within an atomic framework and it is constantly evolving to better accommodate our end user’s needs, as well as to empower members of our team to be the best they can be.
Company: Spectrum Enterprise, a part of Charter Communications, is a national provider of scalable, fiber-based technology solutions serving many of America's largest businesses and communications service providers. The broad Spectrum Enterprise portfolio includes Internet access, Ethernet access and networks, Voice and TV solutions extending to Managed IT solutions.
My Role: Product Designer - currently leading design system efforts
Tools: Figma, Zeplin, Jira, Dropbox Paper, Storybook, Sketch
Tech stack: HTML/CSS, React (migrating from Angular)
Year: 2021-2022
Design System Leads: Tara MacDaniels, Jason Wagner
Product Manager: Justin Lascelle
Contributing Product Designers: Bridgette Bryant, Elisa Krebs, Jessica Simon, Daniel Cayo, Chris Grant
Researcher: Brian Azcuenaga
Content Designers: Otis Garrison, Ricci Eichorn
Accessibility Architect: Hemanth Bodipati
Lead Developers: Crystal O’Mara, Josh King, Alan Hernandez Espinosa, Blas Yaselli, Esteban Pereira, Amanda Cheng, Brendan O’Keefe
Design Director: Joe Bacigalupo, Lucy Hansen
Build and Iterate
Mountaineer is built out atomically, and was birthed from an audit of existing products, that were built in tandem, but not not systematically. With that there was a lot of opportunity to implement consistency, and refine patterns.
Consistent spacing
Was one of the larger problems, so we have spacing baked into each component. This is easily turned on and off through visibility/color. Also it prompts us to be pixel perfect, and reduces dev effort, since they no longer have to go hunting for spacing in between elements.
Reducing bloat
Throughout Mountaineer there are certain components that require a lot of variation, and building them out individually in our design system files created a lot of bloat. We decided instead to document the different types more holistically, and allow the content to remain dynamic. With implementing this for our cards alone we were able to reduce our components from 154 to 7, and we also have more consistent visual styling for different states. We also use auto-layout to make sure everything is pixel perfect.
Document!
Our documentation strategy began with the creation of sticker sheets, which detail out the variants, color usage, anatomy, usage, as well as any additional notes. This served as a great interim solution, but right now we are currently moving our component documentation into storybook, so the code, design and accessibility requirements are all in one spot. This will be our north star.
Another aspect of documentation that was necessary for some of our larger components were tutorials. Some of our Figma workarounds were atypical, and a lot of our team was new to product design, so in order to in crease designer confidence we began devoting time to documenting some of these more complex processes.
Problem Solve + Innovate
As we built Mountaineer, we realized a large opportunity was refining our method of working and collaboration.
Before: A UX designer works out a feature flow and passes it off to a UI designer who builds it in frames based off their own knowledge of patterns, they then pass it off to a content designer and a11y for checks, and then it gets passed to a product manager to groom for development. As a developer builds this out they correspond with the initial UX designer, and finally the UI designer QAs the final feature before it is released.
The main problem with this was the segmentation, and lack of communication.
Currently: A product designer builds a possible solution with defined success metrics—they see this through ideation up until release. They utilize the standards set forth in Mountaineer, and involve content, a11y, and development early and often. Prototypes are utilized for both product discussions and development handoff, in order to better show complex flows, and micro-interactions. Reusable components where design and code are aligned allow for a less rigorous QA process.
Lessons Learned
While at config in 2021, I had a groundbreaking reframing, where I began to look at the end users of our design system, as fellow designers on my team, developers, a11y architects, etc.
Before that point I had been fully putting the end users of our products as the top priority, and ignoring the needs of the more immediate users. This completely shifted how I think about documentation, building components, and even just introducing people to Mountaineer.
This fully motivated a lot of my push for process changes, and overall has made Mountaineer a more democratic system.
Check out more of my work
-
Helpboard
platform connecting clients and creative freelancers
-
Sushi
Samcart Universal System for Human Interface
-
Guppy
Heal the Bay’s volunteer companion mobile app
-
Expunge Assist
A tool to help people clear their criminal records