The Back of the Napkin Part 9

PIE FIGHT.

There's a problem with pie charts: They're in the middle of a war.

Among information designers, there is a long- running battle raging about the effectiveness of pie charts for conveying data. On the one hand are people who think pie charts are fine-easy to create (with the right software), visually pleasing, and easy to read. On the other front are people who believe that since our eyes are less well adapted to accurately measuring proportional size differences in slices than they are in straight verticals and horizontals (which is true), we shouldn't ever use pie charts.

In fact, there is a time and a place for both, and the proof is in the pizza. If you've ever been to a kindergartner's birthday party, you'll have seen that six- year- olds have no problem picking the biggest piece of the pie. If they can figure it out, so can we. So if you prefer round pizza, feel free to use a pie chart. If you prefer your pizza square, there is an equivalent chart to fall back on: the stacked percentage chart. It shows the same information, just lays it out in straight lines.

If the differences among slices are so critical yet so small as to be difficult to visually detect, you're better off going back to a nonpictorial table anyway.

The stacked pizza, or vertical percentage chart.

But that's one of the challenges with the typical how much chart. Because it shows only quant.i.ty, it's easy to forget other critical differences that might exist between the items being measured. In other words, although the numbers we see in a quant.i.tative comparison may be accurate, they can still mislead us. For example, if the pie chart on page 160 were the only measure I had of customer quant.i.ty, I'd in theory have no choice but to a.s.sume that I should allocate 75 percent of my marketing budget to my accountant customers, since they represent 75 percent of registered users. But that might not at all reflect sales reality.

By total spend, accountants are our biggest customer group.

As we continue to look through our sales numbers, let's say that we come across the actual client purchase orders (POs). These POs show the final amounts paid and by whom-not who registered the software, but who bought it. Using another bar chart (since we're looking at absolute numbers, not percentages), we see that accountant customers spent $100,000 with us last year, while salespeople spent only $5,000.

Here we see a different story emerge. While accountants represented three-quarters of our total registered customers, they bought only slightly more software than did the technicians, who were the second smallest customer group in size! That's interesting. Who'd have thought that the technical people were the ones doing so much buying?

To understand how this is true, we're going to have to look at one more chart. This time, let's factor in the quant.i.ty of each customer type against how much money each spent. Doing the math (total spend divided by number of customers per type) tells us the following: When we factor in the number of customers against their spending, we see that the average exec spends $5,500 on our software, the average tech $5,300, but the average accountant spends only $640.

Whoa! Look at that. While execs and technicians account for just half of all purchases, individually each has nearly nine times the individual spending power of the accountants. Nothing we'd looked at in any data before would have led us to see that. Although this chart doesn't tell us why the numbers shake out like this, it certainly gives us a lot to think about. Perhaps the technicians are doing much of the buying on behalf of the accountants. If so, those technicians have tremendous spending power. And just four execs are buying even more? That tells us something new about purchase decision making at our client: It falls disproportionately on the two most disparate groups. It also tells us that we'd better start looking carefully at the buying process of the technicians and execs.

All this should be giving us an inkling of where our sales problem may originate-and that's what we'll be looking at next: the where framework. But before we go there, let's review. The pictures shown here-numeric comparisons, pie charts, and bar charts-are just a few of the variety of ways to show how much or how many. As we saw with portraits, different businesses and different problems will demand different types of charts to represent quant.i.ty; but also like portraits, they are all just variations on the same theme. All are ways to show us how many or how much there are of the whos and whats we represented with our first framework.

By individual spending, execs and technicians are our biggest customers.

* If you're interested in a detailed explanation of when to use each of the myriad types of charts available, there are lots of great books out there. See Appendix C: Resources for Visual Thinkers for recommendations.

CHAPTER 11.

WHERE IS OUR BUSINESS?.

PICTURES THAT SOLVE A WHERE PROBLEM.

Moving Out Across the Map The numbers we looked at in the previous chapter show that the executives and technicians at our client are doing a disproportionate amount of the buying. That was interesting and unexpected: We'd always a.s.sumed it was the accountants who bought most of our software since they were the ones who used it. This twist has got us wondering if we really understand the hierarchy of our client's business; it appears that the technicians are in a position of greater influence than we knew.

So now we've got a where problem-not a geographic "where" as in who is located in what building or which city-but rather a structural problem. We want to see where the now-critical technicians fit into the decision tree of our client's organization relative to its accountants, salespeople, and execs. What we need is a map of our client's business structure. And even though it's not really a geographic map, we go about creating it as if it were.

REVIEW: A MAP SHOWS WHERE.

Maps can be Venn diagrams, schematics, landscapes, "think maps": No matter how different they may look, they're all drawn the same way and all show the same thing-the spatial relations.h.i.+p of one object to another.

After how much, we saw where objects were in relation to one another. We noted their positions, relative orientations, and distances apart. In order to show these locations to someone else, we use maps to represent placement, proximity, overlap, distance, and direction-and that doesn't apply just to geography: Maps make all kinds of ideas about the spatial relations.h.i.+ps of objects unexpectedly clear.

Because of their versatility, maps are the most flexible of all six frameworks, which means that various kinds of maps may not look all that much alike. The fact is that they really are, especially in the way we go about making them and the spatial relations.h.i.+ps they ill.u.s.trate. If we start by drawing in the most prominent feature of our "landscape"-whether that is a mountain, a person, or an idea-and have a clear set of coordinates defined, it's a relatively straightforward matter to move outward and add more and more features and details, mapping overlays of complementary data on top to indicate everything from borders and distances to connections and sets of shared traits.

Maps are the most familiar visual thinking framework we have: from organizational charts (which everybody knows how to draw) to Venn diagrams (which everybody understands) to good old treasure maps (which everybody loves to look at), maps are our most frequently used framework.

Maps: General Rules of Thumb 1. Everything has a geography. Anything that is built up from multiple unique components-whether those components are cities and rivers or concepts and ideas-can be mapped. The task for the visual thinker is to ask, "If these ideas (or nouns, concepts, elements, components, etc.) were nations, where would their borders be-and what roads would connect them?"

2. North is a state of mind. We're used to thinking of maps with a north-south versus east-west coordinate system upon which places and objects are plotted according to their relative spatial positions. We can make maps of most anything using other pairs of opposites: good-bad versus expensive-cheap, high-low versus winners-losers. In fact, the only challenge with most maps is coming up with a meaningful coordinate system; once it's in place, plotting in the "landmarks" is easy.

3. Look beyond the obvious hierarchy. Traditional (hierarchical) org charts are wonderful tools for mapping the official chain of command of an organization and for showing who is responsible for what. But when it comes to understanding where the less obvious-but usually more powerful-political connections really are, a bubble-based or connections-based "map of influence" is the better tool. The data to create such a map is always much harder to collect, but the effort pays off when insights into the inner workings of an organization are needed.

Once again, back to SAX Inc.: We know from the codex that a where problem demands a map, and as we run across the SQVID we think simple, qualitative, visionary, individual, and as is. We see that we'll need to create a picture somewhere between a concept model and a treasure map showing the structure of the company. We also know that the best way to start a map is to draw in the most prominent feature, which in our client's case is their ma.s.sive accounting department, the "factory" of their entire operation.

We start the map of our client's business structure with their most prominent feature: their huge accounting operation.

Even though that's where all those accountants sit, we now know that accounting is not the home of our new target buyers, so let's branch out from there and add in the other divisions.

The main accounting factory is surrounded by administration, sales, and support divisions.

We also know that all those groups are run like little fiefdoms, so let's add in the borders to see who b.u.t.ts up against whom-and who doesn't share any borders at all.

Adding borders shows us that sales is an independent state run by its own rules, while operations, accounting, and support share many common borders.

In the real world, adjacent nations are connected by roads, and the same is true with our client. Let's get one of our own salespeople-someone who knows how things really run over there in client land-to help us map in those interdepartmental pathways.

Based on the insights of our own salespeople into the client's organization, let's map in the roads between departments.

Hmm: No roads between sales and accounting. No direct connections means little influence one way or the other, so it's unlikely either is influencing the buying decisions of the other. OK, we've got our map. Now let's see where the treasure is.

X's mark the spots where treasure (the people who buy our software) is buried.

We've now got a sense of the divisional structure of our client. That gives us a useful overview, but as we look at it, we realize that what we really need to see is the hierarchical connections between those domains: Who decides what and who influences whom. So let's make another map of the same "geography," but this time we'll focus on the real power-the people. We'll approach things in the same way, starting with the most prominent feature: in this case Marge, the CEO.

We start a map with the geography's most prominent feature, so begin with the CEO.

Since we'll be showing everybody else relative to Marge, we need to establish a coordinate system around her, some place to map in the next most prominent features: Mary (who runs sales) and Mildred (who runs operations).

Two lines establish our coordinate system and allow us to start mapping in other people.

Pus.h.i.+ng ahead, we next map in the middle management layer of Morgan, Tom, d.i.c.k, and Beth-the real gatekeepers of the business's domains. Then we decide to erase the coordinates after all, since they're complicating things and, let's face it, everybody knows which way is up on an org chart.

Middle management appears.

Then we map in the rank and file. Amazing. We've got most of the company mapped and we haven't even seen the technicians (half our buyers) yet.

Four layers down and we still haven't seen the technicians.

One last layer and they finally appear, way at the bottom of the stack, far removed from Marge and the executives, and with no visible connections whatsoever back to the sales teams. Well, there we have it: Add a t.i.tle and we're looking at the organizational map of our client, seeing the hierarchical location of each group in relation to the others.

We're finished: a complete map of our client's hierarchical organization structure.

Org charts like this are one of the best examples of a where business map: Creating one ill.u.s.trates how easy it is to show the spatial relations.h.i.+ps of multiple items in a clear way, and-even better-org charts are the one kind of map that everybody in business (including, especially including, the "I'm not visual" people) knows how to draw with conviction. In fact, if anybody asked us to sketch out how our own company works, the first (most likely only) picture we'd draw is a hierarchical, top-to-bottom org chart.

We've all seen org charts, we all understand them, and, whether we're happy with our own position on them or not, find it comforting to see ourselves and people we know concretely represented in such an unequivocal framework. Because org charts give us a sense of confidence in the order of the world, we take great stock in them as accurate reflections of people's organizational influence over one another. This is a belief which, while true enough to keep org charts the favorite business picture of all time, can also make them wildly misleading. In fact, often the most insightful thing about an org chart is what it doesn't show. But to see that, we have to go looking in a different way.

Neither map shows any direct connection between the execs and the techs-what's up?

Here's what I mean. Looking back at our org chart, we're faced with an anomaly. According to our numbers, the execs and the technicians are the big buyers, but organizationally they are as far apart as two groups can get-and our first business structure map didn't show any direct "roads" linking them.

We could say that we've now got two distinct sales targets within the same client company who each require their own distinct marketing approach, but we'd much rather clarify the relations.h.i.+p between the two groups. By better understanding the connection, perhaps we could come up with a single, more cost-effective marketing approach that would appeal to both execs and technicians. That feels like a stretch, but it would certainly be worth the effort if we could find the common thread.

We're stumped until our own salesperson-the one who really knows how things work there-tells us the story of Jason, our client's technical whiz kid. It turns out that Jason, two years out of engineering school and in his first job with our client, is a genius at fixing laptops. He's already got such a great reputation that everybody calls him when they have a problem, and Jason has been able to solve so many problems for Mildred, the head of all operations, that she's come to rely on Jason's technical savvy for insights into everything technology related. So there's the connection: Jason. The lowest guy on the totem pole turns out to have the greatest technical exposure of anyone across the entire company.

What's the critical connection between the execs and the techs?

Aha! It turns out that Jason-the lowest guy on the whole totem pole-is the one everybody calls when their computer isn't working.

Now we've seen both the weakness and strength of a traditional org chart. Since it shows only the "official" structure, it doesn't illuminate many of the human connections that really make things work. Then again, once an org chart is mapped out, it becomes an excellent backbone for mapping in the real spheres of influence.

Size is one of the visual cues that we key off of without any hesitation. So if we were to create a set of overlays on top of the org chart we just created, we could use size as a way to quickly indicate the real influence of Jason within our client landscape. So let's take that same org chart and use different-size circles to indicate the relative technical influence of each person.

Jason's real importance becomes visible when we use different- size circles to indicate his technical influence over middle management and the execs.

We found the missing link: Jason. And if he has the ear of decision makers across the company, that makes him a powerful influence in technology-buying decisions. Whether or not he actually does the buying, he certainly is influencing it-both within the technology and accounting domains that account for most total purchases, as well as among the executives who make the greatest number of individual purchases. Given his influence, it makes sense to figure out what makes Jason say good things (or bad things) about a particular software package.

As a starting point, let's go back to the portrait we made showing what each of our customers looks for when choosing software, but this time try to map out the connections-perhaps we'll see what makes Jason tick. Starting from the top, we recall that executives want security.

Execs value software security above all else.

Then we recall that accountants want reliability, which overlaps security slightly.

The reliability that accountants want shares some overlap with the execs.

Jason, trekking as he does through all levels of the company, knows that the best software doesn't just meet his own flexibility criteria (easy to connect to other systems and easy to update), it also meets the needs of the execs and accountants. And Jason knows their needs because he's the guy who has to listen every time something goes wrong. This means that the one person in the company who knows both what the software needs to do and has the reach to influence buying decisions across the company is the guy who barely even made the org chart.

Jason's view of software intersects with that of both execs and accountants.

This map is called a Venn diagram and it is used to show the spatial overlap between any kind of objects, even ideas. Venn diagrams are a type of broader category of "concept maps" that don't look anything like either the treasure map or the org maps that we created, but do exactly the same thing: They show the same way of seeing (where), they share the same kind of coordinate system (spatial: up-down, right-left, front-back), are created the same way (start with the most prominent feature and add others in relative position around it), and represent the same thing-the relative positions of several objects in s.p.a.ce.

Since the Venn diagram here does such a nice job of showing us what Jason looks for in accounting software, let's use a similar but more elaborate concept map to model out the basic components of our Super Account Manager (SAM) software. This picture will help us see where in the system we could make improvements that would meet Jason's criteria for perfect accounting software: security, reliability, and flexibility.

Like any visual thinking challenge, we start by looking, so here we've compiled a list of all main SAM components. Although the list is categorized, it's impossible to see the relations.h.i.+ps between the components.

Components of our software: a complete list, but impossible to see relations.h.i.+ps.

We know that the best way to start a map is to draw in the most prominent feature. In this case, the last item on the list, Account Management Engine, says "heart of the system," which sounds promising. So if it really is the heart, draw it in the center.

Start with the heart.

The heart of any system connects to all the main components, so let's draw the category t.i.tles around it. There seems to be something parallel about employee records (Employees) and customer records (Customers), so draw those at the same level; the same holds true for reporting engine ("Reporter") and banking engine ("Banker").

Then we add the main categories arrayed around the heart.

OK, there's one way of looking at the basic components of our software-and it looks a lot like that conceptual Venn diagram, only there are more parts and they don't overlap as much. Now that we've got the main categories, we can add subcomponents arrayed off those. And as we do, connections between components, which were invisible in the original list, begin to appear.

Adding the subcomponents gives us a complete schematic diagram of our software. We even see connections emerging that were invisible in the original list.

Now that we've got a way to really look at our software package, let's map in areas that we'd need to improve to meet increasing customer demands. To improve security, we'd need to enhance protection around those areas where the most information enters and leaves the system: the "Banker" components that link to separate systems and the banks, and the "Reporter" components that present information to pa.s.sword-protected Web sites.

In order to meet executives' demands for more security, we'd need to modify the "Banker" and "Reporter" sections of our application.

Similarly, we can now clearly indicate those components we'd need to modify in order to improve reliability, namely the Business Calculator and the Account Management Engine.

To meet the accountants' demands for improved reliability, we need to modify the Business Calculator ("brain of the system") and the Account Management Engine ("heart of the system").

Most important, from Jason's perspective anyway, we can now also use this map of our system to determine where we'd need to make improvements to flexibility. As we can see, there are a lot of areas where the various components interact, and it's in those connections that we can make the biggest changes.

Where Jason would like to see us make improvements: Any way we can simplify and standardize the connections between system components will help flexibility.