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 recently came across a white paper on the "five styles of BI" and thought that would be an interesting read. As it turns out, more interesting than I expected. In this paper, the vendor (in order to protect the innocent, we'll just call them MacroTactics) made a statement regarding the performance capacity of this particular vendor's solution: 72,000 reports per hour. Let's see, 72,000 reports per hour... that would be 576,000 reports in an 8 hour day... and 149,760,000 reports per year. Wow. Who's reading that stuff?

Now, I fully buy in to the fact that applications that deal with lots and lots of data need to be hugely scalable, but what I don't buy is how this is in any fashion a measure that anyone can use to figure out if a particular BI solution is right for them. I can just imagine the requirements spec for that solution: "15.1.182.f - Solution must be capable of creating 70,000 reports per hour. Alternately, solution will be able to generate 140,000,000 reports per year." 140 million reports! Incredible. (Now, what did I do with my mini-me?)

Seriously, here's the thing. More reports is rarely the answer. We already have plenty of data and plenty of reports. What buyers and users really want is fewer reports and more information that helps them get their jobs done better and faster.

We'd encourage business intelligence vendors to think of themselves more as data storytellers than data factories churning out generic report widgets…even if they can do it at incredibly high speeds. From this perspective, you wouldn't want to hear Steven Spielberg bragging about his ability to pump out a dozen movies a year or J.K. Rowling trumpeting her ability to write 1000 pages a year (hmm, wait a sec).

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.

If you struggle to legitimize analytics within your organization, you can't touch this video for a powerful explanation of the impact of analytics:

MC Hammer at the AlwaysOn/STVP Summit at Stanford, "Music Artists Go Entrepreneurial." Around minute 24:00.