TL;DR
By migrating our product data tracking plan entirely to Figma we:
- Dropped event implementation time by 50%.
- Streamlined from 3 tools into 1.
- Unified communication around events into a single source.
- Brought devs, design, and the business teams closer.
Introduction
Crowded is a banking and financial management platform for nonprofits. Our suite of features covers nonprofit banking, spending, payment collection, and tax reporting, enabling organizations to manage their finances in a single platform.
As an agile start-up of 30 employees, we’re familiar with exploring and optimizing internal processes, and pivoting with solutions when needed.
One particular process that the team flagged for improvement was Crowded’s events tracking plan, which aligns multiple teams around a single source and strategy for customer data collection.
“ A data tracking plan is a strategy that businesses devise to clarify what events they need to track and the tracking methods they’ll use. Data tracking plans will cover details like where events need to go in the code base and why those events are necessary from a business perspective. ”
- Segment
The challenge
The biggest challenges around the events tracking plan, which spanned across Jira and Google Sheets, were:
- Developers were missing the full context
They wasted time jumping between Jira, Sheets, Slack, and Figma attempting to understand the full context of events and resulting KPIs that were meant to be tracked. - Confusion from context switching
Jumping between tools contributed to implementation bugs which raised QA estimates and Product support needed. - Communications sprawl
Conversations and comments spread between different tools resulted in miscommunication, slow response times, and a lack of clarity between stakeholders missing a single source of truth. - Stakeholder misalignment
Support, Marketing, and Success teams were missing visual context for event goals which disrupted measured KPIs like customer onboarding and activation.
Where we started
Crowded’s event tracking plan journey started, like most tracking plans do, in Jira, a project management tool, integrated with Google Sheets.
However, implementing events directly from Google Sheets and Jira led to frustrations across teams.
Developers and Product Managers were finding themselves constantly switching between Jira, Google Sheets, Slack, and Figma, to illustrate (on the product side) or understand (on the developer and business side) the full context of the events needed and how they fit in the overall user journey or flow.
For developers, reading events off of a Google Sheet wasn’t cutting it in terms of context. The KPIs the product team was trying to measure were often missed.
Communication was suffering due to the fragmented nature of comments posted across multiple tools and channels. Productivity dropped and implementation ETAs increased which raised a flag. Why did implementing events bring so much friction?
As a fast-growing startup, Product and Design teams make decisions by analyzing customer data. We couldn’t afford this process to be clunky. Wasting capacity on back-and-forth conversations and miscommunications was a killer for growth.
This confusion directly impacted our roadmap and business by adding redundancies and friction to the development/optimization product cycle. Friction needed to be reduced for the event implementation process to be scaled leanly and for estimates to be kept.
Why use a design tool for event tracking?
An events tracking plan holds a lot in common with a design system.
In essence, both a design system and an events-tracking plan serve as foundational frameworks that enable consistency, scalability, and collaboration.
Like a design system, the easier the tracking plan is to leverage and navigate, the greater the impact on development, QA, and product growth.
At Crowded, our design team lives close to the data. Designers work with developers, QA, and product teams on implementing, mapping, and QAing events, so designers not only know which KPIs to track and optimize, but also how to map, measure and story-tell how those KPIs were measured through data.
Thanks to having designers in the data mix, the design team added a step in the Design<>Dev handoff that visually demonstrated how events measuring KPIs like ‘Onboarding Completion Rate’ or ‘Time to First Deposit’ mapped to their UI in Figma.
Allowing the Development, Product, Support, Marketing, and Success teams to view where each event fits within the app provided a critical reference and a larger context of their teams’ goals.
Now, where the event lived, so too did a link to Figma showing the event in context.
The addition of having events demonstrated in Figma ensured that developers could view them visually as a flow, as opposed to contextless rows in a spreadsheet It also helped the Design team visualize how the combined events would result in the KPIs they aimed to measure.
Integrating tracking directly into the design process brought designers closer to developers, developers closer to product goals, and made the process easier to comprehend.
Our AHA moment
Moving events tracking into Figma was a turning point for Crowded’s tech stack. Especially with Figma’s updated Dev mode, Crowded developers now spend more time in Figma than ever. So why not double-click on it?
The product lives in Figma. Marketing lives in Figma. It only made sense to unify product data and tracking into Figma as well.
Measuring impact
In rolling out Figma as the main tool for event tracking, the product team hoped to achieve both a lofty and attainable goal:
- Lofty: Reduce event production and devs implementation work by 20% by the end of the next 2 epics.
This felt ambitious as the process was new, education was needed across teams, and developers needed to adopt it to create impact. - Attainable: Reach 50% adoption from developers by the end of 2 epics.
This felt more achievable, as their team already had signals from seeing developers work on implementation and introducing events/updating the tracking plan.
Initial concerns about using Figma for the event tracking plan:
1. Steep Learning Curve: Devs are familiar with their tools and methods of extracting the info they need. Figma isn’t easy for everyone to understand, and team leads feared a hard transition.
2. Suitability: Once scaled, the ability to manage complex data structures and large volumes of information on Figma, raised concerns of data integrity and reliability. A tracking plan holds an abundance of data. Would Figma be suitable?
Testing our hypothesis
We set out to test our Figma hypothesis. We started by beefing up event data points in Figma with all the relevant information you’d find in a tracking plan. We added an MVP mapping showing where there are events with statuses connected to Jira.
To hedge our experiment, we took these steps:
1. Some of the developers were already familiar with events in Figma as it had already crept into the event process, but many weren’t. So we hosted a Figma crash course meeting detailing the new process with guided visuals and lean support documentation.
2. With the help of Seal Data Plugin, we consolidated the tracking plan into a single searchable widget that made it easy to digest and easy for designers to drop.
For the next 2 epics, the Design team then gave the developers the option to either:
- Use all the required data from Figma directly.
- Use the tracking plan as before and have Figma be a visual support if needed.
Results
By the end of 2 epics:
- Implementation hit 100% adoption. All event implementation and collaboration currently happen entirely in Figma.
- Event implementation time dropped by 50% and the following QA estimate dropped significantly too.
- Communications around events were unified and quicker response times immediately reduced friction significantly.
- Business and BI teams needing to investigate events now had an easier than ever way to deep dive into each event in UI context.
Developers using Figma exclusively were implementing faster than estimated, and QA was significantly reduced. Team leads received feedback from junior developers saying the new process makes their lives much easier.
Wait, is this real life?
To better understand the impact, we conducted follow-up interviews with the development team. Contrary to initial fears, once developers had more experience implementing events solely from Figma, they started developing a real taste for it.
What started as a visual guide, became a new standard, with the Design team available through the familiar communication process in context directly in Figma.
The major win came when the app development team leads requested to move all mobile tracking into Figma and use it as the new process for the entire mobile team 😲
What’s next
Though it’s still early for customer data infra in Figma — the impact we witnessed was real and the potential feels abundant.
Together with the Product and Design teams, we’re exploring scaling in-house automation and integration plugins with analytics platforms and pitching to expand the adoption of Figma data documentation across other teams within Crowded.
Outlook looks promising to say the least.
❤ Crowded Product Design
