This post is the first part of a three-part series. To begin, we’ll discuss discuss the difference between reporting and data products. The second part will talk about what it takes to design an effective data product. The third and final post will review what factors to consider to get to scale with your data product.
Over the years, we’ve written about the virtues of proper data visualization and use, from Chart Chooser to dashboard design best practices. As we’ve practiced these principles with our customers to help their audiences use data, we’ve observed over and over again that the most impactful results come not as data visualizations, but rather as persistent data applications that are purpose-built and long-lived. We call these data applications "data products."
Let’s review what we mean by “data product”
In our Data Reporting Maturity Model (↑) there’s a full spectrum of attributes from raw data to lifecycle management. While not all data reporting opportunities justify the attention and effort necessary to productize the data, true data products demonstrate nearly all of those attributes. These attributes fall into four broad groups: data, defined audience, accessible and usable, and productized.
Data products begin with quantitative and specific data every time. This includes raw data as well as “re-formatted” data such as tables or charts. Smart and legitimate qualitative explanation and description enables full bloom of the meaning and consequently, full reach of the audience, but the qualitative part is always subject to the quantitative data.
“Reporting” implies some specific audience and distribution along with a level of summarization and interpretation. We like to clarify this by thinking about reporting as primarily intended for “up and out.” “Up” refers to people in the author’s own organization who are less familiar with the details of the data (e.g., up the reporting chain), and “out” refers to people outside the author’s domain who are less familiar with the domain itself (e.g., peer departments, or customers). In both cases, the target audience needs the guidance of a trusted advisor in order to fully understand the importance of the data, among other things.
Accessible and Usable
Most of the attention in the data visualization space has been on the side of what we refer to as ad-hoc reporting -- "I have some data and need to explore it to find out what it might tell me." This is a necessary part of the data value chain, but let’s not be deceived: it’s by no means the last mile. The goal is to get people to act on what the data reveals. This means crafting an intentional message and providing that message in a form that is consistently available in the same way. It supports access management, enables easy new-user onboarding through guidance and help, features robust interactivity, and provides operational support (such as usage, error reporting, auto-scaling) — all those things you would expect from any real application platform.
All data reports have a lifecycle, but for the really important stuff we’ve found it helpful to think about it from the perspective of what it will take to provide it to customers over an extended period of time. You’ll want to consider its market, what sort of feature planning is required, what it takes to manufacture its first version versus future versions, how you take it to market and get users to adopt it, how you provide support and answer questions about it, and how you retire it when its time has come.
The building phases
Now that we know what data products are, how do we build them? We break this journey down into three phases.
Phase 1: Narrow the Story Options
This first part is about narrowing a virtually infinite number of options presented by a “blank canvas” approach down to the right design. We use our own process called Guided Story Design™ to solve this problem (see chart above).
Phase 2: Build It
This phase is about taking what you’ve designed and Pinocchio-ing it into a "real boy" (no blue fairies needed).
Phase 3: Make It Available and Scalable
The final phase of making a data product is about enabling what you’ve made to scale both in usage and capacity. This means accessible, usable, low barrier-to-entry and guidance for new users, interpretation, easy to share, discussions, and support.
What comes next
Now that we’ve set the stage and defined what a data product is, you may be interested for more detail on how to make it happen. Over the coming weeks, we’ll be delving into the first and third phases*, so stay tuned.
*Phase two is left up to the interested reader for self-exploration based on your tool/technology of choice. Once you have the first stage result, you can implement it using many different technologies. Juicebox is what we use to create the best apps for telling data stories. If you want to learn more about it, contact us.