After being the bread and butter of the web for most of its early history, tables were cast aside by many designers for newer, trendier layouts. But while they might be making fewer appearances on the web these days, data tables still collect and organize much of the information we interact with on a day-to-day basis.

For instance, there’s what I consider to be the mother of all tables: The United States’ “Harmonized Tariff Schedule,” a table that stretches over 3,550 pages and lists every single good that can be imported into the US, including such thrilling entries as “Men’s or boys’ overcoats, carcoats, capes, cloaks, anoraks (including ski-jackets), windbreakers and similar articles (including padded, sleeveless jackets).”

The ire raised by data tables is due, no doubt, to just how awful they can look when they’re not well designed. The design of a table is its linchpin: if it’s done right, it makes complex data easy to scan and compare. If it’s done wrong, it can render information completely incomprehensible.

Not all numbers were created equal. I’m not talking about π and ∞ (though I often do, at parties); I’m talking about numbers that are either 

Here’s a quick illustration of the difference between oldstyle and lining figures.

Oldstyle figures look nice in sentences, where they better match the size and spacing of lower-case letters; lining figures are more uniform, and reinforce the grid-like structure of the table.

The difference between proportional and tabular figures is not quite so obvious:

Proportional figures are designed to match the color — that is, the general sizing and spacing — of the typeface. Tabular figures, on the other hand, are all identically-sized, so that columns of numbers line up properly. While the difference may not seem great on the scale of one or two lines, using tabular figures makes scanning large tables significantly easier and less error-prone.

A technical note on using tabular lining figures

When designing, you’ll need to do a bit of work to ensure the numerals you’re using are the correct ones (tabular lining figures aren’t typically the default). Adobe Products have an “opentype” panel that can be used to set the figures properly, and CSS provides a 

 for enabling this feature. Beyond that, some basic googling should lead you down the right path.

But now for the bad news: not all typefaces have true tabular lining figures available. The 

. There are a few exceptions: The excellent 

 is a free typeface that has true tabular lining figures.

If you can’t find a suitable typeface that has tabular lining figures, a good fallback is monospace fonts — while they tend to have a more “source code” look, they’ll always be well-suited to displaying numbers in tables. Additionally, the new Apple system default typeface San Francisco has excellent tabular lining figures and looks great at small sizes.

1- Numerical data is right-aligned 2- Textual data is left-aligned 3- Headers are aligned with their data 3½- Don’t use center alignment.

List of U.S. states by historical population — 

Numerical data is read right-to-left; that is, we compare numbers by first looking at their ones digit, then their tens, then their hundreds, and so on. This is also how most people learn arithmetic — start on the right and move left, carrying digits as you go 

. Therefore, tables should keep numerical data right-aligned.

Textual data is read (in English) from left-to-right. Comparing textual elements is typically done by sorting into alphabetical order: if two entries start with the same letter, the second letter is used, and so on. Trying to quickly scan text can be infuriating if it’s not left-aligned.

Headers, generally, should carry whatever alignment their data has. This keeps the vertical lines of the table clean, and provides consistency and context.

Center alignment causes the lines of the table to become “ragged,” which makes it much harder to scan entries, often necessitating extra dividers and graphical elements.

Consistent Significant Figures = Better alignment

One easy way to keep your tables properly aligned is to keep the same number of significant figures — usually the number of digits after the decimal — consistent within each column. Significant figures is a whole rabbit hole of a topic, so I’ll keep my advice here brief: the fewer sig figs you can get by with, the better.

Providing labels to accompany your data is crucial. These pieces of accompanying context allow a data table to be read by a wider audience, in a broader set of circumstances.

It might sound like conventional wisdom, but giving your data table a clear and succinct title is as important as any other design decision you make. With a good title, tables are portable: they can be used in a number of different contexts, as well as cited from external sources.

The most common label used in tables is the unit of measurement for the data; often, it’s repeated along with every single data point. Instead of repeating the label, only include it with the first data point in each column.

Keep headers as short as possible; the design of the data table should be focused around the data itself, and long header labels can occupy a lot of visual space.

When deciding how to style the graphic elements of a table, the goal should always be to reduce the table’s footprint without losing structural fidelity. One of the ways you can accomplish this is by using as little “ink” as possible — that is, whenever possible, choose not to style an element.

If you’ve properly aligned the data points in your table, rules become redundant. The primary benefit they provide is in allowing you to reduce the space between elements, while still being able to differentiate between elements. Even when used, rules should be extremely light to not interfere with quick scanning.

Horizontal rules are the most useful, as they allow you to significantly reduce the vertical space occupied by long tables, making faster work of comparing lots of values or seeing trends over time.

One unsubstantiated opinion I have about rules is that 

. Really, really bad. Take it or leave it.

Backgrounds are most useful when indicating differences in the domain of data: switching between single values and sums or averages, for example. Highlighting values, providing additional context to data, or indicatifng changes in values from previous periods can be done without backgrounds, using graphical elements like ✻, † (one of my faves), or ▵.

Additionally, tables should be monochromatic. Using colors to provide organizational context or added meaning increases the likelihood of misinterpretation or error, and causes usability problems for those with impaired vision. 

, but they are such a major element of any data-rich document that they’re worth every ounce of design thinking we can apply to them. By designing more efficient, clearer, and easier-to-use tables, you can vastly improve the often-painful experience of analyzing and understanding large sets of data.

 has always been a great source of inspiration— they set their numerical data in a typeface called 

, which is specifically designed to fit lots of data in a small space.

 is my go-to for all things typographical, and the kind of reference you keep multiple copies of — it’s so practical!

Lastly, no article on data design would be complete without an 

 shoutout. His insightful writing on design is indispensable.

 For other interesting approaches to arithmetic, check out how Japanese children use a Soroban or how lattice multiplication works.

Design Better Data Tables

tl;dr — I’ve created a tool called 

 to enable designers to use realistic data when mocking up data visualizations. Also, this is a written version of a talk I gave at Data Viz Camp 2016 in NYC. The slides for that talk are 

, both at Planetary and in my freelance work, I’ve constantly struggled with designing real-time data visualizations. You know the kind: dashboards, analytics, reporting tools — anything that displays data on an ongoing basis. Designers at publications like the 

http://blogs.ft.com/ftdata/2016/07/24/tour-de-france-2016-froome-sky-dominate-mountains-cavendish-sprinting-supremacy/(*paywall*

) have been pushing the envelope of design in data-first journalism and reporting, but applying the same principals to dynamic data sets is challenging. Though these visualizations are incredibly valuable to the people who rely on them every day, they’re some of the trickiest to get right.

My hunch is that no amount of aesthetic theory or design experience matters if a designer doesn’t understand the data. The real problem, then, is that …

This fact has a lot to do with the lack of overlap between design and statistics — designers are often the ones who avoided taking statistics class and opted instead to spend their time in studios and darkrooms. But even a background in statistics can’t change the reality that humans simply struggle with data. A few reasons for this:

Our brains are really good at finding patterns. It’s one of the things that makes design so rewarding — looking at orderly shapes and patterns feels good. So when we look at data, we look for and often find patterns, even if those patterns are misleading or downright wrong.

In addition to finding meaning where there is none, the patterns that are meaningful are often incomprehensible. Take the 

, for example: in a group of people, what are the odds that two have the same birthday? For a group of 367 people, we can assume that there’s a 100% chance that two have the same birthday. What are the odds with a group of 70 people?

. Beyond that, for 23 people, there’s a 50/50 chance that two share a birthday. There’s certainly a pattern here, but it’s impossible to discern without analysis.

Try as we might, trying to fake data is a lost cause. One illustration of this is called the 

, and it’s easiest to illustrate with a demo. We’re going to flip 20 coins (virtually); but before we do, enter in what you think the outcome will be — select either “Heads” or “Tails” in each row on the left, then click “flip!” to see how you fare.

What you’ll (probably) see is that your guess on the left alternates from heads to tails often, with few streaks, but the result on the right has streaks. Your guess likely has close to 10 heads and 10 tails, but rarely does the actual result come up an even 10 and 10. These differences are attributable to our assumptions about probability (that a coin flip has a 50/50 outcome) being applied to a larger problem (20 actual coin flips).

There’s even a simple statistical property (called 

) that can be used to identify faked data sets. In short, in any large enough data set, patterns emerge in the first digits of each data point: more numbers will start with the digit “1” than any other number. This pattern is so pervasive and counterintuitive that it is often used to prove — in court — that data has been falsified.

Part of what makes data so tricky to work with is that our assumptions about the shape, domain, resolution, and volatility of a set of data are only just that: assumptions.

Even with the most reliable sets of data — say, an atomic clock — there’s always the possibility of error states or the occasional act of god. These one-in-a-million events are when great data visualization really shines: instead of breaking down in the face of anomaly, they highlight the rarity of the situation and respond appropriately.

But when we’re designing visualizations, how can we predict the unpredictable? It’s almost like something out of a 

; outliers aren’t really outliers if we’re expecting them.

Real data sets of all shapes and sizes are easy to come by if you know where to look. There’s a slew of 

large, well-formatted data sets on GitHub

, collected and maintained by the (excellently-named) 

 group. From financial data to global temperature indexes, these data sets can easily provide a reality check for your designs.

Unfortunately, my experience working with historical data sets fails to overcome some of the fundamental challenges of designing robust visualizations. Here’s why:

 The time series of S&P 500 financials over the past 100 years probably isn’t going to fit your visualization domain and fidelity right out of the box. The benefit of having lots of data to work with becomes a curse when you’re trying to normalize lots of values.

 I find myself discarding data when it doesn’t come out quite like I expect it to. Instead of taking the harder route of improving the visualization to handle the data at hand, I’ll just select “better” data.

Placeholder data is a lot like placeholder text. It’s a design tool meant to ensure the final product — in our case, a real-time data visualization — matches our mockups. It’s useful in all the same ways placeholder text is useful:

Placeholder data allows a designer to test her assumptions about the product.

Placeholder data makes decision-making much easier by providing realistic constraints.

Placeholder data sets realistic expectations for clients and stakeholders.

Just as with placeholder text, we can achieve varying degrees of placeholder data realism by choosing our parameters very carefully. When mocking up a page layout, I can choose the classic placeholder text “lorem ipsum dolor sit amet …” to help pick the right typeface, leading, measure, etc. A placeholder data version of “lorem ipsum” might look just like random numbers, a sort of meaningless pattern that looks like real data if you aren’t looking too hard.

A graph of javascript’s Math.random() function

I’ve often run into trouble using “lorem ipsum,” though, and you probably have, too: it is too obviously fake. Clients have questioned my sanity, when all their mockups look like they’ve been done in latin. And in making decisions with nonsense text, I sometimes run into problems down the line when the real text goes in.

Instead of using “lorem ipsum,” I’ve started to use real text from various sources. If the final text will be highly technical in nature, I can pull from scientific papers in the public domain. If it’s meant to be exciting, Jules Verne serves as a good placeholder. Choosing the qualities of my placeholder text helps me make better decisions, and sets better expectations with my clients.

How do we apply this concept to data? Can we create “flavored” placeholder data, without losing the benefit of randomness and unpredictability?

A 2-dimensional graph of the Perlin Noise function

Perlin Noise (or, a better kind of random)

 was working on a very similar problem: how can a computer generate random images that don’t look like they were generated by a computer? While working on a movie titled 

 (the one without Daft Punk), Perlin developed an algorithm to draw textures that he could apply to the computer-generated images in the film to make them appear more realistic. And while the CGI in Tron looks laughably primitive compared to what we see in theaters today, at the time Perlin’s work was revolutionary. In 1997, he won an Academy Award for the algorithm, which by then was referred to as “Perlin Noise.” The award read:

The development of Perlin Noise has allowed computer graphics artists to better represent the complexity of natural phenomena in visual effects for the motion picture industry.

This is an image of Perlin Noise. The technical description of the algorithm isn’t important for this post, so let’s just leave it at “random vector fields.”

If we draw a line across this image, and track the color values as we go — “high” for white, “low” for black — we get a nice-looking smooth graph of the Perlin Noise field; its peaks and valleys are flattened out to a simple two-dimensional line.

Drawing lines across the noise field is akin to taking a walk with a FitBit and watching the elevation change as you go; a short walk might only have a few elevation changes, while longer walks have many more ups and downs.

One nice thing about this sort of data is that it can be added together to make more varied graphs. For instance, if we add up a few different walks across the noise field, we get a line that has short rises and falls, a plateau here and there, and the occasional rapid change.

Additionally, adding these graphs of Perlin Noise together with very basic functions like sine waves can generate data that resembles real-world patterns. For instance, a graph of the daily active users of a website follows a cycle; during the daytime, there are lots of users on the site, and in the late evening and early morning there are typically not as many. Combing a cyclical wave (in this case, a sine wave) with one of our noise graphs gives us a very realistic simulation of a website’s traffic!

Combining graphs of simple functions with Perlin Noise has a nearly infinite number of possible permutations, making it an incredibly effective tool for mocking up real-time data visualizations. In practice, Planetary uses this method to test our software platforms, like this one, which visualizes the performance of a publication’s stories in near-real time:

To make these noise functions accessible and easy to generate, I’ve created a tool called 

. Just like you might use placeholder text to mock up websites and apps, my hope is that you’ll use realistic placeholder data when creating data visualizations.

By using realistic placeholder data, you can make your designs more robust and free from bias. In putting constraints on the source material you work from, you’ll be challenged to solve problems that typically arise only after real data is available. With tools like Datum Ipsum, you can create tools that handle the unpredictable, difficult-to-understand nature of data in real time.

If you’d like to learn more about Perlin Noise and its uses, I’d highly recommend 

Daniel Schiffman’s Youtube series on the subject

Datum Ipsum: Designing real-time visualizations with realistic placeholder data

It’s no secret that we’re a small team here at Planetary; this means that any new addition to the team brings a huge upgrade in the expertise, experience, interests, opinions, favorite sandwiches, and nicknames we get to use. And if there’s one thing that’s true about this great universe we live in, it’s that two is greater than one.

What could I possibly be getting at here? Drumroll, please …

Planetary is beaming with pride to introduce you to our two newest crew members: 

Samantha (Sam) hails from the great city of Cincinnati, Ohio, from where she’ll be shipping front-end code as our lead front-end engineer. While we at Planetary have always taken pride in the quality of our code, adding Sam’s considerable talent and laser-sharp focus on clean, performant front-ends will open up new horizons for the team: ES6 modules? Custom css properties? HTML emails? Sky’s the limit!

 (Sam) hails from the great city of Cincinnati, Ohio, from where she’ll be shipping front-end code as our lead front-end engineer. While we at Planetary have always taken pride in the quality of our code, adding Sam’s considerable talent and laser-sharp focus on clean, performant front-ends will open up new horizons for the team: ES6 modules? Custom css properties? HTML emails? Sky’s the limit!

(On second thought, HTML emails might actually be the limit.)

 is currently working from our New York office, and though he’s shown remarkable endurance in the face of Josh’s puns, he’ll soon be representing the team in Detroit, Michigan. He’ll be heading Planetary’s design team as our lead designer, which means he knows a lot about shapes. Circles, squares, you name ’em — he’s not too shabby at designing complex, information-rich interfaces either. And rhombuses? Rhombus is his middle name.

(Rhombus isn’t actually his middle name, but maybe it’ll stick)

Ok, phew. I’ve fully expressed all of my enthusiasm for one day. But if you can’t tell by the gifs and the exclamation marks and the bad jokes, I’ll say it once again:

We’re proud of our small-but-growing team, and can’t wait to share the work Sam and Vince help us create.

Those New-Hire Feels

The rise of the robot assistant is happening. Last year, Amazon’s Echo accounted for a 

Siri, Cortana, M, Magic, Alexa, and Slackbots have all begun vying to fulfill your needs in various ways: Siri and Cortana take your voice input on the go, fulfilling queries and doing basic tasks. Facebook’s M and Magic are text-based bot-assisted humans helping you complete more complex actions. Slackbots fulfill a wide variety of (mostly) work and team-related needs through a text-only interface. Alexa rounds out the group, taking voice input at home, helping you answer basic queries, play music, and place orders through Amazon.

Except, every one of these consumer-level bots requires it be communicated with in a specific way. I can’t text Siri or Alexa. I can’t speak to Magic or M. I can’t talk to Slackbots outside of Slack. Likewise, they know nothing of each other.

General purpose robot assistants won’t truly be useful until they can work with each other, in all contexts.

When communicating with humans, we rarely only text or only speak. When talking to a friend, coworker, or family member, you switch modes depending on your context and theirs: you may choose to text them, give them a call, send them an email, or speak to them face-to-face.

The myriad of ways in which we communicate with someone provides the flexibility needed for natural, ongoing conversations. Restricting these bots to a limited set — a “communication surface” — means that they, unlike a person, are unreachable outside of specific contexts. The surface area and, consequently, our ability to rely on the bot, is reduced.

If I’m in a meeting, appropriate social behavior dictates that I probably shouldn’t speak to Siri and ask her to remind me to email off the earnings report before the end of today — but I could text her.

Similarly, while driving, I can’t safely text Magic and ask it to buy and deliver flowers to my home this evening — I could ask Siri to text Magic, but then I’d have two messages to proofread and a greater likelihood of miscommunication.

And at neither of these times could I ask Alexa to do anything — she’s sitting at home.

Switching bots depending on my location, social mores, and personal comfort of speaking or texting means that each time, I need to consider the capabilities of the particular bot I’m interacting with. Without an interface to guide me, I’m left to remember the functional differences on my own. Alexa can place orders. Siri cannot. Magic can do most tasks, but to ask something trivial like Robert De Niro’s age would incur a slower reply than the others.

While their capabilities may overlap, every bot is functionally different.

Additionally, because of the limited usage context of each one of these bots, they have little understanding of me outside of themselves. While Siri could know that my girlfriend texted me about needing onions and garlic for a dinner party this evening, Alexa and Magic don’t have any idea. Conversely, if Alexa places an Amazon order for me, Siri won’t let me know when it’s shipped or at my door.

These bots do share some knowledge; Alexa, Siri, and Magic can all look at my calendar and schedule events. That’s…about it.

Magic, what did Matt ask me to pickup from Home Depot again?

Unlike a real assistant, none of the fully robotic assistants proactively take care of your needs beyond a simple calendar reminder; only Magic offers these capabilities and at a 

. I won’t be notified that my Amazon package will be arriving later today or that the temperature in my apartment has dropped 15 degrees in the past half-hour. It won’t ask me if I’d like to respond to Matt’s text about tomorrow’s meeting.

Worse yet, the tools that do provide these notifications (such as Nest, or a package notification app) don’t usefully tie into our bots. While Alexa can control my Nest thermostat with some configuration, that does very little for me when I’m not home.

So, where does this leave us? Right now, we’re in a fragmented landscape, at the bottom of the uncanny valley of virtual assistants. I can speak to some, but only text others. I can do things with some but not others — until they add that feature (and then it’s up to me to keep up with release notes). Almost none of them will do anything for me proactively beyond reminders.

Until these bots gain the ability to be used more flexibly — expanded usage contexts, sharing knowledge — we’ll continue to see them as very limited curiosities. Anything like 

Why we don't take Siri seriously

this comprehensive list of Donald Trump’s insults

this detailed rundown of the 2016 Primaries

? Data is a big deal in the newsroom right now, and in 2016, we’ll likely see data take on an even bigger role in reporting feature stories.

The New York Times is just one example of an organization increasingly banking on data-driven reporting: in the Politics section of nytimes.com there is a blog called 

 that consistently uses analysis of detailed data sets to reveal surprising insights about news events on the front page. They typically include charts and diagrams to bolster their reporting: large, interactive explorations that are driving more and more traffic for the paper every day.

The Upshot, FiveThirtyEight and Buzzfeed, all of these publications are treating data visualization the same way that financial papers like the Wall Street Journal treat them: alongside the story, illustrating the story, but not integral to the story itself.

So what does data look like when it’s used as part of the story itself? How can we treat it as we treat verbs and nouns, integrated into, instead of apart from, the story?

A sparkline is a small intense, simple, word-sized graphic with typographic resolution. Sparklines mean that graphics are no longer cartoonish special occasions with captions and boxes, but rather sparkline graphics can be everywhere a word or number can be: embedded in a sentence, table, headline, map, spreadsheet, graphic. Data graphics should have the resolution of typography. – Edward Tufte, Beautiful Evidence, 46–63

Edward Tufte describes sparklines in his book 

 as being word-sized graphics. “Typographic Resolution” is his key identifier of a sparkline, and he goes back to this distinction repeatedly without quite defining it. So what does “Typographic Resolution” mean?

Emojis are one example of word-sized graphics that we use every day: these pieces of design have typographic resolution, as they sit directly with the text to add meaning or change context. Emojis can turn “thanks 😀” into “thanks 😕”; a lot of meaning is imparted with a very small symbol.

Let’s look at a data table that might benefit from sparklines.

This is a typographic table: just numbers and letters, spelling out the top 10 index funds over the past 4 years. We can add a small chart to each line with the historic trends for that fund.

This adds 120 more data points to each line, demonstrating the volatility of each fund, as well as demonstrating the forces of market cohesion and highlighting market-wide events.

In fact, we can make this chart far more compact by eliminating the numbers on the right, replacing milestones with historic trends. Some audiences might not need to quantify the specific returns of the funds, and for them, we can add data and reduce complexity.

For the right audience, this compact display of data is just as easy to parse as the original. It might be argued that it’s easier, in fact: the lines resonate aesthetically with our natural instinct to find patterns, using multiple mental modes to add additional dimensions to the data.

Simply taking normal-sized charts and sizing them down doesn’t accomplish the kind of efficiency of space we’re looking for with our new visualizations. In order to succeed, charts have to be designed with their size in mind.

This is a proprietary platform that Planetary designed for The Daily Beast. It displays information about system-wide averages, local maximum and minimum, and current state into a small visualization that accompanies each report.

This approach also applies to paragraph-level charts. This is an example of how we might take a story about market performance and integrate charts into it:

http://www.nytimes.com/2016/01/05/business/international/stocks-asia-markets-china.html

These charts are designed with tininess in mind. They don’t include text or axes. They use very few colors or patterns. They focus on one piece of information and don’t try to draw correlations or associations. This simplicity allows them to add value without adding noise.

There are a number of tools available to designers and developers that make it easy to embed tiny charts into paragraphs of text:

 A developer named Tom Noda has written up a 

great tutorial for rendering small charts in D3

. He deftly addresses some of the technical challenges, such as smoothing and asynchronous data fetching.

 While we don’t normally think of fonts as software, they are actually complex pieces of code, capable of really interesting applications.

, a font originally published by FontFont, can parse numbers into a variety of different visualizations. It uses the inherent qualities of the text — color, style, and size — to style the charts and graphs. And because it’s a font, it can be embedded into web pages and rendered alongside other text; this takes advantage of the optimizations done by browsers when rendering text. It’s nothing short of black magic.

We see the value of data visualization more and more each day, as large and interactive charts are published alongside stories in major publications. Newsrooms that explore the realm of word-sized charts, making data a central and essential component to stories, will stand apart; the next frontier of data is integration with the text of our stories.

Tiny Data Visualizations

Data-driven interfaces are on the rise. Financial District CEOs want to see a birds-eye view of their bottom line as much as Silicon Valley Co-founders want to watch their growth hackers hack. Each user has their own hopes and fears about data, but there’s one thing nobody wants to see: a blank space.

Unfortunately, errors happen. No database is perfect, and as designers and product owners, we have to prepare for the worst. So let’s look at a (real-world!) example from some recent work at Planetary:

In this graph, the values for December 6th, 9th, 13th, and 14th are missing. What are the possible ways of handling this?

The first answer, of course, is “make sure the data is there.” But as I mentioned, there are likely going to be cases where we have to handle missing data — changes in the vendor APIs, hardware issues, acts of god — so let’s analyze a few solutions.

This is what we’re currently doing. If we don’t have the data, we’re simply not drawing that portion of the graph.

 we don’t have this data, so we don’t display anything.

 we don’t have any other design or development concerns: no need to distinguish between “we have data for these days” and “we don’t have data for these other days.”

 a user has no idea what’s going on here. If asked what this graph means, all they can say is “well, there are gaps in the graph.”

 while missing data is not, by default, a reason to panic, having gap-filled graphs might inspire stress in our users.

Here’s what it would look like if we simply filled in the gaps by connecting the dates that we do have:

 It makes it much easier to track the trends in the data that we do have — there was a big increase in the middle of the time period, and that’s easier to understand this way.

 Again, no tricks in design or development: if anything, this solution is slightly easier than not showing data we don’t have.

 By drawing a line between December 5th and 7th, we’re implying what the data was for December 6th. While training and close inspection might lead a user to doubt the interpolation, it’s a little too easy to take the smooth line for granted. Was December 6th lower than the 5th? Higher than the 7th? Showing the line here might lead to inaccurate conclusions.

 even though we’ve connected the dots, we can’t display anything for the most recent two days because we don’t have any points to extend the line. Again, we can’t give a user any idea of what happened these days.

What if we shaded in the regions for which we didn’t have data with some informative error state?

 While we don’t have data for those days, we do have some information about 

 — for the yellow regions, we couldn’t collect the data. For the gray region, we haven’t tried to collect yet. There are a number of different reasons why we don’t have data, and we can provide that to the user.

 This approach allows a user to answer questions not only about the data, but about the state of the application. It’s the most informative of the solutions.

 Implementing this solution is tricky, as it requires a number of steps to record the error state and then display the error state. In addition, a key needs to be present for this to be useful to untrained users.

 I say “might” because it really only gets ugly if we have lots of error states. Seeing lots of these errors could be anxiety-inducing for the user, even if the problem is on our end as the product manager.

As an advocate of user needs even over technical requirements, I prefer solution 3. But I’ve employed all three of these approaches in products, and each can be useful depending on the circumstance.

I’m curious to hear how others have addressed this problem. Opinions? Alternative solutions? I’m all ears.

Mind the Gap

Finding the “just-right” in data visualization

Data visualization is everywhere. From analytics platforms to infographics, across newsrooms and social media channels, there are vast swaths of the internet devoted to delivering data in non-tabular format. There are entire blogs devoted to the subject, such as the ubiquitous 

. With such an immense interest in seeing and understanding complex data, designers are constantly challenged to produce images that both catch a viewer’s eye and accurately depict the information at hand.

With such a high demand, there are (inevitably) a great number of approaches being employed; some to great success, others to embarrassing failure. It’s possible, then, to learn from these approaches to create data visualizations that are good-looking 

. By “plain english,” I mean “words that you speak out loud regularly.” Depending on where you work, you might say phrases like “regular spectral density potential” regularly — so instead think of words your 

Show highs and lows, let the viewer fill in the rest

. Most graphs fall victim to “too many axes” syndrome: lots and lots of grid lines dividing up the space, ostensibly to give the viewer a hand in judging the data. However, humans are pretty good at spatial estimation, so only plot the maximum and minimum on each axis.

. For such a seemingly obvious component, the title is often forgotten. What do you want your viewer to get out of a graph? If you answer this question in a title above the graph, you’ll provide the viewer with vital context and a good sense of what they’re looking at.

Let’s say I’m preparing a graph for a client who makes pizzas. They’re interested to see how their pizza production rates have fluctuated over the last four months. Here are a few examples of how these three guidelines can be applied (or not).

In every board room in the world, there’s a laser pointer landing on a graph that looks like this:

This graph has everything: big numbers, lots of lines, overly redundant labeling. There’s no way you could misinterpret this!

 Well, it’s labeled. But isn’t “July first” much easier to say than “seven-one-twenty-fifteen?”

 This is an example of over-labeling. We’re only looking at four months here — no need for all the lines.

 It does! But it’s a little too literal.

, chances are there’s some sort of data visualization being done. And more often than not, it looks something like this:

Of course, there are good examples of data viz on Dribbble and other showcase sites, but in many cases, the design is being done from a strictly aesthetic point.

 Kind of. But it’s not very descriptive.

Let’s split the difference between these two. We’ll show what’s necessary to preserve the aesthetic qualities, but label clearly and simply to ensure accuracy:

 Yes. We’re really clear about the time scale, as well as the domain and purpose of the graph.

 They are! Also, the extra zeros on the numbers are truncated to save some space.

 It does; “…last 4 months” spells out the time frame in a much simpler manner than “7/1/2015 to 10/31/2015.”

These examples and guidelines are a (biased) set of tools for making good-looking and useful graphs. There are a huge number of topics I’ve glossed over, each of which holds innumerable hints on properly visualizing data; for more information, read the works of 

Insights