Nectar Design System
Nectar enables designers to use their skills to focus on solving core product problems. It has supercharged our teams to move faster and more confidently, while producing a more coherent and extensible product.
- Principle Designer
Kandji is an enterprise Apple device management and security platform. Businesses are able deploy, maintain, and protect their workforce's fleet of devices.
I joined the team to manage and lead the creation and implementation of a modern, reusable, and robust design system across all product lines.
An example of a legacy experience (left) updated with Nectar (right)
Defining my role
My core role at Kandji was to create, implement, and manage our first design system. My responsibilities included:
Develop a strong visual identity that resonates with our brand and values
Craft the design system, from foundational styles to complex components
Create and manage the designer/developer experience - Figma libraries, Storybook, documentation, guidelines, onboarding, designer/developer collaborative processes
Design, plan, and direct the adoption of the design system on both existing legacy pages and new projects
Collaborate with designers, engineers, and product managers
Provide education and advocacy of design system practices
Work with design research to measure design system adoption metrics and success from both internal and external perspectives
Manage the design system team (1 other designer, 2 engineers)
Report to the executive team
Establishing the team
The design system team is a relatively small one. I managed and led the design and product efforts, while mentoring a junior designer just jumping into design systems. I also helped to manage two dedicated engineers.
In my role as both the design lead and mentoring a junior designer, I strived to strike a balance between an efficient process, ensuring quality, and also providing independence and a growth path. I also leveraged the designer's strengths as a visual designer to have them take more ownership around their interests and skill set - for example by having them own illustration and iconography in the system.
I wanted to create an equally efficient process with the engineers on our team. In parallel with our efforts, they set up foundational code scaffolding, quality, and direction. Not wanting to exclude them from the design process either, we would hold regular syncs to present our progress. This was critical to both determine how to build a particular component, if there were particular engineering constraints and requirements, and also allowing engineers to provide their design input.
A critical part of the team is of course the consumers of the design system. I quickly established a rhythm of collaborative sessions to collect input and feedback from design and front end engineers across all teams.
Our highest visibility stakeholder was the executive leadership team. One bar Kandji sets for itself as a company is excellence in user experience - particularly as our product sits directly adjacent with Apple's interfaces. I regularly discussed and presented to our leadership as a way to both receive feedback, update them on progress, and give them a future vision of our product experience.
Planning the work
A thoughtful approach on how to build a design system can alleviate a variety of challenges and headaches before they happen. Having been both on the design system side and on the product design side, I have a lot of empathy for both perspectives. This allows me to operate on a balance between understanding how and why a system is constructed in a particular way, versus how the system is used in practice.
An early task was to audit all experiences and create a map of what common elements and patterns are used throughout. This informed an overall vision of the various aspects that our design system needed.
I drafted a blueprint for how all the pieces of our design system would work together. This included how our design tokens worked (from design primitives such as color and spacing to semantic tokens), component structure, naming, properties, and anatomy. I worked closely with engineering translate this structure into code.
Through an audit, I created a list of components and patterns already in use, and were needed in addition.
Accessibility and environmental factors were another important consideration. Considering many of our primary users are IT admins who are spending long periods of time looking at their screen (and oftentimes high resolution multi-screen setups), my goal was to create an experience where our teams could create highly readable and scannable experiences for adaptable screen configurations.
Creating the system
Design tokens are values and properties that translate design intent and decisions into specific semantic variables. For example, in our color ramp, we define #106AF2 as "blue50". This is a primitive token. We then assign this token for particular uses, for example we assign "blue50" to "button-primary-surface-enabled", meaning we use this color for the surface color of our primary buttons. This powerful system allows designers and developers to reference using a specific language and meaning, along with a slew of other benefits.
Design tokens are values and properties that translate design intent and decisions into specific semantic variables. For example, in our color ramp, we define #106AF2 as "blue50". This is a primitive token. We then assign this token for particular uses, for example we assign "blue50" to "button-primary-surface-enabled", meaning we use this color for the surface color of our primary buttons. This powerful system allows designers and developers to reference using a specific language and meaning, along with a slew of other benefits.
Empowering teams
Building a design system is a large initiative. Enabling teams to understand and feel confident in using the system is an even more important milestone. From day one, I knew that the greatest challege is the adoption and experience for designers and engineers - in many ways Nectar was a product in itself, where our customer was our own teams.
Early involvement from design and front end engineers had multiple benefits. I wanted the team to have full buy in from the beginning through their input, contributions, and feedback. Because the concept of a design system was somewhat new to many of the product teams, this served the dual purpose of building a rapport and education.
This would further increase in effectiveness through early adoption. I worked with individual designers and teams to find opportunities where even before we "finished" the design system, we could start leveraging Nectar in our process. This meant finding areas where we could design and implement a feature with limited surface area, or taking advantage of a new greenfield initiatve to fully build with Nectar from the ground up.
An extensive set of documentation resources served as a repository of knowledge for designers and engineers to understand the roadmap, what was available, and how to use the tools. This included design usage guidelines in Zeroheight, paired with integrated Storybook to integrate design and engineering tooling side by side. Ultimately, I wanted to create a shared language and understanding between pixel and code.
Adoption and implementation
Adoption of any design system is a strategic investment. It can be disruptive to teams and, ultimately, customers if done in haste.My objective was to provide multiple methods of how to adopt the design system that provided flexibility and adaptability to fit a team's roadmap, resources, and goals:
1. Creating a new feature
Any new feature should be considered with the new design system in mind. These are greenfield, new initiatives that Nectar can be fully leveraged from the ground up.
2. Adding a new feature
A feature being added to an existing surface has some challenges when introducing a different visual design adjacent to what currently exists. That being said, there are tactical ways to introduce Nectar in these contexts that can mitigate that disruption.
3. Updating an existing experience
This was a1:1 conversion option. This enabled teams to set themselves up with a foundation to continue building with Nectar.
4. Full redesign of an existing experience
Because of how the existing front end was built, it was immensely challenging and time consuming for engineers to work with. Because implementing Nectar required essentially a rewrite of the front end, we encouraged the teams to consider revisiting the fundamental design and workflows of an experience. While this would take additional scoping for research and design, we would reduce inefficiencies of converting to Nectar, and then improving the experience. This was particularly valuable as a option, as many existing workflows were built without design research or even a designer.
Educating the teams on how to use these different approaches and what it meant to their scope of work became a critical part of our organization's planning process. Because of the team structures and roadmaps, I wanted to provide flexibility in how and when the design system was implemented to fit their goals. Our release strategy would correspondingly be phased to account for this staggered approach.
Outcome and next steps
Deliverables
A Figma component library complete with color styles, typography, semantic tokens, complex components, and motion design
Parallel code that mirrored the designs
Documentation of component design and usage, patterns and layouts, best practices, and guidelines
An organizational culture and excitement for learning, adopting, and contributing
Roadmap for continued development and iteration
Flexible implementation plan
Contribution and governance model
A front end guild that sets best practices and quality control across design and code
A measurable increase in design and code process efficiency
Improved ergonomics and designer/developer experience
Qualitative improvement in perceived quality and user experience
Vastly improved design and code consistency across the product
We are only in the middle of the design system journey at Kandji. There is still much work to be done, and we have been successful in delivering a huge amount of value and resources in just 9 months. Some things we have started to work on is integrating our SUS scores used in research to take into account our design system adoption. We are also building more advanced prototyping tools to improve the developer handoff process.
Back