Charts — Data Visualization Component Library

ecoPortal is a corporate incident management platform where data drives decisions. Safety managers, compliance teams, and executives need to read incident trends, compare categories, and identify patterns across time — but the platform had no consistent component system for data visualization.

Charts appeared ad-hoc across different parts of the product, each designed independently, with inconsistent visual language, different axis treatments, and no shared token system. The result was a fragmented experience where the same type of data looked different depending on which screen you were on.

"How do we design a chart component system that is flexible enough to serve any data scenario the product might need, but constrained enough that it always feels like one cohesive product?"

The scope was broad from the start: four chart families (Area, Bar, Line, Combo), each with multiple data complexity variants and multiple responsive breakpoints.

The project was initiated by the product team after a recurring pain point: engineers were building charts from scratch each time a new screen needed data visualization. There was no reusable component, no agreed visual language, and no guidance on which chart type to use for which data scenario.

The briefing mapped out the required chart families based on existing and planned product features:

• Trend visualization — how incidents evolve over time (Area and Line charts)
• Category comparison — breakdown by type, department, or status (Bar charts)
• Geographic distribution — incidents by location or site (Bar Chart — Locations)
• Combined metrics — overlay of multiple data dimensions in a single view (Combo charts)

Design questions defined in the briefing:

• How many series should each chart type support, and at what point does complexity require a different chart type?
• How do we handle segmented data — stacked vs. grouped vs. proportional?
• What does a responsive chart component look like at different breakpoints, and what information can be dropped at smaller sizes?
• How do Combo charts blend two chart types without creating visual ambiguity?

With the four chart families defined, I ran a broad exploration phase before committing to any component structure. I reviewed how enterprise analytics tools (Tableau, Looker, Grafana, Power BI) handle chart component libraries, and studied how design systems like Carbon, Polaris, and Atlassian Design System approach data visualization at scale.

Key hypotheses from the exploration:

• Chart variants shouldn't multiply beyond the product's actual data scenarios — every variant needs a real use case to justify it.
• Consistent axis, grid, and legend patterns are more important than chart-level differentiation — the visual grammar should be unified even when chart shapes differ.
• Responsive behavior for charts is fundamentally different from layout responsiveness — it's not just reflow, it's about which data labels, axes, and legends survive at smaller sizes.
• Combo charts need a visual hierarchy rule: one chart type reads as "primary" and the other as "overlay," not two competing equals.

I mapped out all the variant combinations that would be needed: per chart family, the data complexity variants (1 series, multi-series, segmented, dataset-applied) and per variant, the responsive breakpoints.

Lo-fi testing for a component library project focuses less on task flows and more on comprehension and scalability. I built low-fidelity versions of the core chart components and tested them with the product's internal data consumers: analysts and managers who regularly interpret incident reports.

What was tested:

• Whether users could distinguish chart types at a glance and understand what each was designed to show
• Whether the segmented variants (stacked groupings) were immediately readable or required explanation
• Whether the responsive behavior at smaller breakpoints maintained data legibility
• Whether Combo charts (bar + line overlay) were read as a unified visualization or two separate charts stacked

Main findings:

• Area charts with multiple series were often confused with Line charts — the fill area needed stronger visual treatment to carry its own identity.
• Segmented Bar charts required a clear legend in all breakpoints, even the smallest — removing the legend at small sizes broke comprehension.
• Combo charts with equal visual weight on both layers caused confusion. Testing confirmed that one layer needed to be clearly subordinate — lighter weight, lower opacity — to establish reading order.
• The "Locations" bar variant was the most immediately understood — horizontal bars with location labels were the most natural read for geographic comparisons.

With testing findings in hand, I revised the component structure before moving to hi-fi. The changes were structural — about how components were organized and what rules governed their behavior — not yet about visual polish.

What changed

Area Chart visual treatment strengthened — Increased fill opacity and softened the line weight to separate Area charts from Line charts as distinct chart types, not style variants.

Legend rule formalized — Legends became mandatory at all breakpoints for segmented variants. At the smallest breakpoints, labels could be truncated but the legend could never be removed.

Combo Chart hierarchy rule established — The primary metric uses the bar layer (solid, full opacity); the secondary metric uses the line layer (lighter weight, slightly lower opacity). This rule was documented as a component usage guideline, not just a design decision.

Responsive breakpoint set defined — Confirmed the breakpoint set for the library: large (desktop default), medium (reduced padding, smaller axis labels), small (minimal — only essential data labels survive), and an extra-small thumbnail variant used in dashboard overview cards.

Segmentation variants scoped — Segmented versions were defined for Bar and Combo charts only, based on actual product data scenarios. Area segmented was scoped in; Line segmented was out of scope for this cycle.

With the component structure validated, I moved to hi-fi — building every variant, state, and responsive size within ecoPortal's Design System token system.

The final library covers four chart families:

Area Chart — Three variants: 1 series (single trend line with fill), multi series (multiple overlapping fills with distinct colors), and segmented (stacked area proportions). Used for time-based trend visualization.

Bar Chart — Four variants: 1 series (single vertical bar per category), multi-series (grouped bars per category), segmented (stacked bars per category), and Locations (horizontal bars with site/location labels on the Y-axis). Used for category comparison and geographic distribution.

Line Chart — Three variants: 1 series, multi-series (multiple lines with distinct colors and dot markers), and segmented. Used for precise trend comparison where exact value reading matters more than volume.

Combo Chart — Four variants: 2 series (bar primary + line overlay), Dataset applied (bars colored by dataset dimension), Segmentation (stacked bars + line overlay), and a fourth compositional variant for custom combinations. Used for overlaying a trend metric onto a categorical distribution.

Each variant was designed at four responsive sizes, with explicit rules for what survives at each breakpoint: which labels, which axis ticks, which legends, and which interactive states.

Key design decisions

Unified token system — All chart components inherit from ecoPortal's data visualization tokens (color ramps, axis colors, grid opacity, label typography). Adding a new chart type in the future requires no new tokens — only new component assembly.

Dark background as the default — Charts use a dark canvas with light data elements, consistent with the platform's dashboard aesthetic. This wasn't just a visual choice — dark backgrounds reduce eye strain in the monitoring contexts where these charts are used most.

Thumbnail variants — Every chart type includes a thumbnail-scale variant (the smallest responsive size) designed specifically for dashboard overview cards, where the chart communicates trend direction rather than exact values.

As with all my projects at ecoPortal, I owned the implementation QA alongside the handoff. I followed every sprint of the chart library's implementation and reviewed each component delivery against the design spec.

Handoff documentation included: component anatomy annotations for each variant, token mapping per visual element (fill color, axis line, grid opacity, label style), responsive behavior specs per breakpoint, and usage guidelines documenting when to use each chart type and variant.

Two dedicated handoff sessions were held with the engineering team — one for the Area/Bar/Line families and one for the Combo chart family, which required more detailed interaction specs for the overlay behavior.

Main QA findings:

• Area chart fill opacity not matching the specified token value at the multi-series variant
• Bar chart grouped variant gap ratio between bars slightly off from spec
• Line chart dot markers not rendering at the correct size at the small breakpoint
• Combo chart line layer rendering above the bar layer instead of below (z-index issue)
• Legend color swatches not matching the chart series colors in the dark theme

All issues were corrected before the library was marked ready for use.

The chart component library shipped as a foundation layer for all current and future data screens in ecoPortal. Every new screen that needed a chart could now pull from the library rather than building from scratch — reducing design and engineering time per screen significantly.

What worked:

• Defining usage rules as part of the component (not just a separate document) meant the engineering team could make correct chart-type decisions independently, without always consulting design.
• The responsive breakpoint set, validated in lo-fi before hi-fi, held up through implementation with only minor QA corrections.
• The dark background token approach made the library immediately compatible with ecoPortal's existing dashboard screens — no visual adaptation required.

What would be different:

• Earlier audit of all existing screens before designing. Mapping every ad-hoc chart that already existed would have surfaced more edge cases before the lo-fi phase.
• Interactive states (hover tooltips, active data points) could have been specced in the same cycle rather than deferred. They became the first addition request post-launch.
• A usage decision tree — "which chart type should I use for this data?" — as a formal artifact would have reduced engineering questions during implementation.

Next steps: interactive state specs (hover, tooltip, active selection); a donut/pie chart family for part-of-whole scenarios; and integration of the chart library tokens into the broader ecoPortal Design System documentation.