Designing Screens Using Cores and Paths

by: and   |  Posted on

Desire path and desire cycle pathImagine you’re on one side of a grass lawn and you want to reach the bus stop on the opposite side. Do you walk on the sidewalk around the edges or cross in the middle? Assuming the grass is dry and it’s not prohibited, you’d probably take the shortest path and walk across the lawn to the bus stop. If others have done so before, you may see a beaten path that you could follow.

Such unplanned paths connect the shortest distance between two points, and we can find them everywhere in our surroundings. In urban planning they are known as “desire paths” or “desire lines.”[1] They are an indication of the gap between natural human behavior and contrived routes.

Architect Christopher Alexander recognizes desire lines in his renowned book, A Pattern Language (1976)[2]. He gives specific instructions for leveraging them in architecture:

To lay out paths, first place goals at natural points of interest. Then connect the goals to one another to form the paths.

Christopher Alexander

In principle, Alexander’s approach is to begin with the goals—the things people ultimately want—and then link them together in the most useful way.

Typically in web design, the opposite approach is the rule: designers begin with the homepage. They then work out a navigation scheme, which pages at the bottom of the site hierarchy automatically inherit whether it’s appropriate or not. The goal—or the primary content people are looking for or tasks they are trying to get done—turns out to be the last thing that gets attention in the design process.

Inspired by “desire lines”, we can reverse this tendency in Web design. Cores and Paths is a technique to guide you through the process of creating straight paths to the core offerings on your site.

The Cores and Paths Model

Instead of beginning with the homepage and overall navigation scheme, start with the core content and work outward from there.

“Start with the goal.” Information architect, Are Halland, makes this recommendation in his presentation “Cores and Paths: Designing for Findability”[3]. He outlines an alternative approach for web design: instead of beginning with the homepage and overall navigation scheme, start with the core content and work outward from there. It’s that straightforward.

The technique is based on three key elements:

1. The Core

The core is the reason users come to site. From the provider’s perspective, the core is what’s offered on the site. Note that the core isn’t always a page. For YouTube, the core is a video and not a page on This makes it possible to have distributable cores, or content that may be found on other websites.

The core may be accompanied by supporting information. Technical details, for instance, can be considered an extension of the core. On sites like flickr a description of a photo as well as the tags user give it are supporting information for the core, which is the photo itself.

2. Inward Paths

How do users get to the core? Sometimes visitors arrive at the core via the main navigation or search of site. But they might also come directly from Google. Other paths are possible as well, such as links from other sites, teasers, entering URLs directly in the browser, and even via rss feeds and newsletters. Thinking about inward paths also considers aspects of SEO, such as what the trigger words do people search with.

3. Outward Paths

Assuming users found what they were looking for, what can they do from there? What are their calls to action? Fundamentally every subsequent interaction should bring some kind of value to the business. This is where conversion takes place. Outward paths can be everything from placing an item in a “shopping cart” to recommending a product to a friend. As with inward paths, there are a variety of options to consider, including links that lead away from the site.

Each of these three elements has a different function. The core is really where value creation for both users and the business takes place. Persuasion plays a big role here: organizations ultimately want users to take some specific action. The inward paths ensure findability. This is how people come to the products and services they are looking for on the web. From a business standpoint, the outward paths are what bring ROI to an organization.

Below is an illustration of the Cores and Paths model, using Amazon as an example (Figure 1). The core is a product, represented here by an image of a book cover and its key details, indicated in the red box. Users find the book in numerous ways, listed on the left. These are the inward paths. Amazon sees a return on investment when users take action on the core, seen on the right as possible outward paths.

The Cores and Paths model for 1: The Cores and Paths model for

The Cores and Paths Process

Imagine the following scenario:

You work for a small agency and have been contracted by a bicycle shop to improve their website. The shop currently only has a “brochure-like” website with address and opening times. They’d like to get into ecommerce and be able to sell online. The product line consists of high-end racing bikes and mountain bikes, along with the appropriate accessories for each. There are about 1000 products in total they want to sell online. The shop’s main target groups are professional cyclists and highly motivated amateurs. As a result, the bikes sold are primarily from premium brands. The design of the website should highlight the high quality of their products.

Following the Cores and Paths approach, here’s how to design the website from the inside out:

STEP 1: Define the core

What is the core offering? First, make a list of possible candidates: bicycles, accessories, services, etc. It initially starts with brainstorming so there are no right or wrong answers. After compiling a complete list, decide on a core and its supporting information. In large teams this means getting agreement from team members and stakeholders alike.

In the above scenario, the core is the product—a bike. A photo of the product is a central element to represent the core. The bike features, brand, and product line are types of information that belong to core in this case. Supporting information includes the price and additional technical details.

After deciding on and prioritizing these details, sketch the core (Figure 2). Don’t sketch the entire page with navigation and a logo: just focus on the core. Customers may want view details of the product up close, so consider how they will interact with the images even at this stage. Think about the experience visitors will have with the core once they find it.

Sketch of the core and supporting informationFigure 2: Sketch of the core and supporting information

Keep in mind that users will also be visiting the site from smartphones and tablets. And they may also post an image to Facebook or Pinterest. This is an example of a “distributable core.” So sketch how the core might transpose to these different contexts (Figure 3). Again, do this without sketching the page chrome or navigation—just focus on the core.

Versions of the core in different possible contexts.Figure 3: Versions of the core in different possible contexts.

From this you’ll see how the core and supporting information behave in different situations. You may have to go back and forth between the versions updating them iteratively.

STEP 2: List all possible inward paths.

What are all the ways that users can reach your core? Obvious things come to mind at first: site search, the main navigation, Google, and links from other websites. But more paths come into play as you brainstorm: links from comparison shopping sites and even references from offline media, such as a printed catalog.

For each inward path in your list, also write down the design requirements that must be met. For instance, SEO and landing page optimization is necessary for visitors coming from Google and other search engines. (See Figure 4)

A list of possible inward paths and the key requirements for eachFigure 4: A list of possible inward paths and the key requirements for each

STEP 3: List all possible outward paths.

Determine the paths away from the core. As in STEP 2, include design requirements for each outward path. This allows you to rank the outward paths in terms of importance to the business, providing clarity for the design in later on. (See Figure 5). Because outward paths ultimately provide value to the business, rank these according to business goals. A clear call to action button brings the user to the checkout process in this example. And if the customer can’t decide right away, a link to a wish list or to recommend the product to others is a second priority.

List of prioritized outward pathsFigure 5: List of prioritized outward paths

Up to this point, we’ve neither looked at the homepage nor have we thought about the navigation. Yet, we’ve addressed important design decisions, such what a mobile version of the core product might look like and how people will interact with the primary content of the site. After making these into higher-fidelity mock-ups, these initial representations could even be tested with users.

STEP 4: Put it all together.

Only after you’ve designed the core and listed the inward and outward paths should you start looking at the homepage and at the navigation. The goal at this point is to bring the user in the simplest, most-direct way possible to the core.

Design the homepage of the site, as well as gallery pages and search results. Sketch several alternatives. While doing this, keep the elements of Cores and Paths in mind: what is the core, how do users get to it, and how will the business see conversion?

Sketch of the homepage – a first draftFigure 6: Sketch of the homepage – a first draft

In this scenario, to get users from the homepage to the core the three product lines of the shop appear in the main navigation: “racing bikes,” “mountain bikes” and “accessories.” Since brand is also important to the target groups, a separate point for “brand” is also included. A prominent link to a shopping cart and checkout process is also located in the header.

Sketch of the gallery page with filters and sorting optionsFigure 7: Sketch of the gallery page with filters and sorting options

Below is a template we used to capture all of the points and steps described in this article (Figure 8). Download the template at the end of this article to try Cores and Paths out yourself!

A template for Cores and PathsFigure 8: A template for Cores and Paths


The Cores and Paths process improves design in several ways:

Identifies gaps. Questioning the purpose of the primary content upfront helps uncover gaps in the initial briefing.

Prioritizes design elements. Breaking down key elements helps prioritize how they appear in the overall design.

Focuses Design. Cores and Paths provides a clear direction to follow for the whole project team.

The difference between Cores and Paths and other approaches may seem subtle at first. But the impact is great: now, the core offering stands firmly in the middle of your design. All other elements in the site design serve the purpose of bringing both users and the business to their goal.


[1] “Desire path”, Wikipedia:

[2] Christopher Alexander, A Pattern Language, 1976 (

[3] Are Halland, “Core and Paths: Designing findability from the inside out”, EuroIA Summit, 2007:

Alignment Diagrams

by:   |  Posted on

Alignment diagrams

Did you ever get bounced around between departments when interacting with a company or service? This happened to me recently with my credit card: the card issuer and the bank backing it seemed to disagree who was responsible for my problem. Each blamed the other. I got caught in the middle.

My communication with them also crossed multiple channels. For some things I used their website, for others I had to call. There were emails, regular mail and even a fax involved as well. None of it seemed coordinated. Apparently it was my job to piece it together. Bad experience.

Why does this happen? All too often companies are focused on their own processes, wrapped up in a type of organizational navel gazing. They simply don’t know what customers actually go through.

What’s more, logical solutions can cross departmental lines. Ideal solutions may require crossing those boundaries. An organization’s rigid decision making makes that difficult.

Here’s where I believe IAs and UX designers can use our skills to make a difference. We have the ability to understand and to map out both business processes and the user experience. Visual representations can provide new insight into solutions that appeal to a range of stakeholders. Alignment diagrams are a key tool to do this. Continue reading Alignment Diagrams

The Art of Project Management

by:   |  Posted on
“Examining all ideas—even bad ones—is essential to creativity. Design is about exploration.”

Project management involves more than just what a project manager does. All team members engage in some level of project management, whether meeting deadlines, communicating with others, or estimating task durations. Ultimately, everyone on a project contributes to its success.

Scott Berkun’s book, The Art of Project Management, is not about any one specific project management methodology, but about fundamental aspects of all projects. This makes it engaging to project managers and non-project managers alike. The author recounts personal experiences while managing projects at Microsoft to provide insight into the not-so-transparent aspects of project management-the art of project management. If you don’t care for the standard, dry project management textbooks on the market, then this is for you.

The book is divided into three large sections: “Plans,” “Skills,” and “Management.” This organization provides a logical flow overall and lets topics to build on another. However, the chapters are relatively self-contained, allowing for random access, as the author recommends.

To begin, a brief history of project management exposes elements common to all projects: processes, design, constraints, dilemmas, and roles. The point here is to learn from the past and avoid repeating common errors.

Berkun then moves quickly to the basics of project management with topics such as project plans, requirements, and creating a vision. In the chapter “Figuring Out What To Do,” Berkun outlines three basic perspectives to approaching plans: The business perspective, the technology perspective and the customer perspective. About the latter, he states, “This is the most important of all three perspectives,” but also recognizes that “sadly, the customer perspective is the weakest in many organizations” (p. 63). Berkun’s insight into bringing users into the design process is comprehensive and genuine: he gets it.

Of particular interest to IAs and designers are discussions about creativity. For instance, in the chapter “Where Ideas Come From,” Berkun offers this sobering perspective on thinking outside of the box:

“Do whatever you want with the box. Think in the box, out of the box, on the box under the box, tear apart and make a fire out of the box, whatever, as long as you manage to solve the problems identified as the goals for the projects.”

He also suggests that examining all ideas—even bad ones—is essential to creativity. Design is about exploration.

In “What To Do with Ideas Once You Have Them,” Berkun recognizes a key issue in creative work: making ideas actionable. The author advocates such tactics as formally tracking ideas, using affinity diagrams to consolidate ideas, and employing iterative prototyping. Regarding prototyping he says, “Because there are so many details and perspectives, it’s impossible to predict which paths will work and which ones won’t. And that’s precisely what prototypes and iterations are for: making mistakes, learning, revising, and moving forward” (p. 157). How true.

Given the author’s active involvement in HCI communities, it is not surprising that he supports usability and design so strongly. It is unique, however, to see heavy doses of design-related topics and user-oriented thought in a book on project management.

The middle section of the book, “Skills,” gives hard advice on a range of practical topics: from how to write good specifications to making decisions to writing appropriate emails. The chapter “How Not To Annoy People: Process, Email, and Meeting” offers down-to-earth recommendations through witty anecdotes. Berkun sees five key annoying behaviors– when others:

  • when others assume you’re an idiot,
  • don’t trust you,
  • waste you time,
  • manage you without respect, and
  • make you listen to or read stupid things.
“Leaders must develop enough trust that people will bring issues to them during crises instead of hiding them. Trust, then, is at the core of leadership.”The final section of the book deals with more general, overarching issues of management. With such chapters as “Why Leadership Is Based On Trust” the author once again touches on the softer side of project management. Trust is built through commitment but lost through inconsistent behavior, he believes. Leaders must develop enough trust that people will bring issues to them during crises instead of hiding them. Trust, then, is at the core of leadership.

Another chapter interest is “Power and Politics.” Here, the author dissects that ever-frustrating political game underlying many projects. He puts the abuse of power in plain words: “The misuse of power occurs when an individual is working toward his own interests … Much of his energy will be spent doing what is best for him, instead of what is best for the project as a whole” (p. 427). Berkun also details various strategies to navigate political problems. This involves knowing the political playing field: who has the power, how is it obtained and applied, and how can individuals get what then need for the project. Ultimately, the amount and type of politics in a given project comes from the top down.

The tone of this book is personal and from the heart, with tough and direct statements. The unfortunate side effect of his chatty writing style, however, is a long book. Weighing in at 488 pages, it is long-winded. Berkun could have covered the same ground in half the space. Ironically, the author stresses concise writing in project documentation (see p. 99). Luckily his causal presentation is fast-paced and the reading goes quickly.

The excellent annotated bibliography not only shows that Berkun has done his homework, it also provides a very helpful guide to identifying additional key sources on the topic. The index at the back of the book is also quite good and allows the book to function as a quasi-reference book.

This is a comprehensive, how-to book devoid of jargon and theory. The author gives direct advice from his own experience. The real value of this book, though, is that it is not about a single methodology for project management, nor is it just for project managers. Instead, Berkun is able to speak about project management at its highest-level without filtering it through a given approach. It is deep enough to keep seasoned project managers reading, but also appealing to non-project managers. I’d recommend this book to anyone looking to improve general project skills.

Random, yet selected, quotations of interest

“Note that because design skill is distributed in the universe independent of political power, people granted design authority might not be people with much design talent” (p. 55)

“There are many different ways to abuse information about customers. Simply claiming that customers are important doesn’t signify much” (p. 75)

“When ideas aren’t accessible or kept in the light, the fade away” (p. 107)

“I do not know where the phrase ‘there are no bad ideas’ came from, but I’m certain it’s wrong…I have incontrovertible evidence that there are an infinite number of awful, horrible, useless, comically stupid, and embarrassingly bad ideas” (pp. 119-120)

“The most common mistake is to treat the design process as if it were a big light switch – you can just turn it on and off whenever you like” (p. 144)

“Don’t fall in love with Visio or flowcharts. Maintain platonic relationships with all tools. Usually, diagrams are interesting only to the person who made them, and they are often not as effective in helping the project as their creator things. Sometimes, a good paragraph or a sloppy, hand-drawn sketch is better than a 500-element UML diagram. (Just because a diagram is the only way for the author to understand something doesn’t guarantee it’s the best way to explain it to someone else).” (p. 179)

“When you spend hours pounding away at the same issues, you eventually lose perspective. When all the choices start looking the same, it’s time to get away.” (p. 210)

“The funny thing about childhood development is that we all get hand-me-down belief and emotional systems. Most of the behaviors we follow are by and large learned from our parents…Until someone stops and examines the value of their behaviors and emotional responses, independent of where they learned them from, it’s difficult to grow in emotional maturity – or even to know how emotionally mature and healthy we are.” (p. 298)

“Calling ‘bullshit’ makes things happen. If people expect you will ask them tough questions, and not hesitate to push them hard until you get answers, they will prepare for them before they meet with you. They will not waste your or your teams’ time.” (p. 343)

About the book

The Art of Project Management, Scott Berkun
O’Reilly Media Inc.
ISBN 0-596-007868

View book site, including a sample chapter

Table of Contents

  • Preface
  • A brief history of project management
  • Part I: Plans
    • The truth about schedules
    • How to figure out what to do
    • Writing the good vision
    • Where ideas come from
    • What to do with ideas once you have them
  • Part II: Skills
    • Writing good specifications
    • How to make good decisions
    • Communication and relationships
    • How not to annoy people: process, email, and meetings
    • What to do when things go wrong
  • Part III: Management
    • Why leadership is based on trust
    • How to make things happen
    • Middle-game strategy
    • End-game strategy
    • Power and politics
  • Notes
  • Annotated bibliography
  • Acknowledgements
  • Photo credits
  • Index
    James Kalbach, assistant editor for Boxes and Arrows, holds a degree in library science from Rutgers University, as well as a masters in music theory and composition. He is currently a Human Factors Engineer with LexisNexis and previously served as head of information architecture with Razorfish Germany. He is an active speaker and author on information architecture and usability in Germany, where he helped cofound an IA community.

Conference Wrap-Up: “IA in Germany – Chances and Perspectives”

by:   |  Posted on
“The German Internet and IT industries have not noticed or otherwise acknowledged IA.”It seems that field of information architecture is picking up again in North America after the dotcom bust. For instance, Lou Rosenfeld wrote in a recent blog entry “…I’m optimistic. The field seems healthier than it was four years ago…” (see Happy Time for IA?, Mar 2005, And Andrew Dillon declared in his closing keynote speech at the Montreal IA Summit (2005) that IA was entering its second phase. IAs are seeing more and more job opportunities as well as more professional recognition, and the field itself seems to be progressing.

Not so in Germany.

Here, IA is barely on the map. The German Internet and IT industries have not noticed or otherwise acknowledged IA. Other northern European countries, such as Holland and Denmark, seem to have far surpassed Germany in establishing IA as a recognized profession. There are some encouraging signs though: The German Digital Business Group (Bundesverband Digitale Wirtschaft: identified IA as an upcoming trend in Germany. Perhaps that will assist the fledgling field. Still, the current situation for those who consider themselves IAs seems bleak on a whole.

In an attempt to bring IAs in Germany together, members of the IA Institute organized a small conference in Frankfurt on Saturday and Sunday, May 28-29, 2005. This was the first such event exclusively for IAs in Germany. The theme was “IA in Germany — Chances and Perspectives.” Nearly fifty participants came from all over the country—from Munich to Berlin to Hamburg—to take in a total of nine talks and discussions. Aside from the planned sessions, IAs networked and spent time meeting new people with common professional aspirations.

Saturday Sessions

We were extremely fortunate to have Eric Reiss, principle of e-reiss consulting ( and author of Practical Information Architecture (, as the keynote speaker. In his speech “The business value of IA” Eric highlighted the fact that there is often a big disconnect between how IAs talk and what business managers really want to hear. In addition to learning how to talk business-talk, we should also be learning how to listen to business managers better.

A panel discussion followed Eric’s presentation. This 90-minute session began with a discussion of definitions of IA in Germany. (No, this topic is not dead yet here and is actually much needed—the parameters within which IA exists in Germany are different than in the US and elsewhere.) The four panelists each gave a perspective on what IA in Germany is and why it hasn’t yet taken a broader hold. The second half of the session evolved into a workshop where the audience gathered to share their possible definitions of IA. This revealed a wide range of varying opinions and perspectives on IA in Germany.

Steffen Schilb, the creator of CardSort (, spoke to a very interested audience. He has been actively talking about this software (a card sorting program developed as part of his thesis work at the University of Bremen) at conferences around Europe. With CardSort, users can sort virtual index cards per drag-and-drop and save the results in a file. In his presentation, Steffen carefully walked through different analysis techniques, including distance matrixes and dendograms.

Next up, Sabine Stössel gave a case study of the IA process during the launch of, one of the largest German TV stations. Attempting to represent a large, fractured concern through a single web interface exposed the many practical difficulties of IA as a process. Sabine shared a wealth of deliverables with the audience, as well as war stories and organizational challenges. Overall, this injected a heavy dose of practical realism into the conference program.

The sessions on Saturday concluded with a brief summary of some of the highlights from the IA Summit in Montreal (2005). Deborah Gover, Piet Kopka and James Kalbach each picked two key themes from the Montreal meeting to relay to the German IA public in Frankfurt. Topics included global IA, enterprise IA, IA as “craft,” folksonomies, and faceted classification.

Sunday Sessions

After an obligatory cup of coffee or two early Sunday morning, Birgit Nussbaum regaled us with a broad overview of IA and its relationship to social classification software. A case study analysis of a client’s intranet revealed the situations in which social classification systems are appropriate and in which situations they are not. A key take-away was that new types of social classification do not necessary replace traditional IA systems, but instead complement them.

Following Birgit’s fascinating talk, Andreas Lechner and Wolf Noeding discussed the advantages of IA as an integral part of the overall development process. Within their own team, they have worked out a detailed, iterative process for IA work. The overall advantage of such a process is an increase in product quality and a decrease in overall work effort. The process is still being refined, but initial feedback from clients and from other team members is positive.

Piet Kopka then discussed a more abstract topic regarding information spaces and how content is bestowed with meaning. Large information spaces are n-dimensional and can’t be easily represented in two or three dimensions. IAs must therefore resist adhering to physical principles of organization. Piet advocates adopting a new personal attitude, one that fosters the development of self-similar principles in information design. Furthermore, he explained that there are fundamental decisions in creating information spaces that can have long lasting effects. This recalls Stewart Brand’s notion of fast and slow changing layers of building architecture.

The Sunday sessions wrapped up with a report about a new IA program just getting started at the University of Potsdam, near Berlin. Professor Danijela Djokic and Professor Boris Müller discussed the challenges and problems of setting up such a program. Overall, they have adopted a more Wurman-like definition of IA, what some might call “information design,” including a great deal of information visualization. Danijela shared a wide range of student projects, demonstrating fascinating new techniques in displaying and visualizing information.

Overall, the meeting was quite successful and far surpassed prior expectations. We exchanged ideas on a technical level, networked with others, and made concrete steps towards a formal organization of IAs in Germany.

A special thanks goes out the financial sponsors of the event: the IA Institute (, Publicform ( and Spirit Link (

Of course, the hours and hours of work that went into planning the event should also be acknowledged. The organizers were Britta Glatten (sinnFormation), Deborah Gover (Siemens VDO), Jochen Fassbender (Indexetera), Piet Kopka (Publicform), Wolf Noeding (spriritlink) and myself, James Kalbach (LexisNexis).

James Kalbach, assistant editor, holds a degree in library science from Rutgers University, as well as a master’s in music theory and composition. He is currently a Human Factors Engineer with LexisNexis.

Printing the Web

by:   |  Posted on
“Consider how extraordinary paper is: lightweight and flexible, it supports thousands of typefaces, as well as black-and-white and color illustrations, and its high-resolution and high contrast facilitates reading.”Despite predictions to the contrary, it doesn’t seem that the advent of networked information sharing has reduced human consumption of paper. In fact, given the amount of printouts modern offices and homes produce, one is inclined to say that even MORE paper is generated today than ever before. A “paperless society” feels a long way off.

Works such as “The Myth of the Paperless Office” by Abigail J. Sellen and Richard H. R. Harper confirm this. The authors show how paper use often increases after the introduction of computers in an office. Such observations have been commented elsewhere (see Information Week). The paper industry is doing fine as well: the largest paper producers in the United States have continued to grow economically over the last five years. In short, there is no real evidence of a world without paper.

Consider how extraordinary paper is: lightweight and flexible, it supports thousands of typefaces, as well as black-and-white and color illustrations, and its high-resolution and high contrast facilitates reading. David Gelernter, Yale professor and computing visionary, aptly summarizes: “The ‘paperless office’ is a bad idea because paper is one of the most useful and valuable media ever invented. …‘On paper’ is a good place for information you want to use; a bad place for information you want to store.”

David Gelernter, “The Second Coming: A Manifesto

The reverse is also true: computers are good for storing information, but generally bad for using it. Research shows that difficulty in reading from a computer screen stems from poor resolution: compared to paper, monitors—even of the highest quality—offer only low-resolution reading.

On the web there are additional complications. Jacob Nielsen offers insight here:

  • Web users feel that they have to move on and click on things.
  • Each web page competes with millions of other pages for attention, potentially reducing users’ ability to focus on one content source at a time while online.

Jacob Nielsen. (1997) “Why Web Users Scan Instead of Read.

It is no surprise that many people print information from the web. Rather than overlooking this common behavior, it may be advantageous to plan for and support printing when designing a website.

Designing web pages with printing in mind
For some websites the user experience already extends onto paper, like it or not. Ignoring this may result in lower overall user satisfaction. Consider the following factors when designing web pages that will be printed:

  1. No Alternate Version
    Sometimes web developers do not have the time, money, or know-how to offer alternate print-friendly versions of web content. Creating online pages that also work on paper is still possible.

    After a user selects “print” from the browser, the page is formatted before it is sent to the printer. The width of the layout is reduced to about 650 pixels for 8.5″ x 11″ paper, or 630 pixels for A4, assuming normal margins.

    If all the elements of a page can’t wrap around to fit within this 630-650 pixel area, content on the right will simply be cropped off. This is often caused by absolute positioning of page elements, such as fixed table widths, or large images. A web page with a fixed size of 800×600 pixels may look great online, but will lose its right edge completely when printed.

    Flexible layouts relying on relative positioning are better for printing, allowing the page to compress down to fit onto paper. I believe using flexible positioning and relative table widths (i.e., percentages) constitutes good web design practice in general and should always be considered (see “The Myth of 800×600” in Web Review,

    Frames may complicate the printing process or sabotage it completely. Flash and other rich media formats may also be problematic and may not print at all. Additionally, including content in a DHTML layer essentially hides it from the printer. If you want your users to be able to print, reconsider these technologies.

  2. Alternate Print-Friendly Version
    Print-friendly pages can eliminate the above-mentioned problems and yield higher quality printouts. Programming a print-friendly function is indeed more work, but CSS makes it relatively easy for an experienced programmer (more below).

    The “print this page” button, however, shouldn’t just duplicate the print function on the browser. Instead it should do something with the content to make it more appropriate for paper. Here are few ideas for creating a print-friendly version of a web page:

    1. Remove navigation. Unless the site navigation is somehow important for the text itself, it is rather useless on paper.
      Example: International Herald Tribune,
    2. Remove or change graphical ads. Banners may not make sense on paper, particularly animated images, which are generally meant to be clicked.
      Example: NY Times online, – changes full-sized, animated ads to small static images.
    3. Remove absolute page widths and change to relative positioning. This will ensure that the browser can scale down a page to fit on paper without losing any text. Removing fixed widths for printing means you can still have fixed width web pages on screen.
    4. Change fonts from sans serif to serif. Sans serif fonts are better (i.e., more comfortable and quicker) for online reading, while serif fonts are easier to read from paper.
      Example: Boxes and Arrows,
    5. Add citation information to the print version. Most browsers print the page title and URL on the top of a printed page by default. However, you may want to offer a clearer, thorough citation at the top of the page.
    6. Remove dark backgrounds. Though most browsers don’t print backgrounds by default, it’s best to change any online color combinations to black on white for the print version to ensure a readable printout.
      Example: Evolt,
    7. Write out links to show the URL. On paper an underlined word (i.e., a link) in the middle of a text is not very helpful. Instead, show the URL after the link in parentheses. This can be very problematic with long URLs (e.g,. dynamic pages with unconverted parameter strings) and may require manual examination of links within a text body.
    8. Display the print-friendly version before printing. This could be in a new window, offering users feedback as to what the document will look like and giving them more control. It is not recommended to start printing immediately after clicking the “print this page” button.
      Examples: International Herald Tribune, (displays print-friendly version and invokes browser’s print command at the same time)
    9. Collate information into the final print version. Related documents are sometimes spread out over multiple web pages. The print version should consolidate necessary content.
      Example: IBM articles – you can print the current article or the entire section.
    10. Ensure that color coding is not required to understand content. It is safe to assume that most users will be printing with a black and white printer. Charts with colored bars, for example, are useless in black and white. Add text labels for clarification for pages that are likely to be printed.

CSS to the rescue
Unless there is a very good reason, you really don’t want to maintain two different versions of a web page. CSS allows you to reformat content for a print version without having to maintain multiple separate documents.

Features of CSS take printing into account and offer a great deal of power and flexibility. Most of the suggestions above can be implemented with style sheets. For example, with CSS you can:

  • Add or remove any defined page element, such a navigation menu or images
  • Change font type, size, and measurement (from pixel to point, for instance)
  • Define page breaks
  • Define page margins (separately for the first page if you want)
  • Write out URLs for links

W3C has recommended a set of extensions to CSS to better support printing from the web, referred to in the specification as “paged media” (see For those who are looking for more details, see CSS guru Eric Meyer’s excellent article in A List Apart, which explains the nuts and bolts of code needed for print-friendly pages (

Additionally, XSL Formatting Objects, also a W3C recommended technology, is extremely powerful. With this you can print from XML with highly controlled layouts. See “What is XSL-FO?” for an introduction (by G. Ken Holman,

Capabilities of both CSS and XSL-FO point to the need for better control of printing formats and underscore the fact that people do indeed print from the web. Web design, in turn, should take advantage of these technologies to ensure a consistent user experience on and offline.

Remember, as well, that the tendency to print from the web is often a desire to capture information for later use. That is, often users want to walk away with content. In addition to or instead of creating a print version, offering a downloadable version of a document also addresses this need. PDF format, for instance, is great for downloading and printing, and can even be generated “on the fly.”

Those of us concerned about the environmental impact of increased paper use may argue that adding a print button encourages people to print, thus wasting paper. I would argue they will print anyway – with or without an added button. But consider how a print-friendly version may actually be better:

  1. Print-friendly versions avoid problems with printer reformatting and normally use fewer pages than directly printing a web page.
  2. Removing navigation, banners, dark images and backgrounds saves ink.
  3. Print versions could also be offered as downloads, thus avoiding printing all together while still allowing users to capture online information.
  4. Cutting and pasting text is easier from print-friendly pages. For the small group of web users (myself included) who cut and paste text from the web, print versions are advantageous.

Finally, designing with print in mind necessarily forces website creators to conceptually separate content from presentation. Lessons learned from developing alternative print versions of web pages could be applied to other situations, such as creating PDA versions of web pages. As designing for multiple formats becomes increasingly more important, such skills are all the more valuable.

This is not at all to say you should ignore creating attractive and useful displays of information to be read online. My point is this: perhaps we are heading toward the paperless society and are just in state of transition. Maybe as the quality of computer screens gets better and people start reading online in the first grade, we will loose our need for paper. This surely won’t happen, however, within the lifespan of your next web project. Therefore, consider how users interact with other formats and media, particularly paper, and address the reality that people print web pages. With a little planning and foresight creating printable pages is relatively easy and extends a positive user experience to paper.

James Kalbach is currently head of Information Architecture at Razorfish, Germany and has a masters degree in library and information science. Previously he established a usability lab at I-D Media, a large German digital agency.

Challenging the Status Quo: Audi Redesigned

by:   |  Posted on

In September, 2000 Razorfish, Germany was charged with the task of “It is not uncommon that, by the end of a project, updating something as simple as a navigation label requires updating half a dozen documents or more. ”relaunching the main websites for Audi, the German car manufacturer. The project encompassed, their global brand portal, and, the regional site for Germany. Both sites were relaunched in December, 2001.

Rather than describe the project from beginning to end, this case study focuses on three aspects of particular interest:

  1. Razorfish’s approach to schematics (i.e., wireframes).
  2. An automated page layout technique referred to as “jumping boxes.”
  3. A user test that compared the performance of a left-hand navigation to a right-hand navigation.

Many web projects suffer from a lack of “traceability.” By this I mean the ability to trace a concept, idea, element, or artefact across a set of documents.

Unless a project employs all-encompassing document management tools, documents tend to end up separate and independent from one another. They are often owned by different people, reside in different locations, and are created in different formats. It is not uncommon that, by the end of a project, updating something as simple as a navigation label requires updating half a dozen documents or more. This is inefficient and leads to version control problems.

To address this problem, Razorfish, Germany turned to Adobe GoLive 5.0 in hopes of achieving a true convergence of documents. The plan was to integrate a range of deliverables, including sitemaps, schematics, text content, and screen designs. We even wanted to create functional specifications directly in GoLive in HTML format.

We chose GoLive for several reasons:

  1. Linkage
    Information was shared between the sitemap and schematics. Updating the page name in the sitemap, for example, updated the page name for the schematic.
  2. Modularity
    Page schematics were created using components. This allowed for the definition of global elements, such as the main navigation. Changes were made across the entire set of schematics very easily.
  3. File Sharing
    Working with a WebDAV server, IAs could check schematics in and out, thus offering version control. Audi was also able to see the schematics “live” online in HTML format through the project extranet.
  4. Cross-Platform
    GoLive is available for the PC and the Macintosh, and the output is simple HTML. Conversions to Adobe PDF, for example, were not necessary.

There were, of course, disadvantages to GoLive:

  1. File Size
    Even without text content and screen designs, the site file for the Audi schematics grew to 30 MB and became unwieldy.
  2. Instability
    We experienced some crashes and loss of work with GoLive 5.0, which had just been released before the Audi project began.
  3. Sitemapping
    The sitemap tool is primitive and doesn’t allow a great deal of control over appearance.
  4. Team Buy-in
    The use of GoLive didn’t get the buy-in from the whole Razorfish-Audi team and ended up being used primarily by IAs. In the end, the idea of true document convergence across skill groups never happened.

Overall, GoLive worked well and met most of our expectations, particularly from an IA standpoint. But it still isn’t the right tool for the job and our experience underscores the need for a program that meets all information architecture needs. Though no single technology will solve the problems of site conception and planning, a more appropriate tool would help.

Jumping Boxes
Razorfish, Germany wanted to address the fact that users surf with different “With an increase of alternative browsing devices on the horizon, the continuum of viewable browsing sizes will continue to expand. Never before has the demand for flexible layouts been greater.”browser window sizes. We believed developing pages for one fixed size is fundamentally inappropriate for web design and ignores the basic flexibility of the medium. Additionally, the Audi sites have a right-hand navigation that had to be visible without horizontal scrolling. Therefore, the layout had to expand and contract to fit variable browser sizes.

There are many ways to achieve flexible page layouts, but we developed what can be called an automated layout solution. Essentially, the Audi sites have “smart” pages that detect browser size and serve up the right layout automatically. Entire content areas of a page appear in different locations depending on the user’s resolution. These content boxes appear to “jump” around in the layout, hence the phrase “jumping boxes.” Three sizes are offered on the Audi sites —small (640×480), medium (800×600) and large (1024×768+).

There were at least two reasons for this approach. First, it fulfilled corporate design constraints. All page elements are aligned horizontally and vertically on a grid. Automated layout allowed us to better control alignment. Second, the solution is highly technical and speaks to the Audi slogan “Vorsprung durch Technik” (“Advancement Through Technology”). The site is based on JSP modules which are arranged to form a template. A style sheet (XSLT) controls the three possible arrangements of modules for a given template depending on the user’s browser size. This all happens in the front end and does not require extra server requests. In a sense, the layouts were supporting the brand with this technical solution.

An automated layout solution can be complicated to implement depending on the technology involved. For us, it proved to be more challenging than initially thought. Further, it is still unknown if there are any usability implications. We don’t believe so, but to date have no proof. Finally, the automated layout solution is not necessary for all page types.

With an increase of alternative browsing devices on the horizon, the continuum of viewable browsing sizes will continue to expand. Never before has the demand for flexible layouts been greater. Since the web stands at the center of our collective digital attention, solutions developed there can drive solutions in other formats and media. The Razorfish, Germany “jumping box” technique is an innovative technique, and we learned a great deal about page behavior from it.

Try resizing this screensaver download page on with an Internet Explorer browser to see the jumping boxes in action.
[] Right vs. Left Navigation
BMW, Mercedes and other car manufacturers generally have conservative page layouts with the navigation on the left or top. To set Audi apart from its competitors, we placed the navigation on the right side of the page. This solution addresses a core Audi brand value: innovation.

We tested the right-hand navigation extensively with our external partner, SirValuse. Two clickable prototypes, of about 10 pages each, were constructed – one with a left navigation and the other with a right navigation. 64 users were split into two groups of 32 each. This was a very large sample and not a sample of convenience: participants were recruited based on our user profiles and to fit Audi’s target group.

Prototypes used to test the Audi website.

The test consisted of three parts:
Part 1: Completion times for six tasks were timed with a stopwatch.
Part 2: Eye movements were analyzed to see where participants tend to look on the page.
Part 3: Users were directly asked what they thought about the right-hand navigation

Our hypothesis for Part 1 was that there would be a significant difference in task completion time for the first task and that by the last task there would be no significant difference in task completion time. We expected that users would need to use the site a couple of times to learn the uncommon pattern of interaction (i.e., a right-hand navigation), but that the learning curve would be very steep.

“Don Norman’s concept of affordance ‘the perceived properties of a thing that determine how it is to be used’ seems to be a better predictor of usability than conforming to standards or matching patterns to user expectations.”What we observed was surprising: There was no significant difference in completion times between the two navigation types for *any* task. In fact, the right hand navigation started to perform faster than the left in later tasks.

Part 2 looked at eye movement patterns. Instead of relying on traditional eye-tracking methods that make use of expensive equipment and headgear, we used a new method developed by an agency in Hamburg called Media Analyzer. This technique asks users to rapidly coordinate mouse clicks with where they look on the screen. Each click then represents a focal point of visual attention. A software program captures user interactions for later analysis.

We found that people tended to focus more on the content side of the page with a right navigation than with a left navigation.

In the final part of the test (Part 3), we asked several questions that addressed the central issue, “Do you like the right-hand navigation?” Overall, users were apathetic towards the navigation position. Most didn’t notice that the navigation was on the right and, when directly asked, they didn’t seem to care. However, seven people actually preferred the right navigation to a left navigation, while only two disliked it.

Subsequent usability tests and post-launch user feedback corroborate these findings: there is no apparent difficulty using a right-hand menu to navigate the and sites.

Though there is research about expectations of the location of page elements in a layout, such research does not correlate breaking these expectations with actual usability (see: Michael Bernard, and Jakob Nielsen, That is, while users normally anticipate a left-hand navigation, positioning the navigation elsewhere does not necessarily result in usability problems.

Don Norman’s concept of affordance —the perceived properties of a thing that determine how it is to be used —seems to be a better predictor of usability than conforming to standards or matching patterns to user expectations. With the Audi site, it is clear what is navigation and what is not. Users can build a pattern of interaction with the site immediately. Our findings show users have no problem distinguishing a right-justified navigation and tend to make generalizations about its function.

This does not mean that all sites should have a right-hand navigation. Indeed, a left-hand navigation may work best in most situations. However, for sites with particularly long texts that require scrolling, for example, a right-justified navigation might be beneficial.

The bottom line is that placing a navigation scheme elsewhere than on the left is not a taboo, contrary to “standards” professed by usability gurus. Without sacrificing usability, Razorfish, Germany was able to leverage a deviation in so-called standards to set Audi apart from its competitors and project an innovative brand image.

For more information:

James Kalbach is currently head of Information Architecture at Razorfish, Germany and has a masters degree in library and information science. Previously he established a usability lab at I-D Media, a large German digital agency. .