# a visualization philosophy I wrote this at the behest of a colleague in December of 2024, while working on design for marketing analytics. --- ## **The “What”** Marketing ROI is a tough term to pin down, because effectively allocating marketing dollars doesn’t mean the same thing to every customer. One thing we are actively working on delivering to customers is a way to highlight metrics and insights as they relate to an overall strategy. For example, growth companies may be willing to spend past the point of diminishing returns with the intent to stake out a larger share in their market. In this case, they may be interested in pursuing a target incremental ROAS goal. Contrast this with a more mature brand whose marketing strategy might be one of efficiency – ensuring that each dollar spent results in a _profitable_ return – they will want to optimize against a metric like marginal ROAS or marginal profit. The above is context for the answer to the first question posed: instead of answering how we can make marketing “ROI” more obvious, I’m going to answer how we can make data relationships that are relevant to your strategy more obvious.  So, the first tip is to know which metrics matter to your business, and to bring those to the forefront. Removing visual noise aids in making better decisions and keeping users focused on only the information relevant to a decision. My younger, more cultured siblings would call this “keeping the main thing the main thing.” The next tip is to do less. Take clutter off the screen. Marketing analytics products, like so many analytics tools, inherited the genetic material of their predecessors. They all share a very prolific predecessor, the Genghis Khan of software, Microsoft Excel. Most companies looking to provide a tool of this nature will find a way to derive what Excel does by creating a complicated data grid, putting it in a browser, slapping on a few data connector APIs, and calling it a product. In addition to this unfortunate genetic inheritance, all of us humans are afflicted with the chronic disease of “additive bias.” When presented with a problem, it is exceedingly rare that someone would consider a solution that removes components – we always favor adding. This results in a lot of artifacts. Appendages.  If you’ve followed tip number one, then you have a few metrics that you can weave together to form a narrative and take action. With these metrics identified, there is no need to reverse engineer your way into Excel. Depending on your organizational structure and fiscal calendar, you may want to see them aggregated at different levels and see their trends over different periods of time (more on this later). I want to take the opportunity to stress this point: **identifying key metrics and aggregating them up a hierarchy or seeing them plotted over time is the essence. It is the outline, the shape, the form. You first must see and understand this shape**.  Only once we are familiar with this shape can we add texture – in the form of more metrics and nuance. But we should be very cautious in doing so; more information does not always lead to better decisions. In my experience as a designer, I’ve noticed that product development shares that infamous characteristic with welfare policies: you can give, but you can almost never take away.  I’ve already written enough for that second tip, so let me summarize _what_ is worth visualizing – start by identifying the key metrics for _your_ business and its goals. Next, present those (and only those!) metrics. Do not fall into the “kitchen sink” trap.  ## **The “Why”** When relationships exist in two dimensions, we can compare them side by side. Math says “points.” Tables and lists are great for points, and everyone understands how to read a list. However, making intelligent marketing decisions requires understanding incrementality and marginal effects. By definition, these are secondary and tertiary effects. Math would call these “functions,” (lines!) and “gradients” (surfaces!). Imagine I drop you into Yosemite national park. I hand you a topographical map and I tell you that you need to get to the top of Half Dome. This is the problem we’re trying to solve for our customers, but we can’t really give them a nice map, we can only use a browser that’s designed to render two-dimensional shapes to give them clues as to which direction to traverse.  Alas, we need to be clever. We start by taking a few cross sections of that same map, saying something like “look, here is the elevation profile if you head due north.” It’s a line that goes up and down. Now, “here’s the elevation if you head south” – it’s another line, but it seems to be going down the whole time. You can infer that you shouldn’t head south. North may not be the way to Half Dome, but we know it ain’t south. We keep going; we’re triangulating, building a three-dimensional picture using two-dimensional sections.  Eventually we find our compass bearing.  It's easy to point out that technology that implements sophisticated math can do all these measurements for us. It can even, in theory, just tell us what direction to walk. These types of products are often touted as futuristic or disruptive. They also tend to fail. They fail because they aren’t transparent, and their users don’t feel that they can trust and verify these recommendations. I have yet to find someone who wants to put their job on the line for a mathematical model that they cannot understand, deconstruct, or use to justify their decisions. If you’re lost in the woods, thirsty and tired, with nothing but Siri, and Siri keeps saying “hey, just keep walking in this direction, trust me!” you might start to wish you had a compass or a map instead. The same reason we prefer driving to flying, even when we know it’s more dangerous. We’re the agents, we’re in control.  Visualization is our happy medium. It’s better than a compass, and a lot less sketchy than Siri. It lets us explore complex relationships by leveraging one of our most powerful senses, our sight. We’re really good at measuring relative distances and angles, identifying shapes and positions. We’re occasionally passable with colors and sizes. It’s also just delightful when done well, at least in my opinion. A beautiful visualization has the potential to make us feel sophisticated, smart, analytical, empowered.  ## **The ”How”** I’ll start by stating that doing “visualization” incorrectly is worse than not doing it at all. There are many infamous examples of how and where visualization was used incorrectly to disastrous results. The nationally televised horror that was the challenger disaster in 1986? O-ring failure. Potential for failure wasn’t caught because even though testing was carried out, the data was visualized and reported in a misleading way.   Hey, we made it to the tips, finally.  We want to visualize data in accordance with proper design principles. Unless what surrounds a data visualization on a page is structured neatly and intelligibly, the visualization cannot tell the story it must. In other words, **first consider information hierarchy**.  **Ask if you really need a visualization**. Consider your users. Do not underestimate the value of sending a concise message in plain language: “Metric A has been increasing for the past 30 days” could be just as valuable as a line chart, but would cost a fraction of the development time. If you do need a visualization, consider that visualization in insolation. Don’t immediately start bandying about the word “dashboard.” **Design according to relationships you want to highlight and problems you want to solve.**  Let me expand on the above, briefly. Dashboards inherently center personas, but in doing so they create bloat and redundancy and promote the furnishing of far too much information, 90% of which is irrelevant at any given moment.  I’ll just say the quiet part out loud. Product teams and engineers like making dashboards, because it makes them feel smart and productive. Lots of colorful shapes appear on their screens, and they squeal with delight. Customers don’t really like this, because it’s complicated and makes them feel stupid, but their boss is on the call too so pretend they “totally get it” to save face. Seeing a convoluted dashboard and saying “wow, this is amazing!” is the corporate equivalent of “well of course I know what that means, I was just testing you!”  As a final gripe, I feel that “personas” are vague, stereotyped ideas which do not map well to a diverse set of org structures and customers that exist on a (very wide) spectrum of technical knowledge. Just. Solve. Problems. If a user needs that particular problem solved they will use that part of the application. Technology companies, in particular e-commerce companies, have developed an acute case of tunnel vision with respect to “saving clicks.” This miserly habit has bled into the world of product design more broadly, and it’s led to all types of bad ideas around how to organize products, turning perfectly fine tools into monolithic processes full of anti-patterns. It’s worth mentioning because to my mind, persona-based dashboarding is one head of this click-saving hydra beast. “We put everything here for you, see how many clicks we saved you?” sounds great until something is inevitably missing, and no amount of clicks can solve it.  Great, so we have some principles to help guide us as to where and when to use visualization. Let’s talk about the visualizations themselves.  **Your app probably would be better with less visualizations**. My personal philosophy as a designer leans away from dashboards full of interconnected widgets and into what I refer to as “key visualizations” – a single, large visualization that explores a relationship, occasionally related to a table which lists the same data shown in the visualization, for easy reference.  **Stick to bars, lines, and dots**. If you cannot communicate a relationship with a set of bars, one or two lines, or a scatter plot with two axes, you have not sufficiently deconstructed the problem you are trying to solve.  **Titles and subtitles are not optional.** Add them, and write them consistently. There is an art to this that I would like to expand upon some time, but it would involve writing several more paragraphs.  **The data-to-ink ratio is gospel**. When we overload our visualizations with ticks, labels, markers, and legends, we lose the emphasis on the data itself. Users don’t need to see every single date on the x-axis of a line chart. It’s enough to show a few dates. Or even none at all, prompting them to interact to learn more. After all, if you’re looking at a line chart it’s because you want to identify a trend, and trends occur across time periods, not on any specific day.  **Leverage interactions and tooltips**. In order to keep the data-to-ink ratio high, we make our visualizations interactive. Are you interested in what happened at a specific point on a line chart? Hover over it and we can give you a wealth of information. Do you see a point on a scatter plot that seems like an outlier and you want to dive deeper? Click on it! We’ll pull up a context-aware menu that will provide you some options to learn more. If your software isn’t interactive, it might as well just be a PDF report, and if you just want to produce PDF reports, why are you paying for all these engineers? **Don’t depend so heavily on color**. Especially red and green. I’m not even going to bore you with another plea to consider colorblind users. I’m just going to say that if your chart cannot be understood without the inclusion of multiple garish colors, you have not produced a useful chart. Use color sparingly to highlight interesting points or relationships.  **Stop stacking axes**! A personal plea to the world, but in particular to our customers. Using multiple y-axes makes it so difficult to understand data. The solution is what we refer to as “small multiples” – stack your charts so they share an x axis but have individual y axes.  **Use language to inform your design**. How we articulate ourselves uncovers how we organize our thoughts when we process information. If you’re putting a metric on a dashboard along with some type of decoration that shows how that metric has changed in the last week, first ask yourself, how would I read this information out loud. If you say “the metric is X, and it increased by Y since last week,” then organize that information according to that flow of words. If you can’t “read” your visualizations or they don’t parse to language that people use every day, you need to reevaluate their design.