Juice Analytics

I have become curiously interested in this post that talks about how it’s difficult to correctly write an application for the iPhone. The assertion is that writing software for the iPhone is harder than for a desktop, not because of the technology, but because:

“everything counts so much — every design choice, every line of code, everything left in and everything left out.”

Very eloquently and precisely put. If you’ve ever used any sort of mobile computing platform, not just the iPhone, you know how much proper design can make an application really useful – or totally useless.

But then again, isn’t this the case with any application? Aren’t the best ones those in which the designer applied Brent’s assertion for iPhone software? Some applications seem to have their genesis in the charter “build an application that allows the user to perform all these actions” while others are built on the charge “build an application that helps the user solve this problem” — it’s the battle of functionality versus purpose.

Take a look at ChartChooser based on Andrew Abela’s “smart charting” guidelines. It doesn’t help users figure out how to pick a bar chart or pie chart. What it does is to help them answer the “what’s the right way to show this information” question. There’s not a lot buttons or features, it just does one thing well. There are certainly other good (better?) examples out there as well (FlipVideo, Evernote, Tivo, to name a few). The better the software, the less the user will think about it when using it to get their job done.

In line with this thinking, we put together a short list of some design principles that we use to keep the user productive:

• Solve a problem – Make sure the end product provides a specific solution to a specific problem so the user can easily understand how it helps them.

• Enable casual use – Minimize the “barrier to entry” for new users by avoiding feature overload, minimizing clicks for each task, and by not letting polish become bling.

• Tell a story – Relate the data to the key questions, answering them in a logical order and revealing layers of detail as users express interest in knowing more, not before.

• Lead to action – Empower the user to finish their task quickly (btw, the “task” is not “using software”).

• Encourage exploration – Use the experienced guide approach to give the user enough context to understand the problem and then point them in the right direction to learn about new factors that will expand their insight.

via Dashboard Spy

Real-time dashboards — the kind that show up on a big screen in a call center — are an entirely different beast than your standard management dashboard. Their job is to support immediate decision-making. As a result, the information must be easy to interpret, alert users to problems, and make the next action obvious. In addition to key success metrics, real-time dashboards may show detailed data about the action “on the ground.” Here are eight characteristics that can make a real-time dashboard effective:

1. A summary status that indicates how things stand overall. Users need to be able to tell at a glance whether they should worry or not. Here’s a great example from the folks at Superblock. The “Is it going to rain?” site tells you the single most important thing you need from a weather report.



2. Reflect a well-understood structure of the business. By the time you design a real-time dashboard, you should have a strong theory for how the pieces of the business fit together (i.e. the relationships between key measures, drivers, and available actions). For example, in the call center business, there are clearly defined success measures (e.g. wait time), a mathematical relationship between these measures and their underlying drivers (e.g. call volume), and known levers to address problems (e.g. staffing levels).

3. Support quick diagnosis of problems. The data presentation should point directly to the likely source of the problem. Real-time dashboards aren’t the place for deep analysis or introspection into the drivers of the business.

4. Simple data presentation. In my view, real-time dashbaord’s aren’t the place for complex or advanced data visualizations. Imagine you were Napoleon and you had to use a half-completed version of this chart to make a battlefield decision in the next 5 minutes.



5. Granular view of the “unit of action.” Real-time dashboards are often about tracking activity. It may be useful to show the raw data around these events in the form of a ticker, scroll or RSS feed. We use at a real-time tracker for our website called Sitemeter. It does a nice job of tracking the basic unit of action — visitors.



6. Appropriate time window. Getting time right on an operational dashboard is critical. If the measures and trends represent too long a time period, users may not react to changes quickly enough. On the other hand, very small time windows encourage frantic reactions to changes that may not represent real trends. Ideally, the dashboard should offer the ability to configure this time range and “freeze” a moment in time.

7. Prominent but balanced alerts. Naturally, alerting users to problems is a central mission for real-time dashboards. The challenge (as always with alerts) is to balance between “the sky is falling” hysteria and “don’t worry, be happy” apathy. I’ve written before about alerts, but one item to emphasize is the need to show a sense of relative importance. Not all problems have the same impact on the business, and finding a way to communicate this relative importance is valuable.

8. Point to specific action. If real-time dashboards are about identifying and responding to issues, the tool should point users to what they can do about a problem. This can be as simple as displaying the phone number of the right person to call.

Real-time dashboards can be ignorable, create mayhem, or drive great behavior in an organization. Thinking carefully about the design and functionality will make a huge difference.

This post is the 2nd part in a 2 part series. Last time we talked about how organizations use Tribal Elders and Static Reports to find answers to questions that they already know. Today we’ll talk about the other three phases of Data Analytics Maturation.

Data Analytics Maturation Phase 3: Bigger Static Reports

Answers to questions you don’t know

Once the organization realizes that they need answers to questions that they don’t yet know, they start to extract all sorts of permutations on all of the data that they have and distribute those reports to the “need to knows” on a regularly scheduled basis. In most cases, an analytics team is set up to manage the requests from the business for more or different information. Sometimes the reports are modified, but many times new reports are created because the users already know how to use the old reports. The analytics team works hard to maintain the information flow to the individual requests with the intent to provide all the information that would ever be needed by the consumers.

On the other hand: Page 73, Row 14, Column G

The down side is that this typically manifests itself in the form of the dreaded 124 page monthly report. So, the reporting “Oracle of Delphi” shows up in the inbox. For a little while there’s some excitement along the lines of “I never knew we could get all this information.” However, soon folks realize that interpreting the data for “questions you don’t know” turns out to be pretty difficult and once they figure out where are the answers to the questions they know, they just look at those few rows of the report and leave the rest for analysis “later” (which probably means it ends up in the recycle bin… if we’re lucky).

Data Analytics Maturation Phase 4: Ad-hoc reports

Answer your own questions

Phase 4 begins when a few folks who get the 124 page data dump realize “if I could just filter the data down a little I could much better understand the answers to this specific question”. So the organization provides the ability for end users create ad-hoc reports. Now the user has the ability to construct their own custom reports to answer the specific and unique questions they have about their data.

On the other hand: Water, water everywhere…

Sadly enough, however, most people who need to know the answers get stuck in any of a few traps down in the weeds. The first trap is that they may be sure they know what questions to ask, but even in spite of their confidence, they’re really asking the wrong ones. Secondly, most people in this situation are more business oriented and less technical (presumably the more technical ones have already figured out how to query the data directly). In all but a few cases, the tool that is provided requires too much technical expertise for most business people to overcome in order to be really productive. Thirdly, even if they can actually get to the data that really does help them to be more productive, they lack the analytical expertise to interpret the data and turn it into usable information. The end result of these three hurdles is that the users end up either in analysis paralysis, or just plain giving up.

Data Analytics Maturation Phase 5: Experienced Guide

Answers to questions you should know

To solve the barriers presented by having a lot of data available only to technical users, maturing organizations provide solutions targeted at specific business areas that make exploration accessible to those who can impact business performance (in other words, everyone involved in the workflow). These solutions are not about the technology or even the data, but rather about providing information that translates easily in to getting stuff done.

The results are provided in a fashion that makes access to the right information easy by guiding the user through a process to help them answer the known questions, discover new questions to ask, and explore answers to these questions. It’s sort of like the guide you might hire on a photo safari. The experienced guide will make sure you find the animals that you came to see in the first place, but will also point out really interesting things along the way that you had never thought of. And you might even discover something amazing and exciting that you didn’t even know existed. Good information tools are just like an experienced safari guide.

On the other hand: Few and far between

The sad part about “experienced guide” information tools is that there are so few that exist. The good news is that we see more and more information workers and decision makers “seeing the light” when it comes to understanding their need for these sorts of tools. And, we believe that as more and more organizations mature and experience the challenges of the first 4 Phases of Analytics Maturation that more and more will see the benefits of Phase 5, and implement solutions that help us all be more effective and efficient users of information.

Key takeaways for the 5 Data Analytics Maturation Phases:

Recently, while meeting with one of our clients, they mentioned their desire to provide their customer’s business team with the ability to run ad-hoc reports. This notion spurred me to think about whether or not I thought this was a plan for success. Would having this additional analytics ability help the non-analyst be more effective at getting their job done?

Over the next few days, we’ll be exploring the different stages of maturity that information workers go through as they try to become more effective and efficient at consuming and acting on information. By our reckoning, we figure there are 5 Phases in the maturation cycle:

Phase 1: Tribal Elders

Phase 2: Static Reports

Phase 3: Bigger Static Reports

Phase 4: Ad-hoc reports

Phase 5: Experienced Guide

As we go through the different stages, we’ll discuss the breadth (how wide is coverage of all available information), depth (how deep is the understanding about covered information), reach (how easy is the access to the covered information), the typical user of the analytics method, and the signs that the organization is outgrowing each phase in the model. So, without further ado, let’s get started.

Data Analytics Maturation Phase 1: Tribal Elders

Answers from the Experts

The earliest stage of analytics maturity is one in which the organization relies entirely on the expertise of one or two individuals who use their business savvy to provide analytics. These folks, we’ll call them Tribal Elders, have been around the company for a long time and have “seen it all.” Just like the those “elders” in the movies, they’re wizened leaders who can mash all the data in their head and join it with their experiences to make good decisions. I guess you would say that technically, there are no formal analytics that are performed during this stage. However, everyday, the expert is using their training in the school of hard knocks to observe, analyze, act and advise on what they know to be the best for the business.

On the other hand: No rest for the weary

An organization outgrows this phase when the business becomes complex either through growth or through changing environment (such as variance in market conditions, or the expert leaving the business). All of a sudden, the leaders find themselves in a situation where they can’t scale the decision making quickly enough to continue to drive the business. The huge asset of the expert’s experience has turned into a liability that acts like an anchor on the organization’s maneuverability.

Data Analytics Maturation Phase 2: Static Reports

Answers to questions you know

An organization has reached the second phase when they have realized that they have outgrown their ability to rely wholly on what they can get out of the Tribal Elders to run the company. So they start to write down all the questions they normally ask. They use this list to start to build reports that that can provide answers to those questions that they know. Once completed, the organization now has the ability to enable a broad audience to answer the questions that have been asked on a regular basis.

On the other hand: Surprise!

The limitation of this approach is that the Tribal Elders are still needed to answer the questions that fall out side of the standard “what I know to ask” category. The beginning of the end of this phase happens when an event that was unforeseen occurs that dramatically and negatively impacts performance. The logical question arises “why didn’t we see this coming?” followed by the answer “we didn’t have that data.” The organization then begins the transition to Phase 3.

Key takeaways for analytics Phases 1 & 2:

Next time we’ll discuss the remaining three phases of maturation.

(Update: Here’s Part 2 of the 5 Phases of Data Analytics Maturation – Enjoy!)

A couple years ago we released our first baby dashboard design. I’ll admit it was a bit rudimentary. It tracked only the most basic measures and offered little insight into your baby’s current mindset. I was a new father and had a relatively superficial understanding of the nuances of babies, not to mention actionable baby metrics.

With the arrival of my second child, I set to work designing a dashboard that would give a parent all the important information they need, presented in ways that let them react to baby data even in a harried household. Let me present the prototype of our new Baby Dashboard 2.0, modeled by my daughter Maya.

We use the same heads-up display technology as in our first release, but now with more sophisticated data collection techniques we’ve included a meltdown prediction chart and real-time translation engine.

There are a few features in here that I believe demonstrate important fundamentally design principles for great Information Experiences:

• Choose metrics and information that a user can act on. Information that is just interesting isn’t worth a random pile of ones and zeros. You need information that you can act on. In BD 2.0, we wanted to deliver news you could use, in the moment. The “meltdown fuse”, for example, is a way to measure how close your baby is to freaking out. As she gets tired, sick, or hungry, her fuse shortens to the point that a simple disruptive act — a loud noise, Mom walking out of the room — will set off a meltdown. You need to know how close you are to this threshold so you can minimize the smallest of disruptions.

• Draw attention to the information that is most urgent. While the dashboard provides detailed trend breakdowns, the most important thing for a parent is the current state of things. The top bar of the dashboard answers the most critical questions always on a parent’s mind: 1) How close is my baby to melting down? 2) Does my baby need any of the basics: food, sleep, or clean diaper? 3) What is my baby trying to say to me?

• Progressively reveal data as the user expresses interest. Like a busy executive, a parent doesn’t have time for all the information at once. They are on a need-to-know basis. If a parent needs to get a better sense of the potential meanings of a baby word (“daaah”), a single click will give a breakdown of the most likely interpretations.

• Different views for different audiences or perspectives. BD 2.0 provides distinct views for baby status and parent status. The parent status (not shown) was added because we recognized that the mental state of the parent was as important to a happy child as a clean diaper.

For those of you who expressed interest in licensing our Baby Dashboard 1.0 technology, please be patient while we work out the bugs in this next release.

Have you ever tried to define a word such as “design”? It’s not too easy. Here’s what the New Oxford American Dictionary says:

design |dəˈzīn|
noun

2 purpose, planning, or intention that exists or is thought to exist behind an action, fact, or material object

I guess that probably covers it. But then again, I find myself asking my favorite question: “So what?”. I mean, what does it help me actually get done?

It looks to me like the folks over at Duarte Design have it figured out. Nancy Duarte made this post regarding the recent DesignThinkers2008 conference. In it, she very astutely stated “[proper] design isn’t about decoration, it’s about meaning and access to information”. Very cool.

It’s easy to “get your flash on” and decorate information visualization up with all sorts of glassy, bouncy and flying designs; they might even be considered “tastefully stylish”. But if you haven’t focused on the meaning in the information and haven’t made it accessible to the observer (i.e. understandable so they can actually do something with it), you’ve missed the purpose of the whole design process. So when you’re designing a solution for those you love, make sure you stay purpose driven.

Thanks Duarte for helping us keep our eyes on the ball!

(For those of you who might not know who Duarte Design is, among other things, they were heavily involved in the design of the presentation Al Gore used in “An Inconvenient Truth.” If you’re interested in how to communicate better through presentations, check out their blog slide:ology.)

When people contact us at Juice, they sometimes don’t have a complete picture of what we do. Our obsession with finding better ways to communicate information is obvious, but how it adds up to something relevant to their business isn’t always as clear.

The answer: We design, prototype, and develop great Information Experiences™.

Information Experience™ is our way of describing the intersection between user experience and information-intensive applications, where success is how effectively a user can consume, understand, and apply that information.

Like sitting behind the wheel of a BMW or my two-year-old flipping through photos on an iPhone, great Information Experiences have less to do with features and more to do with an intimate connection between human and device. Great information experiences tell stories where data is the primary medium for communication. The information appears when it is needed and the device or application seems to anticipate the next question or action. These are the objectives that we apply to the solutions we design and build.

Designing Information Experiences spans from the highest architectural model of a system to the specific details of user/interface interaction and data visualization. Across these levels, we consider four objectives:

1. Support the achievement of organizational objectives. How can the information experience fit into users’ existing decision-making and work processes? How can we influence decision-making with the right information at the right time?

2. Direct the user to likely actions in order to “get it done”. What are the important questions a user is trying to answer or tasks the user wants to accomplish? How can the application make it as easy and intuitive as possible to get to results? Does the navigation and user flow feel like an extension of users’ thought process?

3. Present only the information that needs to be seen. For any given view of data and situational context, what is the most critical information to share with the user? How can information be progressively revealed to give the user what they need to know at any given time?

4. Present the information in a way that produces understanding and action. For any given data and situational context, what is the most effective information visualization? What are the best ways to present information given users’ experience and sophistication with interpreting information? What is the appropriate level of detail to be displayed given the context and user needs?

When we talk about the social rather than technical challenges of Business Intelligence, it is motivated by the belief that too many vendors are more comfortable tackling technical details rather than evaluating how users can interact and gain value from information. Which is to say: design better Information Experiences.

That’s what we do here at Juice. And we have people skills! We are good at dealing with people! Can’t you people understand that!

I had a fascinating discussion with my sister-in-law, a real-life professional Architect, about the parallels between her work and the type of interface design we do at Juice. In both cases, design requires looking at the problem from many perspectives, blending art and science, creativity and time-tested principles. Sure, she had to go to graduate school for three years and is part of a rigorous apprenticeship system. But when you consider the ways we approach and solve problems, there are a number of common threads:

1. Start with the context. For Architects, a project begins with a site analysis to evaluate the available space, direction of the sun and wind, characteristics of surrounding buildings, street patterns and other environmental factors that need to co-exist with the building. The parallel in interface design is considering the context of users: What is their typical workflow? What other data and reporting are they working with? What decisions will be made from viewing the data? What is their skill level?

2. Decipher client needs The ultimate job of the architect and interface designer is to translate vague but strongly-held desires of the client into a practical reality. There are straightforward functional requirements: “I need a house with three bedrooms upstairs.” And there are more subtle demands: “The application needs to be simple enough for anyone to use.”

3. Evolved toward reality. It wasn’t hard to find parallels in the ways that we approach the process of designing. Like interface design, the architectural design process evolves from the most abstract (blocks of wood) to more realistic representations (drawings and models). The more realistic the format, the more time intensive and the more clearly the concept and details can be communicated. At Juice, we are particularly fond of prototyping analytical applications because it gives our clients an opportunity to engage with the interface and data directly.

4. Build a narrative. Like any piece of art, a building needs a core story that characterizes its essential qualities. In our interface designs, we call these design principles. These are the basic truths that we want to permeate the application. Here’s an example of design principles for a reporting application design:

   a) You’re one click away from what you need; b) Allow lightweight, temporary ways of paying attention to something; c) Alerts are so important that they are always visible

5. Connected whole. I shared with my sister-in-law a description of how many dashboard vendors are essentially selling functional pieces without offering guidance on how they fit together. She remarked: “if you designed a building that way, you’d end up entering into the bathroom.” I’ve seen dashboards that feel about like that. Architecture has had many decades to recognize the primacy of the cohesive whole. Interface design, particularly when it comes to the presentation of data, hasn’t come nearly so far.

6. Multiple relationships. Designing a building requires thinking about the problem from many different perspectives, and ensuring that the answers work together. Architects need to consider how functional spaces relate to each, how the spaces flow together, and how the spaces relate to the site. Interface design requires thinking about how the presentation of information links together, how users navigate between this information, and how the results fit into the broader user workflow.

7. Multiple scales. Architectural and interface design requires viewing the problem at multiple scales. There is the high-level view of how a building fits into its site locations all the way down to the design of specific rooms and spaces. Each of these scales needs to be in harmony.

8. Facilitate flow. A good design supports intuitive pathways within the structure. The design accounts for the most common use cases and makes solving these use cases obvious. In our work, we always want users to have a sense of where they are and where they can go.

9. Iconic elements. My sister-in-law described iconic elements as the center-point of the building design and narrative. They encapsulates the personality and essence of the design. I hadn’t previously thought of interface design in this respect, but I will in the future. In our work, there is frequently a single element, whether it is a data visualization or navigational structure, that is the core of the application.

10. Visual vocabulary. The “vocabulary” of the building represents the materials (e.g. wood, metal, glass) and other visual elements that compose the common aesthetic for the design. The analogy for us is the UI style guide where we define the color palette, typography, and other treatments that make up the look-and-feel of the interface. An effective UI style needs to align with the narrative and design principles described above.

11. Upholding and breaking rules. There are many conventions and expectations that shape the design of a building or an interface. These rules exist for many valid reasons, and we agreed that it is important to acknowledge and respect them. However, my sister-in-law noted that her professors would often challenge students to “break the rules to make them stronger.” There are times to challenge convention, in particular with your iconic elements, to push the design beyond the ordinary and formulaic.

At the beginning of our discussion, I was surprised to learn that a few of my sister-in-law’s Architecture classmates had gone on to do interface design. Given the similarities in the thought process, it may not have been a big transition.

Many analytical applications fail for a simple reason: they assume users know precisely what they need before they’ve begun the analysis. There are cases where this assumption holds and the user has a specific end-point in mind. But more often, users depend on the tool to track down an answer with only a vague idea of where to start. The exploratory analysis that follows can feel like swimming upstream when the application isn’t designed to facilitate the journey.

The source of this mismatch is partly rooted in the technical perspective of database developers. The simplest path to providing data access is to let users fill out a form to define a SQL query. It is a linear mindset that isn’t well-suited to ambiguous problems.

I’d like to offer a couple examples that illustrates the difference between the common, form-based approach and a more dynamic, interactive approach. Then I’ll explain the implicit assumptions behind the different models and why it matters.

At its heart, Travelocity is a travel analysis tool intended to help you find the best flight (or hotel, car rental, package, etc.) given a complex set of parameters. The relative importance of each of these parameters (departure day/time, return day/time, airports, connections, preferred airlines, price, etc.) is a personal preference… but not one that is explicitly or fully known even to the user. For example, it would be hard for me to say exactly how much more I would pay for a non-stop flight or what is the relative value of a more convenient airport versus a more reliable airline. These preferences are hard to understand prior to seeing specific trade-offs.

Travelocity approaches this complex problem in the way that so many analytical problems do: it asks for all your preferences first then offers a static list results for the specified query.

A few things to note about this search results page:

1. On a busy web page, “Change Your Search” is not emphasized.
2. The “tracker” across the top shows a linear five-step process. The user is expected to flow through this sequence in order.
3. Getting results for a new search takes more than ten seconds.

I’ve been a loyal Travelocity user for years, and I don’t want to imply that this site is poorly designed or difficult to use. The problem is more subtle than that.

By way of comparison, let’s take a look at a more recent entrant to the online travel business, Kayak. This site is designed with a different usage model in mind. Kayak starts by asking for the same information as Travelocity, but the results pages is designed to support further analysis:

The biggest difference is the prominent filtering functionality on the left side of the page. The filters allow users to narrow down their original search without leaving the results page (it takes less than a second to view refreshed results after changing a filter—no “run report” button required). In addition, Kayak places more emphasis on the start-over option. The designers of this site did not assume your first search would be enough to get you to the perfect flight option. Finally, notice the different “views” of the data that are available for a given result set. The views help support different types of decisions based on the same search parameters.

Analytical applications for business have similar underlying structures and usage models. The analysis process in Omniture SiteCatalyst, the leading web analytics platform for large sites, offers a typical example:

This application offers lots of functionality, and it feels like featuring functionality is the primary purpose of the start page. If you want to get to useful data rather than view an advertisement for Omniture products and events, you can start by selecting the “Report Builder:”

Now, it is form-filling time. Like Travelocity, the user is expected to choose the precise parameters before they get to see anything. The resulting report requires a 10 second wait, and the result is static. Any additional filtering will require you to run a new report

Now let’s look at how Google Analytics chooses to structure the user experience:

In contrast to SiteCatalyst, Google Analytics shows you results immediately—no defining or configuring a report before you can get started. Similar to Kayak, the application offers a bunch of options on the report results page to refine parameters (e.g. data ranges, metrics, comparisons).

Travelocity and Omniture make a few assumptions common to analytical applications:

• Users can accurately define their need (i.e. they already know what they are looking for).
• Users can precisely define their need (i.e. they know all the relevant parameters).
• Users’ workflow will follow a linear sequence of events. Going back to the beginning is a failure of the process or user.

More effective analytical applications like Kayak and Google Analytics make different assumptions:

• Users have a general question, but do not necessarily know details about what they’re looking for.
• Users need to see results before they can ask better, more detailed questions. These feedback loops provide critical learning.
• Users need to get to data as quickly and easily as possible. A screen without data is delayed progress.
• Different views of the data can provide different insights about results.
• Users want the application to keep up with their trains of thought. Speed and responsiveness matter. Here’s a framework from Jakob Nielsen’s blog about response time:

0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

10 seconds is about the limit for keeping the user’s attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

In my experience, making the right assumptions about user behavior makes all the difference between an application people enjoy and depend on and an application people dread using.

Organizations have a personality, and it bleeds into everything from executive reporting to product offerings. A recent Fortune article entitled Microsoft without Gates offers this wonderful tidbit about Steve Ballmer, CEO of Microsoft:

Even though he never was a serious computer programmer, by all accounts Ballmer is just as good at math as Gates is. He lives and breathes data. “Steve has a computer in his head,” says Bob Muglia, a 20-year company man who heads the Server and Tools division. Ballmer expects his subordinates to be adept in math as well. He distributes 11-by-17 sheets filled with numbers detailing the progress of various operations. The numerals are so small that executives use transparent magnifier rulers to see them. But there are never any columns showing percentage changes. Ballmer believes people ought to do that in their heads. It saves space on the paper for more numbers.

Wow. If it is as bad as the author describes, Ballmer has designed the anti-dashboard.

The Presentation Zen blog offers another great example of organization culture as displayed in business artifacts:

Gates here explaining the Live strategy. A lot of images and a lot of text…Good graphic design guides the viewer and has a clear hierarchy or order so that she knows where to look first, second, and so on. What is the communication priority of this visual? It must be the circle of clip art, but that does not help me much.

Does it get more “Zen” than this? “Visual-Zen Master,” Steve Jobs, allows the screen to fade completely empty at appropriate, short moments while he tells his story.