“Dashboard”, “Big Data”, “Data visualization”, “Analytics” — there’s been an explosion of people and companies looking to do interesting things with their data. I've been lucky to work on dozens of data-driven interfaces throughout my career and I wanted to share some thoughts on how to arrive at a distinct and meaningful product.
Many people have already tackled this topic, so I'm going to try and stick to the parts of our process that have the most impact.
Different users, different data
Whenever you're designing complex systems there will inevitably be multiple users or personas to design for. Executives, managers, and analysts are common personas that each have their own workflows and data needs.
"Whenever you're designing complex systems there will inevitably be multiple users or personas to design for."
Defining good personas and generating insights is an art within itself, and it’s not something I’m going to detail here. If you're curious about how to do this, check out this helpful post from Cooper.
The important thing to remember about personas is to identify them upfront and organize your information architecture tasks and wireframes around them.
Below is a deliverable we used for a healthcare reporting application we worked on last year. The system has distinct users each requiring their own data workflows. Once we established the key personas we included them alongside our deliverables with each review session.
Notice how the personas top each artboard. Our clients have been receptive to this approach.
Presenting artwork to a room of clients can be a difficult task. Whether you're explaining wireframes and flow diagrams or debating visual treatments, it’s hard to keep everyone tracking to your vision.
Organizing your artwork by personas will help you (and your clients) stay on point during these discussions.
Shape the page
One technique I've picked up over the years is the concept of shaping the page. The core idea is really simple:
"Show the user what they need to see first, then structure the remainder of the page based on the user story or hierarchy of information."
The concept of shaping the page is a core principle of writing prose (and many other forms of communication), and something I became intimate with after writing a book. Over the years I've spent a lot of time with the book “Style: The Basics of Clarity and Grace”. Aside from being an excellent reference for writing, it describes the concept eloquently:
"When you start with distractions, your audience has a hard time seeing not just what each element is about, but the focus of the entire passage."
This is a useful principle to keep in mind when designing UX. Below are two common approaches we use to shape the page.
Give your dashboards some structure. Ask yourself — What story am I telling with this information?
Many of the dashboards and data viz projects I see popup on behance and dribbble are beautifully designed (visually) but are often overwhelmingly underwhelming. They are either A) a myriad of graph widgets arranged in a pinterest-style layout with no hierarchy or B) over-designed visualizations that aren't appropriate for the data.
The left image shows an overwhelming approach to data vis. The right is an example of ornamentation that detracts from the point of the data.
In the image above (on the left), the reporting dashboard takes a Mission Control approach to presenting the information…which is pretty overwhelming. To avoid this, we try to approach these types of interfaces by curating the information more like you're reading a magazine article.
Not to say there isn't a time and place for a mission control UI…I personally would love to design something like that. But for most situations seeing everything all the time is unnecessary.
The key thing to consider — avoid creating a smattering of visualizations. Shape the information on the page so the user is presented with key information first, then follow it up with supporting content.
Choose the *right* visualizations
There are many (too many) designs floating around that misuse charts in favor of aesthetics.
The worst part is — these “bad habits” seem to be multiplying. Everywhere I look, I see area charts that should be pie graphs or line charts that should be bar graphs. So let’s try to stop this together… Here’s a few tips for doing your data justice:
Start with the data
It’s not sexy — raw tabular rows of data. However, it’s the best place to start. It will help you start thinking about what variables are available in the data and how the various data entities are related.
The flat nature of raw data will help you think through relationships between entities in the system.
Aside from staring blankly at rows of data and hoping ideas eventually slip into your subconscious, you can be a little more proactive by checking out these great resources to help uncover interesting connections:
- Charted — a tool developed by Medium that automatically visualizes data.
- Designing Better charts with Google Sheets, Illustrator, and Sketch
- Tableau — This tool is one of the best out there, but very expensive.
There is no silver bullet for this part of the process. Don’t be afraid to dive into the data and try making basic charts by mixing and matching different variables. It takes time, but it’s worth it. Some of the best ideas I've come up with started with tinkering around with raw data files.
Working with discrete vs. continuous data
It took me a while to realize this, some graphs do a better job of articulating your data than others. It’s easy to pick charts that look good in your composition and hope your data works out. I've been guilty of doing this myself many times (I love me a good scatter plot).
"Depending on the type of data you're working with some types of visualizations work better than others. One way to choose the appropriate chart is to evaluate the type of data you have."
There are two main types of data:
Discrete Data — distinct values you can count. For example, a number of goals scored or Facebook likes.
Bar charts work best for discrete data
Continuous Data — Any value in a range. For example, rainfall for a season or a person’s height/weight.
Line charts work best for continuous data
In short, line graphs work best for continuous data and bar graphs work best for discrete data.
One resource that really solidified this for me is “The Wall Street Journal: Guide to information Graphics” by Dona Wong. I wish I would have had this book with me years ago. Its an invaluable reference for choosing appropriate graphs and the dos & don'ts for presenting information.
Basic vs. custom visualizations
Lastly, as the designer of these data-rich systems you have to constantly ask yourself “should I take the path less traveled and go custom? Or should I use tried-and-true charts to articulate the message?”.
I recently came across this article from 37 Signals — Three charts are all I need. The author makes a strong point about how a visualization “problem solving” characteristics supersedes its visual qualities. I totally agree with the sentiment of his post. However, I think his opinion represents a very utilitarian perspective. I believe custom visualizations can often enhance the usability of the data AND look unique and compelling.
An example of a basic bar chart
To me there are “one-size-fits-all” charts and “best-fit” charts. Tables, lines and bar charts do a great job of accommodating many types of data, but they are also pretty generic (one-size-fits-all). As a professional designer I want the look and feel of my work to be distinct and useful.
For example, The New York Times does an amazing job augmenting their articles with custom interactive visualizations. You can see more of their work here. Let’s explore a couple examples of impeccable custom visualizations:
This example puts a twist on a line graph by offering a “peek” into the underlying data driving the chart.
http://www.nytimes.com/interactive/2013/03/29/sports/baseball/Strikeouts-Are-Still-Soaring.html?_r=0
In this 3D graph, the change in perspective is visually mind-blowing but also helps give the user a better insight into the relativity of the data.
http://www.nytimes.com/interactive/2015/03/19/upshot/3d-yield-curve-economic-growth.html?_r=0
This example from Selfiecity.net does a nice job using the actual content to create the visualization.
http://selfiecity.net/
Lastly, from a project we did with CNN, we use color-coding to show political party preference and 3D extrusion to visualize demographic information simultaneously.
http://truthlabs.com/work/cnn
As a rule of thumb — we try to come up with custom visualizations when the data and tech call for it, but we always have a plan B in case things don't pan out or the client prefers a less ambitious approach.
So what?
So why do we put all this data on the page anyway?
Answer: so people can do shit with it — make decisions, investigate, predict the future, whatever. The point is, your users aren't marveling at the pretty colors you've selected, they are trying to do their jobs.
So here’s my advice — after you've gotten your page laid out and everything is crafted just right, ask yourself “so what?”. Look at each graph, widget, chart, table, and ponder what someone will glean from it. Often times you'll come to the conclusion, “it doesn't matter”, which a red flag to reduce or rethink.
It’s happened to me a few times — I’ve created wonderfully complex dashboards housing a series of trend graphs, pie charts, and maps with thousands of data points. Only to be asked by the client “I just want to know if the product is working…where can I see that?” or “I only need to know 3 things…X, Y, and Z. Where can I find those?”
Sigh. In this moment you realize that you've gotten lost in the weeds and missed the big picture.
One tactic I've picked up to help with this is to try and use text to communicate exactly what someone wants to know.
At a high-level, text summaries can be more useful than charts.
The images above are taken from two of our recent projects. Both simply tell the user what they need to know via text rather than relying on charts or graphs that need to be interpreted.
This approach resonates with our clients, especially for high-level information. But as I mentioned earlier there are always multiple personas to consider, so use where appropriate.
This article was originally published on Erik's Medium page.
