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.

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

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 

, a critic of poor data visualization and a proponent of the just-right approach.

Lastly, no approach is successful without constant improvement and experimentation. Edit frequently and update your methods constantly. By refining and revisiting, you’ll find the happy medium between overwrought powerpoint and abstract art doodle.

Goldilocks your graphs

Those New-Hire Feels

Website

We developed a new vertical for the storied Wall Street Journal.

Buy Side from WSJ

Product Design and Development

We iteratively designed and developed Sacra's digital platform.

Sacra

Product Design

We envisioned a new creator platform for Hellosaurus' digital product.

Hellosaurus Creator Studio

Network of Websites

We redesigned a network of school websites to align with their new brand.

Higher Ground Schools

Product

We created a remote team building product that serves real food.

Pizzatime

We reconceptualized the website for Miss Hall's School based on their rebrand.

Miss Hall's School

Mobile and Web Apps

We reinvented the furniture customization process for a family-owned furniture company.

Best Home Furnishings

We built and run a service to help distributed teams.

Spacetime

Mobile Apps

We reimagined and rebuilt Univision's mobile app infrastructure.

Univision

Platform

We built an unconventional photo booth product for events.

Photoland

Platform Design

A familiar brand at your local grocery store, we rethought the digital experience for the network of almond growers that produce one of the country’s favorite nuts.

Blue Diamond

We built a platform to help nonprofits apply for funding from Google.org.

Google Impact Challenge

We created a post-run experience for Prudential's 4.01K run.

Prudential 4.01K

We prototyped a new experience for purchasing smart home products.

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

Up next

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