Data science beyond the dashboard

Data science work is often equated with experimentation, forecasting, and optimization. But in domains where correctness and visibility are paramount, the practice looks markedly different: less A/B testing, more modeling of event lifecycles, cross-system data reconciliation, and building small tools that make complex systems legible.

Madison Kohls, a data scientist supporting Figma’s Billing infrastructure, describes this shift in practice and outlines lessons that apply broadly to high-stakes domains. Her account challenges the assumption that impactful data science must produce a model or a metric — sometimes it means producing clarity.

A full-stack approach to data science

The value data science can add varies dramatically by team. Some groups need rigorous experimentation frameworks; others require deep product analyses or strong data modeling and instrumentation. Figma hires full-stack data scientists because a single role often spans most of these modes — sometimes within a single project.

Billing sits between a user-facing product and a backend system. Reliable, accurate billing directly affects customer experience and trust. Supporting Billing with data science means building domain expertise, partnering closely across functions, and developing tools that explain, verify, or clarify system behavior. Tasks like experimentation and opportunity analysis matter but represent a smaller slice of the work than traditional DS assumptions would suggest. Figma’s engineering culture values initiative over convention, which permitted exploring and co-defining the right support model with partners rather than following a playbook.

Explanations that aren’t charts

Some of the most impactful work focuses on explaining how past or present outcomes of a complex system came to be. This was the case when simplifying Figma’s invoicing process. Users occupy seats, and the lifecycle of those seats — assignments, removals, permission changes, contract terms, and edge-case adjustments — spans several systems with different schemas. What appears as a simple line item on an invoice can represent a long chain of interactions.

Many internal teams need to understand how charges come to be. Support, order-management, and enterprise specialists must explain invoices to customers confidently. Billing and monetization engineers rely on precise charge histories when debugging unexpected behavior. To make this complexity tractable, the team built the Invoice Seat Report, a data application that reconstructs the full narrative behind each seat charge, pulling together product usage events, contract metadata, billing rules, and state transitions into a plain-language explanation.

The effort required more than querying tables. Early work involved wrangling fragmented data and building a shared mental model of how seat state evolves across systems. Existing logs often captured what happened but not why, necessitating collaboration with engineering to ensure future events reflected underlying mechanics. Seat pricing depends not just on usage events but on contractual terms, upgrade paths, workspace state, and the exact timing of transitions — including legacy multiyear contracts with sparse history and early upgrades that create data blind spots. This required careful translation of rules into traceable, debuggable SQL transformations.

Shaping technical direction

By translating business rules into measurable checks, data science can define what correct looks like, monitor for drift or regressions, and surface anomalies early. This provides additional assurance in development and production for complex, stateful workflows where failures are subtle and costly.

When Figma refreshed its billing model — a major re-architecture of pricing, packaging, and mechanics — the team needed to verify new logic worked as intended across pipelines and environments. To support this, they built consistency checkers: SQL-based invariant tests that compare expected system state against data recorded across multiple sources of truth on a schedule. These fall into two categories:

  • Data-quality checks, validating whether stored data reflects the real product state
  • Code-logic checks, detecting divergence between application behavior and defined billing rules

Consistency checkers enforce correctness more thoroughly than end-to-end testing or User Acceptance Testing, which is why other companies use them as part of testing strategy. Designing invariants required mapping how data moves through billing systems and where it can go wrong. The team encoded assumptions into simple, explainable SQL checks. When a checker detected a violation, it routed a structured alert with the relevant rows and metadata to the engineering team. Because checks unified product logs, billing state, payment processing, and CRM data, they offered a holistic view not captured elsewhere in the stack. Results surfaced both code-quality issues (usually race conditions or unexpected edge cases) and data quality gaps from missing or misaligned logging.

Scaling impact through applications

When a question or workflow repeats often, turning the underlying logic into a simple application saves time and reduces cognitive load. Both the Invoice Seat Report and consistency checkers started as bespoke analyses and became data applications when multiple teams were found to depend on the same logic.

The Invoice Seat Report captured the full sequence behind each seat charge, giving support, order management, and engineering a shared, reliable explanation — and becoming one of the most-viewed data applications at Figma. Consistency checkers encoded invariants giving engineers real-time observability during the billing refresh, which caught edge-case bugs early and made for an uneventful rollout. The framework has since been adopted beyond billing, powering checks for product security, access and identity management, and growth teams. Connected projects, for instance, use consistency checkers to confirm sharing and access settings behave as expected.

The lesson: in correctness-driven domains, data science isn't just analysis. Some of the most impactful work is building small, durable applications that embed shared logic into how teams operate.

A familiar process, unfamiliar deliveries

The core data science process doesn’t change even when the work does. The same steps used for ML modeling or A/B testing apply — they just expand to fit correctness-driven, systems-heavy areas. Understanding the domain meant mapping system boundaries and learning how first-party logic interacted with external systems like Stripe. Gathering and cleaning data involved advocating for new logs and aligning representations across services. Exploratory analysis meant reconstructing how the system arrived at an outcome by stitching together product events, contract logic, and state transitions.

The deliverables, however, differed. Instead of a model or writeup, the work produced tools like the Invoice Seat Report and consistency checkers — forms that aligned better with the Billing team’s needs than presentations or experiments would have.

Reconstructing event paths, defining invariants, and packaging reasoning into internal tools are not specific to Billing. They are approaches that can help any team bring clarity and confidence to complex systems as the field of data science continues to evolve.

The Collaboration Layer

Modern data work is rarely a solo effort. The shift toward shared, versioned artifacts means that code review, documentation, and peer feedback are no longer afterthoughts—they are part of the core workflow. Treating analysis as a collaborative product, rather than a personal deliverable, changes how you structure your work.

Put the same rigor into your notebooks and scripts that you would into production code. This means:

  • Using clear, consistent naming conventions for variables and files.
  • Writing modular, reusable functions instead of long, monolithic cells.
  • Documenting decisions inline, so that future readers understand not just what you did, but why.

Reviewers and stakeholders should be able to trace your logic from raw data to final recommendation. That transparency reduces the friction of handoffs and builds trust in your findings. When someone else can pick up your work without a lengthy walkthrough, your contribution has a longer shelf life and a wider reach.

Designing for Comprehension

Even the most rigorous analysis fails if the audience cannot grasp it. Visuals are not decoration; they are the delivery mechanism for your conclusions. Prioritize clarity over complexity in every chart you produce. Every graph should answer a single, specific question, and the visual encoding should make that answer obvious at a glance.

Practical guidelines:

  1. Label axes directly and fully—abbreviations confuse readers.
  2. Use color deliberately; reserve it for highlighting the key takeaway, not for decoration.
  3. Order categorical data by value or by a logical sequence, not alphabetically.
  4. Remove chart clutter: gridlines, borders, and legends that merely repeat what is already visible.

A well designed visualization lowers the cost of comprehension. When your audience spends less time decoding the chart, they spend more time evaluating the insight, which is where your value as a data scientist comes through. Ultimately, effective communication is not a soft skill layered on top of your technical work—it is the medium through which that work becomes actionable. Presentation shapes whether your analysis changes minds or just occupies disk space.