Data is a Design Tool

Dear designer,

Data is a a design tool.

Not because you cede your taste to it. Not because your instincts and gut impressions can't yield amazing results.

Because the only way that you have to peek into your users' lives is to understand how your product is being used by them. Screen recordings are too slow.

Helpful but slow.

User research is great for quotes, anecdotes, and seeing how your users think. Hearing from them how they want problems to be solved.

Data tells you what they actually do vs what they say.

It's always been odd to me that designers, who could be the most data-savvy people inside of an organization, oftentimes are the most separated from it.

Do you have to be able to write SQL? No.

Do you have to understand the complexities of an ETL workflow and how a warehouse is functionally set up? No.

Do you have to write Python, create workbooks, and and do statistical analysis? No.

But should you know how your data is stored? Yes.

Should you understand how the database functionally works so that when a user does something, you know conceptually how it will be saved? Yes.

Should you see how your users are adopting features, how frequently they're signing up, how much they're running into issues, distributions of cohorts or segments or demographics? Yes.

Should you understand if what you're doing is "moving the needle?" Yes.

Not because you need to be only driven by data. But you need to know the pulse of your product, and data is that pulse.

You should know if a feature that you spent months on isn't getting used.

You should know if a flow in the app that nobody thought would exist is suddenly getting a spike in traffic—so that you can design a more effective solution for what happens when people land there.

You should know the drop off points of your app so that you can optimize the journey, remove steps, remove user friction, and make it so that people can easily get the value out of the product that you're spending so much time building.

You should be able to be aware enough about everything to be the canary in the coal mine—so that you know when something is no longer working, when users are dropping off, when they're fleeing to competitors, or when they're coming to your product to competitors. So you can capture the momentum.

Data is a design tool.

The way to get a larger organization to move is data.

The way to get a small organization to get excited is data.

The way to inform a pivot is data.

The way to get buy-in is data.

The way to collaborate with product managers is data.

The way to collaborate with developers is data.

The way to collaborate with sales is data.

The way to have a clear path to articulate your value and get raises or bonuses is data.

The way to see if your ideas actually work is data.

Data is not at odds with great design, and it's often cited as a way to strip design decisions away from taste. To optimize A/B test, to design by committee. I'm not talking about using data to determine what is right. I'm talking about using data to determine what is real, what questions you should be asking, what ideas you should be pursuing—and so that you can understand if what you have built is working.

But here's the problem.

Designers have to rely on someone else to get the data for them. Because we don't speak data, we can't get the questions we have answered.

We can't dig on our own.

We can't understand what's going on.

Security and technical norms have informed a world where designers are at the bottom of the barrel of data access. We are mostly "non-technical". We might "break something".

"Create a ticket"

"Ask you developer"

"Use this spreadsheet"

All layers of obstruction and, in many cases, theater to make it so that a cohort of few can actually answer questions. It's not a power move. It's a security move. It's a capacity move.

Writing SQL is not easy. Getting access to the data should be strict. Companies are rightly concerned about PII, data compliance & governance, row level access, GDPR... don't even get me started on HIPAA.

So as a result, they've built up impenetrable walls of data access. Rigid, inflexible, background-noise dashboards on TVs that make it seem you're a data driven team. CRON jobs that run daily or weekly with the appearance of data and little of the value of understanding of what it means. Giant conflicting spreadsheets with data that is who knows how old from a bucket that is unclear of the source.

Yesterday's Chinese takeout leftover pivot tables.

But this is all changing.

Dear Designer, with AI, you can finally speak data.

You can ask questions about anything you want. You can be imprecise with your terms. You don't have to know the difference between an inner and outer join.

Dear developer, your data doesn't have to be clean for it to be useful. You don't have to have this looming plan to reformat things to work better with your BI tooling.

You don't have to have rigid structured data sources with buttoned up foreign keys, clearly defined relational structures, or a migration that makes sense of that disaster of a JSON column that contains crucial data for it to be useful.

Where SQL is good at structured data, AI is great at unstructured language. All it takes is the appropriate context, in plain text, to start to be able to dig through your data. To map out relationships or calculations that are a little more nuanced. To allow anyone to ask questions.

Even designers.

So, dear designer... what's holding you back from using data?

Well. You're not using Basedash.