Enterprise analytics dashboards with dense data views and embedded contexts.

Emplifi

Enterprise Analytics

Enterprise social analytics: metric-heavy dashboards that had to stay readable and responsive while rendering a lot of data at once. Most of my work sat where chart behaviour, React composition, and the rendering budget meet.

Senior Frontend Engineer· 2022–2023
  • React
  • TypeScript
  • D3.js
  • Design systems
  • Performance

Context

The dashboards were React, TypeScript, D3.js, and GSAP, shipped to standard browsers and to embedded mobile webviews. The webviews were the constraint that mattered: they surfaced animation and layout cost that desktop testing never showed.

Problem

Dense analytics degrade quietly. Interaction cost, layout pressure, and host constraints each look tolerable on their own, and then a customer opens the dashboard in a webview on a mid-range phone and the charts stop being usable. Cutting the data down would have solved the symptom and broken the product.

Diagram

Cutting the data vs cutting the rendering cost

Reduce what the dashboard shows

  • Makes charts usable again on lower-powered devices
  • Removes the dense data the product exists to show
  • Leaves interaction and layout cost unexamined

Reduce what rendering costs

  • Keeps dense views intact
  • Targets unnecessary re-renders and chart-update paint work
  • Tunes desktop and embedded webview contexts separately
  • Treats readability and interaction pacing as part of performance
Reducing what the dashboard shows would have fixed the symptom and broken the product, so the cost had to come out of rendering instead.

My role

  • Built dashboard modules in React, TypeScript, and D3.js.
  • Profiled and reduced rendering cost in dense views, focusing on the embedded webview path where problems showed up first.
  • Built the reusable, accessible components the dashboard modules were assembled from, and wrote the documentation that let other engineers use them without asking.
  • Used Sentry and Hotjar to understand how the dashboards behaved after release rather than only in local testing.

What I built

  • Metric-heavy dashboard modules with chart interactions and the UI around them.
  • Shared, accessible UI components and the usage documentation around them, so dashboard work started from an existing baseline instead of from scratch.
  • Responsive behaviour tuned separately for desktop and embedded mobile webview contexts.
  • GSAP motion used where it helped people keep their place in the data, not as decoration.

Diagram

How a dashboard module is composed

Select a layer to see what it owns.

  1. The dashboard UI, controls, and layout around each chart.

Splitting chart behavior from product composition let chart tuning happen without losing control of the surrounding dashboard UI.

Technical decisions

Decision

Use D3.js for chart behavior and React for surrounding product composition rather than trying to collapse the whole dashboard into a single abstraction.

Why

The product needed both tailored data visualization behavior and maintainable UI composition around it.

Trade-off

This requires careful coordination between chart rendering and the broader React surface.

Result

The team could tune chart-specific behavior without losing control of the surrounding dashboard UI.

Decision

Work on rendering performance specifically for embedded and mobile webview paths instead of assuming desktop behavior would translate well.

Why

Those contexts expose animation and layout problems earlier than standard desktop testing does.

Trade-off

Host-specific tuning adds more QA complexity and more edge conditions to account for.

Result

Dashboard modules stayed more usable in constrained contexts where performance issues would otherwise surface first.

Diagram

Performance work anchored to the webview path

Select a step to see what happens there.

Step 1 of 4

Run in webview

Test dashboard modules in embedded mobile webviews, not only desktop browsers.

Embedded mobile webviews surfaced animation and layout cost that desktop testing never showed, so that is where profiling started.

UX and detail decisions

  • Treated readability and interaction pacing as part of performance work, not as separate concerns.
  • Used production monitoring with Sentry and Hotjar to understand how dense dashboard UI behaved after release.
  • Made motion serve orientation and hierarchy rather than decorative movement.

Outcome

  • Cut unnecessary re-renders and chart-update paint cost on lower-powered devices by 80%.
  • Left behind reusable accessible components and documentation that colleagues credited with helping the team ship faster.
  • Left behind patterns for balancing chart interaction against readability in dense product surfaces.
  • Kept performance work anchored to the environments the dashboards actually ran in.

What I would improve

  • Document clearer motion and rendering budgets so new modules inherit the same constraints more consistently.
  • Capture more product-specific evidence around embedded edge cases as part of the portfolio narrative.