Data Visualization Requirements & Design System

The team included a Data Scientist, Database Administrator, Product Owner, and Business Analyst, but no shared process existed for turning their respective knowledge into a complete visualization requirement. I researched data visualization as a discipline, then built a requirements process that defined the user, purpose, data, and relationship before any chart was selected.

That process became the foundation for a chart-selection framework and an extension of the Clinisys design system. Implementation constraints later exposed another problem: a visualization could be easier to build while communicating something different from what the data actually supported.

The tool shipped, and the requirements process, principles, and design system gave the team a way to define and review visualization work without ongoing UX involvement.

Clinisys was developing an application-agnostic data visualization tool intended to support its full product portfolio. I was asked to design the interface and extend the existing design system for data visualization, but the requirements arriving in Design described desired reports without defining the measures, calculations, dimensions, context, or questions those visualizations needed to answer.

There was also ambiguity around the scope of Design. I was asked to develop the visualizations directly in Power BI as well. My role stayed focused on designing the interface and the visual representation of the data; implementation in Power BI remained with the development team.

My first role in IT was in report writing, so I came into the project with a foundation in structured data, queries, calculations, and reporting logic, but that experience was very different from designing data visualizations. In application design, I was accustomed to starting with the user and their work; data visualization required a different way of thinking, since the representation itself carries meaning. I studied established data visualization research and practice, including Good Charts, Storytelling with Data, and Fundamentals of Data Visualization, and became much more conscious of how aggregation, scales, baselines, axes, and omitted context can alter perception. A visualization can contain accurate values and still create a misleading impression.

I translated the research into a Data Visualization Requirements process. Instead of asking the requesting team to specify a chart, the requirements forced us to define the user and purpose first, followed by the underlying data and the relationship that needed to be communicated. Ownership was deliberate: the Product Owner and Business Analyst were responsible for defining the user and goals, while the Data Scientist and Database Administrator were responsible for defining the data. Interaction requirements, including filtering, highlighting, drill-down, drill-through, and contextual information, were defined separately. View the Data Visualization Requirements form ↗

I developed a chart selection framework that considered the relationship alongside the structure and dimensionality of the data. Comparison, change over time, distribution, composition, correlation, ranking, and other relationships each introduced different possibilities; the number of measures and categories, whether the data was continuous or categorical, whether time was involved, and the level of precision required further narrowed the selection. The goal was not to prescribe a chart from a single characteristic of the data, but to systematically narrow the available representations until the chart matched both the analytic relationship and the data's structure.

I also extended the existing design system to establish data visualization conventions it hadn't addressed: standards for chart selection and anatomy, axes and scales, labels and legends, interaction, visual hierarchy, and the use of color, including 10-color categorical palettes so visualizations with different numbers of data series could remain distinguishable and consistent across products. View the Data Visualization Design System ↗

The visualizations ultimately had to be implemented in Power BI, which introduced a significant constraint: the implementation team primarily relied on Power BI's graphical interface and lacked the proficiency to use its more advanced capabilities. I accounted for that constraint where possible, but implementation capability could not determine how the data was represented. A visualization could be simplified if the alternative preserved the same meaning; it could not simply be replaced with something easier to build if doing so changed what the data communicated.

My involvement continued after the visualizations were handed off for implementation: the team would recreate the designs in Power BI and return them to me for review and approval. In some cases, implementation decisions changed how the data itself was represented. Units of measurement could change between charts on the same page. Related visualizations could use their axes inconsistently. Numerical values were sometimes represented out of proportion because the accurate representation was considered visually undesirable. In other cases, a different chart was substituted because it was easier to produce in Power BI, even though it communicated a different relationship in the data. These were not differences in styling; they changed what a user could reasonably conclude from the visualization. When that happened, the visualization went back for revision before approval.