Category: Visual and Visible

The Challenge of Dashboards and Portals

by:   |  Posted on
“In the same way you can create a cost-effective kitchen from a standard components such as cabinets, islands and fittings, it is possible to combine building blocks to create an executive dashboard or enterprise portal to meet your particular needs.”

Executive Dashboards present an interesting array of design challenges ranging in all areas of user experience. Take your pick from a list that includes information and interaction design as well as information architecture. Add to that the business of creating information architecture that can provide a structure for growth and evolution. These challenges will be addressed in a six-part series over the next few months. The first article looks at problems facing dashboards which can be addressed by using a system of components that fit together to form a whole. Much like IKEA uses interchangeable islands, counters, and cupboards to create a custom kitchen, by using a system of tiles, it is possible to create an executive dashboard that effectively serves all its users.

The executive dashboard is a portal that combines business intelligence systems and browser-based applications to summarize the status of a complex enterprise for senior decision-makers. Like all portals, dashboards integrate a variety of content and functionality. Integration lowers the acquisition costs of finding items from multiple sources. It also increases the value of each individual tool and content asset through grouping to help decision-making and understanding.

But integration may also emphasize the differing, and sometimes conflicting, origins of the content, highlighting differences in the contexts, forms, and behaviors of dashboard offerings. The challenge is to create an effective user experience unifying these variations into a cohesive whole while preserving the meaning and identity of the individual assets. These challenges exist in all areas of user experience, from information design and interaction design to information architecture. Establishing sound information architecture capable of providing a consistent structure for growth and evolution for dashboards is particularly challenging.

Portlets: MIA (Missing Information Architecture)

The portal paradigm (collections of individual portlets in a single environment) is, so far, the most useful and familiar approach to these user experience challenges. I call it the “box of chocolates” model, because it packages a large number of different elements, while keeping each piece in its own compartment. The portal paradigm has two great strengths. First, it is a simple design approach, easily understood by users, business sponsors, and development teams. Second, it addresses many of the user experience design challenges associated with dashboards. It does this by breaking large collections of widely varying content into a series of well-defined and self-contained units. These units then present individual problems of information design and interaction design which can be solved one at a time, independently. It’s a classic divide-and-conquer strategy that is successful because it is so simple.

From the perspective of information architecture, however, depending on compartmentalization and self-containment is not a complete solution. In the short term, separating items in this way helps manage some of the user experience complexity. Over the long term, it results in two significant weaknesses.

First, self-contained portlets cannot be combined easily to address the need for larger and more flexible communication, beyond the single chunk of information. Portlets are a one-size-fits-all solution to the many-sizes-at-the-same-time problem. The goal of a dashboard is to synthesize disparate information, at multiple levels of granularity and size, into meaningful packages that can be shared among leaders, each with their own perspectives. Facilitating such communication is a primary purpose of most executive dashboards.

Second, portlets are inherently flat, or two-dimensional. Flat portlets alone cannot provide a scalable, adaptable framework for growth and change within a consistent information architecture. Two-dimensional portlets will work is cases where information architecture is not a challenge (i.e., when a dashboard shows a small set of critical key performance indicators or functions to a select audience on a single page or screen) But as the amount of content and functionality (hereafter referred to simply as “content”) grows, the number of portlets increases. This is often the case with many successful enterprise portals and executive dashboards. As word spreads about the usefulness of the dashboard, new audiences and users with differing information needs will join the early adopters, challenging the single view of the dashboard’s range of content offerings.

Dashboard teams may face issues of poorly integrated or conflicting content, reduced usability, navigability, and findability, and a poorer quality user experience. Portlets can only deal with unmanaged growth by sprawling horizontally. Though convenient in the short term, flat portlets lack the capability to provide useful and adaptable structure in the long term. Such horizontal sprawl is similar to the real world example of unmanaged residential growth around major cities – a pattern resulting in urban sprawl, traffic congestion, social isolation, and high ecological impact combined with low energy efficiency.

Escaping flatland

“Building blocks offer standardization, modularity, and interoperability at multiple levels of the information environment, as well as in the user experience.”

After encountering these weaknesses in a number of dashboards, I developed a simple set of information architecture building blocks to introduce depth and structure to flat dashboards. These building blocks allow for the rapid creation of larger units of content from smaller chunks of information, and support the goal of easily managed enterprise IA. The building blocks offer design teams modular information architecture components designed for assembly into larger combinations that scale effectively and respond to change. In the same way that you can create a unique but cost-effective kitchen from standard components such as cabinets, islands, fittings, and appliances, you can combine these building blocks to create an executive dashboard or enterprise portal that meets your particular needs.

The basic building block is a flexible component called a Tile. Tiles combine with other Tiles and building blocks to form larger, more complex units for content and functionality. Tiles and the other building blocks simplify the addition and removal of content, provide a basis for access and security controls at all levels, offer standard metadata attributes to simplify syndication and semantic issues, and make it possible for users to move about within the dashboard using consistent navigation flows. Together, the building blocks provide a sound information architecture for content required by business and a means of managing growth and change. Building blocks offer standardization, modularity, and interoperability at multiple levels of the information environment, as well as in the user experience.

Here’s an example of a complex dashboard designed with the building block system. The image shows a portion of a business intelligence dashboard displaying content related to products sold by the U.S. subsidiary of a global pharmaceuticals company. Many of the different building blocks appear in this single screen: a Section Connector, a Page Connector, a View, Control Bars, several varieties of Tiles, Utility Navigation, and Convenience Functionality. Present but not visible are common metadata, access definitions, and other infrastructure attributes. This screen illustrates several of the basic guidelines and principles of the building block system: openness, inheritance, independence, and layering. This screen also shows effective stacking of smaller building blocks. In this case, several Tiles are stacked within a View, which is itself part of a Page, to create a larger unit of content available for syndication to other enterprise systems.

us_products_1_example_thumb.jpg
Figure 1: Example Dashboard Screen, Products Page (Click to enlarge.)

us_products_example_callouts-1_thumb.jpg
Figure 2: Dashboard Screen: This overlay outlines the individual building blocks that make up the Products page (Click to enlarge.)

A vision: syndicated assets for enterprise portals

The building blocks provide a strong foundation for the executive dashboard as an individualized console or executive information system. They allow the dashboard to offer different users a tailored subset of a larger pool of shared information and functionality assets.

This vision is based on a collection of building blocks for sharing and syndication: a Tile Library. Because the blocks represent standardization across many levels of the information environment, the Tile Library itself could take form at one or more of these levels. In enterprises lacking information infrastructure (such as a robust integrated enterprise applications layer or a strong semantic framework of enterprise metadata), the Tile Library might exist as a set of defined UX and IA blocks requiring custom technical design and system integration efforts. In enterprises with stronger, more mature information infrastructures, a Tile Library could take the form of a repository of building blocks users may access as services and assemble into new configurations labeled Dashboards, Enterprise Portals, or something else.


Figure 3: Tile Library

When used in environments with infrastructure capabilities such as single sign-on, distributed security and access management, discoverable web services, and integrated enterprise applications (EAI), this system of building blocks allows sharing and reuse of defined blocks among applications of all sizes and complexity. Widespread adoption and implementation of web services, XML, enterprise metadata, and enterprise security protocols make this both possible and practical.


Figure 4: Vision: Shared Enterprise Assets / Tile Library

In this vision, the dashboard is the conduit through which a consumer can access and manipulate assets from a common library managed and governed as an enterprise resource. It is possible to imagine an integrated suite of dashboards relying on common architectures (information, user experience, and systems) and coordinated management or governance apparatuses working together to satisfy the needs of a diverse enterprise leadership.

This is the first in a series of articles about executive dashboards and portals. Part two will address, in detail, the use of Tiles as bulding blocks for an effective enterprise portal.

Icon Analysis

by:   |  Posted on

“She gave up the search for the mouse settings icon in seconds and opted to just use the ridiculously over-sensitive mouse.”

An icon search task that lasts longer than anticipated can result in user annoyance or even premature abandonment. I once changed the mouse settings on my laptop to be overly sensitive, and had a colleague use it to show me a data analysis technique she had been working on. She immediately noticed and asked permission to change the settings. At my resolution of 1400×1050, the icons in the Windows control panel folder render at 16×16 pixels. In addition, I had the list pre-sorted by comment rather than application name. Not used to these settings or dealing with mouse preferences, she gave up the search for the mouse settings icon in seconds and opted to just use the ridiculously over-sensitive mouse while demonstrating her analysis technique.

You may think she was justified if only using my system for a short time. If so, you’d be surprised to know this was no small demo! It went on for almost a half an hour. She surfed the web to retrieve various files, used several applications, accessed her FTP space to download some of her own work, and showed the technique twice with different sets of user data. Scientist and user throughout, she sprinkled obscenities about the mouse amongst her thoughtful discussion of data analysis. I was astonished, and now far too afraid to tell her I had fooled with the mouse on purpose.

Two weeks later, I was discussing the analysis technique with another coworker and he said, “By the way, I heard your mouse is all messed up. I can fix that if you want.” Bad human computer interaction (HCI) experiences travel fast! The issue could have been avoided if only the mouse settings icon had been more identifiable.

Inability to discriminate one icon from another and/or find an icon in a set can be far more disastrous than my anecdote above. Systems used by first responders in hazardous materials incidents (see MARPLOT, for example) rely on icon design to signify entity classification (e.g. small icon of a schoolhouse) and level of critical danger to an entity (e.g. a school icon is painted red on a map). Immediately recognizing danger to a school amongst lumber yards, garbage dumps, and plant nurseries is imperative; any time-slip in the search and discrimination task could delay notification and evacuation of hundreds of children. How then can we diagnose problems with icons that fail in this regard?

Search and discrimination of icons

The human visual system is a complex mechanism that encodes information using many channels in two major pathways. The magnocellular pathway (M pathway, or “big neurons”) contains channels sensitive to gross shape, luminance, and motion. The parvocellular pathway (P pathway—“small neurons”) contains channels sensitive to color and detailed shape (Nicholls et al, 1992). In order to discriminate between two different visual signals—icons, in our case—the signals encoded in available channels must differ beyond some threshold. A common distinguishing technique is color. For example, try to find the red network settings icon on the right in figure 1.

icon_analysis-fig-1_th.jpg

Figure 1: Original icon list shown in the Windows control panel (left) and the icon list with the network icon highlighted red or feature-based search (right). Click to enlarge.

Searching by some distinguishing feature like color is called (not surprisingly) a feature-based search. Feature-based searches are limited in a few ways: their effectiveness drops if we apply a unique color to all icons in the image set and distinguishing by color only employs purposeful differences in only one of the two visual pathways (the P pathway). Additionally, icons tend to be small in a UI, thereby restricting differences in shape to “detailed shape” information—also encoded in the P pathway. Ideally, we would like to design icons that purposefully differ along channels in both M and P pathways.

Fig 2

Figure 2: Original Network Connections Icon with constituent M and P pathway representations.

An elegant technique to do this involves leveraging the core difference between the pathways. Large neurons are less densely packed in the retina of the eye than small ones. The spatial density leads to fundamentally different encodings of the visual image. Figure 2 shows an image of an icon that has been filtered to simulate the way it would be encoded in the M and P pathways.

Images filtered in this manner can be judged for distinctiveness along 2 pathway dimensions, assisting in economy of discrimination and search tasks. Distinctiveness in P pathway representations is easy enough to judge without the use of filtering techniques; designers weigh color and detailed shape decisions directly during the design process. The only tool a designer has to judge M pathway distinctiveness is the “squint test” (i.e. squint your eyes to obstruct sharp focus and rely mostly on dark and light values). However, the squint test is not very practical for HCI and Usability assessments; spatial frequency filtering is a better tool to simulate M pathway representations of icon images for evaluation purposes.

Spatial frequency filtering

The visual system maintains a set of scales that we associate with distance. If we see an object thought to have great size—say, a building—but that takes up little space on the retina (i.e. it looks very small), we immediately “perceive” it as being far away rather than perceiving it as a miniature building. The perception of scale is actually based on the encoding of visual spatial frequency (Schyns & Olivia, 1994).

This is interesting because you can encode images in specific spatial frequencies (Schyns & Olivia, 1999). View figure 3 from a foot away. Now stand back and view it from farther—say, 10 feet. Up close it is difficult to make out the image of Bill Frist in the center image. From farther away the image of Hillary Clinton disappears altogether in the center image. However, at both distances the outer images of Frist and Clinton are easily discernible. This phenomenon is based on our inability to perceive high frequency information from greater distances; if the image has no distinctive low frequency component, it simply disappears when viewed from a distance.

Fig 3

Figure 3: Hillary Clinton (left), frequency composite of Hillary and Bill Frist (center), and original Bill Frist image (right).

Not surprisingly, we hold specific spatial frequency registers for icons. Just as the color and shape choices for an icon design should be unique, so too should the frequency composition of the design. When a user searches through a UI in order to compare or find icons, his or her eyes jump all over the screen. Where eyes land are called fixation points, while the sharp eye movements are referred to as saccades. Users only see roughly 1.5 degrees of visual angle in sharp focus (roughly the size of your thumb nail held at arms distance); the rest of the image is processed in the M pathway and at lower spatial frequencies. At each fixation point, most of the icons in a UI fall outside of 1.5 degrees. The key is to filter the icon images to ensure that they differ in low spatial frequency so as to preserve their uniqueness during visual search. (Filtering methods discussed here are based on the work of Loftus and Harley, 2005, who used filtering to create representations of faces at a distance.)

The technique I show here requires the use of the R package (R Development Core Team, 2005) and the add-on package called “rimage” (Windows, Linux, and OSX versions are available here). Once you have downloaded and installed R, you can download and install the “rimage” addon from within the R program. (On Windows: Start R, then select packages » Install package(s). Choose a mirror from the dialog. Then select the “rimage” package.)

Filtering instructions

After the R program is set up and the rimage package has been installed, you are ready to start. Collect a set of icons you wish to analyze and put them all into a single image using your favorite image editing program, as shown in figure 4. Save the image as a jpeg.

Fig 4

Figure 4

Start the R program. Load the rimage library and the icon collection image into R using the following commands in the console window:

<br /> > library(rimage)<br /> > icons <- read.jpeg("address to your file”)<br />

Where “address to your file” is the full directory address where you saved the icon collection image. Make sure to enclose the address in quotes and use “/” instead of “” to signify subdirectories. Mine looks like this:

<br /> > icons <- read.jpeg("C:/Documents and Settings/Queen/My Documents/icon-collection.jpg”)<br />

Press Enter and then view the image in a display window by typing:

<br /> > plot(icons)<br />

Resize the window so that the images are full scale and not distorted. Now we’ll filter the images:

<br /> > plot(normalize(lowpass(icons,27.8)))<br />

Fig 5

Figure 5: Filtered icon set

Some explanation is necessary here. The number 27.8 defines the radius of the frequency filter in frequency space. I’ll spare you the math lesson and give you a short table of calculations that solve for radial lengths based on user distance from the screen (calculations based on size-distance-invariance equations; see Gilinsky, 1951).

 Icon Pixel Dimensions   Viewer Distance   Radius 
128×128
128×128
128×128		 18 in.
24 in.
36 in.		 98.8
74
49.4
48×48
48×48
48×48		 18 in.
24 in.
36 in.		 37
27.8
18.5
32×32
32×32
32×32		 18 in.
24 in.
36 in.		 24.7
18.5
12.3
16×16
16×16
16×16		 18 in.
24 in.
36 in.		 12.3
9.2
6.2

Using this table, you can see that I chose to assume the icons are 48×48 pixels in dimension and the viewer is 2 feet from the screen. As a general practice, filter the icons using all settings that might actually occur at use time and make sure that icons remain sufficiently unique (there are no studies that elaborate on what is sufficient—so be overly cautious).

I feel compelled to note that spatial frequency filtering is very different than just blurring the image; blurring removes detail that the M pathway relies on for recognition. Figure 6 shows the very different results of frequency filtering and blurring.

icon_analysis-fig-6_th.jpg

Figure 6: The filtered image (left) is far more representative of what a user actually sees than the blurred image (right). Extreme differences can be seen in icons with tight detailed patterns such as the second icon on the bottom row. Click to enlarge.

How effective are spatial frequency unique icons?

The following is a short study showing the benefits of using icons that have unique low spatial frequency compositions. 10 users were shown 20 icon images (called “trial icons”) of varied size. Simultaneously, they were presented with two additional icon images and asked to click on the icon that matched the trial icon, as shown in figure 7. Response times were recorded. The idea was to see if low frequency unique icons were easier to identify, and therefore result in faster response times.

Fig 7

Figure 7: Experiment screenshot

With each presentation of a trial icon, the match icon (fig. 7 – right) and distracter icon (fig. 7 – left) had either similar or different low frequency compositions. The response time data was then analyzed to determine if having all 3 icons contain similar low frequency compositions slowed responses. If responses were slower, the match icon was assumed to be more difficult to identify. A box plot of the resulting dataset is shown in figure 8.

Fig 8

Figure 8: Dataset box plot

As you can see, on average, users identified icons with unique low spatial frequency compositions faster than those with compositions similar to distracter icons. In fact, 75 percent of the time the fastest response times under normal conditions were just about average when frequency differences were present. The frequency-unique icons result in almost a half-second faster identification times. Summing that difference for every icon search task during use-time adds up to quite a bit of what could be critical decision-making time. Unique low-frequency compositions in icon designs make a noticeable difference.

References

  • MARPLOT: http://archive.orr.noaa.gov/cameo/marplot.html

  • Nicholls, J.G., Martin, A. R., and Wallace, B. G. (1992). From Neuron to Brain. Sinauer, 3rd edition.

  • Schyns, P.G., Oliva, A. (1994) From blobs to boundary edges: Evidence for time and spatial scale dependent scene recognition. Psychol Sci 5:195–200.

  • Schyns, P.G., Oliva, A. (1999) Dr. Angry and Mr. Smile: when categorization flexibly modifies the perception of faces in rapid visual presentations. Cognition 69:243–265.

  • Loftus, G. R., & Harley, E. M. (2005) Why is it easier to identify someone close than far away? Psychonomic Bulletin & Review, 12(1), 43-65.

  • Gilinsky, A.S. (1951) Perceived size and distance in visual space. Psychological Review, 58, 460-482.

  • R Development Core Team (2005) R: A language and environment for statistical computing. R Foundation for Statistical Computing, Vienna, Austria. ISBN 3-900051-07-0, http://www.R-project.org.

Ads Are Here To Stay: Planning For Ad Placement

by:   |  Posted on
“What must be developed… is not a way to make ads go away, but rather a better way to incorporate ads and ad content into our sites.”Ads: IAs dislike ’em; I dislike ’em. And, as an information purist, I believe everyone dislikes ads. They interfere with navigation. They flash annoyingly. They disrupt the flow of content, awkwardly placed, as so many of them are, right in the middle of the content we want to read. Even worse is when they have been somehow blended into the content, as if we wouldn’t notice. Ads, in short, dilute content and diminish the effect of a page.

This interference can be especially frustrating for IAs. We spend time architecting a page that will meet user needs in the best way possible. We’ve done user research. We’ve understood business models. We’ve brainstormed. We may even know that a page has to support ads, but if you’re like me, you try to place them somewhere out of the way, like the bottom of the page. And then the dreaded moment occurs, probably at the final schematic review, when the marketing director or some other important stakeholder looks at the page, searches in vain (ignoring all your fine work), and finally points to the top of the page and says, “We need an ad right there.”

What’s an IA to do?

The bad old days

In the bad old days (the not so distant past, actually), the design team swallowed their pride and agreed to do what our imagined marketing director asked of them. We grumbled, but in the end, whoever was responsible for the profitability of the project soothed our wounded egos and directed us to place the ad in the exact spot we had so astutely avoided placing it.

Whether it was a banner ad, skyscraper, pop-up, roll-over, or some other new-fangled advertorial innovation, we accepted our fate and placed the ad. Months later, when the site was launched, we could only cry as we navigated to our beautifully designed, and cruelly despoiled, pages.

I wish we could say that things have changed dramatically since then, but they have not. Advertisers still think up wonderful new ways to draw attention away from a site’s content to their content. And business models are still created which rely on advertising revenue for a site to be “successful.” The truth of the matter is that ads may never go away. If anything, the prevalence of online advertising is growing.

Just consider these facts.

  • The second quarter of 2004 saw record revenue growth for online advertising at $2.37 billion.1
  • Online advertising now accounts for 5.4 percent (or $8.7 billion) of ad spending in America, and 3.6 percent globally.2
  • Twenty-five percent of Ford’s Lincoln Mercury ad spending is going online.3

Add to that the perception among advertisers that online advertising is one of the best ways to reach adults,4 and one is inclined to conclude that online advertising is here to stay. What must be developed then is not a way to make ads go away, but rather a better way to incorporate ads and ad content into our sites.

Strategies for presenting ads

Fortunately we are not alone in our understanding of users’ feelings about ads. Advertisers, while not having our background, do understand that many web users are not all that happy about having ads on the internet, and that too many ads can ruin a page and dilute their own advertisement. Success is often measured by click-through rate, and advertisers now seem to understand that improving the user experience of ads can improve their own success. The success of contextual, text only ads should be noted (40 percent of online ad revenue is generated by search related advertising5).

What follows is a list of some strategies and guidelines for presenting ads on a page. These approaches will undoubtedly become more sophisticated as the possibilities, and variability, of online advertising grows. The Interactive Advertising Bureau (IAB) has put together a list of standards and guidelines for presenting advertising on the web, and is dedicated to educating people on how to advertise online. Instead of addressing these standards in this article, we would like to address their information architecture—how they fit into a larger page-level and site-level system.

Accordingly, the terms “success” and “failure” when used below refer not to the financial success or failure of an ad presentation strategy, but the user experience success or failure of an ad presentation strategy. As to which definition of success or failure is more important, I’ll let others debate.

1. Wrap the ad

Wrapping, or identifying your ad, is really a call-out indicating that what is in the box is an ad. A wrapped ad is really just a nice way of saying to the user, “Look! This content? It’s not our content. It’s someone else’s, and they paid money to have it here. Go ahead, look at it if you want, but know what it is you’re looking at—an ad.”

The visual design of the wrap should be consistent across the site. The design of the wrap generally never competes with the ad or with the design of the site. The text may be grayed, for example, but it is enough to be a consistent indication to the user.

Ad wrapping is appropriate for most types of ads, but most commonly seen with rectangles, buttons, and, skyscrapers.

wrap.jpg

2. Cluster the ads

An alternative to wrapping your ad is clustering several ads together. With this approach you indicate to the user that this area has been set aside for ads. In this example, the right hand side of the page has become an “ad zone,” and the user can see it for what it is, and then concentrate on the content in the center of the page.

In order for this strategy to be “successful” all, or almost all, pages on the site must have the same area set aside for ads. In general, the types of ads clustered together tend to be either skyscrapers or buttons.

A distinct drawback with this approach (and perhaps why one doesn’t see it too much) is the possibility that a line of ads can become like a row of Las Vegas slot machines – lots of blinking and distraction. One way to deal with this is an ad styleguide, addressed later, but advertisers do not always follow the guidelines set out for them.

Another “drawback” to this strategy is that you’ve lost the right-hand column as a space to put content.

cluster.jpg

3. Use leaderboards

“Leaderboard” is an IAB term, and refers to an ad that is placed at the very top of the page. It is larger than a banner (728 x 90 vs. 468 x 60 for a “full banner”), and its use appears to be more and more popular these days. The advantage of the leaderboard is that it gives the advertiser prime space, but also moves the ad out of content’s way.

Of course, the problem with the leaderboard ad is that it pushes the page down, moving more content below the fold.

An additional leaderboard may also be placed at the bottom of the page, but most advertisers may consider this space to be undesirable.

4. Use multiple layouts

Varying the layouts on different pages will help allow for the best accommodation of ads for the type of content that is being presented. The homepage, for example, will demand one layout, while a content page may demand another.

home.jpg
Homepage

content.jpg
Content Page

This can help avoid a certain sameness across a site while giving advertisers the options they crave. However, whatever ad layouts you choose, they should be standardized into a system that advertisers can understand and rely on.

The same template can also have variations that allow for different ad sizes. This allows for the content creator to select a layout that works best for the content, and then ad placement and sizes will conform to that layout. Advertisers also find this option appealing since they can track which ad layouts are the most successful.

5. Place the ad beyond 800 x 600

Another strategy that may be less popular with advertisers but can help the page retain its cohesiveness is placing the ad outside of the 800 x 600 area. This allows the page to retain its cohesiveness, and the content to take center stage, especially for those users who have limited desktop space to begin with.

In my experience advertisers tend not to like this option since the ad may not be seen by all users. However, other IAs have related that they are beginning to see this type of ad more often. It may be that as a greater percentage of users move beyond an 800×600 screen resolution it is becoming less of a worry for advertisers.

multiple.jpg

6. Hold firm on pop-up ads

The pop-up ad is still a no-no, especially if it pops up behind the browser window (a “pop-under”). These types of ads are the most distracting and disrespectful to users and should be avoided at all costs. They also happen to be among the most annoying ads, perhaps because they are not actually near any content that a user might want to read, and are instead off by their lonesome, desperately trying to get your attention.

Although I have no statistics to bear this out other than my own observations, it does appear that pop-up ads are beginning to become a thing of the past. Pop-up blockers are certainly part of the reason for this, but we like to think that advertisers are beginning to realize that extremely annoying is less effective than mildly irritating.

However, if you are forced to use a pop-up, or pop-under, then at the very least follow the guidelines set out by the IAB.

7. Create guidelines: the ad styleguide

An ad styleguide is similar to a styleguide that one might create for a site, except the audience is not content creators, but ad creators. The desire for an ad styleguide stems from the fact that advertisers often have their own interests in mind before that of the content. The result is an ad that competes with your content for the attention of the user, and advertisers do this by making the ad animated, or flashing, or by begging the user to click on it for some special service.

An ad can also ruin the effect of a well-designed page. Pages are normally designed to emphasize the most important content elements, but a “well-designed” ad can ruin even the best page designs. Placing limits on what advertisers can create to insert in your site will make for much happier content producers and much happier users.

However, as mentioned above, advertisers will push the boundaries of what is acceptable, and following this strategy means that the ad sales team must enforce the styleguide, otherwise the situation will quickly degenerate.

8. Check the business model

While advertising is certainly a revenue generator, it might please you to know that much of the world, including content producers, would probably be happier with fewer ads, or generating revenue in other ways than selling ad space next to their content. The ad sales department might object, since their year-end bonuses often depend on how many ads they place, but businesses sometimes do consider other ways of generating revenue from content.

As the IA, it is important, and even refreshing, to be a part of this conversation. From a business point of view, ads often have a limited upside. After all, page real estate, while theoretically limitless (a page could scroll forever), is in reality finite, and often advertisers will want a limit to the number of ads on a page so that their ad is not competing for “eyeballs.” This means that the smaller your site is, the less money you can possibly make, and the more likely you are to be motivated to monetize your content in new ways.

While a new business model probably will incorporate ads to some degree, removing ads as the sole source of revenue for a site will make it that much harder for the ad sales team to argue for “top billing ” on your templates.

Strategies involving contextual ads

In the spirit of “if you can’t beat ’em, join ’em,” contextual ads use external inputs to try to blend in better with the content and, it is hoped, with the interests of the user.

9. Take advantage of text-only ads (ala Overture and Google)

Most users should be familiar with the text-only ad. This was popularized by Google AdWords and allowed advertisers a way to capture some of the huge amount of traffic that comes to Google every day, and also allowed Google to monetize their search engine.

Text-only ads, as their name implies, have only text within the ad space, and tend to be generated by a keyword either entered by the user, in the case of search, or a keyword provided by the content, such as a metatag keyword. The resulting links presumably fall in line with not only what you’re interested in, but also the content on the page. The user then, the theory goes, will be less annoyed because the links have a legitimate reason to be on the page.

They are most commonly spotted on search results pages and they are far more effective than your typical banner ad.1 The danger with these ads is that they may be used in place of real content. In this example from abc.com, the abc.com search results don’t appear until far down the page-certainly below the 600 pixel mark-under the sponsored results section.

This suddenly makes search far less useful.

10. Personalize the ad

Similar to text-only ads, responding to a search or metatag keyword, the traditional ad can now be coded to respond to the type of content the user is viewing, and to the type of user who is doing the viewing. If there is profile information available – say the user is registered on the site and demographic or psychographic information has been gathered on them – this information can be used so that the ad presented is in line with certain known information about the user. For example, if the user is from New York City, an ad might be selected promoting a Broadway show.

While these ads may still visually clash with the design and layout of your site, they do have the benefit of having a better reason for being on that page than an ad that contains random content. They also tend to be more popular with advertisers and marketers, and make the ad space more valuable.

How I learned to love the bomb

While ads, by their very nature, will always live in tension with the content they support, new strategies are being developed that can help satisfy the needs of users and advertisers. By thinking of ads not as those annoying flashing animations that distract the user, but rather as another content type with its own peculiar features that must be incorporated into the page, you can change your distaste of ads into an architecture challenge. This may not change how you feel about ads (and if you feel about ads as I feel about ads, you can always purchase Norton Internet Security which has an ad blocking feature), but it can change how you feel about the work you produce.

Successfully incorporating ads into a site is perhaps one of the most difficult challenges, not least because of the nature of the content itself. Ads are revenue generators, and the ad sales department will often make blanket demands about what ads sizes they want and where they should live on the site. Balancing these demands with user needs can be difficult, but using some of the above-mentioned strategies can increase your chance of success.

 For More Information:
 1 IAB Internet Advertising Report Revenue Report
 http://www.iab.net/resources/ad_revenue.asp

2 The Economist December 29, 2004 “Back on the up.”
http://www.economist.com/displaystory.cfm?story_id=3523042

3 IAB Internet Advertising Report Revenue Report
http://www.iab.net/resources/ad_revenue.asp

4 “For advertisers who want to reach employed adults during the day, the Internet offers an unprecedented opportunity, with 50 million people regularly online at work,” says eMarketer CEO Geoff Ramsey. “There’s a virtual elephant in the room — one that astute marketers can no longer choose to ignore.”
http://www.emarketer.com/Report.aspx?atwork_feb03

5 IAB Internet Advertising Report Revenue Report
http://www.iab.net/resources/ad_revenue.asp

6 “Roughly 15 percent of ads displayed adjacent to Google searches (at the company’s own Web site and on Google-powered sites like Yahoo! and AOL) result in clickthroughs – more than 10 times the click rate of the average banner ad.”It’s an Ad, Ad, Ad, Ad World,” Josh McHugh.
http://www.wired.com/wired/archive/12.03/google.html?pg=8

2005 Online Media Outlook
http://www.avenuea-razorfish.com/OnlineMediaOutlook.pdf

Special thanks to Liz Danzico for finding some of these examples of ad displays.

Alex Kirtland is a Senior Information Architect and Experience Lead and is currently working as a freelance consultant. He has worked with a variety of companies and organizations, including Kodak, Verizon, Avaya, Western Union, and the Federal Reserve Bank of New York. He has experience with a diverse set of project types, from executive dashboards to metadata strategies to recipe finders. Most recently he has helped the Rodale Press redesign their online magazines, including MensHealth.com. If you want to learn more about him please visit his website www.alexkirtland.com.

Executive Dashboards

by:   |  Posted on

Contrary to first impression, an “executive dashboard” is not found in a CIO’s car. Rather, an executive dashboard, also known as a manager dashboard, executive cockpit, or digital cockpit, is a child of what in the 1980s was referred to as the Executive Information System (EIS). These systems, and their web-based progeny, all have the same goal: bringing critical information to decision makers and improve the performance of their business.

“Companies are finding it’s much better to allow a manager to make an immediate decision in response to a market opportunity than to force him to wait for the CFO…“Who uses them and why?
An executive dashboard (referred to as “dashboard” for the rest of this article) is an intranet for a select group of users. These users tend to be executives—VPs and above, the people who are the main decision-makers in the company.

However, not all new dashboards are for executives and their ilk. As organizations push to become more nimble (and hence more competitive), dashboards are now being developed for managers of all stripes. When developing a dashboard, don’t be surprised if you hear phrases such as: “Every employee a CFO.” These reflect a realization by companies that faster decision-making helps them succeed. This means giving managers the ability to make decisions on their own. Companies are finding it’s much better to allow a manager to make an immediate decision in response to a market opportunity than to force him to wait for the CFO, or some other executive, to be alerted to the opportunity and then make a decision.

A dashboard supports a manager or executive by doing three things:

  1. It answers fundamental questions about the business or business unit.
    The dashboard should answer basic business questions: fundamental questions about the health of the business that can be financial, operational, or comparative in nature, such as:
    • Did I reach my sales numbers this month?
    • How many widgets did we sell in China last year?
    • How many widgets are we producing per month at the Chicago factory?
    • How often do employees call in sick at our Miami store? On what days are they most likely to call in sick?
    • Is revenue growing on a month-to-month or week-to-week basis?
    • How am I doing in comparison to my competitors?

    These sorts of questions can often take a full-time administrator and several spreadsheets to answer. Currency of information is important, but not as important as having the right information.

    Each particular executive or manager will have their own statistics (called Key Performance Indicators, or KPIs) that are important to them, but often companies will also have a standard set of measures that has been applied across the organization. This eases comparison of managers and executives to one another. Basic KPIs can be combined to form a scorecard, and organizations that have a scorecard likely will want it to be a part of their dashboards.

  2. It alerts the user to issues or problems in such areas as production, sales, and revenue.
    Closely related to the first point, a dashboard should alert the executive or manager when something goes wrong. How an “alert” is defined is based on the needs of the business. Some example alerts would be:
    • A product defect rate is going above an acceptable level.
    • Absenteeism is becoming a problem at a particular store or factory.
    • Average delivery time is falling below normal.
    • Sales targets are not being met.
    • Operational expenses are growing beyond an acceptable rate.

    Every dashboard needs to have an alert system that communicates when a critical figure has been passed or is about to be passed. In this case, currency of information is extremely important.

  3. It helps make decisions that impact the business.
    Finally, the executive or manager will use the information from a dashboard to make decisions. Sometimes these decisions can be very straightforward and can be answered by a single KPI, but more often business decisions will be complex and require a variety of inputs. Examples of these decisions are:
    • Do I increase or decrease production?
    • Do I need to change my product mix to be more competitive?
    • Should I close shop in Des Moines?
    • Do I need to hire more salespeople?
    • Why is the business not growing as fast as planned?

These types of questions require the ability to explore a series of KPIs. Also, they require drilling down into figures based on time or region, or selecting and comparing variables. In this case, it is important that the information is presented in a way that helps the executive or manager come to a conclusion about the issue they’re confronting, and construct a rationale to support the decision they make.

The backbone of the dashboard
The heart of any dashboard is the KPI. KPIs can measure all sorts of things, such as:

  • Inventory levels
  • Monthly gross profit
  • Sales revenue by business unit, by product, by region
  • Revenue forecasts
  • Top customers
  • Number of consultants engaged
  • Accounts receivable
  • Employee attendance rates

These measures can be financial or operational, but at the very least they should say something important to the user about the business. KPIs are most often presented in tables, charts, and graphs. Different executives and managers will need different KPIs to support their views of the business.

Data sources
For any project, understanding the technology is important. For a dashboard project this is doubly so. My advice is: become good friends with your technologists and understand as much as you can about what they’re doing.

The data for each KPI has to come from somewhere. For each KPI it is important to know:

  • Which system or database will provide the data?
  • What is the format of the data?
  • How the data will be abstracted from that system?
  • Will it be moved to a data warehouse or some other environment where it will be cleaned up and analyzed?
  • Will a person need to review the data before it can be disseminated?
  • How will the data be pulled into tables and graphs?

The source data will often be kept in a variety of places. Some of these will be operational systems, such as SAP or PeopleSoft, and some will be data warehouses. It is important for information architects to understand where the data is coming from, and how it is getting into the dashboard. Data accessibility will have an impact on how the dashboard is designed.

It can help reassure the street
As a side note, companies have also used dashboards in recent years as a way to tell Wall Street that their CEO and executive staff are aware of the financial state of the company.

CEOs are now expected to be responsible for the financial integrity of their company, and dashboards have been touted as a way to ensure that the CEO is aware of all financial aspects of the company.

Personalization/Customization
During the requirements-gathering phase of the project, executives and managers will voice the need for different KPIs. Also, based on their level within the organization, some information may have to be protected from some users. Information architects should have a clear understanding of these limitations to ensure that the right data is delivered to the right people.

Users will also want to customize the dashboard. The dashboard’s interface should also allow users to pick which KPIs they see first, as well as set their own alert levels. Users’ interests may change over time, and alert levels can change depending on the business environment. Pre-set alert levels should be programmed into the dashboard, if these are known, but unless the business requirements state otherwise, users should be allowed to change these to suit their situations.

Finally, the more robust portal servers will allow integration of other business systems into the dashboard, such as email, news feeds, and so on. These should be included, if possible, since they will only increase the value of the dashboard and the likelihood that the user will, in fact, use it.

Since not everyone is interested in the same set of KPIs, and since the structure of the company may require that some information is screened from particular users, a good portal server will be required, or a server platform that can provide similar functionality. If the company already has portal software, then it would be wise to take advantage of this.

Gathering requirements
Dashboard projects can sometimes move a bit slower than other projects because the target audience—executives, mostly—are harder to schedule time with. If the dashboard is for senior executives (the CEO, for example), then it will be very unlikely you will be able to interview your users (with the likelihood decreasing as the size of the company increases). Usually, at this point, the client will appoint someone to identify the needs of the senior executives, and he or she should be able to provide you with most of the information you need.

However, there are some other things you can do to help make the dashboard as useful as possible:

  • Interview administrative assistants and technical support staff.
    These people respond to the needs (and whims and desires) of executives on a daily basis. They will be able to inform you of how the executives like to get their information (print vs. screen vs. PDA, etc.) as well as what other sources of information the executive uses. Keep note of any failed information systems (there are usually a few) that were supposed to make the executive’s life better, but were accessed only once or twice for demonstration purposes and are no longer used.
  • Understand the business.
    While this should be true for any corporate web project, it is extremely important for a dashboard project. You’ll want to know more than just what products and services the company sells, but things like:

    • What are their lines of business?
    • How do they report revenue?
    • Is the company is growth mode or managing for profitability?
    • What is the company’s overall business strategy?

    If the company is public, read the annual report, or go to Yahoo! Finance and review the company information. Since executives are usually striving to please shareholders (and increase the stock price), it’s important to understand how investors look at the company, and what the major issues are, such as problems with debt or flagging product sales. This will help give context to the KPIs executives will ask for.

  • Be aware of similar but different KPIs.
    You should be aware that, especially in large organizations that are the result of several mergers, a KPI may have been created in one group that is similar to, but not exactly like, a KPI generated in another group. For each KPI it will be important to know how it was generated, how long it has been around, and the exact formula used to generate the KPI. If you are merging two KPIs into one, understand how the KPIs are similar or different, and what the effect of losing one of these will have on an executive or manager.

    Balancing these needs can be politically tricky, but should be manageable.

  • Consider access issues.
    Access issues are important to consider especially when creating a site for users who are almost always pressed for time, as executives and senior managers generally are. To ensure your dashboard gets used, spend some time during the requirements-gathering phase to understand how executives currently get the information that will be newly presented in the dashboard. Understand what they like and dislike about how they get the information.
  • Choose an effective delivery system.
    A dashboard can have amazing information design, a smoothly functioning back end, and can satisfy every whim and desire of the executive, but it still may not be used because the executive or manager travels so much they only use their wireless handheld, or because they’re used to reading everything on paper, or because their administrative assistant doesn’t know how to find it and therefore doesn’t open it up for them.

    Also, don’t underestimate the power of having reports hand-delivered. For people who have an enormous amount of information to look at, printed reports is one way of controlling that flow. When interviewing an executive’s administrative assistant, ask them about the best way to deliver the dashboard to ensure it gets used by the executive.

  • Plan for security.
    Given the type of information that is being displayed, security will play a big role in the development and design of the site. There will be two aspects of security you will need to confront: who gets to see what; and how is the site protected. Personalization will allow you to control who sees what (see above), but controlling access to the site also needs to be considered.

    The best is to take advantage of a current Single Sign On (SSO) solution, if one has been developed, or use the network login, if that is possible. Otherwise, one is faced with having to generate a new set of user names and passwords for users to memorize. Given that most of these users are pressed for time and already overwhelmed with systems that are supposed to help them, a new set of user names and passwords can severely hamper the success of a new dashboard.

    Balancing security concerns and ease of access concerns may confront you with some tough decisions. Try and resolve these issues as soon as possible in the project.

    • Understanding the technology
    A large part of ensuring the success of a dashboard project will be getting the technology right. As an IA, you will probably not be expected to manage this part of the project, but it will be critical that you understand the possibilities and limitations of technology. The following are some things to keep in mind.

    Business intelligence
    Business Intelligence (BI) is an area of technology that is concerned with gathering and analyzing financial and operational information. Most likely, the systems from which data will need to be extracted are BI systems. It is also likely that there will be other BI projects with which the project team will have to coordinate. These projects are normally managed through the technology department.

    There are many companies that provide systems and software for the BI space, and they all offer a variety of features. Some of the players currently develop systems to manage business information, such as SAP, PeopleSoft, and Siebel. Others develop data warehouses and analytic tools such as data-mining tools. Some of the players here are Oracle, Hyperion, Cognos, and Business Objects. This is by no means a complete list, and each vendor offers a different set of capabilities. Most have some sort of dashboard offering that is tied into their own system.

    However, the information needed to create an effective dashboard rarely lives in just one system or database. Most organizations use a variety of these systems and may even have a few home-grown solutions as well, including Excel spreadsheets. On a recent project, the client captured much of their financial information in Hyperion Essbase, operational information in SAP, and sales information in Siebel.

    Moreover, many of these systems are not known for their ease of use. Often they present too much—or too little—data, and sometimes they are not customizable by the user. The graphs themselves may be confusing.

    Real-time data
    At some point you will have to define what you mean by real-time data. Very rarely will this mean instantaneous data. Often, data is exported out of one system and into another on a daily or weekly basis. Financial figures are revised often, and sometimes only reported on a weekly basis. Sometimes there is data manipulation that needs to occur to bring the data into the right format. Almost always, companies are tinkering with their data systems in an attempt to improve or consolidate them. All of this will have an effect on the accessibility of data, and how current it will be when it is abstracted.

    Understanding exactly what information the executive or manager needs, and why they need it, will help you make a decision on how current the data needs to be on the dashboard. Sometimes data that is a little older may even be better, since the executive or manager will have more faith in its reliability.

    Reporting software
    Before designing functionality for the dashboard, it is best to understand which charting software will be used and how it will impact chart and graph design. Many BI systems will export tables and graphs that can be pulled into a dashboard. Crystal Reports is a popular charting option, but there are many other providers of charting software such as JFreeCharts, Big Charts, and Object Planet’s Easy Charts. All of these charting programs have benefits and drawbacks, and all of them will place some limitations on chart and graph design.

    Once charting software is chosen, you might perform a test to help clarify its limitations. Design one chart or graph, and then try to generate that using the charting software. You may find that you can’t make the font as small as you would like, or that other design elements cannot be represented as you intend. It’s better to find this out sooner rather than later.

    Another thing to keep in mind is that not all reporting software generates charts on the fly. Especially if charting is a part of a BI system, be sure you understand how often charts are generated, as some BI charting applications generate charts on a daily basis, rather than on demand.

    “3-D options may look nice, but they add a lot of excess ‘chartjunk’ and detract from the story you’re trying to tell.”Information design
    You should keep in mind that dashboard projects often come about because of frustration with existing systems. Often, the current BI systems have not been stitched together in a meaningful way (there are too many of them, or they are not integrated), or the systems are less than useful because the information is presented in a way that is not immediately comprehensible or useful.

    For an information architect (at least for me) this is the most exciting challenge: Organizing data in a way that is meaningful for the user, as opposed to reflecting how the systems collect and manage data. It is the essential Tufte challenge: how to take massive amounts of data and clearly tell the story inherent within it.

    Tables, charts, and graphs
    Most KPIs, if not all of them, will be displayed using tables, charts, and graphs. Most reporting software packages offer the basic graph options—pie charts, column graphs, bar graphs, and line graphs—and then some. These should be enough to represent the KPIs you’ve selected for the dashboard. However, even within these basic types, there are variations you should be aware of. Review Information Graphics by Robert L. Harris for a complete exploration of data displays. You should be able to find the appropriate table, chart, or graph from this book.

    When using reporting software, be wary of options that look great, but don’t tell the story you’d like to communicate. For example, 3-D options may look nice, but they add a lot of excess “chartjunk” and detract from the story you’re trying to tell. For the busy executive, quick comprehension outweighs a pretty picture every time.

    Data exploration
    There are two important dimensions to data that the executive or manager must be allowed to explore: time and scope.

    The user must be able to compare the data to either the past or the projected future. Incorporating past data will help give the executive or manager perspective on current data. Incorporating projections will help the user see where they are headed if the current state remains unchanged. Almost every KPI should have some time element incorporated into it for these reasons.

    Scope refers to the ability to drill down into data, or roll up data. For example, if an executive is experiencing extreme growth for his or her business unit, they will want to know who or what is responsible. Giving them the ability to drill down in data based on geography, or sub-group, or some other variable, will help provide them with answers to their critical questions.

    The ability to navigate along these dimensions will improve the value of the dashboard immeasurably.

    Conclusion
    The steps one follows to build an executive dashboard are not too different, if at all, from the steps one would follow to build a “normal” website (if there is such a thing). However, the target audience, and the types of information being presented, place demands on the project which are different from the average web project. It may also require the Information Architect to spend more time worrying about technology than he or she is used to.

    But, putting these issues aside, designing an executive dashboard presents an almost pure data-design challenge-one of the few an IA can find in the web world. It gives the IA an opportunity to understand specific questions, and then try to answer those questions using data presented in tables, charts, and graphs. As an IA who also considers himself an information designer, this is a wonderful opportunity indeed.


    Articles

    • Betts, Mitch (April 14, 2003). “Management Dashboards Becoming Mainstream:” ComputerWorld.
    • Krell, Eric” (March 1, 2003). “Gauge Performance by the Dashboard:” Internet World
      Magazine.
    • Orlov, Laurie M. (December 2002). “Use Business Intelligence To Manage
      Velocity:” Forrester TechStrategy Report.
    • Tedeschi, Bob (July 29, 2002).“E-Commerce Report; Digital cockpits are a faster,
      much closer way of tracking performance in a corporation’s every corner:” New York
      Times.

    Books

    • Harris, Robert L. (1999). Information Graphics: A Comprehensive Illustrated Reference:
      Institute of Electrical & Electronics Engine.
    • Norton, David P. and Kaplan, Robert S. (1996). The Balanced Scorecard: Translating
      Strategy into Action      : Harvard Business School Press.
    • Any of the Tufte books


      • Alex Kirtland is a Senior Information Architect and Experience Lead at SBI.Razorfish where he’s
      worked for the past three-and-a-half years. He’s worked with a variety of companies and
      organizations, including Kodak, Verizon, Avaya, Western Union, and the Federal Reserve Bank
      of New York. Besides executive dashboards, he’s also worked on metadata strategy and
      user research/usability projects. If you want to learn more about him please visit his website www.huangkirtland.com.

Learning to Love the Pixel: Exploring the Craft of Icon Design

by:   |  Posted on
“Discussing craft as a value of the user-centered process will expand upon typical issues confronting designers, highlighting matters of moral value, innovative potential, and aesthetic character.”Designing web-based enterprise software involves creating complex artifacts like architecture wireframes, object models, screen flows, and clickable prototypes in order to articulate aspects of the online experience for product stakeholders. As an interaction designer at Oracle, this is quite the norm for me. This routine, however, was recently disrupted when I was assigned the task of creating icons for some of our products.

I first wondered (a bit snootily, perhaps) whether such seemingly trivial bitmaps could be worthy of an interaction designer’s breadth of skill and knowledge. I’m used to designing whole systems of interaction! It soon became clear that, while macro-level outputs (such as flow diagrams or wireframes) require a flexible 10,000-foot view of the application, micro-level icons demand I put on a parachute (or straightjacket, some may say) and plummet to a 1600-percent zoom in Photoshop, going eyeball–to-eyeball with just a few pixels. Amid this dramatic shift in scale and display, I realized interaction designers can have a positive impact on the user experience in two additional ways:

  • The craft of creating icons can support high-level (i.e., typically IA-driven) considerations of the user’s experience by helping visualize access points throughout the application.
  • Conversely, processes and methods used in high-level design can improve icon design by avoiding thrown together graphics that simply “pretty up” screens, and instead crafting something relevant, usable, and attractive.

But what does “craft” mean for interaction designers? In looking at the activity of creating icons, craft can be seen as contributing care and diligence to the production of artifacts that benefit the user. From the designer’s point of view, craft also suggests a personal sense of pride and ownership in the artifact. In addition to debates over wireframes, search engines, and controlled vocabularies, discussing craft as a value of the user-centered process will expand upon typical issues confronting designers, highlighting matters of moral value, innovative potential, and aesthetic character, which are embodied within and transcend any one artifact (such as an icon).

Icons as communication

From Byzantium to your desktop
What are icons anyway? Historically, icons (from the Greek, eikons, or “images”) were religious paintings on wood panels, made during the Byzantine Empire in the 6th century.[1,2] They flourished across Europe for several centuries under various stylistic and cultural influences (i.e., the Middle Ages, the Italian Renaissance, etc.). As visual symbols, they encouraged pious duty and passed on Biblical stories to mostly illiterate audiences.[3] They served as a way to “touch” and “see” something otherworldly yet influential in daily living.

Fast-forward to today. In the dynamic graphical computing context, icons are stylized representations, with varying degrees of abstraction, of some internal (i.e., encoded in binary) object, process, or status of an application. According to Mullet and Sano, an icon denotes an object “by virtue of its own likeness to or resemblance of that object, on the basis of some quality or characteristic inherent in the icon itself.”[4] Icons are thus points of access to the digital space. They may be clicked or viewed, and offer actions the user can take for routine computing tasks. Of course, “pious duties” are not espoused, but “holy wars” over icon colors and styles are known to have raged across design departments.

How does meaning come from icons?
As contextually-located objects, icons exemplify the big challenges of communication and interpretation when using codified visual languages to convey meaning. “Semiotics,” or the study of communication processes, can help designers arrive at a deeper understanding by defining the relationships among signs, symbols, references, and human interpreters. I will forego academic discourse about this rather dense topic, but the following basic semiotic elements should be noted:

  • Syntax: the internal grammar of parts that enable a properly formed sign to be parsable by someone or some system—think of the computer throwing a “syntax error”
  • Semantics: the intending meaning of the sign by the maker(s) of it
  • Pragmatics: how the sign is received, perceived, and acted upon by some person or interpreter by the confluence of syntax and semantics; the resulting effect [5,6]

Whether in home software, mobile phones, or enterprise applications, icons have helped make computing more communicative between people and digital systems. Arguably, they have also cluttered our screens and morphed into a winking, blinking miscellany of digital ephemera that distracts the user from her goal. Or they are simply ignored. Herein lies the value of craft in enhancing user experience, at the pixel level and beyond.

Icons as problems of craft

The craftiness of it all…
So, what is craft? A quick (and somewhat simplified) stroll through its history will help, with guidance from Malcolm McCullough’s Abstracting Craft. Arising from old English “craeft”—for strength and power—craft was the province of tradesmen, smiths, and guilds skilled in the manual production of goods.[7] Craft was plying one’s trade to materials like metal or wood, devoting significant time and effort to creating objects of unique worth. This is in contrast to products of mass industrialization and distribution, created via mechanized means under the inhumane conditions of factories and mines.

Mass-produced goods gave rise to the social unrest of the early 20th century and the critical philosophies of Marx and others, which emphasized the value of the human worker in regards to his output. This suggested the primacy of relationships between the eye, hand, and mind, and tools and materials. In the UK, William Morris led the noble Arts & Crafts movement to resurrect handiwork aesthetics and values of material economy and moral virtue. Americans saw this with Shaker furniture, which was borne of homespun simplicity. Amidst the tumultuous changes of the ensuing “machine age” of the Industrial Revolution, craft as a practice came to be perceived as hobby-like amateurism (think of the crafts section at your local Wal-Mart), while art became a search for loftier values removed from technique. Meanwhile, bold, fast machinery suggested high quality and “futuristic” production. Remember “streamlined” refrigerators, phones, and car tailfins of the first half of the 20th century?[8]

However, from Eames furniture to Rand’s logos to Apple consumer products, personal craftsmanship has resurged as a signifier of commercial design achievement. Consumers and BusinessWeek alike have applauded the high quality of the iPod, Mini Cooper, Nike watches, OXO utensils, and so forth. Craft remains “skilled labor applied towards practical ends.”[9]

It’s not easy being digital
But what about digital media? Can there be a craft of intangible things like icons and interfaces? Digital media is ephemeral, iterative, incremental, reversible (thanks to Undo), and now increasingly networked and collaborative—does any of this make a GIF or web page less craftworthy? And why should designers care?[10]

One reason craft is important, as McCullough suggests, is that the structure, constraints, and play of any medium stimulate personal innovation, pushing the boundaries of what’s possible while solving design problems in a skillful manner. The digital medium, comprising pixels, screen resolution, and color bit depth, can be manipulated by computational processes and tools like Photoshop to unheard levels of ingenuity and “craftiness.”

Secondly, as designers plan an optimal interface, concern for detail—striving for craft—can motivate a team, elevate quality, generate pride, and encourage positive attitudes about how people can use digitally mediated processes and artifacts to improve the user experience. McCullough refers to this as the “moral value” of an activity independent of the product, towards a “humane end.”[11]

Crafting icons, pixel by pixel…by pixel

Some examples from my time designing icons should help illustrate the value of craft with the interaction designer’s involvement at such a detailed level. No doubt these examples will help many readers recall their own icon design efforts—maybe even yesterday’s project.

The development of an icon can be a deep process of applying personal knowledge, corporate context, and skilled labor towards the creation of something the user will see and interact with and that will drive her experience with an application. And, since an icon gets maximum exposure to the end user, the designer better do a darn good job creating it!

I start pixel production after receiving detailed icon requirements from the product team, such as the product name and user profile, visual context, task situation, functional description, and icon type. In the Oracle UI standards for web-based applications, icons are categorized into different types: global button, information quantifier, inline messaging, object type quantifier, and functional icons. Each type has specifications for sizes and colors that reflect the corporate brand for Oracle’s web-based applications and that constitute a usable, persistent visual language. This aids in a user’s interpretation of and expectations for icons featured in other Oracle applications. So I must match the icon request with the category and dictated visual style, including dimensions and colors (e.g., a functional icon is 24×24 pixels, with four to six shades of web-safe “blue”).[12]

I then sketch out concepts on paper, starting broad and narrowing down to a select few worthy of Photoshop. Digitizing the icon is a task featuring a curious intimacy among the tools (PC workstation and Photoshop), the artifact I’m making, and me, due to the level of zoom required to manipulate the pixels. Much like a bricklayer building a wall or a nuclear scientist laying down plutonium, I precisely position pixels one by one, which can yield big differences in just a few clicks—what was once a folder suddenly becomes an account ledger.

Meanwhile, with multiple windows open in Photoshop (across two monitors, of course), I am afforded different views of the same artifact at varying levels of zoom—this helps me consider the totality of the image, like a cinematographer taking in a whole scene. I also concurrently view other icons and source materials (screen captures, stock photos, scanned sketches, clip art, etc.) that I can use for quick reference, inspiration, or even for some parallel icon analysis (“Should I move this pixel over one more?” “Why is this icon not like the others?” “How can I strengthen the color scheme?”). I also refer to screenshots of the application to make sure what I’m making fits in its context. Throughout the process there is rapid iteration and multiple undos, which permit many concepts to be generated in a short period of time. Some Photoshop features, such as the History and Layers Palettes, make this even easier.

The immediacy and improvisation of this process help cultivate dexterity with the tools (such as implicitly mastering keyboard shortcuts and mouse positions to reach toolbar buttons). This also creates a “feel” for the pixels—the ability to anticipate the effects of moving one pixel versus another, much like a sculptor gaining a feel for marble or clay to express her vision.

This increasingly smooth, continuous interplay of hands, eyes, and tools (particularly the mouse as an extension of my hand) mediates my influence on the pixels and creates a sense of “flow,” or optimal experience of a craftsman engaged in his trade. (This is usually aided by listening to trendy trance music.) Popularized by University of Chicago psychologist Mihalyi Cziksentmihalyi, the concept of “flow” combines maximum performance towards a challenging goal with immediate feedback loops.[13] This is exactly what icon design involves at a tightly focused level, much like a jeweler refining an intricate pattern. All the while, my past training as a designer operates subconsciously, evaluating visual balance, scale, harmony, color, form, contrast, figure and ground, etc. The hand/tool/mind relationship implies ongoing active knowledge, but with the physical memory of mousing around to different parts of the Photoshop interface to find functions and shortcuts.

Of course, beyond the actual production of icons, I work as an intermediary among project managers and developers (the folks that request the icon) and the standards group (the people who approve the icon) to achieve icon agreement. There is constant pressure to satisfy team requirements and user goals while preserving standards. And there’s always input from other designers—often the toughest critics!

Shifting the mind from icon to wireframe…and back

These anecdotes suggest craft is an emergent value of a dedicated, focused activity that requires individual skill and diligence. This is the interaction designer’s value in creating artifacts of the user experience—the “it” a user sees and uses firsthand on screen.

Similarly, reflecting upon icon craft offers lessons for information architects and strategic design thinkers. For example, in moving from macro-level plans to micro-level pixels, there is a shift of mind (or “metanoia”) that forms new perceptions of how parts and wholes relate in the overall application UI.[14] In particular, considering the craft of the design helps the designer or architect:

  • See icons as manifestations of functional requirements in the product plan—as action triggers and status cues that support information display and decision-making.
  • Recognize that icons reflect the character and voice of the application, particularly that of a style guide governing the look and feel of products.
  • See icons as designed entities that require research, testing, iteration, and specifications in order to ensure sound, consistent construction.
  • Add a sense of poetics to enhance the user experience, to alleviate the tedium of tasks that rely on drop-down menus and other standard web widgets.
  • See icons as part of the whole system of interactions, at a page level (in the organization of components), an architectural level (as visual indicators resting on invisible wireframes that the user may or may not perceive), and a transactional level (as points of access to various paths or flows).

Good craft can be applied to “macro-level” outputs, like wireframes, prototypes, even code itself, to yield something worthy of attention to boost user experience quality and designer morale. Thus, while creating the interaction flows, the designer should be mindful of the controls and pixels that must be crafted to helpfully, efficiently guide the user. Similarly, while designing the icons, the designer should be mindful of the architecture and interface context within which the icon resides, to ensure its relevance and utility.

Examining the craft of icons suggests various ways designers can add value to the user experience, both from the typically broad, strategic perspective, and at the level of detailed pixel perfection. I believe part of a designer’s significance is found in providing a sense of craft to the design, whether it be embodied in an icon, a diagram, or a task flow. This is achieved by using a sound process respectful of context, users, constraints, goals, and especially personal attention to the details of the artifact. Craft adds to a sense of the cohesiveness of the whole and its parts, at varying levels of abstraction and in various relationships. This is particularly true for enterprise applications that have interdependent flow, architecture, and page level issues. Craft also contributes to the “quality of life” for designers slaving away, by offering a sense of purpose in an often impersonal economy where satisfaction must arise from the designer’s attempts to produce “good work” with positive impact. Ultimately, craft becomes a key concept in the modern design lexicon, and helps ensure a sense of humanity in the production of digital artifacts, and their user experiences.

  1. “A Short History of Icons,” from Praying With Icons by Jim Forest, published by Orbis Book, 1997.
  2. “Icons, Their History and Construction,” online document.
  3. Ibid.
  4. Mullet and Sano, Semiotics: A Primer for Designers,” at boxesandarrows.com.
  5. McCullough, Malcolm. /0060920432/ref=nosim/boxesandarrows-20”>Flow: The Psychology of Optimal Experience.
  6. Senge, Peter. Uday Gajendar is an interaction designer with the Oracle Usability and Interface Design Group, where he has spent the last two and a half years designing healthcare software, financial applications, and visual querying tools.

Six Tips for Improving Your Design Documentation

by:   |  Posted on
“Writing effective design documentation (like design itself) is really all about making sure you serve the needs of your audience.”If you are a designer or product planner, you probably create documents of some kind to capture your design decisions and solutions. Documentation is a crucial component of successful product planning and implementation, so it’s important that it communicates as effectively as possible. Good organization, complete information, and clear writing are, of course, key to the success of any design document, but there are some other, less-obvious techniques you can use to make your documents more readable and understandable. Here are a few of them.

(Note: I refer to “the document” throughout this article, which implies a bound stack of paper, but a printed volume is just one—and not always the best—way to present design documentation and specifications, as Brian Krause points out in his article, “Getting Creative With Specs: Usable Software Specifications.” While many of the following tips are described in the context of printed documents, most of them can be applied to design documentation in any format.)

1. Know your audience
Writing effective design documentation (like design itself) is really all about making sure you serve the needs of your audience. So before you begin writing, it’s worth finding out who your audience is and what, exactly, it needs.

Most important is to know who your primary audience is. Is it programmers, project managers, executives, designers, marketing people? It can be difficult to satisfy every reader in a single document, so, if possible, pick just one target group of people and write for them. If you must serve everyone in a single document, organize it so that each audience can read just the section that applies to them, and not be bothered with the other stuff.

Next, ask yourself—or, better yet, ask your readers—what they want to get out of your document. What will satisfy their goals? Do they need something to help them make a decision? Do they want to better understand who the users are? Do they need to know exactly how the interface behaves and looks? The answers to questions like these should inform the structure, tone, and emphasis of your documentation.

Also important is the culture of your audience. You must be aware of the ways in which your audience uses documentation, and when. What language does your audience speak—technical, marketing, design? What other kinds of documents do they use, and how? Does a paper document make sense, or would a presentation be more appropriate? You want your document to integrate into your audience’s culture, not disrupt it (unless, of course, the intent of your document is to shake things up).

Once you know who your audience is and what they need, you’re ready to start writing. As you go, regularly double-check yourself to make sure you are still on track to deliver your audience what they need.

2. Tell a story
A major goal of design documentation, especially in the early stages of a project, is to educate its readers about the value of the design itself (rather than the specifics of it), and convince them that the product is worth building and producing. One effective way to help people learn and understand these concepts is to present them as narratives: Instead of thinking of your document as simply a well-organized collection of specifications, descriptions, illustrations, and diagrams, try telling a story. Your design document doesn’t have to read like a novel, but incorporating some novel-like elements into your work can often be surprisingly valuable.

Using characters
All novels have a main character, and your design document should, too. If you used personas during the design process, you’re set. Since personas represent the goals and needs of the people who use the design, they are a natural choice for the main characters of your documentation. They even have names, backgrounds, preferences, ambitions, and goals, just like people in a book. Throughout your document, refer to your personas by name, and refer to them often. If you are describing how a product might fit into a market, write a story about how Alison benefits from using the product in her life. If you’re explaining a complex behavior of the product interface, cast it in terms of Daniel’s actions and reactions.

Even if you don’t use personas, per se, it’s a good idea to have some representation of the user in your documentation (more than just bland, generic “the user”). Something as simple as a sketchy description or outline of the target user’s characteristics, coupled with a name, can be quite compelling.

Using scenes
Two excellent ways of presenting the narrative of the design are scenarios and walk-throughs.

Scenarios are like short stories: they communicate a persona’s situation, and describe her motivations, expectations, and goals, without getting into the details of the design. Scenarios are especially useful in the early stages of a project, when conveying the value and purpose of the product is key. Here’s an example passage from a scenario:

Jane’s brother’s birthday is coming up soon and, after much consideration, she has decided to buy him the Ansel Adams retrospective book he keeps talking about. It’s not cheap, though, and she’d like to find the best price. She decides to check ShopAround.com because she’s had good luck with the site before, so she opens her browser and types in the URL. When the page loads, she’s pleasantly surprised to find that it remembers who she is and has even stored the items she was thinking about purchasing the last time she visited the site. Jane clicks in the “ShopAround for:” field and types “ansel adams”…

Notice that this scenario doesn’t specify what the ShopAround site looks like, or what content is featured on the home page. Instead, it focuses on what’s important to Jane: that it remembers her and what she was shopping for last time. It also only describes Jane’s interactions with the page that are pertinent to her goals—namely, finding the book she wants to buy.

Walk-throughs, on the other hand, are good lower-level communication tools. They are basically step-by-step procedures that explain how the persona does something with the product, each action she takes, and each response she gets from the system. Walk-throughs are great for explaining interface behaviors. Both scenarios and walk-throughs work best when accompanied by illustrations or screenshots of the design. The text part of a walk-through might look something like this:

   USER INPUT
      1. Jane types URL into browser Address field and presses Enter

   SYSTEM RESPONSE
      2. Display ShopAround homepage
      3. Display user name in the Sign In module
      4. Display user’s most recent items in Shopping Cart module

   USER INPUT
      5. Jane types “ansel adams” in ShopAround field

   SYSTEM RESPONSE
      6. Query for search string
      7. Load page with search results

Be careful when using a narrative-based document structure, though. It’s not appropriate in all situations. For example, some design documents are used as reference guides for developers; those documents must present information clearly and concisely, and in a way that makes it easy for programmers to find what they need. Here, story-telling might get in the way. One approach is to use narrative to provide an overview of each element of the design, then use a more straight-forward format, like bullets or numbered lists, to convey the nitty-gritty details of each element. Again, always be aware of the needs of your audience, and structure your document so it best meets those needs.

3. Describe the rationale and implications of the design
When you’re documenting a design, it can be tempting to just explain how the product works and show what it looks like. But for many in your audience, that’s not enough. They also want to know the “why?” behind the design. They may wonder why a particular feature was (or was not) included, or why a certain interface element looks or behaves the way it does. While you don’t want to overload your document with too much exposition, providing a bit of rationale where appropriate is another way to get your audience to embrace the design.

The best way to support a design decision or solution is to frame it in terms of how it serves the needs of your users (here again, personas are useful if you have them). Explain how each decision will help your users satisfy their goals and how it will make their experience more powerful or pleasant. Most of the time, using this approach will answer your audience’s “why?” questions even before they ask them.

While providing rationale for your decisions answers your audience’s questions, it can also be a great way of showing that you’ve considered the needs of your development organization. Describing the design in terms of the business requirements it satisfies can help put the minds of product managers and executives at ease. Similarly, using design principles to back up unusual or unique interface behaviors can reassure programmers that what they code is sensible. There’s a benefit for you, too: providing reasonable arguments for design decisions gives you authority. It demonstrates that you know what you’re talking about, which means fewer “well, I think it should be this way” discussions with developers.

Additionally, it can often be valuable to include discussions of the implications of the design. If the design requires certain changes or additions to the technical architecture of the product—such as the need for additional server-side functionality or streaming Internet connectivity—address them up front, so engineers can make fully-informed decisions about how to implement the design.

4. Stick to a grid
Something that is often overlooked is the design of the document itself. Chances are, you’ve come across few examples of development documents that, while full of excellent content, are almost impossible to read because of their haphazard layout. Making the format of your document visually clear and consistent from page to page is just as important as getting the content right.

Effective documents rely on a fixed grid of page elements. Flip through the pages of any book on your bookshelf, or any above-average news website—notice how the bodies of text all line up, and that the header, footer, and margins are the same on each page. That’s the grid. It’s not there only for aesthetic reasons. Having a clean, organized layout means your readers don’t need to do as much work to find things on the page or to make sense of the content they see. A grid also lets you focus on what you’re writing, instead of trying to figure out where to put things on the page.

Applications like Adobe FrameMaker, InDesign, or QuarkXPress make it fairly easy to establish a consistent page layout grid, and many of them offer sample templates to get you started.

Document Grid
Well-planned page layout grids maintain “white space” in the margins and between page elements. This lets your pages “breathe.” Don’t cram things together just for the sake of getting them all on one page.

5. Use the present tense, active voice
If you are producing design documentation, the product is what you write, and the tone of your writing should reflect that. Compare these two sentences:

   The user is provided with a screen for entering data.

Versus:

   The user enters data in a screen.

The first sentence is written in passive voice. It’s wordy, and somewhat awkward. The second sentence is in active voice. It is strong, definite, and clear. Using active voice makes your writing bolder, more direct, and more concise. In your documentation, write as though the product already exists, and you are simply explaining it to a colleague (“the product does this…,” as opposed to “the product would do this…”). When you write with conviction, your confidence and belief in the design is carried through to the reader, and helps make the design more persuasive to your audience.

6. Get a partner
No major book or article is published without an editor. Your design documentation should be no different. Find somebody who can review drafts of your document periodically, before you hand it off to the developers. Ideally, your editor should be a teammate—someone who is already familiar with the design and the project—but a colleague or a trusted member of the development team will work, too.

You and your editor should ask: Is the design described correctly? Will the developers “get” it? Is the organization clear? Are all the key points covered? Have the important technical and development implications been addressed? And so on. Check in with your editor regularly, not just at the end before your document goes to the printer or the web. It’s much easier to deal with holes in your content or problems with your organization scheme if you catch them in early drafts.

As you go through the editing process, keep in mind your ultimate goal: to get the best design produced and out the door. Don’t get too attached to your prose—no word, sentence, or paragraph is precious, and if reworking what you’ve written serves the greater good, do it.

These tips are just a few of the things that go into crafting a great design document (there are many more), but following any one or all of them will help you better serve the needs of your audience. And if your audience of developers and business people is happy, it’s a good bet the users of your product will be happy too. Write on!

Ryan Olshavsky has over five years of experience in interaction design and design documentation. He is currently an Interaction Designer at Yahoo! Inc., a small Internet company. Previously, he worked as a design consultant at Cooper.

Visible Narratives: Understanding Visual Organization

by:   |  Posted on
“Visual designers working on the web need an understanding of the medium in which they work, so many have taken to code. Many have entered the usability lab. ”Art vs. engineering. Aesthetics vs. usability. Usability experts are from Mars, graphic designers are from Venus . The debate between design (of the visual sort) and design (of the technical sort) remains ongoing. A website, however, can’t take sides: it needs both to be successful.

“Interactive design [is] a seamless blend of graphic arts, technology, and psychology.”—Brad Wieners Wired, 2002

So, why the debate? Perhaps the dividing line sits in our minds: left brain (logical) vs. right brain (intuitive). Or, if we take a less deterministic view: few engineers have taken the time to study art and few artists have spent time programming or conducting usability tests. But times are changing. Visual designers working on the web need an understanding of the medium in which they work, so many have taken to code. Many have entered the usability lab.

But what about the other side? Are developers and human factors professionals immersed in literature on gestalt and color theory? They certainly have the tools for it—programming environments make it very easy to throw around images, colors, and fonts (of all shapes and sizes). But with power comes responsibility. And in this case, the need to understand how visual information communicates with your audience.

“We find that people quickly evaluate a site by visual design alone.” —Stanford Guidelines for Web Credibility, 2002

Visual communication can be thought of as two intertwined parts: personality, or look and feel, and visual organization. The personality of a presentation is what provides the emotional impact —your instinctual response to what you see. Creating an appropriate personality requires the use of colors, type treatments, images, shapes, patterns, and more, to “say” the right thing to your audience. This article, however, focuses on the other side of the visual communication coin: visual organization.

How we see: visual relationships
Whenever we attempt to make sense of information visually, we first observe similarities and differences in what we are seeing. These relationships allow us to not only distinguish objects but to give them meaning. For example, a difference in color implies two distinct objects (or different parts of the same object), a difference in scale suggests one object is further from us than the other, a difference in texture (one is more blurry) enforces this idea, and so on. Once we have an understanding of the relationships between elements, we can piece together the whole story and understand what we are seeing.

This process is accelerated by our ability to group information visually. When we observe one blade of grass, nearby objects that share a similar color, shape, size, and position are grouped together and given meaning: a lawn. We don’t have to compare each blade to the others.

The principles of perception give us valuable insight into how we visually group information. For example, objects near each other are grouped (proximity), as are objects that share many visual characteristics (similarity).


Fig 1: Principles of perception: proximity, similarity, continuance, and closure.

But understanding the psychological manner in which we group visual information is not enough if we want to be able to communicate a specific message. In order to do that, we need to know how to use visual relationships to our advantage—we need to know what makes things different.

Though lots of variations are possible, we can group distinct visual characteristics into five general categories: color, texture, shape, direction, and size. Introducing variations in one or all of these categories creates visual contrast. The more contrast between two objects, the more likely they will be perceived as distinct and unrelated.


Fig 2: Visual differences between objects.

Telling a story: visual hierarchy
“Designers can create normalcy out of chaos; they can clearly communicate ideas through the organizing and manipulating of words and pictures.”—Jeffery Veen, The Art and Science of Web Design

Now that we understand the basic ways to visually distinguish objects, we can look at the big picture: using visual relationships to tell a coherent story. Elements within a “visual narrative” are arranged in an easily understood order of importance. A center of attention attracts the viewer’s attention, and each subsequent focal point adds to the story. This logical ordering is known as a visual hierarchy.

To build effective visual hierarchies, we use visual relationships to add more or less visual weight to page elements and thereby establish a pattern of movement through the layout. Visual weight can be measured by the degree to which a page element demands our attention or keeps our interest. Large red type, for example, contrasts with a white background much more than a light gray dot. As a result, the visual weight of the red type grabs our attention first, though it might not keep our attention as long as a detailed image.


Fig 3: Three objects with differing visual weights created by variations in color, shape, and texture.

Visually dominant elements (those with the heaviest visual weight) get noticed the most. They are the center of interest in a layout and they determine where the story begins. The hierarchy of subsequent elements guides our eyes through the rest of the composition, giving us pieces of the story as we go. The relative position of each element in the hierarchy provides valuable information about its importance to the big picture.

Fig 4: The heaviest (most visually dominant) elements in this circus poster are the images of the performers and the title. They communicate the big picture: the circus is in town. The lightest (least visually dominant) elements in the hierarchy are the ticket prices and features. If the hierarchy were reversed, few people would know the circus was in town. Instead they would be confused as they passed posters seemingly promoting “$5.50.”

A balanced hierarchy provides not only a clear path for recognizing and understanding information, it also helps unify the disparate elements within a page layout into a cohesive whole. This creates a sense of order and balance. Without visual hierarchy, page elements compete for attention, and as a result, none of them win. In all hierarchies, only certain elements should be on top; the rest need to follow suit. The appropriate position of each element in the hierarchy depends on the message you are trying to communicate.


Fig 5: In a layout with an effective visual hierarchy, the distinct visual weight of each element guides viewers through the page in an informative and appropriate manner.

Putting it to use
Any given web page is composed of many distinct elements. Navigation menus (possibly several layers deep), contact information, search boxes, site identifiers, and shopping carts are just a few. The visual organization of a web page can communicate valuable information about the similarities and differences between elements and their relative importance. Once your audience understands the significance of your page elements, they can apply that knowledge to the rest of the site.


Fig 6: If all the elements in a page layout are given equal visual weight, making sense of the page is difficult. Meaning is created through the differences and similarities among elements and their place in the page’s visual hierarchy.

Generally, the hierarchy of a web page is based on distinctions between the content, navigation, and supporting information on a page. Within each of these sections further distinctions can also be made. A general web page hierarchy (from highest to lowest importance) may look like the following:

Content

  • Page title
  • Subsection title
  • Embedded links
  • Supplementary information (captions, etc.)

Navigation

  • Location indicator
  • Top-level navigation options
  • Sub-navigation options
  • Trace route (breadcrumbs)

Supporting elements

  • Site identifier
  • Site-wide utilities (shopping cart, site map, etc.)
  • Footer information (privacy policy, contact info, etc.)


Fig 7: The visual hierarchy of a generic web page.

Of course, there are many situations where deviating from this formula is advised (on navigation pages, home pages, etc.). The content, audience, and goals of each page should determine its exact hierarchy. Nonetheless, the visual representation of each element on a web page should always be:

  • Appropriate for and indicative of the element’s function
  • Applied consistently throughout the site
  • Positioned properly in the page’s visual hierarchy (in a manner reflective of its relative importance)

Visual hierarchy, however, does more than simply explain page elements. It guides users through the site’s content and interactions. Armed with an understanding of each element’s place in a hierarchy, we can emphasize important elements (such as content or interaction points), and subdue other elements (supporting information).


Fig 8: In this online form, visual hierarchy guides the user through the necessary steps to place an order. It also emphasizes (with color, positioning, and scale) the first step (“Ordering from…”) and the last step (the “Sign-In” button). Simultaneously, the supporting information is subdued (it has little visual weight) and does not interfere with the main interaction sequence.

Similarly, visual hierarchy can provide users with a sense of where they are within a website, to direct their attention (to special offers, for example), to suggest distinct choices, to explain new elements, and more. However, effective visual communication does not “speak” loudly. It quietly educates and guides the audience through the interface.

Given the massive number of web pages and applications, users often rely on visual cues (especially initially) to assess web interfaces. Therefore, a well thought-out visual organization can greatly enhance usability by grouping information into meaningful page elements and sequences. Such a system relies on an understanding of how people use visual relationships to distinguish objects and what those relationships reveal to viewers (through visual weight and hierarchy). But visual organization is only half of visual communication. The rest, personality (or look and feel), is another story…

Luke Wroblewski is a Senior Interface Designer at the National Center for Supercomputing Applications (NCSA), birthplace of the first widely distributed graphical Web browser, NCSA Mosaic. At NCSA, he has designed interface solutions for Hewlett-Packard, IBM, and Kellogg’s, and co-developed the Open Portal Interface Environment (OPIE).

Three Lessons From Tufte: Special Deliverable #6

by:   |  Posted on
“Information itself cannot inherently be misleading or difficult to understand, but its visual representation or interpretation can be.”Spend any time as an information architect and you’re bound to run into the name Edward Tufte (that’s TUF—tee). Tufte taught information visualization and statistical analysis at Yale University, but he is perhaps best known for authoring and publishing a triumvirate of books: “The Visual Display of Quantitative Information”, “Envisioning Information”, and “Visual Explanations”.

Because his books focus primarily on producing graphics for paper and on the representation of information, not the structuring of information, many information architects wonder about the value of Tufte’s writing for their work. One of Tufte’s principles, for example, is the data-ink ratio, a means for measuring the value of a graphic by comparing the ink used to the data represented.

Tufte measures the amount of ink used to represent data against the total amount of ink used in the drawing. If data-ink is high, the author has done a good job using “their ink to convey measured quantities” (Display 93). With a low ratio, the graphic has less of what Tufte calls “non-erasable” ink.

Information architects who focus on classification and structuring information might have no use for this principle. Those who stray into the realms of interface design might consider a digital equivalent: the data-pixel ratio, comparing the pixels used for representing the interactive parts of the interface with the total number of pixels used. While perhaps easier to count pixels than ink, such an approach does not take into account the subtleties of interaction, usability, and the need for branded interface elements.

Tufte’s work, however, can be applied to documentation successfully. This article considers three of his principles as they relate to information architecture documentation.

Principle 1: Authorship
Tufte spends fifteen pages in “Visual Explanations” talking about the Challenger disaster in the mid-1980s. In short, the scientists at NASA had an opportunity to stop the launch of the ill-fated space shuttle. Tufte surmises that if they had presented the data better, the scientists might have been able to convince the decision makers not to push the button. Although he spends considerable time in the details of the presentation, Tufte first notes that the title slide did not include the names of the authors.

In my work as a consultant, I noticed that “consulting culture” discouraged individual ownership. Perhaps consulting culture prefers to emphasize the team-oriented nature of its work. Perhaps it comes from the explicit clauses in the employment agreements assigning ownership of intellectual property to the consulting firm.

Regardless of the reason, it’s a habit that must change because, as Tufte says about the slides in the Challenger presentation, “authorship indicates responsibility, both to the immediate audience and for the long-term record.” Without any indication of accountability, a document “might well provoke some doubts about the evidence to come” (Explanations 40).

Examples of including author names on documentation:

  • Sean Patrick Coon’s documentation for the EyeWeb system (http://www.apperceptive.com/portfolio/eyeweb.html) includes his name on the flow for the kiosk, but not the site flow or the search schematic.
  • Jesse James Garrett puts his name on the Yahoo! Mail diagram (PDF) he did for Boxes and Arrows (http://www.boxesandarrows.com/archives/images/031102_YahooMail/jjg_ymail_poster.pdf).
  • Erin Malone uses a stylized title bar for her design process timeline for AltaVista (PDF) (http://www.emdezine.com/designwritings/files/AV_ExperienceDesignFlow.PDF)

Principle 2: Smallest effective difference
One of my favorite Tufte principles is the smallest effective difference, which says, “Make all visual distinctions as subtle as possible, but still clear and effective” (Explanations 73). The intent of this strategy is to discourage authors from creating a greater visual distinction than the data implies.

There are many different ways to apply the smallest effective difference, and the approach you select depends on the distinction you’re trying to make. In our documentation, we deal with different kinds of relationships. Here are some ideas for the information architect’s standard deliverables.

The flow chart: My now infamous approach to creating site maps, the “bubble” (PDF) diagram, relies on the smallest effective difference for the connections between nodes. The beauty of avoiding the standard org chart approach to site mapping is that it frees the information architect from the boundaries of the rectangle. By using circles, the relationships can illustrate themselves by taking advantage of the distances between them.

In creating the connectors between the nodes, in showing the relationships, I often want to show directionality or hierarchy. Because of the “non-traditional” layout, however, the diagram needed to allow users to follow the relationships whether they started at a node or not. In other words, if her gaze started at the middle of a connector, the user should not have to trace the line to either end to understand the nature of the relationship. Arrowheads would force users to do just this. Taking Tufte’s principle to an extreme, the arrowhead is not the smallest effective difference between the beginning of the line and the end of the line.

Flowchart showing tapered lines to imply directionalityBy tapering the line, starting thicker and ending thinner, every point on the line could imply directionality. Overall the diagram becomes more subtle, without arrowheads cluttering the drawing.

Because the flow chart or site map is all about showing relationships, there are many ways to apply the principle of the smallest effective difference: the different kinds of nodes, the different kinds of relationships between nodes. Other information architecture deliverables are not so fortunate.

The user profile: The principle of the smallest effective difference can apply to writing as well. In the case of the user profile, authors should focus on what makes each type of user different. In explaining smallest effective difference, Tufte says, “Muting … secondary elements will often reduce visual clutter – and thus help to clarify the primary information” (Explanations 74). With a user profile the “secondary elements” are those that do not contribute to the information architect’s understanding of the user’s information needs.

If an aspect of the user type neither contributes to the information architect’s understanding of that type’s needs nor distinguishes its needs from any other group, perhaps it should be “muted.” While eliminating this kind of information from the profile entirely could lead to flat, inhuman depictions of the audience, finding a way to de-emphasize it could make the document more effective.

The wireframe: In a representation of a web page, the relationships are necessarily implied by the layout. The author need not distinguish between two pieces of information because the position on the page implies that relationship. Perhaps where smallest effective difference comes into play for the wireframe is to suggest that information architects do not “over design” the screens.

With smallest effective difference, however, it is possible to go too far. When a diagram does not have a lot of data, creating subtleties where none necessarily exist could make your diagram hard on the eyes.

Principle 3: Layering
“Confusion and clutter are failures of design, not attributes of information” (Envisioning 53). In a way, this sentence—which begins the chapter in Envisioning Information on Layering and Separation—captures the essence of Tufte’s work (and reminds me of the statement made by my dog’s trainer, “There are no bad dogs, only bad owners.”). Information itself cannot inherently be misleading or difficult to understand, but its visual representation or interpretation can be.

By layering information, authors have an enormous opportunity to eliminate confusion. Misapplication of information layers, however, runs the risk of causing further confusion. Says Tufte, “For every excellent performance, a hundred clunky spectacles arise” (Envisioning 53). What makes layering so challenging is that through layers, authors often create “non-information patterns and texture.” If authors do not effectively separate the layers, they can combine to create nonsense or chartjunk [see note below], further obscuring the message.

Layering is important to information architects because information architecture does not live in a vacuum.

To help information architects apply layering, let’s first explore two reasons why people get confused with our documentation.

Context: Information architecture, while a craft in and of itself, belongs as part of a greater process. By taking a project’s information architecture out of context, clients might experience a variety of misunderstandings that really center on a misunderstanding of how the decisions were made. There are a handful of ways to set the context of an information architecture:

  • Business strategy
  • User needs
  • Functional requirements

Implications: Perhaps this is less about confusion and more about misinformation. How many information architects have experienced the dreaded meeting months after the IA documentation was approved where clients explode because the visual designs are not what was expected? No doubt the good consultant sets expectations, but good documentation can help in this matter by showing the visual design, maintenance, or operational implications of key IA decisions.

Through layers, then, information architects have the opportunity to build a more complex story—to include other elements to the data set. With additional plots, however, comes the potential for added confusion. Although there are several techniques for creating a layered diagram—color, value, contrast&#151jthese will only contribute to misunderstanding if not applied consistently. Each layer must include only one kind of data; and conversely, every data of a particular kind must appear on the same layer.

What happens if the author removes a layer from his or her diagram? Visually, if the author has done her job well, the diagram itself will look like it isn’t missing anything. On the other hand, the person looking at the diagram will get an incomplete story.

Conclusion
Ultimately, the presentation of an information architecture depends on the people using it. Tufte’s principles must be applied in ways that are appropriate and relevant. Layering business strategy context within a diagram for the visual design team, for example, may not be useful. Illustrating the various relationships inherent in the content types of a content management system through the use of Tufte’s smallest effective difference may be more relevant to the engineering team than the client.

Tufte begins his first book with a treatise on “graphical excellence,” which lists nine basic principles from “show the data” to “encourage the eye to compare different pieces of data.” Perhaps this is where information architects find themselves furthest from Tufte’s teachings: his principles do not take the motivation of the user into account. What drives Tufte’s drawings is the data alone. Indeed, for information architects, the deliverable’s audience must guide its design as much as the data does.

*Note:* Tufte’s term for visual elements that obscure data under the pretense of contributing to it. A heavy grid on a line graph is perhaps the best example.
Dan Brown has been practicing information architecture and user experience design since 1994. Through his work, he has improved enterprise communications for Fortune 500 clients, including US Airways, Fannie Mae, First USA, British Telecom, Special Olympics, AOL, and the World Bank.