Introduction
Walk through most climate tech or deep tech companies' public materials and you'll spot the problem fast.
The investor deck uses one colour for "emissions reduced." The website dashboard uses a different one. The quarterly report flips the axis direction entirely.
Technically strong teams often publish charts, dashboards, pitch decks, and product screens with inconsistent colours, type, scales, labels, and chart conventions. Each piece might be accurate on its own. Together, they confuse the audiences who need to trust your data most: investors, regulators, and customers.
A data visualisation style guide fixes this by turning brand strategy and data literacy into repeatable design decisions. It helps audiences understand complex information faster while strengthening credibility with every chart they see.
This guide covers the components that matter: purpose-driven chart selection, colour and typography systems, accessibility and data integrity rules, reusable templates, and the governance needed to keep it all working as your company scales.
Key Takeaways
- A dataviz style guide defines how your brand communicates evidence, not just its logo or colour palette
- Build rules around audience, decision context, data type, and the platforms where charts appear
- Use specific chart examples and templates so non-designers apply the system correctly
- Treat the guide as a living system with an owner and a documented exception process
Why Data-Heavy Brands Need a Dedicated Data Visualisation Style Guide
A brand guide governs identity: logo, colours, tone of voice. A data visualisation guide governs something different: how quantitative evidence gets encoded and interpreted. One tells you what your company looks like. The other tells you whether a reader can trust the number on screen.
This distinction matters more for technical and climate-focused companies. You're often explaining unfamiliar terminology and scientific uncertainty. That same data then gets reused across websites, investor reports, dashboards, and product interfaces, often by teams who never spoke to each other.
Consistency doesn't mean every chart looks identical. It means a shared visual language: the same colour for "baseline" across every report, the same axis logic for every time-series chart, so each chart can still fit its question and dataset without new conventions every time.
Consider a typical emissions report built by three different contributors:
- Green means "reduction" in one chart and "current emissions" in another
- Units switch between tonnes and kilotonnes with no flag
- The insight sits in a footnote instead of the chart title
A shared chart language fixes this: consistent colour roles, matching annotation style, and hierarchy that puts the insight in the title.
We've seen this play out directly with climate tech clients. Ribbit Network, which builds sensor networks for atmospheric carbon monitoring, needed its data visualisation to work identically whether it appeared in a scientific report, an investor update, or a live dashboard. That shared language lets a grid operator or a VC parse the same chart in seconds, without clarifying questions.
The Essential Building Blocks of a Data Visualisation Style Guide
Every functioning guide documents a minimum set of components. Skip one, and your designers or analysts will improvise, which is exactly the inconsistency you're trying to eliminate.
| Component | Job it performs |
|---|---|
| Brand expression | Approved logo use, visual tone, background treatment, how much identity surrounds the data |
| Chart system | Approved chart types, intended use cases, unsuitable uses, examples for common datasets |
| Visual variables | Colour, typography, spacing, gridlines, axes, legends, annotations, icons, interaction states |
| Accessibility and integrity | Contrast, colour-independent cues, readable type, honest scales, source notes, units, uncertainty, alt text |
Build Semantic Colour Tokens, Not Just Brand Swatches
Your brand palette tells you what "on-brand" looks like. It doesn't tell a chart which colour means "comparison series" versus "alert." That's where semantic tokens come in, naming colours by role rather than hex code:
- Primary series and comparison series
- Highlight and neutral context
- Positive movement and negative movement
- Missing data and uncertainty bands
Design systems like IBM Carbon publish separate categorical, sequential, and diverging palettes for this reason. A palette built to distinguish unrelated categories does not work for ordered magnitude. Don't assign chart meaning based only on which colours happen to sit in your logo.
For implementation, document actual values: HEX, RGB, and CMYK where print matters, plus CSS variables, font fallbacks, spacing units, and export requirements.
A workable guide structure usually covers:
- Principles
- Colour and typography
- Chart anatomy and chart recipes
- Accessibility
- Templates and do/don't examples
- Governance
Chart Selection and Formatting Rules for Common Data Types
Choosing a chart type should start with the question you need answered, not which chart looks most impressive in a deck. The Financial Times' chart vocabulary groups formats by analytical purpose, which is a far better organising principle than listing chart types alphabetically.
| Analytical purpose | Recommended chart | Common misuse |
|---|---|---|
| Change over time | Line or column chart | 3D effects that distort the trend |
| Comparison | Ordered bar chart | Unordered categories that force extra reading |
| Distribution | Histogram or boxplot | Pie charts with too many slices |
| Part-to-whole | Stacked or proportional bar | Donut charts with similar-sized segments |
| Relationship | Scatterplot | Dual axes that imply false correlation |
| Geography | Choropleth (rates) or proportional symbols (counts) | Choropleths for raw counts, which distort by area size |
| KPI monitoring | Scorecard with target comparison | Sparklines with no baseline reference |
Standardise chart anatomy across every output:
- Title that states the insight, not just the metric name
- Subtitle or methodology note where the data source needs context
- Direct labels where practical, instead of forcing readers to cross-reference a legend
- Units, source, and date range, every single time
- Explanatory caption when the "why it matters" isn't obvious from the chart alone
The same rules apply when charts move into product UI. Dashboards need a clear hierarchy:
- Primary metrics get visual priority
- Supporting context sits below
- Alerts interrupt only when necessary
- Filters, empty states, and loading states use the same chart language as your reports
Climate dashboards often fail here. A loading spinner that looks nothing like the rest of the product breaks trust as fast as a mislabelled axis.
Colour, Typography, Accessibility, and Data Integrity
Colour and Accessibility
A restrained palette beats a decorative one. Build four distinct sets:
- Categorical palette for unrelated groups
- Sequential scales for ordered magnitude
- Diverging scales for data with a meaningful midpoint
- Alert and highlight colours reserved for exceptions
Test every palette against your actual brand background and the chart sizes you'll really ship, not just a swatch on a white canvas.
WCAG 2.2 sets specific, testable thresholds: 4.5:1 contrast for ordinary text and 3:1 for necessary non-text graphical information, including the lines and bars that carry your data.
Colour can never be the only way you communicate status or category. Pair it with patterns, icons, or direct labels for colour-vision-deficient readers.
Typography and Data Integrity Rules
Keep a clear font hierarchy: titles, labels, annotations, legends, and axes each get a defined size and weight, with minimum readable sizes for dense dashboards and a documented fallback font for every platform.
Data integrity rules protect your credibility:
- Consistent baselines across comparable charts
- Proportional scales that don't exaggerate differences
- Visible units and clear denominators on every axis
- Source attribution and update dates on every published chart
- Disclosure of estimates or uncertainty, rather than hiding it
Small visual choices change how people read your numbers. Across five separate studies, 83.5% of participants showed a measurable effect where truncated bar graphs made differences look larger than they actually were. For a climate tech company reporting emissions reductions, that distortion is a credibility risk.
Pre-publication checklist:
- Is the data accurate and the source credited?
- Is text legible at the smallest size it will be viewed?
- Does the chart pass contrast and colour-independence checks?
- Does it hold up on mobile and in print?
- Does the visual emphasis match the actual scientific or business significance?
How to Create and Roll Out the Guide
Start with an audit, not a blank Figma file. Pull every chart your company has published in the last year: investor decks, website graphics, product dashboards, social posts. Look for repeated chart types, accessibility gaps, and the handful of use cases that get reused constantly.
Then talk to the people actually making and reading these visuals: founders, analysts, scientists, product teams, sales reps, and customers. You'll usually find the current rules (or lack of them) create friction in predictable places—like analysts defaulting to whatever Excel suggests because no better option exists.
Build a minimum viable system first:
- A small set of chart recipes covering your most common datasets
- Defined colour roles and type styles
- Annotation and source-citation conventions
- Editable, real templates, not placeholders
Validate it with real data in dense dashboards, printed reports, mobile layouts, and investor materials before expanding scope.
What if Design uses this same path with climate-tech, ESG, energy, and deep-tech teams: turn complex science and business goals into coherent brand, website, and product systems.
On projects like HYDGEN and Susteon, that meant colour palettes and typography built for technical readability, then design tokens engineering teams could implement—not a PDF nobody opens again.
For implementation, use what your team will realistically maintain: Figma libraries, presentation templates, CSS variables, charting-library themes, or spreadsheet templates, backed by a central documentation URL.
Then lock in rollout habits:
- Name a single owner for the guide
- Record version history on every change
- Define a clear exception process
- Review accessibility as audiences and data practices evolve
Frequently Asked Questions
What are the 7 stages of data visualisation?
Ben Fry's 2007 framework outlines seven stages: Acquire, Parse, Filter, Mine, Represent, Refine, and Interact. Names vary by framework, but Represent, Refine, and Interact matter most for style guide decisions.
Can you give me an example of a style guide?
A practical style guide covers brand principles, chart do/don'ts, colour roles, typography, chart anatomy, accessibility rules, source conventions, and reusable templates for common chart types.
What are the 5 C's of data visualisation?
One commonly cited chart-design framework lists Clarity, Clutter, Context, Consistency, and Contrast. Terminology differs between practitioners, so treat this as one useful lens rather than a universal standard.
What are some common styles of data visualisation?
Common styles include explanatory charts (making one specific point), exploratory dashboards (for discovery), KPI scorecards (target comparisons), narrative data stories, and maps. Each suits a different audience and decision context.
