In today’s data-rich world, data products that turn data assets into actionable insights are becoming increasingly valuable. Technologies that help users surface, process, organize, store, share, and act on data have defined a new generation of products.
That’s why we sat down with Katie Bayes, a product engineer at IOPipe. Katie has deep experience designing data products, and her advice will prove valuable to any teams designing data products.
How do you think about design in the context of data?
Katie: With data products, you’re constantly walking a fine line between simply being a point of access (i.e. the data dump) and doing useful things with that data. You have to strike that balance of doing helpful things like aggregating and organizing massive amounts of data, without obscuring the source. You want to be talking to your users and collecting information about their wants and pain points; however, if you make too many assumptions about what kind of information a user might be looking for, you risk getting into the territory of obscuring.
How do you think about raw vs. interpreted data?
Katie: When your product centers around data, it’s important to keep in mind that: *this is not your data*. That obviously has significance around things like privacy and security, but also how you think about what you’re reporting. When your source data is a metric from a computational process, that’s inherently objective data. It’s a measurement. But when you’re making millions or billions of metrics into a readable and usable product, at some point you have to impose some opinion. Sometimes in the form of hierarchy, sometimes in how you perform necessary aggregations.
When your product centers around data, it’s important to keep in mind that: “this is not your data” - @Kpoeb, Product Engineer at @IOPipes Click To Tweet
This makes it absolutely crucial that you never skimp on your discovery process with the product team. To form those opinions of how to usefully present that data, you have to first understand it, both in what it actually means, and how it could be used in a user’s workflow. But through it all, particularly with a technical audience, you don’t want to risk abstracting away from the source data. Aggregate, clean up the view, make it useful, but keep the source data available to your audience in some way.
For a technical/data-literate audience, you have to tread carefully in determining what conclusions you’re making for a user. They might want shortcuts of getting at the data and how it’s structured, so consider carefully: “When do you fall back on the root data and when do you make the root data available?”
For a less technical audience (e.g., marketers), they may not be as interested in the source data. They often times don’t need to see every granular detail behind their data and are rather look for the trend data/insights between the discrete points.
What are some non-obvious learnings from building serverless/infrastructure products that inform a “non-traditional” product design/development process?
Katie: When working on infrastructure products it helps to have some information about how users are tending to architect their applications. That gets really interesting in serverless computing because even by tech standards the “best practices” in this area are changing so rapidly. To add to that, serverless vendors are adding new capabilities at a pretty fast clip; some of these new capabilities become game-changers in how you might build an application if starting from scratch. So it’s partially a game of staying on top of that while aiming to keep the data at the forefront so every user from every company size can find value, regardless of how or when they started to build.
For product teams in data-focused products, probably the most notable departure from a traditional designer/development process would be the extended discovery process around the source data before you even start scribbling with a sharpie. In many processes, that depth of understanding is seen as an extra, a “plus” if you will – something that helps but might not be that crucial to getting started. But when your product is data, the data is the driving content. So it’s a lot more than diving in and creating some hierarchies. Instead of starting with the roughest of the rough sketches, you really have to stare at those numbers (real numbers if at all possible), wipe the slate clean, ditch your assumptions, and really think about the clearest and most useful way to present that data for what it is.
What are the tactical pieces of advice you have for designers and product managers in building data products?
Katie: In your user research, leave questions somewhat open-ended but centered around lived experiences. Asking more questions that drive to a concrete experience (e.g., “tell me about how you deal with an outage, last time you had downtime”) can help drive answers away from hypotheticals and zero in on specific memories/examples that you can learn from.
