Design System for Trustworthy Data Interfaces
This page documents the system behind how data interfaces are designed for clarity, consistency, and trust.
This page explains the system, then shows how it is implemented and used.
System Flow
Design Tokens → UI Components → Charts → Trust Layer → Interpretation → Decision Layer
Introduction
The goal of this system is to make interface decisions explicit and repeatable so that information is interpreted carefully, not just consumed quickly.
Authorship and Intent
This system was designed and implemented as part of my transition toward Information Design, with a focus on building trustworthy data interfaces.
Why This System Exists
- Dashboards can mislead when visual hierarchy or emphasis is inconsistent.
- UI inconsistency creates cognitive overhead and reduces confidence in interpretation.
- Information design requires system-level thinking so structure and meaning scale together.
- For example, dashboards often highlight metrics without clarifying scope or limitations, leading to overconfidence in interpretation.
Core Principles
- Calm over attention.
- Clarity over decoration.
- Trust over persuasion.
- Restraint over novelty.
Data Integrity Rules
This system prioritizes truthful and responsible communication of data. Every visualization is expected to prevent misinterpretation, not just display information quickly.
Nothing critical is hidden
- Key assumptions, limitations, and transformations must be visible.
- If context is required to interpret data correctly, it must be shown alongside the data.
Uncertainty is communicated, not removed
- When data is incomplete, estimated, or variable, this is explicitly represented.
- Precision is not implied where it does not exist.
Aggregation does not erase variation
- When data is grouped or summarized, the loss of detail is acknowledged.
- Where necessary, users are given a way to explore underlying variation.
Missing data is shown clearly
- Absence of data is never treated as zero.
- Missing values are explicitly labelled or visually differentiated.
Interpretation is separated from data
- The system distinguishes between what the data shows and what it might mean.
- Interpretation is always contextualized and bounded.
System Architecture
System Foundation
- A shared semantic token layer for color, type, spacing, motion, charts, and trust UI.
- Mantine theme settings aligned to system typography, radii, and defaults.
UI Standardization
- Consistent token usage across navigation, projects, case studies, and timeline UI.
- Unified project-card interaction patterns and modal behavior.
Trust Layer
- Reusable trust components for sources, methods, scope limits, and definitions.
Chart System
- A token-based chart reference to keep axis, grid, series, and highlight usage consistent.
Enforcement
- Shared SCSS mixins and documentation guardrails that reduce styling drift over time.
Trust Layer
Trust notes are treated as first-class UI patterns. They are intentionally quiet, factual, and grouped so users can understand source quality, methodological limits, and interpretation boundaries.
These patterns reduce misinterpretation by making limits, evidence, and definitions visible at the point of reading.
The trust layer is a reusable system rule, not an optional add-on. It is always required when data is aggregated, when data is incomplete or estimated, or when a visualization may influence decisions.
Each visualization may include Source (where data originates), Methodology (how data was processed), Scope (what is included and excluded), and Limitations (known constraints or uncertainties).
Placement follows context needs: inline for critical data, expandable for detailed context, and always accessible without leaving the current view.
Source
Source attribution pattern
- Primary datasets and provenance references
- Transformation and aggregation assumptions
Methodology
Method note pattern
Scope
What this shows
Scope
What this does not show
Definition
Interpretation boundary
Decision Layer
This system does not stop at presenting data. It supports informed decision-making by structuring how insights are derived from evidence and context.
- What is happening?
- Why is it happening?
- What does this mean in context?
- What action should be considered?
- Data → factual representation.
- Interpretation → contextual explanation.
- Decision → possible actions.
Decisions should be grounded in evidence, not assumption.
Chart System
Charts use the same semantic token system as the rest of the interface. Axis and grid structure stay neutral, context series remain muted, and highlight is used sparingly.
Charts follow the same design rules as the interface: calm, structured, and unbiased.
Tokenized chart reference
Axis, grid, series, legend, and emphasis consume dsChartTokens.
Highlight is reserved for a single emphasized point; all other context remains muted.
- Axis: provides structure and readable orientation.
- Grid: provides reference for comparison without visual dominance.
- Series: represents data using categorical/system tokens.
- Highlight: reserved for purposeful emphasis.
- Muted context: supports side-by-side comparison without distraction.
Chart Usage Guide
Chart selection is based on the structure of the data and the question being asked, so visual form supports valid interpretation rather than preference.
Line Charts
- Use when showing trends over time or comparing change across periods.
- Avoid when points are sparse, irregular, or exact individual values matter more than trend.
- Risk: can imply continuity where data may be discontinuous.
Bar Charts
- Use when comparing discrete categories or showing relative differences clearly.
- Avoid when there are too many categories or differences are too small to perceive.
- Risk: can exaggerate differences if scale is not carefully controlled.
Maps / Geospatial Views
- Use when location is critical or spatial distribution reveals meaningful patterns.
- Avoid when geographic variation is not meaningful or data density varies heavily across regions.
- Risk: large regions may appear more important than they are.
How Consistency is Maintained
- DS tokens are the source of truth for color, spacing, typography, and motion.
- Legacy hex-value drift is removed in favor of semantic token references.
- Shared mixins prevent local duplication in repeated project UI patterns.
- Trust and chart patterns are implemented as reusable components.
- No ad hoc styling is introduced at component level.
What This Enables
This system enables building data interfaces that are:
- Consistent.
- Interpretable.
- Trustworthy.
- Scalable.
System in Practice: California Wildfire Dashboard
This design system is applied in the California Wildfire Dashboard to transform complex raw data into a structured, interpretable interface.
Before
- Raw datasets with fragmented structure.
- Difficult to identify meaningful patterns.
- High risk of misinterpretation.
After applying the system
- Clear visual hierarchy.
- Structured exploration of wildfire activity.
- Trust layer provides context for interpretation.
- Data is presented with appropriate constraints and clarity.
Outcome
- Users can understand wildfire patterns over time.
- Compare regions meaningfully.
- Interpret data within its limitations.
California Wildfire Activity
A structured interface for understanding historical wildfire patterns.
This preview applies the chart system, trust-layer patterns, and narrative flow to support careful interpretation of wildfire activity data.
The goal is to support clearer understanding of real-world conditions and enable more informed decisions.