Accelerating projects with data storytelling patterns

Data storytelling is the ability to combine interactive data visualizations with narrative techniques in order to package and deliver insights a compelling, easily understood form for presentation to decision makers.

-Unknown

Human problem

Becoming a software designer of analytic applications requires a fairly big learning curve. Our Design team wanted to help our designers and others throughout the company improve their data storytelling skills.

Business problem

Multiplying this skill was a way for designers to add business value, far beyond creating some pretty data visualizations on a page. My design director and I had a vision to turn designers into data translators.

A data translator is a conduit between data scientists and... decision makers. They are specifically skilled at understanding the business needs of an organization and are data savvy enough to be able to talk tech and distill it to others in the organization in an easy-to-understand manner. This professional must be someone who can "talk the talk" of both the executives [and other personas] and the data scientists. They are adept at extracting the business meaning and applications from the information they are provided by the data scientists. They not only respect the functions of the data scientists, but also understand the needs of decision-makers; therefore, successful data translators are typically respected by those entities in return.

-Bernard Marr, business performance consultant

Design approach

My main design effort for this site was to devise an information architecture to organize and connect the many materials I'd been using to build data storytelling skills among designers in Watson Health.

Many design teams rely on chart libraries and chart choosers to design the user experience of interacting with a dashboard. We wanted designers and stakeholders to start with the flow of business or clinical questions to be answered by a persona, whether the result is a dashboard or another experience, such as a conversation with a chat agent.

We wanted designers to consider data and analytics sooner, at the requirements phase, namely during Design Thinking workshops with product managers, engineers, business analysts, and data scientists. With two data scientists, my director and I patented a new workshop and technical approach, but that's another story.

We envisioned a having pattern library web site that mapped from a user's business or clinical question to a chart pattern. We'd already accelerated previous projects through use of these patterns, but they lacked a home for easy retrieval.

Top level site organization

I organized the site to prominently feature introductory material (Home, About), Best practices (Thought and tools), and the pattern library (Find a pattern, Cost, Population, Quality, Risk, Usage). The Home page contains some shortcut links to often-used reference materials, such as our glossary of "starter words" for capturing users' analytic intents - aggregating, benchmarking, classifying, and so on.

Secondary navigation examples

To keep the top level choices manageable and ensure the pattern library sections were quick and easy to access, I packed many topics under Thought and tools, with secondary navigation within the pages under Thought and tools. This section really captures how broad and comprehensive the data storytelling concerns of designer should be. As with any design discipline, there's more than many people realize, beyond picking the right chart for the data and executing a high quality visual design.

Data visualization pattern library

When the site was fully populated, it would have contained 75+ patterns from mining 344 examples from 8 projects, across 3 segments of Watson Health. Here's an example of one pattern, "How are costs changing?," and the lookup tables to help a designer find this pattern.

Challenges

Perspective. The user persona was a designer, and I'm a designer, but the typical audience wasn't me. I took care to validate the information architecture and terminology with teammates of varying experience levels and backgrounds. For example, a design colleague seasoned in health informatics was unfamiliar with the term "data storytelling," so I included a definition on the home page. You never can assume what your users will know or not know.

Spare time. Drafting and populating the site has been a labor of love. Although improving data storytelling skills was important to our Design team from a business perspective, we'd have to sell the concept to our larger organization in order to carve out any time from our official project work. Making the case to spend time working on the site would, to some extent, require drafting the site, piloting its use, and then generating metrics (such as visitor counts) and demonstrable business outcomes from its use.

Technology. Related to time was technology. I originally envisioned designers using a site similar to a commerce site (Amazon, Target, and so on) to search for patterns and filter them based on categories such as business question family (Cost or Quality, for example). It ended up being a static web site due to constraints.

Human outcome

For lack of time, the site has been shared and used informally with a handful of projects, but was not finished and debuted for wider use.

Business outcome

Acceleration of products to market through more effective workshopping. Higher quality outcomes due to templates conveying best practices from analytic SMEs and designers.