DLUX Design System
In 2014, only four designers and a handful of devs made up the product team at ZapLabs. By 2018, our design team grew to 13 designers and over 70 engineers. As the company grew at a rapid rate and dev and design efforts multiplied, we needed a consistent pattern library and reusable components in order to ship products efficiently and within scale.
Offer a consistent pattern library and standards that will enable product designers and engineers to build and ship high quality products quickly, efficiently, and consistently.
Audit existing products for all patterns and variants
Work with team to redesign patterns
Create sketch library containing all new patterns and shared components
Replace inconsistent patterns with new pattern iterations as engineering time allows
Create comprehensive guidelines across product and engineering teams
Increased velocity: Web Components allow developers to build scalable, performant, mobile-first products rapidly
Increased efficiency: Teams are able to build and deploy applications quickly, requiring less time developing new features, while reducing back and forth in testing and QA
Improved User Experience: Design Systems are how companies deliver high quality prototypes and mock ups, quickly, true to code, and at scale.
Collaborating with our Developers
From early on, it was important to partner with our engineers in order to understand their needs and frustrations. We had an early system in place with just essential components and specs, however, development still ended up with duplicate work, which led us to examine reusability and dev practices
Why was it a challenge to keep work consistent?
Why did shared spec artifacts only get us so far?
We talked to our devs and our designers, learned their frustrations and looked to other companies out there to see what we were missing: A living code repo library and a core foundation of shared principles
The Trajectory of Front End Technologies (Enter Web components) :
From analyzing the industry, our developers chose to build out patterns as reusable web components in Vanilla JS (with the goal to extend to other frameworks). As we started out, we examined some of the top design systems from industry leaders in order to compare how we stack against these mature systems, understand the gaps in our offerings, and set a marker for our own standards—not only in our catalog, but in our component library as well.
Into execution: Getting Granular with components, and what makes the cut.
Prior, our design system was created under the limitations of a legacy product. By 2019, we had the opportunity to not only reskin and give these a facelift, but also revisit these components and patterns to create better experiences, starting with essential components for our product down to more complex compositions and interactions.
Each component needed to be tested, introduced into a feature, and live within a minimum of two to three sprints before being vetted as viable and added into our DLUX system.
Bringing it all together:
Lo-fi, Hi-fi Explorations, Iterations, and Preference Testing
With our core users being our own developers, it made it easy to gather feedback and test early and often.
Define: Threshold of minimal components needed for initial release
Content: Guidelines and Writing
DLUX Readme Content Publishing (Process and automation)
CMS (Content Management System)
Asset Publication and Download
Accessibility and Ada Compliance
Versioning, backwards compatibility
Navigation (Three tier of parent/child content hierarchy)
Visual Style (Including Colors, Typography, Illustrations)
Dev: Currently only in Vanilla Js, and will need to build out in other frameworks (React)
Design: Animations, Loaders, Date Picker, Modals, etc
Catalog Explorations and Development
We needed a system for our devs to navigate the catalog easily, going through three tiers of navigation, amongst 179 components (and rising). We settled on having a global navigation for top-level categories, a left nav for sub-levels, and anchor links to quickly denote where you are.
Most importantly, we built our catalog to be interactive rather than contain static images, in order to adequately depict each interaction (simple or complex) and showcase with the intent for each component to be always updated while keeping track of versioning.