Data Visualization Guide

Creating a unified Data Visualization Guide to ensure clarity, consistency, and accessibility across cross-functional teams.

Role

UX lead / Product Designer

The Challenge

Teams struggled to create accessible and consistent visualizations. WCAG guidelines—while essential—were often too technical and hard to apply, leading to uneven accessibility practices. Misunderstandings around color usage created tension between brand, clarity, and accessibility.

Teams also lacked a shared approach to chart selection, resulting in inconsistent patterns and duplicated effort.

Objectives

Design a Data Visualization Guide that unifies how the organization communicates data while keeping accessibility at the forefront. The guide needed to:

Ensure all visualizations meet WCAG 2.1 accessibility standards
Establish visual and conceptual consistency across teams
Make chart selection and color usage clear and approachable
Strengthen collaboration through reusable principles

Approach

To make the process clear and actionable, the work was organized into three steps.

1. User Research

We started by understanding the people behind the visualizations. Stakeholder mapping revealed four groups: Brand/Marketing, Product Design, Front-End Development, and Data Analysis. Using an influence x relevance matrix, we focused on the three most critical: Product Designer, Front-End Developer, and Data Analyst.

A cross-functional survey surfaced common frustrations: inconsistent chart standards, unclear accessibility requirements, and duplicated work during handoff. We also learned that each role defined “readability” differently — designers through aesthetics, developers through structure, and analysts through comprehension.

From these insights, we created three personas:

Maja Wallner, a Product Designer balancing brand and accessibility
Stephan Ackner, a Front-End Developer focused on technical scalability
Lukas Schneider, a Data Analyst translating complex insights for non-technical audiences.

These personas helped shape the guide's tone and ensured all disciplines were equally represented.

2. Information Architecture

To structure the content, we ran a closed card-sorting exercise with participants from each role. Using a similarity matrix, we identified strong consensus on how information should be grouped and navigated.

The result was a four-pillar information architecture:

Basics & Glossary — Foundational terms, chart types, and shared vocabulary
Color Palettes — Balancing brand expression with accessibility and color-blindness support
Data Visualizations — Chart anatomy, dashboard design, and responsive behavior
Accessibility — WCAG guidelines, ARIA patterns, testing tools, and inclusive practices

Each section mapped to specific user needs: designers leaned on Basics and Color; developers on Visualizations and Accessibility; analysts spanned Basics and Visualizations.

To maintain consistency across tools, we documented design tokens, reusable chart components, and example patterns that could be easily implemented in the product ecosystem.

3. Validation & Refinement

Before publication, the guide went through multiple review rounds. Accessibility specialists validated color contrast, keyboard navigation, and ARIA labeling. Internal teams tested the guide in their workflows, helping identify areas where instructions or examples needed simplification.

The Solution

Accessibility was embedded from the start, not added later.

The guide outlined concrete principles for accessible data visualization:

Fully WCAG 2.1 AA compliant site
Use Semantic HTML and ARIA roles to describe user interactions
Include skip-navigationand landmarks for screen-reader navigation
Light and Dark themes

Each discipline benefited in tangible ways:

Designers gained color recipes and usage guidelines; developers received ready-to-use code snippets; analysts learned clearer labeling and annotation techniques. Together, they established a workflow that naturally produced accessible, consistent visualizations.

Impact

The Data Visualization Guide became a single source of truth for how the organization approaches data visuals. It improved cross-team communication, reduced redundant work, and set clear accessibility expectations from the start of every project.

Early feedback was highly positive. Designers reported faster alignment on color and typography, while developers appreciated having codified accessibility examples instead of scattered references.

Reflection

This project reaffirmed that accessibility and consistency are inseparable. When teams share a common design language, collaboration becomes smoother — and users benefit from clearer, more inclusive visual communication.

By bringing designers, developers, and analysts together under one accessible framework, we built a foundation for data visualizations that are both unified in appearance and equitable in experience.