Designing trustworthy interactions with large language models
How can we integrate large language models in design effectively while addressing their limitations and ensuring trust?
An underexposed area within design systems is data visualization. Looking for example at IBM’s Carbon Design System, which is considered a leading standard, the data visualization section doesn’t fit seamlessly in the overall design system. For companies with a strong dependency on data, which is almost any organization these days, there is much to be gained. Both for internal applications as well as customer-facing products.
In this article I will explain:
I will use examples of two of our client cases to illustrate what this means in practice.
The basic principle behind a data design system is similar to a “traditional” design system; by deconstructing, standardizing and structuring the different types of data visualizations you gain efficiency and scalability, while at the same time improving the quality and consistency across your products and services.
The difference between the two lies in the nature of data visualization. Next to the high complexity of data visualization, there is a limit to what extent you can, for example, deconstruct a line-chart. The different elements that make up a line-chart are heavily intertwined.
Similar to isolating an input field as a reusable component or defining a search pattern in a “traditional” design system, you can distill general principles to provide guidance in, for example, applying the correct line color and thickness across different types of charts (e.g. line-chart, sparkline or timeline). Also, legend interaction or hover and select states can be deconstructed as recurring patterns applicable to different types of charts.
However, combining all the different guidelines and patterns does not allow you to consistently build up a line-chart, or any chart for that matter. The line needs to be in context of the other elements of a chart for it to have meaning. In order to fit it into a system. As such, in a data design system we add a third layer. Next to the commonly used categories “components” and “patterns”, we add “charts”. Within this category we describe the generic behavior, attributes and rules that apply to the applicable chart-type.
As such, we use three categories when designing or deconstructing a data visualization within a data design system:
As part of the overarching design language we then ask ourselves:
For Cisco DNA we included the timeline chart in the chart library. The different variations touch upon a few recurring patterns and guidelines that were applicable for this chart. For example, how to deal with the patterns no-data, thresholds and hover as well as applying the guidelines for data color usage, typography and layout.
There are numerous articles written on the benefits of “traditional” design systems. Below four key benefits specifically for data design systems.
Next, we will go into ‘where to start?’
If you are convinced of the added value that a data design system can bring to your company, the question arises where to start? Below five concrete tips to get the ball rolling.
Structuring data visualizations within a design system may seem daunting at first, but when correctly setup from the start it can grow into one of the most valuable assets of your company. With this short introduction into data design systems combined four concrete benefits and five tips to get started, I hope to have given you a few valuable new insights. If you would you like to know more about data design systems in practice or our work in general, please do not hesitate to reach out.
Designing trustworthy interactions with large language models
How can we integrate large language models in design effectively while addressing their limitations and ensuring trust?
On applying for a job as a developer
Some practical advice in showing your value and getting noticed by hiring managers.