Defining our principles

I spent the first month as Lead meeting with each member of the design systems team to better understand its history, the challenges they faced, and where they envisioned Kindred to be. I knew that before starting on any redefinition, we needed to align on a set of shared principles to guide our decision-making.

• Scalable ⚖️
  When I started on the Kindred design system team, we already had a legacy design system that housed all foundational elements and components within one file. On top of that, this legacy design system only reflected one particular product - the Enrollment experience. I identified that in order to scale Kindred to span across multiple products, we needed to redefine our organization into a collection of systems.

• Collaborative 🤝
  We believe that design systems should be a collaborative process and so to gate keep it seemed antithetical to the success of Kindred. Instead, I created a model where global elements would be owned by the Kindred team while embedded designers own and maintain their own local design systems.

• Accessible ♿️
  Accessibility and inclusivity are imperative for building successful products at scale, and it starts with the design system.

• Measurable 📐
  We wanted to introduce qualitative and quantitative research methods to track user sentiment and component usage.  

Kindred (2.0)

I identified that in order to scale, we needed to make significant change for how we scaled Kindred across Bestow. Rather than thinking of Kindred as 1 systems, I leaned on “Spotify’s Design System Methodology” to cast a vision for a system of systems.

• Kindred Base contained the foundational elements that are universal to every product at Bestow. These are things everyone should use - it’s what makes Bestow look like Bestow. Using Kindred Base is the minimum bar for every Bestow product.

• Kindred Components (Connect & Care) inherited Kindred Base to create a set of basic components like buttons, inputs, form controls and more.

I also wanted to create a collaborative approach to Kindred in the form of localized design systems. Each design lead would have the ability to create and manage their own local design system. I knew this was important to reduce friction, and it would give them the freedom to experiment and design their own custom components. The Kindred team would then host monthly syncs with these leads to review new components and determine whether or not it should get folded into Kindred.

Redefining our ways of working

When I joined, the Kindred team was composed mostly of members splitting their time on the design system and their own respective teams. Because of this, the team adopted the Kanban method to accommodate for that. However, the challenge with Kanban was that there were no deadlines and in part, lack of scope and urgency for given work. I worked alongside my Product Manager and Scrum Master to convert to Scrumban - introducing 2-week sprints to better compartmentalize our efforts. I also utilized storypoints to improve estimating and prioritizing our component work. I worked with our team to define and document our ways of working, roles & responsibilities, and definitions of done.

Utilizing Figma’s design system features

One major component in my efforts on the design systems team was to restructure the way our files worked within Figma. The design team had only recently migrated from Sketch/Abstract into Figma in the fall of 2021, and the Kindred design system file was merely an import from Sketch. Both foundational elements (Color, Typography, Icons, etc.) and components were being housed in one file. As I dug deeper into how design systems are being built in Figma, it became increasingly clearer to me that we needed to break up our file into multiple files.

I developed a new structure to accommodate the Bestow ecosystem:

• Kindred Base
  Kindred Base contains the foundational elements that are universal to every product at Bestow. These are things everyone should use - it’s what makes Bestow look like Bestow. Using Kindred Base is the minimum bar for every Bestow product.

• Kindred Components
  Due to the variety of products on Bestow's platform, Kindred's components are separated into Kindred Connect and Kindred Care.

  • Kindred Connect (D2C) embodies the digital experience for how we create an initial connection with a potential customer.

  • Kindred Care (B2B) embodies the digital experience for how we take care of our existing customers.

Documenting the work

Documentation was one of those items that the Kindred team never ended up prioritizing. Yes, there was developer documentation via Storybook, but what was missing was a source-of-truth for design, engineering, product and marketing to rally around. I made the decision to utilize Zeroheight as our platform to house our documentation. I also introduced a “writing documentation” step into every component to ensure some level of information was being produced. 

View Kindred Documentation ➔

Forming the foundation of accessibility and inclusion

Design systems present a unique opportunity to build accessibility and inclusion into your component libraries from the get go, both from a UI/UX design perspective, and from a code repository perspective. We knew that accessibility needed to be prioritized but that there is also much work to be done.

Our MVP was to solve for the following:

• Adjusted all Kindred Base colors to be WCAG AA compliant

• Added hover and focus states at the component level

• Added ARIA Specs in Storybook for every component

• Provided usage guidelines in Zeroheight for every component

Getting buy-in and adoption

Gaining design system adoption was the biggest challenge for our team. Before I joined, Kindred adoption was predominantly based on word-of-mouth. We had an internal Slack channel to a small group of engineers, product managers, and designers, but because Kindred was built primarily for one product - many of the teams were left questioning its relevance.

Top-down ⬆️
I worked with our Product Manager to schedule presentations and workshops with Product and Engineering lead meetings. I used this time to discuss Kindred’s plan to integrate with the wider Bestow ecosystem. Through these conversations, we became aware of other key initiatives that had major overlap with our design system. Hitching ourselves to these initiatives proved more successful in gaining full design system parity.

Bottom-up ⬇️
We expanded more ways for the wider organization to gain visibility into what we were working on. We created a Slack channel to have two-way conversations with designers and developers regarding our releases. We also created an intake form that allowed users to submit bugs or feature requests to our team.

Kindred examples from figma

Kindred Before & After

Outcomes

Lessons Learned

My time at Bestow was unfortunately cut short due to company-wide layoffs that left 14% without jobs. However, I was proud of the work I was able to accomplish with the team. Here are some lessons learned.

You’re only as good as your team 👨‍👩‍👧‍👧
Design system work can often feel removed from the end user. Often times, you are the machine behind the machine, and the work may feel disconnected if not managed properly. I sensed that the team lacked direction which led to a lack of enthusiasm. Casting a new vision was my number one priority, as having something to rally around keeps teams focused and engaged. It also made it easier to evangelize what we were working on to the rest of the company. I sensed ownership from the team and that in turn gave us a renewed spirit.

Adoption is imperative to success 🙋‍♂️
Having a shared vision for where our design system was heading was imperative to our team’s success. It’s easy to put your head down and get caught up in building components. But having a design system that is partially used isn’t really a system at all. The messy work in getting teams fully integrated is vital to the success of any design system. And that takes hard conversations, meetings, documentation - things that aren’t privy to the day-to-day production work.