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 

, 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

One day last August my Dad called to tell me that my Mom had cancer and it was serious.

When I got off the phone I was in shock. I mumbled to my coworkers that it was bad news and I didn’t know what to do.

With hardly any input, they booked me a one way ticket to San Diego. Transportation was booked to and from each airport, all on the company card. No need to worry about communicating my absence to my clients; my teammates would take care of it.

I had been working at Undercurrent for just six weeks.

Before coming to Undercurrent I worked at the nonprofit Invisible Children. My coworkers felt like an extended family. We went to absurd lengths for one another: four A.M. rides to the airport; friends of friends sleeping on our floors and couches as needed; letters of recommendation; over-the-top low budget birthday celebrations; donations to each other’s Kickstarter/Indiegogo/GoFundMe campaigns.

I was a writer there and it was my dream job. My coworkers were my closest friends, and the work itself was full of mission and purpose and hope.

Despite all of this, after nine months as a volunteer and two years on staff, I was burned out, depleted, and confused. I was still committed to the mission, but tired.

Telling a friend about my confusion, I explained that my employer truly cared about me: they wanted me to be happy and healthy and advance in my career. My friend patiently explained to me that Invisible Children, Inc, wasn’t actually a person. It couldn’t feel the care and compassion that I was ascribing to it. My managers and colleagues did care about me and want the best for me, but the organization had a separate mission: to end a war in central Africa that had child soldiers at its center. That was the explicit and worthy purpose that the organization was accountable to.

That made sense to me: People can care about people, but organizations can’t.

After leaving Invisible Children I got a job at Undercurrent, a 30-person strategy firm in New York.

The shift from the nonprofit world to the management consulting world was jarring and my year at Undercurrent forced me to reconsider my conviction that organizations can’t care about people.

) was different than most companies in that we were a self-organized company, not a top down company. (Specifically, we were a 

.) We didn’t have managers, just teammates and sometimes team leaders. Seniority was recognized and respected, but it didn’t confer extra privileges. As part of this setup, the employee handbook was written by employees, for employees. Anyone could contribute to the handbook, whether new hire or senior strategist. And the handbook was updated monthly. We added, changed, and removed policies as our business grew and changed.

When my Mom got sick, the instances of kindness and empathy I experienced from the people at Undercurrent were myriad and nuanced. But it wasn’t just the individuals — I had a feeling that Undercurrent as an incorporated entity was showing me kindness and empathy, too.

The contents of the care package Undercurrent sent me when I was at home with my mom.

This feeling came into focus when my Dad asked me who we should thank for all of the allowances I’d been given while my mom was sick. The CEO? The senior partners? My mentor at the company? The colleague who booked the plane ticket? The folks who took on extra work while I was out?

The closest I had to an answer was everyone, and no one person more than another. My colleagues were just acting out the spirit of the policies that we had woven into the handbook and our culture. Because of that, it was like every single individual had the power to decide to pay for that initial flight home and give me eight consecutive weeks off of work and rearrange my project load.

It was like the decision had been made long before I arrived at Undercurrent. Every action was an extension of Undercurrent’s values and policies. Just as a computer acts out the instructions it was programmed with, so too was Undercurrent behaving according to its programming, like it had an artificial emotional intelligence.

While the specific kindnesses that Undercurrent showed me aren’t feasible for every organization, I do believe that people can create policies and mechanisms so that an organization mimics empathy. If that’s true, then empathy can be scaled. More than any formal framework like Holacracy or sociocracy, the key is hiring empathetic people and giving them both the freedom and mandate to bring their empathy with them to work. Too often as employees and employers, we check our human feeling at the door.

My mom died five months after being diagnosed with stomach cancer. I worked remotely from San Diego for several weeks at a time, and spent an extended Christmas with my parents and siblings. Thanks to Undercurrent, I didn’t have to choose between keeping my job and taking care of my mom in her final months.

Today, I am the Director of Communications at Planetary, a boutique web development company that builds awesome web apps to simplify complex information.

Now that I’m at Planetary, I mean to repeat the experiment and see if we can practice empathy at the organizational level. It’s hard to know what shape that will need to take, but I think it begins with asking each other “how are you?” and then sticking around to hear the answer. The team is smaller, and half the team is remote. These are challenges, but I’m excited — not to mention determined — to work them out because in the throes of grief and gratitude, paying it forward is the only thing I know to do.

Thanks to everyone who helped make this piece better. Looking at you, 

The human organization

3 billion people used the internet for the first time in the past decade

. Can you imagine what that was like? When I began using the internet, the web was 

. Interface design required finagling websites from knots of spreadsheet-like tables, and even the most sophisticated designs couldn’t do much more than blink and display images. Now, 

37% of the world has the internet literally at their fingertips

, allowing them to manage their finances and healthcare, communicate in real-time using pictures and videos, and purchase everything from hamburgers to houses. Complex functions require complex interfaces; so how has interface design changed to accommodate?

Well, in many ways, it’s gotten boring.

In 1990, a group of researches concluded that “

” — “the ability … to recognize the value of new, external information, assimilate it, and apply it to commercial ends” — would become one of the most important factors in a company’s success. Their paper has since been cited by 26,347 others, and 25 years later, the 

 is fitting proof of this prediction’s accuracy. But our brains change at a pace much slower than the rate at which technology 

. So how do we use new technology to even our odds? Let’s look at one of the most commercially successful business interfaces of the last 25 years: the Bloomberg Terminal.

This monstrous pile of letters and numbers nets Bloomberg roughly 

. Friends who have used it rave about its ability to quickly visualize a vast amount of information; a specialized keyboard allows users to command financial data with speed and accuracy. It is ugly as can be, but it is brilliantly 

: There is a deliberate hierarchy, an accurate color scheme, concise and useful charts, and clearly-labeled tools throughout.

. There’s no thinking “outside the box.” No Jony-Ive-slinging-superlatives-in-a-black-t-shirt materials. No cleverly branded names, no breath-taking or game-changing, and certainly nothing even close to “intuitive.” Just data. This aspect — the lack of design-award aspiration — means that there’s little between the user and the information they’re assimilating. These terminals often span 

: no whitespace means more information. Despite its steep learning curve (or, perhaps, because of it), its charts and graphs are 

 of the financial industry. Its closest competitor, Reuter’s Eikon system, is only marginally less ugly, maintaining the same density and resistance to interface metaphors.

Insights