Thoughtful Friday #11; Designing Great Data Apps

I just reread Don Norman’s book “The Design of Everyday Things”. Dashboards, Reports, Recommendation Engines, are becoming our everyday things! Or how many people do you know that cannot tell you from the top of their head at least 2 recommendation-like thingies (Thanks Amazon & Netflix)?

Great design is important in all solutions and applications. But it is especially important in the ones that tend to be more complex, and that for some (not good, not apparent) reason do not hide this complexity. Data applications of all kinds fall into that category, I see that when I look at dashboards, recommendation engines, data catalogs, infrastructure, and almost every single product of a company in the data space.

Twitters Search is amazingly complex. It’s not just about searching, you might want to search for people, hashtags, tweets, and yet, Twitter hides all that complexity and provides you with an amazing search experience:

And yet, 95% of the time, I use the quick search bar. Until today, I didn’t even know how to go to - Layer 3.

Ok, so let’s make this tangible and walk through the process say for a set of dashboards. I like to make things real. Here is my process for designing amazing dashboards, which includes hiding complexity. 

The caveat about a lot of data applications is that before you can hide complexity, you’ll need to:

1. Design a proper product

2. Make the complexity transparent

This is the easiest step of the process, which involves talking to people, thinking through the problem yourself, brainstorming etc.. In the end, you’ll have a long list of things. 

Yes, I think it’s “figuring out” not “asking people”. The idea of designing good products is always a balance between talking to people and asking what they need, then understanding the underlying reasons, and potentially delivering something different which still solves some of the problems and maybe more. 

This step is really about understanding the domains of the people using the dashboard, the decisions they have to make, and their process for implementing these decisions into action.

Next, you’ll need to figure out which information is needed, and which is not needed.

Never display too much, just the right amount of information.

Make sure you have a proper userbase for your data app/dashboard. Add filters, enlargen it to a set of dashboards, maybe even deliver something that doesn’t serve the original “request” or “idea”. That’s what good product management is about.

Not all dashboards deserve to be dashboards. Some should be notebooks, some machine learning systems, some reports, some CSV dumps. Make sure you understand the process of the people using it. If the customer support needs a report to display the top bought items to then call customers, maybe you can go straight for a recommendation engine instead. 

The mantra here is simple: Build the iPhone, not a Blackberry. 

Good dashboards don’t need additional paper documentation. They have the documentation inside the dashboard. Here’s my terrible example of one “North Star Metric” dashboard which has the relevant information right on the dashboard. I’d assume you would be able to use and understand it without any further information.

But we’re not gonna stop at good.

Great dashboards don’t need documentation. They are self-explaining. The easiest way of doing that is to expose your business logic to graphical implementations of it. This essentially means you’re making complexity transparent. A nice side effect is that this makes the dashboard way easier to debug should problems occur. Even a user could now debug numbers on certain days without help from a data engineer.

You might think that’s too complex to display! But you know what, if you do not display the calculation in this example, you’re effectively assuming every user of this dashboard is doing that in his head. 

From my perspective, that is even worse. What you’re aiming for here, is making complexity transparent, or to say it in different words, to “stop aggregating away complexity”. 

Amazing dashboards have another feature, they are the true iPhone because they simply do not have that complexity! Once you are able to make the complexity visible, you might also be able to help a process to reduce it, design a north star metric that is easy to understand, which actually carries true meaning in itself. 

Amazing dashboards are like the Twitter search. They have only plain and simple concepts on the big dashboard which 95% of the people use 95% of the time. And then they have layers and layers. 

Keep this example in mind, the Twitter search and the dashboard. Now think about your data products, are they good a hiding complexity? How about the dashboards you use every day? I know a bunch of the things I built suck from that perspective. 

It is terrible | It’s pretty bad | average newsletter… | good content… | I love it, will forward!