When designing digital products and services, we need to find places where we can push beyond the Minimum Level of Service (the oven should cook my food, the car should start reliably, the phone should make and receive calls, the waiter should get my order right) in order to make something that our customers will value and love.
A great place to start is the places where you’re providing raw data — basic facts and figures, records from a database, or data without context. With a few rare exceptions, your customer is never looking for these atomic pieces. They’re looking for insight that they can help them make great decisions. Raw data is the least you could possibly do — asking your customers to decide what’s relevant, perform their own analysis, draw their own conclusions and filter out the noise for themselves.
I recently received a text message. Here’s the interesting part:
You’ve reached 80% of your 1GB data limit. Excess charges apply from 100%.
While I’m thankful for the heads-up (anything is better than a nasty surprise on my bill), this pretty lazy design. The onus is now on me to decide if I care. In order to make that decision, I’m missing a second piece of information — when will my quota reset? If I’m 50% through the month and 80% through my quota, that’s a problem. If there’s one day left, no problem. If I have 5–7 days left, I’ll need to be careful. By combining multiple relevant pieces of data, we can increase the value of the message:
You’ve reached 80% of your 1GB data limit with 5 days remaining. Excess charges apply from 100%.
With this iteration, I have everything I need to draw my own conclusion and take action, but can we do better? After reading this message, my conclusion would be to “take it easy for the next few days”, drawing an insight from the data. What if the system could offer me the insight instead of the data?
Your average daily data usage this month could lead to excess charges. Take it easy until Oct 5 or purchase a data pack.
Maybe we’re taking it too far, or being too imprecise, but the same thought processes can be applied to whatever you’re working on.
Let’s say you’re designing a software issue tracking system. The number of open tickets is usually vomited onto the project dashboard somewhere. In isolation, this number is barely useful. However, when combined with the average number of tickets closed per day, the system can tell me roughly how many days of work remain. When combined with the average number of new tickets created each day (or a comparison to last week, or last month) we now have insight into something much more valuable — are we keeping up, or are we drowning in tickets?
This high level information feeds directly into hiring and planning for a software team. It’s important, it’s someone’s job. Sure, they could crunch the numbers themselves if you give them the raw data, but if we focus on the customer and the information they need to do their job, it becomes clear that we should crunch those numbers for them, proving the insight instead of the raw data.
Context gives data meaning and value. You can dump raw data onto the screen and pretend you’re doing great work, or you can design something that truly helps your customers. This seems so obvious (it is), but take a look at the tools you use every day — there is so much room for improvement.