Background
About Influitive
Influitive is a B2B SaaS web platform used by companies to build branded communities where they can discover, nurture, and mobilize their most loyal customers and advocates to complete tasks that fulfill their sales, marketing, and product needs.
Project opportunity
At the end of 2020, the Influitive product team prepared for a complete rebuild of the member-facing app, stemming from a need to eliminate tech debt and to improve performance through a modernized tech stack.
This presented the perfect opportunity for a complete app redesign that needed a new design system to serve as its foundation.
Our original member app was filled with inconsistencies and bugs
What is a Design System?
A Design System is a set of standards complete with design guidelines, reusable UI components and patterns, and code snippets used to manage design at scale. It is a single source of truth that simplifies product design, development, and testing by allowing teams to build consistent interfaces across different experiences.
Problem: Designed by Accretion
Since its inception in 2010, Influitive introduced 3 custom design systems and their component libraries to its codebase. These systems were used to support rapid product growth, allowing customers to engage with their customers and advocates through discussions, challenges, referral campaigns, and multimedia content in a custom-branded community.
The cost – the platform became visually fragmented, inaccessible, outdated, and increasingly difficult to maintain due to the concurrent use of 3 unmaintained design systems.
2 of our 3 existing design systems, both of which are currently used
Project Goals
The goal for this project was to consolidate the 3 existing component libraries into a modern design system. Our vision was simple: a theme-able design system that’s accessible, usable, aesthetic, and could guide our approach to building our product.
However, we weren't planning to repeat past mistakes. Our ambitions were to create a strong foundation that could be maintained with limited resources and could support a rapidly-evolving application for a global user-base.
Business goals
Increased velocity for Designers and Frontend Engineers
Using a design system should make it as easy as possible for designers and engineers to respectively design and implement solutions with existing components. Having a robust and complete component library on both sides makes this possible.
More effective and efficient bilateral communication
Consolidating three design systems into one source of truth will allow product, design, and engineering to easily communicate and align on how the product should be built.
User and customer goals
Provide a consistent and polished experience with fewer bugs, accessibility, and usability problems
Users engaging in our customer communities should be allowed to enjoy their experience interacting with their favorite companies. Replacing our existing component libraries riddled with bugs and UX issues will enable us to create a more polished, consistent, usable, accessible, and robust product.
Improved flexibility for theming by our customers
A key differentiator of our platform is its customizability, allowing customers to theme it however they want. Our product’s foundation should fundamentally support customizations at every level.
Impact: Faster and Happier
Prior to our new design system, two of our organization’s largest pain points were the immense number of front-end bugs being reported and the time required to implement front-end changes.
Two years after integration, our new design system has contributed to a:
Reduction in bugs by 80%
Reduction in accessibility issues by 84%
Increase in customer and member satisfaction
Increase in engineering + design velocity by at least 50% with lots of appreciation from our engineering team
In addition, this new design system has become the catalyst to numerous projects that aim to improve the customization capabilities of our platform.
Research
Identifying our problems
The idea for this project arose during a conversation I had with another designer. At the time, we didn’t have a complete understanding of the problems created by our existing libraries. All we knew were the struggles we had as designers working with them.
Without many insights, I interviewed our design and development team, customer success managers, and community admins to learn more about problems faced internally and externally, and to see if they relate to how our app is fundamentally built.
Process slowdown
None of our libraries were completely represented in Figma, which forced designers to design using screenshots from the app. This lengthened design time, created unmaintainable design artifacts, and made it harder to provide developers with accurate requirements which ultimately led to longer development times.
Visually inconsistent look & feel
Our 3 libraries were used in parallel, causing inconsistencies between pages that led to reduced usability and polish. To better understand the current state of our existing design ecosystem, I built a catalogue of all the reusable components in our product.
UX debt & accessibility issues
Our out-dated libraries were built with little thought for accessibility. Alt-text, semantic tags, ARIA roles, sufficient color contrast, and focus/hover states were missing from many components which contributed to a heavy flow of bug reports from customers.
Brittle support for branding and theming customizations
Since our libraries were not built with custom theming in mind, rolling out component updates frequently break customer CSS and theming which shutdown communities and made the lives of community admins difficult.
Identifying past mistakes
At the time, I was a newcomer and these findings surprised me. Given that we serve companies across the world who have diverse customers, I truly believed we should’ve had better accessibility and theming support. Since our libraries were built before my time, I talked to more tenured engineering and product folks to discover that our failed design systems were the result of 2 things:
Not enough resourcing to build, maintain, and improve our libraries to meet our product’s needs
Effort and time required to build bespoke components caused us to abandon the libraries in favor of using external libraries that gave us a shortcut to the final product.
“We were a bit too ambitious. We tried to move too fast and it resulted in having multiple incomplete libraries that don’t work for us anymore”
Getting others bought in
With our app being completely rebuilt through project Elevate, our product team knew there wouldn’t be a better opportunity to eliminate the issues we faced. To get the ball rolling on this project, I used our findings to get our executives and team leaders on board by:
Involving execs and engineering leadership in a kick-off where we shared the current pain points, anticipated benefits of the project for the company as a whole, and our plan moving forward.
Sharing progress and seeking input from engineering and management through weekly syncs.
By getting every relevant team involved at kickoff and as the project evolved, we were able to promote understanding of the project and inspire a sense of co-ownership throughout the entire process.
Picking an Approach
Learning from past mistakes
In order to avoid our previous pitfalls, I collaborated with our engineering and product leads to weigh out our options for building our new design system.
We ultimately decided that it would be best to build our design system on top of a well-maintained open-source library.
This approach would provide us with accessible and usable foundational components right out of the gate, allowing us to focus on solving more complex problems for our product rather than spending our limited resources on building and maintaining simple components such as buttons, input fields, and labels.
Sourcing a vendor
Picking an external library to use wasn’t as simple as choosing a look that we liked. We conducted rigorous engineering testing, and had numerous conversations with product and engineering leads to determine what was necessary to support the engineering and strategic goals of our teams. After comparing and contrasting various vendors, we eventually landed on Material UI.
Material UI is a popular open source React UI Framework built around Google’s Material Design guidelines.
We chose Material UI due to the following:
Open source, rigorously tested, and continual updates/support (over 27k contributors)
Well thought-out components that match our existing set of components, follow existing ux conventions, and have animated delights (40+ components)
Robust theming capabilities
Customizable tokens that can support our color system, grid layouts, and type styles.
Accessible, responsive, and supports localization
Consumer-facing look & feel but support heavy-data applications
Worked well with our engineers’ stack built on React.
Cross-device and cross-browser compatibility
Composable - allowing us to build custom components on top of more atomic components
Available Figma file
Design Principles: Unifying Our Approach to Design
Although we had a new toolkit, it wouldn’t mean much if our teams continued to design and develop with the wrong values in mind. We were missing core values that could unite our company and guide us towards a product that delivers value to our customers and all of their community members.
The challenge was – despite not having done this before, how could we as a design team come up with a good set of design principles for an entire organization? We looked at other leading companies and figureheads in the design community for some help and eventually landed on what we thought defined an effective set of principles.
Helps resolve practical and real-world questions around specific design decisions.
Applies to an entire class of design decisions, both things we can think of today, as well as questions that will pop up in the future.
Takes a stand on which value is the most important
Inspires empathy for users
We also took time to understand our business and product’s position in the market to ensure that our designs would bolster our business and inspire confidence from our customers. By talking to our customer success managers, sales team, and executives, we came to understand that the following were our product’s primary value-drivers:
Customizable in look and feel for unique customer use-cases
Effective for diverse global audiences
Efficient and powerful for community admins to achieve their marketing goals
By pairing this newfound knowledge with inspiration from leading design teams from companies such as Airbnb, Google, Shopify, Apple, and Atlassian, we brainstormed and eventually crafted a set of principles that our product, design, and engineering teams believed in.
Creating an MVP System
At this point, we didn't have much time left until our app rebuild project started so I decided it would be best to set up an MVP version of our system to ensure our engineers won't be blocked. The plan was to translate over old foundations and components using Material UI and any larger improvements would be made as we redesign each feature as a part of the rebuild project.
Foundations and tokens
Although our previous design systems have caused us a lot of trouble in the past, our foundational elements have worked well for us. We had a distinct Influitive style that our users were accustomed to and we didn’t want to stray too far from that.
To retain our look, we updated stock Material UI to ensure our styles were in place and being inherited by all stock components. A part of this process was also implementing design tokens to keep our styles aligned with what we have in code. This included but was not limited to our color system, font styles, spacing, radii, and shadows.
This time around we also tackled accessibility by using REMs for our typography and media query breakpoints to accommodate font scaling.
Components
After setting our foundation, we moved on to recreating old components using components from our new library built with Material UI. We started by unifying variations of components uncovered during an audit to leave only the essentials and those that were unique to our platform such as our Challenge Cards, Reward Cards, and Activity Feed components.
To ensure that our components were future-proof, robust, and align with our design principles, we set a few rules in place:
We made our components responsive with Figma’s auto-layout feature so we could use the same components when designing for various devices and layouts.
We designed to cover all relevant states for each component. We were able to use Figma’s Variants feature to create component sets that have these states along with prebuilt interactions for quicker prototyping. Using Variants made our components easier to use, maintain, browse, and swap.
Each component we designed with accessibility in mind to comply with WCAG AA accessibility standards and AAA where possible. We achieved this through the foundation of our design system.
Supporting Accessibility
At this point, our new design system had everything we needed in an MVP. It had all the components we needed to sunset our old libraries, principles that help us build and design the right way for our users, and a brand new look and feel that up-levels our product.
The only thing we were missing was a process for testing our work to ensure that our previous issues don’t happen again. One big concern that we tackled as a team was accessibility compliance which fell under our new design principle of being “Universal”.
The 4 principles of accessibility
Historically, our platform focused mainly on font legibility and color contrast which is covered under “Perceivable”. However, other concerns such as keyboard-only operation for those who are motor-impaired, alt-text for the vision-impaired, and screen-reader friendliness were rarely tested and designed for.
To strengthen our stance around accessibility. I dove deep into what it meant to be WCAG 2.0 A, AA, and AAA compliant. With this newfound knowledge and some inspiration from how other companies tackle accessibility, I crafted an accessibility checklist for design reviews, engineering merge requests, and QA testing to make it easier for all teams to test for WCAG AA compliance. This checklist was shared with the respective teams and numerous cross-functional workshops were conducted to brainstorm how we could efficiently implement this into our existing processes.
Our engineering and design teams now refer to these checklists when testing major features.
Our new accessibility checklist used during design, development, and QA.
Building and Testing
Since we did not have dedicated resources to work specifically on the design system, we sought opportunities in the rebuild project to redesign, build, and test the design system as we rebuilt different parts of our app. For example, during the Challenge page rebuild, we were able to redesign and implement our new and improved Challenge cards and Challenge player.
Influitive’s newly rebuilt "Elevate" platform that uses the new Design System
Next Steps
Our design system will forever be a work in progress, constantly evolving, improving, and teaching us throughout the process. So far, our design system has a set of robust components that has been used in a complete rebuild of our member-facing application (case study on this here) and numerous other features. This has been game-changing for our team in terms of efficiency and standardization, and also for our customers in terms of accessibility and usability.
To keep us pointing in the right direction, we plan to:
Cultivate processes to ensure that our library stays up-to-date and perfectly in sync both on the design and code side
Write usage guidelines for our components and foundation, and guidelines detailing our stance on all topics
Test our governance process as we grow our component library
