design systems & team processes
Summary
Throughout my time at Zigzy and Credit Repair Cloud, I have been in charge of conceptualizing and maintaining three distinct design systems across two diverse products (Cosmos, Credit Repair Cloud [HTML system], and Credit Repair Cloud [MUI system]).
Additionally, I have created, implemented, and enforced numerous departmental processes and guidelines to ensure unwavering consistency in design output, established design team role expectations and hierarchies, organized recurring meetings to foster a collaborative team culture, and implemented skill matrixes to assess employee skills and identify skill gaps within our team.
Challenges
As the first UX designer in the product department, I was given the responsibility of expanding the design team. Before doing so, I realized that an implementation of processes was necessary, to address current issues and prepare for future expansion.
With no one to rely on for guidance or advice, I leaned on my previous lived experience of working in a well-oiled and well-established product and design team environment. This, coupled with extensive research of other design department processes and online-published articles (such as Figma, which has much of it available online), I was able to establish many successful processes that we use to this day.
Outcomes
The implementation of processes, which include, but are not limited to:
Versioning history files: An organized and categorized archive file of all previous and ongoing work. New files would be created every year for proper storage.
Documentation tools and processes to streamline and properly document designs during the design-to-dev handoff process.
These new documentation processes took the team from an average of 636 QA comments to 33 QA comments on a single feature - resulting in a 90.91% decrease of QA, design and engineer time, and a drastic reduction of errors and miscommunication on feature requirements.
Documentation outlining design team member and role expectations, team culture and values, career ladders, and other technical resources for designers.
Skill matrix to assess design employee skills, identify skill gaps within our team, and better navigate career advancement conversations.
The implementation of meetings, which include, but are not limited to:
Daily standup.
“Watercooler chats” to foster design team culture.
Installation of “design syncs” to foster team collaboration and establish clear communication across individual projects.
Challenges
At its core, the original CRC design system was largely unusable. Instead of aiding and making design work easier and faster—it did the complete opposite. Working with the system was an uphill battle for both design and developers, largely due to its widespread inconsistent, poorly designed, and ill-documented components. Aware of this monumental issue, I offered to fix the design system.
Fixing this design system posed a significant challenge since it had been created by multiple agencies and contributors who lacked a proper understanding of design system implementation and component creation.
Extensive and meticulous restructuring of ALL components was required to make it usable.
Some issues included a deep level of disorganization, no consistency in base units and naming conventions, technically unsound components, and no clear documentation stating a component's intended use, which all contributed to a less-than-helpful system.
Due to the inconsistencies within the system itself, the software also mirrored these inconsistencies, which led to a cheap and sloppy impression of the software.
To solve this problem, I undertook the task of singlehandedly rebuilding every component, implementing naming and organizational structures, defining responsive breakpoints, and creating clear instructional guidelines for designers, developers, and QA to reference. These efforts spanned over a 4-week timeline.
Outcomes
A successful creation and implementation of the updated design system which aided in a 90.1% decrease in QA time.
An establishment of crucial systems, including:
Base unit systems
Typography standards
Defined color palettes
Clear button hierarchy and defined use cases
Modal standards and defined use cases
Technical re-structuring of components for ease-of-use and scalability, as well as defined use cases
View File
Challenges
As the lead designer on the greenfield product Cosmos, I was tasked with building and establishing its design system. At this moment in time I had not yet built a full-scale design system, so although the task seemed daunting, I dove in head first.
Since we were not going to use an existing component library, and all components would be custom-coded, meticulous attention to all component documentation, expectations, and states was of utmost importance. This also meant that documentation and organization needed to be effective for not only designers, but also for engineers and QA.
The system needed to be effective, organized and clear, yet easy enough to scale, so other design team members could add components or component states without my immediate help or oversight.
The system had to be adaptive to both desktop and mobile platforms while adhering to accessibility guidelines.
As the lead designer, I had to uphold brand and technical standards as the system evolved and expanded.
Outcomes
Successful creation and implementation of the design system into our greenfield CRM. It was clear and easy to understand by all teams.
This design system was so successful, that its template was later adopted by another greenfield product within our product suite (Atlas).
Challenges
One year following the successful redesign of the Credit Repair Cloud design system, the decision was made to transition from custom components to MUI (Material-UI). Spearheading this design system transition, I simplified the existing design system to ensure a smooth and efficient transition.
The team faced a tight deadline of 6 weeks for the entire system transition, which included the learning curve associated with the new MUI environment and ensuring the proper migration of existing components.
A meticulous review of the existing components was imperative, aiming to minimize the creation of custom components and maximize the utilization of native MUI components.
Implementing a strategic process was essential to successfully convert existing designs and upcoming features from our current components to the updated MUI components.
Outcomes
Figma library transition successfully completed within 6 weeks.
I infused a minimal yet sufficient level of customization into the Material library to maintain the distinctive look of our product.
MUI rollouts have been successful and ongoing as of January 2024.