Impact
+72%
Increase in E-NPS scores from -90 to -25.
100%
Adoption of Obsidian's Figma Libraries across the Tinder Design team.
+26%
Decrease in UI-related bug tickets filed through the Platforms team.
~75%
Of Tinder's products were AA WCAG compliant through the use of Obsidian's design tokens.
Accessibility
Obsidian resulted in providing Tinder's millions of users with better accessibility by meeting AA compliance, screen reader support, dynamic text, and more across iOS, Android, and the Web.
Redesign
Obsidian provided Tinder the ability to efficiently test, experiment, and implement Tinder's redesign.
Improved Workflow & Process
Obsidian improved workflows and processes between engineering when it came to implementing, and testing features through the use of reusable design tokens, components, and hands-on training.
Scalability
As a result of Obsidian's design tokens, Tinder was able to much more easily implement themes, such as a Dark theme, along with Swipe Night, Vibes, Gold, etc. Similarly, Obsidians components allowed us to quickly build, and optimize for our iPadOS app.
Discovery
Goals & Problems
There’s been a historical demand for a design system from many different teams at Tinder. The initiative kicked off once I started, and the problem was straightforward; create a system that enables Tinder’s products to be consistent, and enables teams to ship high-quality experiences quickly.
What made this set of problems challenging was; the rapid pace of which Tinder moves at, regularly shipping, iterating and testing new features on a weekly basis, and a looming redesign coinciding with the timeline of the design system.
The Process
.png)
Research, Vision & Principles
.png)
Though there were a baseline set of problems to solve with the design system, I wanted our team to do due diligence and speak to people across Tinder to get an understanding of needs and expectations with a design system. Given that historically it’s been a need, I wanted to loop in our adopter’s voices in shaping the system.
A. My engineering lead and I conducted thirty interviews across product, design and engineering. Leading these interviews, I was able to uncover a lot of problems that extended beyond a design system, problems that stemmed from a broken product process. This was when our team learned that the design system could be a tool that solves for process inefficiencies, communication gaps and overall frustrations.
B. The synthesis of all this research (and a workshop that I lead), lead us to shaping our design system principles, a set of guidelines that our team adheres to, and measures against (see measuring success).
C. As a part of this phase, I facilitated a workshop that helped align our teams mental model of what a Design System is.
Defining our Team’s Process
Once a shared vision and a set of principles were established, the engineering lead and I got to work in defining a process, project structure, and in collaboration with our product director, a roadmap and OKR’s. Knowing that many of our members on the team weren’t full-time and dedicated, it was critical to establish a process for them to jump-in-and-out.
It was also important to define all of our processes so that our workflow is transparent to other teams, knowing that many of them would likely collaborate with us in the future.
Design
Defining the Architectural Layer
Designing the initial system with all of the different pieces was a challenge that took several months to figure out; consisting of a lot of researching, prototypes, testing and iterating. The engineering structures were particularly challenging since our system needed to support; a redesign across multiple platforms for teams creating, testing and iterating on features, all while support lots of existing tools at Tinder that teams used.
My role during this phase was to define the taxonomy of the language, how different libraries on the design end would ladder up to the engineering infrastructure, and overall support engineering in visualizing and documenting the overall systems.
Design Tokens & Component Library
A. Design tokens are an instrumental part of every design system. For us establishing our tokens was an immediate goal because of the role they play in seamlessly updating a design language. As a part of defining a list of our tokens, In collaboration with my engineering lead, the two of us created documentation covering the taxonomy of tokens, hierarchy, naming conventions, etc.
B. A sitemap showing the different sections of documentation in priority for our website.
C. An example of a list of design tokens in Figma, accessible for our designers.
D. The component library was an artifact also designed early because of the immediate need for the design org’, but also the usage of components could help design communicate these different design tokens.
E. An example of components built thoroughly using Figma variants, a powerful feature that would allow design to configure different properties of a component such as state, theme, etc. This ensured that when I created components, I covered all possible use case
Defining the Language
Documentation for some of our different pieces of the system. Examples include the; color, typography, layout systems and the button component. Every piece of system defined would go through a thorough design process including phases such as discovery, define, design, QA and publish.
Adoption & Measuring Success
Defining Process & Guidance for our Users
A. Flowcharts depicting different processes that relate to design systems:
• Evaluating the existing process, and its' challenges.
• How do other teams use the design system?
• How do new features integrate into the design system?
B. A set of guidelines for onboarding teams at Tinder, some topics included; Installing & Enabling, Do’s & Dont’s, Contributing, etc.
Evangelizing & Training
A. Frequent presentations and trainings were held on the Design Systems for the org’ on progress and updates.
B. Training sessions were held once different parts of the systems were released, such as the component libraries, design tokens, tools & plugins, etc.
C. An example of a remote training workshop with a designer, Ying, on designing for themes.
Measuring Success
A. In collaboration with my product manager, I created an E-NPS surveys for each org’ at Tinder using the design system principles as a form of measurement. This was the primary method of measuring many of our KRs.
B. Figma Library analytics, showing adoption of the different libraries I created and managed.
C. Google Form surveying the quality of training workshops the design systems team that I lead. There were training workshops throughout the year, covering system concepts such as taxonomy, design tokens, etc.
Next Steps & Lessons
Next Steps
A. In collaboration with the Core team at Tinder, I helped redesign the different navigation components, conducting preliminary research, running multivariate tests, and rethinking the apps’ IA through a collaborative workshop.
B. Another early initiative that was happening (but slated more for the future) was to scale the system to support iPadOS.
C. A dark theme was an initiative our team continued to support regularly through the use of design tokens, but is still an ongoing process in having different teams at Tinder support the theme.
D. A major redesign in collaboration with an agency that our team was leading!
Lessons Learned
1. Don't Be a Librarian
People need active guidance and training to change their habits.
2. Design Systems are Much More than Figma Libraries
They're a system of many moving pieces and connections that bring change to not just the product and it's experiences, but the process, people, and the organization.
3. Get Something out Quick
Design systems deeply impact peoples behaviors and workflows, its critical to get things out quick, and get an understanding of it's impact.
4. It Takes a Village
Design systems are a collaborative initiative that extend way beyond the team that's creating it. They only succeed at the level you want them to, if everyone across the org' is on board.
5. Empathize with All your Users
Design systems are often thought of as internal tools, and therefor impact internal users. But, It's the responsibility of the system to also think about its' end users (Tinder's users) and impact the experience at a holistic level for them (often through systematic experiences such as accessibility, navigation, etc).
.png)
.png)
.png)
.png)