DesignOps – Complex Product Design System
Goal: To document and catalog implemented design patterns and components for both the design team and the engineering team.
When looking how you structure a design system, you really need to understand and meet people where they are at. With this design system we started updating the previous “simple” design system which had worked for a couple of years but did not scale to the addition of new engineering teams, growth of the design team, and the growing complexity of an ecosystem of apps type product. Being able to quickly scan through a design system for what was needed was paramount for engineers. And for the design team, being able to grab the correct component no matter what product you were working on was paramount.
From an information architecture standpoint, we focused on the ability to drilldown for a user looking to find exactly what they needed. The whole company had access to the design system. My design team only transferred over new components and patterns as they were implemented to ensure the design system was a reflection of the current state of the product(s). In some cases, there were items that were specific to a product within the suite of apps. When this happened, we made sure the design system label was easy to read as shown below. “Design System” was the universal patterns where the Icon file had icons that were specific to the main platform and material design.
Once inside the file, we broke down pages for specific items. These pages gave an easy way to link or view what a designer/engineer would need.
Components
Designers often would only use the component page (as it was published to the team library) The component would have all the use cases that were currently in use on the product along with a tester for a designer to get familiar with how the component could be used.
Engineering/QA Pages
Each non-component page have specs for how the component is built (anatomy), interaction states, placement location, and an interactive prototype link for interaction validation.
Each page allows for a flexibility with engineering goals. 90% of the teams would follow these component pages while coding and/or QA testing while the engineering team dedicated to creating the react component library had the time needed to work through creating dedicated components with the design team to make sure there was not an interruption to the user experience. Engineering teams could accomplish their goals without a design bottleneck and the design debt technical team could work through items for modernizing the products with little to no interruptions from customer feedback.
Related Projects
Product Design – Community Site
Full Product - Community SiteA year in the life of...OverviewThe community site was their first yearlong project. Standard web design process, information discovery, spec development, wireframes, mockups, and development. When launched, engagement spiked, and we truly...
Product Redesign
Product RedesignUser feedback, lost deals, & new technology = Redesign for more revenue.OverviewThe B2B platform was in desperate need of a redesign. Customers consistently commented on its dated style and general overwhelming nature of the platform. Many of the...
Product Design – Enterprise LMS
Full Product - Enterprise LMSTasked with a training portal learning management system (LMS), we needed to train users and employees on our products and best practices.OverviewAfter the success of the community site rollout, we were next tasked with a training portal...