Growing up, did you ever wonder how many chairs you’d have to stack to reach the sky?
No? I guess that’s just me then.
As a child, I always asked a lot of “how many/much” questions. Some were legitimate (“How much is 1 USD in VND?”); some were absurd (“How tall is the sky and can it be measured in chairs?”). So far, I’ve managed to maintain my obnoxious statistical probing habit without making any mortal enemies in my 20s. As it turns out, that habit comes with its perks when working in product.
Growing up, did you ever wonder how many chairs you’d have to stack to reach the sky?
My first job as a product designer was at a small but energetic fintech startup whose engineers also dabbled in pulling data. I constantly bothered them with questions like, “How many exports did we have from that last feature launched?” and “How many admins created at least one rule on this page?” I was curious about quantitative analysis but did not know where to start.
I knew I wasn’t the only one. Even then, there was a growing need for basic data literacy in the tech industry, and it’s only getting more taxing by the year. Words like “data-driven,” “data-informed” and “data-powered” increasingly litter every tech organization’s product briefs. But where does this data come from? Who has access to it? How might I start digging into it myself? How might I leverage this data in my day-to-day design once I get my hands on it?
Data discovery for all: What’s in the way?
“Curiosity is our compass” is one of Kickstarter’s guiding principles. Powered by a desire for knowledge and information, curiosity is the enemy of many larger, older and more structured organizations — whether they admit it or not — because it hinders the production flow. Curiosity makes you pause and take time to explore and validate the “ask.” Asking as many what’s, how’s, why’s, who’s and how many’s as possible is important to help you learn if the work is worth your time.
The answers, or partial answers, to those questions probably already exist in your company’s beloved but elusive business intelligence (BI) tool. You’ll likely have to file a data request and make an elaborate case for why you need access to this knowledge. Don’t get me wrong; it is important to have guardrails in place to protect users’ personally identifiable information (PII) and other sensitive data.
But when your quest for information becomes a battle of convincing the “data governance council” to grant your request, it’s just inefficient and bureaucratic. Many organizations also shun data discovery because it could offer a direct look into their financial health. However, this hierarchical practice only creates mistrust and blocks meaningful collaborations. At worst, it discourages data self-discovery, an essential skill for anyone striving to build a well-functioning product.
Why is the barrier to entry for traditional data analysis so high for amateurs? One assumption I have (and you can help me validate it here) is that traditional data tools like Tableau, Qlik and frankly any SAP product look absolutely terrifying. They’re powerful analytic tools that have no doubt done wonders for business executives everywhere, but they have a deep learning curve and do not serve someone like me: a curious but amateurish data explorer. Their UX is complex and their UIs are cluttered — two of a product designer’s biggest nightmares. In addition, data analysis is often believed to require coding — a word that alienates half the creative population.
DIY data queries
With the rise of Squarespace, Webflow and Airtable, no-code tools are all the rage nowadays. Following the trend, the analytics industry is also lowering the barrier to entry and producing tools that encourage non-experts to participate.
Tools like Looker and Metabase have relatively straightforward graphical user interfaces (GUIs) that allow users to run quick and simple but powerful queries without writing a single line of SQL.
I’ve gotten into the habit of attempting the first pass at a Looker query before passing it along to someone from Insights to verify or assist me. I often am unable to completely articulate a question until I start running the query myself since there is always some sort of dimensional constraint that only comes to my attention once I start doing instead of just asking.
There are definitely trade-offs with being able to use solely a GUI. Perhaps the biggest hurdle to overcome if you don’t come from a programming background is the need to gain a solid understanding of the product’s data architecture.
I recommend studying Mozilla’s web docs on JavaScript data structures, especially the JSON object. Knowing basic data structure concepts will drive your understanding of the database and, most importantly, help you navigate it. Learning this could take a while, especially if the database is not well organized, so don’t beat yourself up.
From my own experience, one of the most useful things an analyst could do to help non-analyst explorers is to have consistent, easy-to-grasp object-naming conventions. As you become more comfortable with the data tool and find yourself wanting to expand the scope of your query, you’ll need to write code. However, you’re in luck because most modern insights and analytics tools have custom syntax and thorough documentations. Eventually, you’ll get better at hacking code together. As with any skill, it gets better with practice.
Design with data: Lessons and learnings
How might you leverage this newly acquired skill to inform design decisions? For me, the first step to validating any hypothesis starts with analyzing existing users. You can also start by talking to users — you should do both if you have the time and resources — but querying data is quick, free and will give you a more encompassing picture.
Early usage data explorations have helped me look past the temporal surface design and craft holistic, viable experiences that work for both the 80% and the 20% cases. Minor UI tweaks won’t help much if the workflow is not usable. Early data analysis on existing behavior is helpful at this point because it can give you insights like how a current product surface is being used, how different user segments gravitate toward different features, how likely and by whom the functionality you have in mind will be adopted, etc.
I’ve made classic amateur mistakes in the past in my approach to designing with data, such as taking quantitative data as the absolute truth and focusing too much on moving metrics. I’ve used averages frivolously and jumped to generalizations.
I’ve also made the No. 1 mistake that people armed with statistics make: doing too much proving instead of improving. While it is important that we design with data, it is even more important that we recognize the humanity behind the data and, hence, its biases. If you’re not a trained professional, you should constantly check in with an analyst on your interpretation of the data to avoid and/or learn from these pitfalls.
If you’re reading this article and happen to be a C-level executive, I hope you consider the benefits that orgwide data literacy could have on your product. Data literacy not only allows your employees to ask and answer meaningful product-driving questions themselves, but also cuts down on the back-and-forth conventionally needed to obtain insights.
If you haven’t invested in a modern data exploring tool, consider it. If you have a team of product analysts at your disposal, think about holding companywide introductory analytics workshops. Equip your team with the right exploratory medium, and you may even see interest rise in areas that aren’t traditionally associated with analytics.