Category: Business Design

We Tried To Warn You, Part 1

by:   |  Posted on

I believe we all have a role to play in detecting, anticipating, and confronting the decisions that lead to breakdowns that threaten the organization’s very existence. In fact, the user experience function works closer to the real world of the customer than any other organizational role. We have a unique responsibility to detect and assess the potential for product and strategic failure.

There are many kinds of failure in large, complex organizations – breakdowns occur at every level of interaction, from interpersonal communication to enterprise finance. Some of these failures are everyday and even helpful, allowing us to safely and iteratively learn and improve communications and practices. Other failures – what I call large-scale – result from accumulated bad decisions, organizational defensiveness, and embedded organizational values that prevent people from confronting these issues in real time as they occur.

So while it may be difficult to acknowledge your own personal responsibility for an everyday screw-up, it’s impossible to get in front of the train of massive organizational failure once its gained momentum and the whole company is riding it straight over the cliff. There is no accountability for these types of failures, and usually no learning either. Leaders do not often reveal their “integrity moment” for these breakdowns. Similar failures could happen again to the same firm.

I believe we all have a role to play in detecting, anticipating, and confronting the decisions that lead to breakdowns that threaten the organization’s very existence. In fact, the user experience function works closer to the real world of the customer than any other organizational role. We have a unique responsibility to detect and assess the potential for product and strategic failure. We must try to stop the train, even if we are many steps removed from the larger decision making process at the root of these failures.

Organizations as wicked problems

Consider the following scenario: A $2B computer systems integrator provider spends most of a decade developing its next-generation platform and product, and spends untold amounts in labor, licenses, contracting, testing, sales and marketing, and facilities. Due to the extreme complexity of the application (user) domain, the project takes much longer than planned. Three technology waves come and go, but are accommodated in the development strategy: Proprietary client-server, Windows NT application, Internet + rich client.

By the time Web Services technologies matured, the product was finally released as a server-based, rich client application. However, the application was designed too rigidly for flexible configurations necessary for the customer base, and the platform performance compared poorly to the current product for which the project was designed as a replacement. Customers failed to adopt the product, and it was a huge write-off of most of a decade’s worth of investment.

The company recovered by facelifting its existing flagship product to embrace contemporary user interface design standards, but never developed a replacement product. A similar situation occurred with the CAD systems house SDRC, whose story ended as part two of a EDS fire sale acquisition of SDRC and Metaphase. These failures may be more common that we care to admit.

From a business and design perspective, several questions come to mind:

  • What were the triggering mistakes that led to the failure?
  • At what point in such a project could anyone in the organization have predicted an adoption failure?
  • What did designers do that contributed to the problem? What could IA/designers have done instead?
  • Were IA/designers able to detect the problems that led to failure? Were they able to effectively project this and make a case based on foreseen risks?
  • If people act rationally and make apparently sound decisions, where did failures actually happen?

This situation was not an application design failure; it was a total organizational failure. In fact, it’s a fairly common type of failure, and preventable. Obviously the market outcome was not the actual failure point. But as the product’s judgment day, the organization must recognize failure when goals utterly fail with customers. So if this is the case, where did the failures occur?

It may be impossible to see whether and where failures will occur, for many reasons. People are generally bad at predicting the systemic outcomes of situational actions – product managers cannot see how an interface design issue could lead to market failure. People are also very bad at predicting improbable events, and failure especially, due to the organizational bias against recognizing failures.

Organizational actors are unwilling to acknowledge small failures when they have occurred, let alone large failures. Business participants have unreasonably optimistic expectations for market performance, clouding their willingness to deal with emergent risks. We generally have strong biases toward attributing our skills when things go well, and to assigning external contingencies when things go badly. As Taleb (2007)1 says in The Black Swan:

“We humans are the victims of an asymmetry in the perception of random events. We attribute our success to our skills, and our failures to external events outside our control, namely to randomness. We feel responsible for the good stuff, but not for the bad. This causes us to think that we are better than others at whatever we do for a living. Ninety-four percent of Swedes believe that their driving skills put them in the top 50 percent of Swedish drivers; 84 percent of Frenchmen feel that their lovemaking abilities put them in the top half of French lovers.” (p. 152).

Organizations are complex, self-organizing, socio-technical systems. Furthermore, they can be considered “wicked problems,” as defined by Rittel and Webber (1973)2. Wicked problems require design thinking; they can be designed-to, but not necessarily designed. They cannot be “solved,” at least not in the analytical approaches of so-called rational decision makers. Rittel and Webber identify 10 characteristics of a wicked problem, most of which apply to large organizations as they exist, without even identifying an initial problem to be considered:

  • There is no definite formulation of a wicked problem.
  • Wicked problems have no stopping rules (you don’t know when you’re done).
  • Solutions to wicked problems are not true-or-false, but better or worse.
  • There is no immediate and no ultimate test of a solution to a wicked problem.
  • Every solution to a wicked problem is a “one-shot operation”; because there is no opportunity to learn by trial-and-error, every attempt counts significantly.
  • Wicked problems do not have an enumerable set of potential solutions.
  • Every wicked problem is essentially unique.
  • Every wicked problem can be considered to be a symptom of another [wicked] problem.
  • The causes of a wicked problem can be explained in numerous ways.
  • The planner has no right to be wrong.

These are attributes of the well-functioning organization, and apply as well to one pitched in the chaos of product or planning failure. The wicked problem frame also helps explain why we cannot trace a series of decisions to the outcomes of failure – there are too many alternative options or explanations within such a complex field. Considering failure as a wicked problem may offer a way out of the mess (as a design problem). But there will be no way to trace back or even learn from the originating events that the organization might have caught early enough to prevent the massive failure chain.

So we should view failure as an organizational dynamic, not as an event. By the time the signal failure event occurs (product adoption failure in intended market), the organizational failure is ancient history. Given the inherent complexity of large organizations, the dynamics of markets and timing products to market needs, and the interactions of hundred of people in large projects, where do we start to look for the first cracks of large-scale failure?

Types of organizational failure

How do we even know when an organization fails? What are the differences between a major product failure (involving function or adoption) and a business failure that threatens the organization?

An organizational-level failure is a recognizable event, one which typically follows a series of antecedent events or decisions that led to the large-scale breakdown. My working definition:

“When significant initiatives critical to business strategy fail to meet their highest-priority stated goals.”

When the breakdown affects everyone in the organization, we might say the organization has failed as whole, even if only a small number of actors are to blame. When this happens with small companies, such as the start-up I worked with early in my career as a human factors engineer, the source and the impact are obvious.

Our company of 10 people grew to nearly 20 in a month to scale up for a large IBM contract. All resources were brought into alignment to serve this contract, but after about 6 months, IBM cut the contract – a manager senior to our project lead hired a truck and carted away all our work product and computers, leaving us literally sitting at empty desks. We discovered that IBM had 3 internal projects working on the same product, and they selected the internal team that had finished first.

That team performed quickly, but their poor quality led to the product’s miserable failure in the marketplace. IBM suffered a major product failure, but not organizational failure. In Dayton, meanwhile, all of us except the company principals were out of work, and their firm folded within a year.

Small organizations have little resilience to protect them when mistakes happen. The demise of our start-up was caused by a direct external decision, and no amount of risk management planning would have landed us softly.

I also consulted with a rapidly growing technology company in California (Invisible Worlds) which landed hard in late 2000, along with many other tech firms and start-ups. Risk planning, or its equivalent, kept the product alive – but this start-up, along with firms large and small, disappeared during the dot-bomb year.

To what extent were internal dynamics to blame for these organizational failures? In retrospect, many of the dot-bombs had terrible business plans, no sustainable business models, and even less organic demand for their services. Most would have failed in a normal business climate. They floated up with the rise of investor sentiment, and crashed to reality as a class of enterprises, all of them able to save face by blaming external forces for organizational failure.

Organizational architecture and failure points

Recognizing this is a journal for designers, I’d like to extend our architectural model to include organizational structures and dynamics. Organizational architecture may have been first conceived in R. Howard’s 1992 HBR article “The CEO as organizational architect.” (The phrase has seen some academic treatment, but is not found in organizational science literature or MBA courses to a great extent.)

Organizations are “chaordic” as Dee Hock termed it, teetering between chaotic movement and ordered structures, never staying put long enough to have an enduring architectural mapping. However, structural metaphors are useful for planning, and good planning keeps organizations from failing. So let’s consider the term organizational architecture metaphorical, but valuable – giving us a consistent way of teasing apart the different components of a large organization related to decision, action, and role definition in large project teams.

Let’s start with organizational architecture and consider its relationships to information architecture. The continuity of control and information exchange between the macro (enterprise) and micro (product and information) architectures can be observed in intra-organizational communications. We could honestly state that all such failures originate as failures in communications. Organizational structure and processes are major components, but the idea of “an architecture,” as we should well know from IA, is not merely structural. An architectural approach to organizational design involves at least:

  • Structures: Enterprise, organizational, departmental, networks
  • Business processes: Product fulfillment, Product development, Customer service
  • Products: Structures and processes associated with products sold to markets
  • Practices: User Experience, Project management, Software design
  • People and roles: Titles, positions, assigned and informal roles
  • Finance: Accounting and financial rules that embed priorities and values
  • Communication rules: Explicit and implicit rules of communication and coordination
  • Styles of interaction: How work gets done, how people work together, formal behaviors
  • Values: Explicit and tacit values, priorities in decision making

Since we would need a book to describe the function and relationships within and between these dimensions, let’s see if the whole view suffices.

Each of these components are significant functions in the organizational mix, all reliant on communication to maintain its role and position in the internal architecture. While we may find may have a single communication point (a leader) in structures and people, most organizational functions are largely self-organizing, continuously reified through self-managing communication. They will not have a single failure point identifiable in a communication chain, because nearly all organizational conversations are redundant and will be propagated by other voices and in other formats.

Really bad decisions are caught in their early stages of communication, and become less bad through mediation by other players. So organizations persist largely because they have lots of backup. In the process of backup, we also see a lot of cover-up, a significant amount of consensus denial around the biggest failures. The stories people want to hear get repeated. You can see why everyday failures are easy to catch compared to royal breakdowns.

So are we even capable of discerning when a large-scale failure of the organizational system is immanent? Organizational failure is not a popular meme; employees can handle a project failure, but to acknowledge that the firm broke down – as a system – is another matter.

According to Chris Argyris (1992), organizational defensive routines are “any routine policies or actions that are intended to circumvent the experience of embarrassment or threat by bypassing the situations that may trigger these responses. Organizational defensive routines make it unlikely that the organization will address the factors that caused the embarrassment or threat in the first place. (p. 164)” Due to organizational defenses most managers will place the blame for such failure on individuals rather than the consequences of poor decisions or other root causes, and will deflect critique of the general management or decision making processes.

Figure 1 shows a pertinent view of the case organization, simplifying the architecture (to People, Process, Product, and Project) so that differences in structure, process, and timing can be drawn.

Projects are not considered part of architecture, but they reveal time dynamics and mobilize all the constituents of architecture. Projects are also where failures originate.

The timeline labeled “Feedback cycle” shows how smaller projects cycled user and market feedback quickly enough to impact product decisions and design, usually before initial release. Due to the significant scale, major rollout, and long sales cycle of the Retail Store Management product, the market feedback (sales) took most of a year to reach executives. By then, the trail’s gone cold.


Figure 1. Failure case study organization – Products and project timeframes. (View figure 1 at full-size.)

Over the project lifespan of Retail Store Management, the organization:

  • Planned a “revolutionary” not evolutionary product
  • Spun off and even sequestered the development team – to “innovate” undisturbed by the pedestrian projects of the going concern
  • Spent years developing “best practices,” for technology, development, and the retail practices embodied in the product
  • Kept the project a relative secret from rest of the company, until close to initial release
  • Evolved technology significantly over time as paradigms changed, starting as an NT client-server application, then distributed database, finally a Web-enabled rich client interface.

Large-scale failures can occur when the work domain and potential user acceptance (motivations and constraints) are not well understood. When a new product cannot fail, organizations will prohibit acknowledging even minor failures, with cumulative failures to learn building from small mistakes. This can lead to one very big failure at the product or organizational level.

We can see this kind of situation (as shown in Figure 1) generates many opportunities for communications to fail, leading to decisions based on biased information, and so on. From an abstract perspective, modeling the inter-organizational interactions as “boxes and arrows,” we may find it a simple exercise to “fix” these problems.

We can recommend (in this organization) actions such as educating project managers about UX, creating marketing-friendly usability sessions to enlist support from internal competitors, making well-timed pitches to senior management with line management support, et cetera.

But in reality, it usually does not work out this way. From a macro perspective, when large projects that “cannot fail” are managed aggressively in large organizations, the user experience function is typically subordinated to project management, product management, and development. User experience – whether expressing its user-centered design or usability roles – can be perceived as introducing new variables to a set of baselined requirements, regardless of lifecycle model (waterfall, incremental, or even Agile).

To make it worse (from the viewpoint of product or requirements management), we promote requirements changes from the high-authority position conferred by the reliance on user data. Under the organizational pressures of executing a top-down managed product strategy, leadership often closes ranks around the objectives. Complete alignment to strategy is expected across the entire team. Late-arriving user experience “findings” that could conflict with internal strategy will be treated as threatening, not helpful.

With such large, cross-departmental projects, signs of warning drawn from user data can be simply disregarded, as not fitting the current organizational frame. And if user studies are performed, significant conflicts with strategy can be discounted as the analyst’s interpretation.

There are battles we sometimes cannot win. In such plights, user experience professionals must draw on inner resources of experience, intuition, and common sense and develop alternatives to standard methods and processes. The quality of interpersonal communications may make more of a difference than any user data.

In part II, we will explore the factors of user experience role, the timing dynamics of large projects, and several alternatives to the framing of UX roles and organizations today.

Enterprise IA Methodologies:

by:   |  Posted on

Information architects working within enterprises are confronted by unique challenges relating to organisational culture, business processes, and internal politics. Compared to public website or interface design projects, key aspects differ in the application of IA discipline relating to uncertainties around the exact nature of the business problems being solved.

In a typical web or design project, the information architect is given a task, such as:

  • Improve the design of the website for consumers
  • Develop a user interface for a new business application
  • Make it easier for staff to find information on the intranet

In all these cases, the problem is known, and the challenge is to work out the best way to design the solution. User-centered design methodologies then provide a rich toolbox for delivering an effective solution.

However, within the enterprise space, the problem to be solved is often not well understood. For example, information architects may be approached with ill-defined “problems” such as:

  • Improve the effectiveness of the intranet
  • Help call center staff to access required information
  • Increase the uptake of the document management system
  • Support sales staff with better online resources

The first task for the information architect in this context is to better understand the problem. Only then can an overall approach be defined, and the normal user-centered design process initiated.

In practice, this means that enterprise IAs often start two steps earlier, focusing first on analyzing needs, and then defining a strategy and scope to meet those needs.

Traditional IA methodologies

EIA.0407.diagram1.jpg
Diagram 1: Illustrates a typical IA approach

While there are many valid ways to redesign a website or intranet, most projects start with user research to identify user tasks and goals. Then, the IA uses these results to develop a draft IA, which is tested in an iterative manner. Wireframes detail the user interface, and usability testing or similar techniques are used to refine it.

The overall goal of this approach is to clearly understand what the user is trying to achieve when using the site or system, allowing the IA to develop a solution that is both effective and satisfying.

This much is well understood, and much better documented elsewhere.

Enterprise IA approaches

Within the enterprise, the core user-centered design methodology remains just as valid. However, to be effective, the process must start two steps earlier.

EIA.0407.diagram2.jpg
Diagram 2: Illustrates an Enterprise IA approach

Step 1: Needs analysis
The first step now becomes needs analysis, which uses the same user research techniques as in typical user-centered design (interviews, contextual inquiry, observation), but to different ends. This time, we don’t ask questions about the system, but instead focus on obtaining a more complete and holistic picture of what staff do and the environment in which they work.

This might include questions such as:

  • What activities make up your job?
  • What information do you need to do these activities?
  • Where do you currently get this information?
  • How do you find out what’s happening in the organisation?
  • What is the most frustrating task you had to complete in the last month?

Rather than support the design process, this research helps the IA understand the nature of the problem. Open-ended and ethnographic, this research will undoubtedly highlight the unexpected and the unknown, both of which radically shape the approach going forward.

(For more on needs analysis in the context of intranets, see my earlier article on this topic, “Succeeding at IA in the Enterprise”)

2: Strategy and scope
The needs analysis then informs the creation of an overall strategy, scope and direction. From this clear framework for the IA work, a comprehensive overall roadmap of the activities required can emerge. The strategy also identifies the most critical issues to be solved, along with the activities with the potential to deliver the greatest business benefits. In this way, the IA work can be targeted for the greatest impact.

In many cases, needs analysis helps the team discover underlying issues which need to be addressed before any IA or design activity can succeed. (Cultural and business process issues are common examples.)

Together, the strategy and scope define the “problem” and provide a concrete context for the user-centered design process. Along with the illumination of the practical aspects of the work to come, the strategy also builds the business case for change and creates a sense of urgency.

A real-life case study drawn from a number of different intranet projects in call center environments illustrates the effects of the enterprise approach.

Case Study: Call Centers

In many organisations, call centers now serve as the primary point of contact with customers or the public. Whether in the insurance industry or within a government agency, call centers handle a huge volume of queries and transactions.

Within the call center, staff work in a high-pressure environment. They are expected to literally answer questions correctly within 30 seconds. Failure to deliver the right information leads to customer complaints or legal liability (organisations are directly responsible for every piece of information given out by a call center). Slow response times can create long queues, more complaints, and customer attrition.

To meet these expectations, call center staff require an effective and well-designed set of information resources. The typical call center intranet contains a large number of documents and news items for staff.

As an information architect, we are often brought into this environment to ‘redesign the call center intranet, to make it into an effective resource for staff. Based on experiences in other environments, it is natural to make a number of assumptions about where efforts should be focused:

  • The most common questions or transactions handled by staff should be identified
  • Effort should then be focused on providing resources to answer these key tasks
  • Paper resources should be migrated onto the call center intranet where possible
  • A user-centered redesign should be conducted of the call center intranet, to ensure it is effective

Spend a day or two in the call center, and the gap between these assumptions and reality will quickly become apparent. Let’s look at a call center in the insurance and investment industry.

In this particular case, the most obvious non-technical artifact in the call center was the book of photocopied notes that most staff had sitting beside them, scribbled on and annotated with sticky notes. Then there were the sheets pinned to the cubicle walls, similarly inscribed.

Additionally, product brochures adorned everyone’s desk to cover the 30-40 products sold at any given point. A deeper look uncovered the huge amount of email filed away in folders within Outlook.

There were good reasons why the call center worked in this manner:

  • Customers rang up asking, “On page 54 it says this, but what does it mean?” The call center staff needed to quickly access the same page to walk them through the details.
  • Key information (such as system codes) needed to be instantly available. Pieces of paper pinned to the wall would always be quicker than looking up an electronic system.
  • All important communications were broadcast via email, and maybe (only maybe) added to the intranet. Since the details probably were not needed at that point, it was necessary to file away the emails for later use.

In this situation, we drew some unexpected conclusions from these (and other) observations, even having been primed by previous call center projects.

In the end, our efforts focused on:

  • Managing uncommon rather than common details: The information related to the most frequent queries or transactions resided in the heads of staff. The complex issue that only came up every 6-12 months posed the real challenge.
  • Capturing old rather than new information: The brochures for the current products worked perfectly well. The real problem came from investment products that could go back decades and were still covered by the original terms of the contract. Finding a 20 year-old printed policy was not easy!
  • Eliminating email as the distribution mechanism: As long as email remained the primary way to deliver critical information, the intranet could never succeed. There were also clear productivity benefits in eliminating the duplicated information management conducted by every individual staff member.

The net result was that the call intranet still needed redesigning, but the needs analysis gave a very clear idea of where to focus efforts and identified the unique environmental aspects of call centers to be taken into account when conducting any work.

Solving the Wrong Problem

This case study highlights the importance of conducting the needs analysis process before embarking on any design or development activities. Failure to do so exposes the organisation to the risk of solving the wrong problem—putting significant effort into developing a solution that fails to work in practice.

Always assess the issue at hand to work out whether it is the cause or merely the symptom. For example, the intranet may be very poorly structured, with considerable usability problems. This naturally calls for a user-centered design project delivering a new IA and page layouts.

However, the underlying causes of the problem may be the disorganised publishing model, the lack of resources, or key cultural problems. If only the symptom (the design of the site) is tackled, the site will immediately start to slide back into disrepair the day it is re-launched.

A small piece of initial needs analysis work and strategy and scope planning allows identification of these underlying problems. Address them, if possible, before (or during) the project, improving the chances that the site continues to prosper post go-live.

Summary

Within the enterprise environment, our methodologies must start two steps earlier than the typical user-centered design process.

  1. Make use of holistic needs analysis techniques to build a clear picture of the real needs and issues of staff, along with an understanding of the environment in which they work.

  2. Then create a meaningful strategy and scope that identifies the symptoms and the causes. This information allows us to correctly target our work and ensure that we deliver solutions that actually work for staff.

 

(All of this is not to say that it’s easy to get the opportunity or the mandate to conduct this initial work, before being forced to jump straight into the design process. But it is possible—we’ve done it many times—and a discussion of how to tackle the broader positioning of enterprise IA will have to wait until another article.)

About the author
James Robertson is apparently the “intranet guy,” or so he was told at the IA Summit in Vancouver. He runs Step Two Designs (www.steptwo.com.au), a consultancy based in Sydney, Australia, and has written over 150 articles on intranets and content management, which can be found on his site. He also has a blog, the writing of which gives him something to do each morning while his brain warms up.

Change Architecture: Bringing IA to the Business Domain

by:   |  Posted on

“Information architects hold the potential to become master Bead Game players who help companies play the right music to succeed. But gaining a seat at the business table requires that we change aspects of our usual perspective.”

In Herman Hesse’s Nobel-prize winning novel, The Glass Bead Game, skilled players tap into a symbolic language that encodes all of human knowledge into a kind of music to be played and shared: [1]

These rules, the sign language and grammar of the Game, constitute a kind of highly developed secret language drawing upon several sciences and arts, but especially mathematics and music (and/ or musicology), and capable of expressing and establishing interrelationships between the content and conclusions of nearly all scholarly disciplines. … on all this immense body of intellectual values the Glass Bead Game player plays like the organist on an organ. [2]

Today, as the world of knowledge increasingly resides encoded in digital form, stored in databases, and accessed through the web, information architects hold the potential to become master Bead Game players who help companies play the right music to succeed. But gaining a seat at the business table requires that we change aspects of our usual perspective.

As IAs, we are not just architecting information; we are using information to architect change. In “traditional” information architecture, the target of work is usually a website or a web-based application. Change architecture steps outside of these bounds. The domain is not limited to a web team; it expands to include today’s dynamic business environment and the way people, processes, and tools interact and interoperate. The target is no longer limited to web browsers; rather, it is the minds of those people charged with understanding the broader business landscape and contributing to better business decisions.

When seen from a change architecture perspective, the IA’s existing toolkit—normally used to discover and capture information, re-categorize content for easier consumption, and visualize ideas for shared understanding and action—naturally supports this expanded business domain. IAs can help companies reap the benefits of positive change by reducing fear of change, creating hope for the future, enhancing adaptivity to change, and architecting applications and processes that enable business success.

Thinking about change architecture raises new questions:

  • How can we clearly communicate with clients about the ways information architecture paves the way for positive change?
  • What role do digital (or even physical) assets—including site maps, work flows, and visual explanations—play in helping a team and a company share a vision for change?
  • How do we help our clients, and their employees or customers, adapt to and embrace change?
  • How can we change the perception that IA is just a step in a website production process?

Not just for websites anymore

In fact, a number of information architects are already applying IA methods to business problems beyond the web. A few recent cases in point:

  • At Vanguard, the mutual fund firm, information architects Richard Dalton and Rob Weening stepped into the company’s strategic planning process to synthesize and visualize findings from extensive client interviews and make recommendations to internal business decision-makers about solving key pain points. Dalton and Weening faced initial skepticism about the ability of IA to overcome what they call the “web design” stereotype in the strategic planning arena. [3]
  • At Dynamic Diagrams, a Rhode Island-based information architecture firm, the company’s “visual explanation” services are often employed by companies with complex business processes or products to help put an internal team on the same page. The Dynamic Diagrams team advocates the use of “isometric” illustrations that bring perspective—in both the literal and figurative sense—to large-scale information and process issues. [4] “When applied correctly,” note several members of the firm in the Interaction Design Journal, “the introduction of depth makes the information easier to grasp by appealing to our intuitive understanding of space.”
  • At EZgov, which helps bring government services online, information architect Peter Boersma and other internal team members convinced decision makers to incorporate user-centered practices into the company’s software development process. Their persuasion tools include workflows and process maps overlaid by visual design. [5]

Commenting on his experience, Boersma notes that visuals, when converted into life-size objects such as posters, can help convert an abstract realm into something tangible that the team can talk about: “Visual explanations, when designed well, are the proverbial pictures that are worth more than 1000 words; they make lengthy explanations unnecessary. But, more importantly, they allow for discussion by pointing at things and indicating relationships by drawing lines in the air, when the visual is projected or hung on the wall.” [6]

The physical form, scale, and transmission of visual explanations can become extremely important as the medium for “spreading the news.” Dalton and Weening created one large-scale information map, and then hundreds of smaller “placemat” versions that were distributed to business units. [7] Depending on a particular IA’s skill set, these visual assets may be developed directly by him or her, or they may be developed in close collaboration with a visual designer.

Anecdotal evidence points to an evolution of IA as a unique approach to business consulting that combines analysis with tangible digital assets and actions. While business consulting comes in many flavors, information architects bring a particular set of top-down and bottom-up tools and capabilities to the table. IA practitioners may not necessarily think of themselves as change architects or persons engaged in change architecture, but there is a common thread of working to make changes in the process and/or perceptions of a collaborative team.

Learning more about change

As IAs, we know a lot about working with information. However, we need to learn more about attitudes toward change. Areas of knowledge that could be incorporated into change architecture include business strategy, business process intelligence, and cultural psychology. Change architecture could also benefit from the lessons of change management, a business consulting approach with roots that pre-date the emergence of the web.

One of the key models in change management comes from Kurt Lewin, one of the founders of modern social psychology. Lewin suggested a three-phase approach of change, which has been distilled into the following framework: Unfreeze, Transition, and Refreeze. Here’s a quick look at each phase:

Unfreeze: People tend to create a comfort zone where habits, patterns, and processes repeat in a somewhat static, fixed way. This gives them a sense of familiarity, control, and purpose. As Charles Handy writes in an essay, Unimagined Future: “Most of us prefer to walk backward into the future, a posture which may be uncomfortable but which at least allows us to keep on looking at familiar things as long as we can.” [8] There is an instinctive and understandable resistance to change. Old patterns have a powerful ability to propagate across a culture, achieving a kind of cultural lock-in and monopolizing the way people think about possibilities. Before someone becomes change-ready, they often need to be “unfrozen” from their static environment.

Transition: Transitioning marks the journey across the chasm of change. People and organizations reconfigure themselves from an old formation to a new one (“re-form”), through many different and often difficult realignment steps and stages. The first step is often the hardest, and leaders need tools to help people to avoid “change shock”, feel hopeful about change, and acclimate to the new possibilities.

The writings of creativity expert Edward de Bono are an excellent source of transitioning tools. He draws the following analogy in his book, Parallel Thinking: “Your existing cooking-pots may allow you to cook all the meals you have always cooked, but if one day you want to cook dim sum, then you may need to get a proper steamer system.” [9]

The practice of IA provides transitioning tools that can help people limber up their thinking and explore new structures, new terminology, and new approaches. For example, card-sorting sessions, interactive prototypes, and visual explanations safely simulate change in advance and let people “try it on for size” before the full change arrives.

Refreeze: Aims to bring a renewed sense of confidence and comfort to the person or organization’s changed environment. Refreezing also helps bolster the changes, so the organization avoids falling back into the earlier frozen patterns. (Alas, refreezing is perhaps not the best word choice. In today’s constantly changing environment, one shouldn’t strive to achieve another frozen state, but rather an integration of stability and dynamism.)

Big change, small change, and loose change

Lewin’s change model brings to mind major top-down changes. But what about the smaller-scale everyday decisions that drive the tempo and tenor of business? In their article, “Who Has The D? How Clear Decision Roles Enhance Organizational Performance” in the January 2006 issue of the Harvard Business Review, Bain & Company consultants Paul Rogers and Marda Blenko offer a compelling framework for clearing decision bottlenecks. [10]

They call it “RAPID,” for the sake of a catchy acronym (even though the terms are ordered differently), and define five key roles in the decision-making process: those who recommend a course of action based on discovery and analysis, those who offer input on the recommendation, those who review and agree to the recommendation, those who ultimately decide on the recommendation, and those who perform the decided action.

Although the Rogers and Blenko article focuses on role-definition, not information architecture, it has a number of implications for our field. For one, information architects are often asked to perform a recommendation role. The often-hazy path leading from recommendation to decision and action has historically been a source of great professional frustration to many IAs, who may chalk up shortcomings in that terrain to “politics.” From a change architecture perspective, the conflict inherent in this decision-making process may be seen instead as an opportunity. While people often disagree over the possible outcomes and pace of change, we need to understand that conflict is an attribute—not a side effect—of the decision-making process. In addition, business decisions increasingly play out across a distributed team that never actually converges face-to-face. Decisions hang in the ether and, in the words of Rogers and Blenko, “get stuck inside the organization like loose change.”

If we IAs become attuned to this situation, we’ll come to understand that the assets we create for fostering understanding are well-suited to helping clear these decision-making bottlenecks and improving the decision “throughput” across the company. Teams that are divided by office, country, continent, and culture can be placed on the same page. IAs are in a position to not only inform the situation, but also proactively propose a workflow to define the path leading from a recommendation to “performing” that recommendation. With these approaches, an information architect can become a kind of Black Belt in architecting and navigating big, small, and even loose change within an organization.

Is change architecture worth changing for?

Using the paradigm of change architecture, IAs can become more aware of the idea that when we step onto the business stage of a project, we will first need to unfreeze aspects of the situation and the environment, and ultimately make the path from recommendation to action visible to the participants.

Change architecture could even be applied to the trade of information architecture itself. When I began as an information architect 10 years ago, such matters were outside my field of vision; I thought of my role only in terms of providing information and documentation. Today, I recognize that practicing information architecture in an organization—either as an employee or as a consultant—requires intervention, persuasion, and leadership.

For many IAs, even the idea that the first phase of a new project engagement requires unfreezing to create a change-ready state would itself represent a major change. But information architecture may be a domain that is ready for a sea change. The signs are there: the internal soul-searching that has taken place on IA mailing lists and conferences, the seeming confusion about the overlap or gap between IA and design, and the struggle to find a shared language. Could it be we are unfreezing, heading toward transition?

Learn More

Podcast with Bob Goodman on Change Architecture “Bob also shares his thoughts about Web 2.0 and the value add this new approach to the web will bring to organizations. As well, we discuss different approaches to IA and Usability including card sorting and Bob’s experiences with Listening Labs.”

Footnotes:

[1] The connection of the “Glass Bead Game” and its players to the domain of “information visualization” was recently noted by Alan Marcus, “Visualizing the Future of Information Visualization”, Interactions, (March/April 2006): 42-43.

[2] Herman Hess, The Glass Bead Game, (New York: Picador, 2002), 15.

[3] Robert Dalton and Rob Weening, “A Foray Across Boundaries: Applying IA to Business Strategy and Planning”, (Power Point presentation.)

[4] Paul Kahn, Piotr Kaczmarek, Krzysztof Lenk, “Applications of Isometric Projection for Visualizing Web Sites”, Information Design Journal, (Volume 10, No. 3, 2000): 221-229.

[5] Peter, Boersma, “Integrating IA Deliverables in a Web application methodology”, paper adapted from ASIS&T Bulletin publication, February/March 2005.

[6] Peter Boersma, e-mail exchange, March 2006.

[7] Dalton and Weening, “A Foray Across Boundaries.”

[8] Charles Handy, “Unimagined Future,” in The Drucker Foundation : The Organization of the Future, ed. Marshall Goldsmith (San Fransico: Jossey-Bass, 1996): 377.

[9] Edward, Debono, “Parallel Thinking,” (London: Viking, 1995),

[10] Paul Rogers and Marda Blenko, “Who Has The D?,” Harvard Business Review (January 2006): 53-61.

Value-Driven Intranet Design

by:   |  Posted on

Fundamentally, your intranet must be tied to value creation like other business services within your organization.

Within most corporations, taking ownership of an intranet is an unglamorous, exhausting, and thankless job for a new intranet manager. Many corporate intranets lack thoughtful, focused, and disciplined design and are often extremely large and unwieldy. Fixing these intranets can seem an impossible and futile task.

Furthermore, with new terminology proliferating from the armies of IT consultants, software vendors and business professors in the marketplace, it is becoming even harder to define an intranet, determine what it should accomplish, and measure those accomplishments. In the domain of company intranets, terms like empty portals, peer-to-peer sharing, smart enterprises, digital dashboards, social networks, taxonomy design, and knowledge management all come together and compete for attention and dollars. These buzzwords capture the imagination of senior executives who force you to devote dollars to intranet-related initiatives that the organization may not be ready for or that do not benefit the employee community.

Managing these internal and external challenges and developing your intranet into a meaningful, measurable, and relevant business tool can be difficult and draining. But if you reduce your intranet to its essence, use consultants smartly, manage your stakeholders and users effectively, and approach it with the same rigor, discipline, and focus you do with any other business initiative, your task can quickly become much simpler.

Defining the intranet’s value

Fundamentally, your intranet must be tied to value creation like other business services within your organization. If it does not result in value creation for your business, the intranet is a failed service. Establishing value creation can be tricky. Intranet objectives such as increased employee communication, collaboration, and knowledge management are hard to quantify and measure. As a result, some corporations choose to establish tactile goals in the form of metrics such as page views, total hits, and customer satisfaction ratings. This approach is not effective for understanding and measuring the value creation driven through your intranet. Measuring the value is difficult, as the intranet’s greatest benefits to an organization are not in a measurable, packaged, and corporeal form. So how do you determine the value of an intranet?

A recent MIT Sloan Management Review article by C.K. Prahalad and Venkatram Ramaswamy introduces an approach to understanding value creation, which can be applied to understanding an intranet’s value as well. Prahalad and Ramaswamy discuss how value is increasingly being defined through the co-creation of experiences in which the consumer (in this case, the employee) triggers value creation through the combination of a personal event-based need and the actual services being provided. The nature of the individual’s involvement, the personal event that leads to the interaction, and the personal meaning derived from the interaction are what determine the value creation.

This theory applies to the intranet domain where the intranet alone doesn’t create value, but the site’s efficient, able use in the context of specific, individual employee needs does. The use of the intranet in the context of other services provided by the organization also affects the value creation. Unlike a product or service that is sold to a consumer and therefore has an easily recognizable cost and perceived value, the use of an intranet rarely costs an employee anything. As a result, the value is not assessed at the point of purchase but rather at the point of use, and therefore is tied directly to how it is used.

This approach for understanding an intranet’s value can seem to make it still harder to measure the value because the value creation happens at a personal, individualized, non-structured, and non-measurable level. Also, measuring the value of the intranet at the point of use puts the onus on the employee to create value by using the intranet more effectively. With such a definition of value creation for your intranet, can the value be measured at all?

Measuring the intranet’s value

In this context, breaking up your intranet into discrete, tightly defined services is the first step in measuring its value. These discrete services should provide tangible benefits to narrowly defined target audiences. They should be as self-contained as possible and ideally should be designed, positioned, and perceived as co-services in the context of other services provided in the offline space to the target audiences.

Let’s take the case of sales information in a drug company to explore this point. Intranets are commonly used as platforms to distribute market share and sales information to field sales representatives. The effective and efficient dissemination of timely sales information segmented by product and region is, in this example, the means for determining the value creation.

In this case, the business objective is to share the sales information. This objective can be divided into a series of discrete services by information type, namely the broadcasting of general market share information by brand and region; market-specific sales and competitor trends to representatives in a particular region; and finally real time, sales-representative-specific raw sales data that is used to motivate each sales person and communicate progress towards individual monthly targets.

The next step is to take one of these services—for example, the communication of sales-representative-specific sales data—and ask yourself and the specific target audience questions such as:

  • Is this service being delivered in the offline space?
  • If so, how effectively is it being delivered and is it reaching all of its target audience?
  • Can the service be delivered more effectively and efficiently via the intranet?
  • Will it reach a larger percentage of the target audience?
  • Will the offline service need to continue once the intranet service is launched?
  • How does the target audience benefit from access to the service?
  • Under what circumstances will they use this service?
  • Does it make a meaningful difference to their jobs?
  • Does it enable them to create measurable value for the company?
  • Do they have the right tools, usage patterns, and motivations to use the service?

The questions above are designed to help you truly understand the need for the service, the context in which the service will be used, the tie to the business value through the service, and the personal event triggers that will motivate use of the service. Without looking at each of these elements in the context of each service piece on your intranet, it will be hard to determine value creation and prioritize future enhancements.

As you go through the exercise above of dividing your intranet into discrete services and determining how they create value for the organization, you will quickly uncover certain trends that are commonly seen across large corporate intranets.

These trends include:

  • Value creation is optimized around a small set of high-value core services, which provide dependable value to tightly defined target audiences.
  • These high-value core services are not expensive to deliver and manage. Their success lies in their recognition of basic employee needs and the simplicity with which they respond to those needs.
  • High-value core services share similarities in how they serve their audiences, the personal events that trigger their uses, and the methods of generating value through their use. This is because these services are most in tune with the organizational behavior and culture of the organization and fit neatly into that modus operandi.
  • Services with extremely narrowly defined audiences based in one location are less successful, as offline and unstructured mechanisms for communication, collaboration, knowledge management, and task performance needs take precedence. There’s often a direction correlation between the size of your target audiences, how geographically dispersed they are, and the value of a particular service.
  • Similarly, services that have carelessly defined target audiences fail because the broader and more loosely defined the target audience, the more challenging it is to identify common personal event triggers and design a service to meaningfully respond to those triggers.

When you complete the exercise of identifying the high-value core services—i.e., the services on your intranet that result in the greatest value creation for the organization at the least cost—you will discover how your intranet is currently being perceived and valued. If your intranet is not providing much value, it is a sign either that there’s lots of room for improvement or that other tools and processes within your organization are serving your employee needs effectively enough.

Managing and nurturing talent

Once you have determined where your intranet’s value lies, the next questions are what should it do for your organization, and how do you create optimal environments for value creation. This is where two fundamental business drivers come into play: managing your talent pool and listening very closely to your customers.

Managing and nurturing talent is always challenging, and it becomes even harder when providing a technological service to an internal clientele. How do you identify the right resources to deliver on the promise of your intranet? How do you find them in the first place? Do they reside within your organization or do you have to bring in consultants enmasse to do the job for you? What about knowledge transfer and providing exciting growth opportunities for your team once the core set of intranet services has been built?

The following steps can help you manage your talent pool more effectively.

  1. Identify an intranet solutions strategist.
    The strategist is an individual who intuitively understands the potential of your intranet as well as the limits of what it can cost-effectively accomplish from a business perspective. This person needs to have enough intranet design experience, preferably in other organizations, to be able to quickly grasp the current state of the intranet, identify the key areas to focus on for improvement, and bring in the right skills to execute on the creation of new services and the redesign of existing ones. The intranet solutions strategist needs to have seen it all before, and should ideally also have experience in project execution and the management of interdisciplinary teams. This person can either be an employee or a consultant.
  2. Organize your teams by services delivered rather than skill silos.
    Interdisciplinary teams are recognized as being more cost-effective and more likely to deliver on-time and on-budget services. Each service team should have the use of the intranet solutions strategist’s time for guiding the design and development of their core services. Roles and responsibilities should be determined in a similar fashion to those defined for the cell teams that are common in manufacturing plants. Cell teams closely locate people and equipment required for certain processing families of like products. The cell’s operators are often cross-trained on several tasks, engage in job rotation, and take more ownership and responsibility than in normal manufacturing plants. Similarly, your intranet service teams must share a common value system, work practices and means of communication. A certain degree of creative dissonance should be tolerated but nevertheless controlled.
  3. Establish measurable objectives for these teams.
    These teams should be given core services to develop or redevelop within specified timeframes. They should be financially motivated for timely delivery, cost control, and customer acceptance. The teams should always have visibility into the work that will follow the delivery of their current project. Creating an atmosphere of professional competitiveness between teams can serve as a motivator, especially if the teams have financial incentives.
  4. Leverage teams across all web properties.
    Your intranet teams should not be confined to intranet design but should be given opportunities to take on the design and development of services related to external website and extranet projects. The philosophies that drive strong intranet design whether in the business analysis, user experience, or technology sphere are just as applicable to other web initiatives.
  5. Encourage and reward cross-pollination with other business units.
    If you manage an intranet in a large organization, encourage other departments to borrow your more junior employees for short periods. The experience in the business will be rewarding for the team members, and it will bring fresh insights into intranet usage patterns, strategies, and tactics for new services that benefit the business and exposure to business processes. Likewise, bringing in employees from the business for short periods will give your teams new insights into the business and how to optimize the intranet around use. Unlike an external web solution, you have the benefit of having your customers work for your CEO just as you do. This provides incredible opportunities for understanding and serving them better — short-term cross-pollination is one such opportunity that should not be missed.

Usually the best person to play the intranet solutions strategist role is an external consultant, as you want someone with diverse experience.

Using consultants effectively

As you have probably observed, the team structures recommended above share many similarities to the way consultancies are organized. This is because consultancies are tightly focused on delivery and cost control. So do you need consultants at all, and if so, how do you use them? This is where things can get a little trickier.

Usually the best person to play the intranet solutions strategist role is an external consultant, as you want someone with diverse experience. This consultant would naturally rather lead his or her own teams than have to shepherd internal employees. Often that can be a condition for a consultant accepting such a position. So how do you resolve this dilemma?

The answer is to either combine your teams with the consultant’s team (which the external firm will resist, arguing that there are increased delivery and quality risks involved in mixing teams), or to bring in the consulting firm to deliver certain services while having your internal team develop other services. In the situation presented above, it is much easier to engage with the consulting firm and leverage the intranet solutions strategist across all the teams. The goal should be to engage with the intranet solutions strategist on a near-permanent basis and bring in consulting teams occasionally to augment your internal talent pool.

What if you do not have the right type of talent in-house? The answer is to invest in training and hiring as soon as you can. Using consultants to solve your talent shortages is an expensive solution, and while it will produce the quick short-term results that you may need to deliver, in the long term it will turn out to be much more expensive. The only exception to this rule is if you find that your intranet initiatives are not complex enough or continuous to warrant full time internal teams.

Listening to your customers

The importance of listening to your customers in business can never be underemphasized, and it matters just as much in the intranet domain. Ironically, because your customers are so close to you, you might be in a situation where you believe that you are listening to them when you actually aren’t. Inter-department politics and clashes over annual budgets make it hard to listen to what the business community is saying versus what you’d like them to be saying.

The following steps can help you listen better:

  1. Organize yourself into a result-oriented governance model that includes representation from your business community.
    These representatives should be able to commit at least ten hours each month to prioritize services, support usability testing, and serve as champions for new services rolled out. Do not depend on them for anything else. You might be accused of taking more of their time than you should and, worse still, inviting them to make decisions in areas that they shouldn’t. Making all intranet-related documentation available to them should greatly mitigate the concerns regarding involvement that they may have.
  2. Set up a usability laboratory for monthly testing.
    Usability labs are extremely cheap to set up and manage and they provide immense benefits to your intranet teams. Require monthly usability testing of new or redesigned services; this will put pressure on your intranet teams to deliver something each month, and it will keep your user community involved. Publish the results of these tests for all your intranet teams and the larger business community. Rotate which user representatives get to participate in the usability testing. Invite senior executives and your business representatives to watch the testing so that they understand the challenges of intranet design.
  3. Design and deploy for use.
    Engage with your business community as actively as possible for the design and rollout of a particular service. Make them feel like you are providing them a service and that they are your client. Listen and understand the business needs, and map these processes on paper before designing a digital solution. Promote transparency and engage with them to provide feedback at critical stages. Be careful not to include them to such an extent that your design process evolves into participatory design. The business owners are not your intranet designers; they are your users, and just as car manufacturers regularly bring in customers to view prototypes but refuse to let them participate in the actual design process, so should you limit the participation of your business users.
    This needs to be done tactfully; these representatives need to be your champions, so you don’t want to disenfranchise them. There’s an axiom in the business community that if you want your boss to like your decisions, let him or her make them for you. Don’t fall victim to that axiom.
  4. Always question the value creation.
    Demonstrate to the business community how your intranet is broken into a series of services with core audiences to whom you provide measurable value. Encourage them to think of new services for additional value creation. Keep them updated on releases, delays, and plans for future services. Don’t be afraid to scrap projects midway through if you discover they will not provide sufficient value. While this may hurt you in the short term, as your detractors will consider it a failure, in the long term it will establish greater credibility.

Conclusion

Too often, large corporations approach intranet design like any other technological initiative. You have your end users. You have the technology, an interface, and the usual parameters of cost, time, build-versus-buy decision making, resourcing, and interoperability with other technology. But intranet design is not just another technology initiative. Rather, it is a targeted business service to employees within your organization. Greater emphasis should be put on the strategy and the design and less on the technological implementation. An intranet’s value should never be determined by what technology it uses, how quickly it is rolled out, or how many standards it complies with. Keep this in mind as you design your intranet, establish where value creation lies, and engage with your customers.

Also remember that the value of your intranet might be hidden and not immediately apparent. If designed appropriately, your intranet can provide immense value to your employee base. This was seen in a Watson Wyatt HCI study, which revealed that implementing technologies that improve employee service can increase shareholder value by as much as 2.3 percent (Watson Wyatt’s 2001 Human Capital Index® [HCI] study). This means that organizations can generate an additional 2.3 percent increase in shareholder value by using employee relationship solutions to reduce the costs associated with delivering service to employees. This is not a percentage to ignore.

Fixing an intranet can be likened to trying to repair a submarine while at sea. Your customers will continue to have needs for new services and functionality while you try to fix the existing problems. But by identifying where the true value of your intranet lies, managing your talent pool effectively, and engaging with your business community strategically, you will be able to align your customers with your vision of the intranet, meet their most important needs, and fix the right services at the same time.

  • Prahalad C.K, Ramaswamy V., (2003) “The New Frontier of Experience Innovation”

Shiv Singh is an Experience Lead & Information Architect with SBI.Razorfish. Working out of SBI’s London office, he spent most of 2003 leading the user research and experience design team for an enterprise intranet that is being launched in 50 countries over the next two years. Prior to that, he worked on a large multidisciplinary SBI.Razorfish team that developed a decision support intranet for a Fortune 1000 company. He has been conceptualizing, designing, and building websites and intranets since 1995, and likes to work at the intersection of business strategy and information architecture.

Designing Customer-Centered Organizations

by:   |  Posted on
“True product innovation requires a radical rethinking of our roles as researchers and designers.”Which way?
Organizations increasingly view usability and user-centered design to be a key ingredient in creating high quality products. Designing for ease of use is a well-accepted goal, even if many organizations have far to go to create user-centered products. Even with the present downturn in the economy, more companies, from new media to established banks, have larger usability and design teams than ever before. Should we be content that we have come so far?

In this context of greater corporate presence, how should user-centered design advocates evaluate whether the field has achieved success? We suggest two questions as possible criteria. First, are the products and services we build becoming more innovative in serving our customers’ needs? And are we, as professionals, confident that our activities are as effective as they can be?

User experience practitioners have long called for their involvement at the earliest stages of product development. If only they could be involved at the start of a project, their voices—and the customers they wish to serve—would have a greater impact on the type of products and services that ultimately get produced. This laudable goal acknowledges the often-late role of usability in the product development cycle, closer to implementation than inception. Less talked about is how even design often occurs late in business formation and product creation—after entrepreneurs and investors have created business plans and goals, and after product managers have defined product strategy and metrics.

True product innovation requires a radical rethinking of our roles as researchers and designers. Smart companies will gradually adopt early stage consideration of usage and users, with innovations in specific products and, more importantly, sets of products. To accelerate innovation, we must go beyond project-by-project improvements and employ many of our existing skills and methods to create customer-centered organizations. Rather than focusing on products, our impact can be greatest when we become advocates for developing organizational capital, the ability of companies to maximize the value of their investments in technology and ultimately their impact on the customers they wish to serve.

This article focuses on the shift from customer-centered products to customer-centered organizations through an emphasis on the why and how of creating change. Contextual research, iterative prototyping, customer frameworks and models, workflow diagramming, and building consensus are skills many interactive user experience professionals already have. Working with cross-functional teams of technologists, marketers, executives, researchers, and designers, we have begun to shift our work, in-house and as consultants, to building organizational capital.

Why now?
Companies are under more pressure than ever to achieve dramatic increases in their operational effectiveness. Despite recent times of relatively flat or even negative sales growth within many industries, expectations for ongoing improvement to the bottom line persist. As a result, reducing the costs of bringing successful products or services to market is a primary concern for even the most successful companies.

At the same time, as market competitiveness increases, the need for effective product strategies similarly becomes much more important. As the range and number of similar products offered to consumers expands, it is an ever greater challenge to define a unique and differentiated value proposition that attracts consumers’ attention and convinces them to buy your product over that of a competitor, and keeps them coming back for repeat purchases.

User-centered design (UCD) methods, now increasingly well-known, offer help on both of these fronts. By incorporating knowledge of how customers will use and react to new products, designers help reduce the risk that costs related to bringing products to market will fail to generate a return. Additionally, by putting more emphasis on the design of the product up front, development cycles can often be dramatically shortened, reducing the time and cost of developing the product. By prototyping product concepts early in the development cycle, teams have a higher likelihood of catching expensive errors earlier in the process when they are cheaper to correct.

Furthermore, early stage user research can identify strategic and tactical opportunities for product differentiation. By illuminating how different customers are likely to interact with the proposed product, research can help clarify and prioritize which features are likely to result in the most benefit and appeal. Designers can then work with researchers to prototype product designs that account for critical user tasks and contexts of use, iteratively refining the end product.

But despite the promises these user and usage-centered design methods hold for reducing development costs and increasing product quality, companies still fail to make sufficient use of them. Why? Conventional wisdom among practitioners suggest that the failing is due in whole or at least in significant part to an inability to successfully demonstrate to corporate decision makers a business case for a compelling return on investment (ROI) of employing user experience practices.

But this may not be, as most practitioners seem to think, so much the failing of being able to demonstrate return, as it is an unwillingness to approach design projects as investments at all (Merholz and Hirsch, 2003). Expenditures related to usability testing, design, prototyping, and content development are not valued as investments, but are seen simply as operational costs, akin to spending on IT support and facilities maintenance. Spending on design is necessary in this view, but something, ideally, to be minimized as much as possible. A return simply is not expected, and hence not calculated. Companies do not realize that by spending more on design, or by spending differently on design, they may be able to realize different returns.

While this may in part be true, the idea that a company can develop better products by listening to its customers is nevertheless a fairly self-evident one, and as such it is difficult to accept the notion that quantitatively proving the value of design is the only recourse to convincing companies to take advantage of these methods. Instead, we argue that the challenges companies face in attempting to truly benefit from design are more systemic, and embedded in the structure of traditional business practice and organization.

“Producing innovative solutions for our customers’ needs requires making significant and lasting contributions to an organization’s performance over the long run.”Beyond product strategy?
For the sake of discussion, we will assume that companies do recognize that employing user experience designers (including usability specialists, information architects, interaction designers, etc.) is worthwhile for the contribution they can make to elevate product quality. During the product development process, companies employ iterative usability testing to test for and correct critical errors in the product design, and incorporate improvements into the final version prior to release. You might think that this scenario represents the usability specialist’s utopian paradise. But what if the product fails in the marketplace nonetheless? “It’s not our fault,” some would say. “We did the best we could with improving the product design, but it was a flawed concept.”

Such a scenario is entirely imaginable, and likely one that many have experienced. But it begs the question: if it isn’t “our” fault, whose fault is it? That of product management? Of the corporate structure? Such answers feel unsatisfactory inasmuch as they deny our responsibility and accountability for product success. Producing innovative solutions for our customers’ needs requires making significant and lasting contributions to an organization’s performance over the long run. We must focus our attention beyond the incremental improvements we are able to offer during product development, and instead address strategic concerns about product and service selection, development, and evaluation. In order to substantively improve the competitiveness of the organizations we serve, we must utilize our methods to help those organizations discover how to more effectively plan for, prioritize, and invest in unique activities that create enhanced potential for identifying and taking advantage of market opportunities.

Contemporary organizations are growing in complexity. Decision-making is increasingly decentralized and distributed, technical infrastructures many layers deep, and cross-functional teams are now de rigueur. Even if a company is able to optimize its process for managing product development projects, it still faces significant challenges in seeking the right mix of development projects within its aggregate portfolio. Most large organizations encounter difficulties forecasting and tracking resource capacity, choosing which team members and skill sets to dedicate to projects, and communicating between groups to ensure that redundant or competing projects do not simultaneously find their way onto the queue. These challenges are exacerbated by the ever-diminishing ability of any one person in the organization to hold a clear picture in their head of the present state of the company’s operations.

If we recognize these as challenges and view them as inherent to today’s complex development systems, we can start to identify ways to use our training and talents to effectively manage them. Our skillfulness with analyzing and understanding structure, for clarifying problems, and for managing communication are strategic assets. These skills can be redirected to enhance an organization’s ability to thoughtfully align its endeavors and activities with its capacity, and to deliver on those initiatives effectively.

To accomplish this initiative, we must not only recognize the need to move user research farther forward in the product design process; we must also disrupt the relegation of design within an organization to a process of making (or, worse still, of decorating), rather than one fundamentally concerned with formulating and developing strategic plans. If we accept the notion that successful companies operate from the bottom up, using customer insight and feedback to form the foundation for developing product strategy, which in turns aggregates to form the basis of an overall corporate strategy, we then have a useful framework for situating design activities within an overall context for creating meaningful change.

Within that framework, the value of user research early in the product development process is obvious, and in fact is necessary in the development of product strategy. Less obvious is the role research-informed-design can play beyond the formulation of product strategy.

But could the same concepts not apply to all areas of corporate planning and effectiveness? If researching customers can help a company develop better products by clearly articulating the most important aspects to consider during product design, why can’t researching a company’s effectiveness at ongoing product development help a company develop a more robust corporate strategy? Product researchers and designers bring with them a unique set of skills that have potential to contribute to effective investment prioritization, capacity planning, and organizational decision making.

To help organizations negotiate the complexity of their technical environments, researchers and designers can map key relationships within the technical infrastructure that help visualize and clarify structural components, data elements, and workflow. To help decide between sets of projects, we can analyze the organization’s available resources for delivering on those projects, and create prototypical scenarios and simulations that reveal possible outcomes of projects in different combinations.

Crafting business strategy includes “creating fit among a company’s activities” (Porter, 1996). Note the similarity in objective to those of design, where quality is evaluated based on fitness to purpose (Alexander, 1970). Within modern day corporations, user experience designers are in the unique position to observe, understand, and communicate the needs of a company’s customers, as well as those of a company’s internal constituencies (including marketing, engineering, product teams, etc.) since the role of design spans multiple functional groups. As such, we have an unprecedented opportunity to sit at the fulcrum of a company’s efforts to align its internal activities with value generating activities for its customers. But to do so, we must take responsibility for driving business decision making, and stop seeing ourselves as passive victims of organizational politics run amok.

Case study: Toy manufacturer
A leading toy manufacturer (TM) approached the interactive design agency where one of us worked with a request to improve the usability of the registration process for a web-enabled educational toy. What began as a usability study for a patch project uncovered organizational structures that produced an “each sold separately” user experience.

Baseline
TM executives and product managers expected that the installation process for the toy’s accompanying software and hardware would take about 10 minutes. By contrast, parents initially imagined the process would take 20 minutes, and reported that they postponed installing on their own because they did not think they had sufficient free time. Our initial research in customer homes with parents and children aged 7 to 12 revealed the problem to be much worse. The actual installation process required on average two hours, with many people unable to complete registration at all.

We discovered that the initial process required performing several tasks, including installing software, connecting a special module to the family PC, registering online, downloading new games, transferring games from device to toy, and remembering how to return for online purchases of new game packs.

Approach
Short-term solutions included reducing required registration entities from three to one, adding navigation and nomenclature that allowed users to understand how far they were from their primary goal, and reducing the interface complexity for first time users. But it was our mapping of the user experience and organizational obstacles to product simplicity and coherence that had lasting impact.

The root of the toy’s problems exceeded the scope of our project. The toy and connector module forms, functions, and packaging were developed by one set of groups, the installation CD by yet another group, and the website design begun after the other artifacts were in production.

Organizational change
Our consulting engagement helped TM change its product design process and recognize weaknesses in its existing organizational structure. Rather than rush to market toys with an ad hoc “internet enabled” gloss, the company has become more cautious about launching complex toys despite the allure of new technology and potentially more profitable distribution channels. Planning and collaboration between product and design groups are recognized as necessary for creating high quality products. And TM reacted to the effectiveness of our multi-stage research and design process by building a large in-house usability and user research department.

Conclusion
Because we served as external consultants we cannot be sure about how successfully TM has been able to move towards becoming a customer-focused organization. We do know some of the measurements for evaluating how far they’ve come:

  • Are customer needs and opportunities a critical input to the development of each product?
  • Have customer models been created across product lines and used for initiating new product development and prioritizing which products receive scarce resources?
  • Have research and design practices migrated from product design to other key organizational strategy and planning areas, including future scenarios modeling, resource allocation, internal workflow modeling, and corporate culture change?

The TM study illustrates how a particular project led to changes in how customer research contributes to product design and strategy. The next case study looks at how research and design methods were used to model an organization’s internal workflow and the impact on user experience, in order to create a framework for organizing product development across distributed business units.

Case study: Financial services
At a leading financial services institution, an internal user experience research and design team was struggling to maintain a set of design guidelines for the company website. Created as a way to ensure consistency across the 8,000+ page site, the existing guidelines governed use of brand assets (e.g., the corporate logo) on web pages, specified page layout, and defined best practices for site navigation. It also included guidelines for creating and maintaining effective metadata, ensuring compliance with ADA standards, and writing effective copy.

Baseline
The team responsible for “owning” the guidelines-championing and maintaining them within the organization-often found that rather than serving as a useful tool to help promote effective online user experience design, the guidelines became a burden to keep up to date, and often caused frustration among the team as product managers, engineers, and third parties remained ignorant of the standards that had been developed, or refused to comply with them. So, in addition to the burden of developing the guidelines and keeping them up to date, the team struggled to keep up with their policing roles-attempting to convince other groups within the organization that they should respect the guidelines and design to them.

Approach
We decided on a two-pronged approach to clarifying the problem and attempting to generate sustainable solutions. First, we used ethnographic user research methods to study the work practices of those responsible for developing, maintaining, approving, and using the guidelines. We discovered that though the guidelines were developed as a way to govern site user experience, in reality they were used much more as a tool for governing production-level decisions: where to place headers, how big images should be, how to label buttons, etc. As new interface questions arose, new guidelines had to be developed and documented, and added to the intranet site where the guidelines were kept and referenced. Since product managers were constantly coming up with new Web product ideas that did not (or, at least in their own minds did not) fit within the currently specified guidelines, the team responsible for maintaining the guidelines was under constant pressure to re-examine, modify, and document their stylistic decisions.

After completing the internally focused research, we then planned and executed a rapid customer ethnography designed to evaluate the guidelines based on the effect they had on creating a high quality website (which, remember, was the ultimate point of the guidelines). Participants in the study were asked to keep journals of all their financial services activities over the course of five days. They were encouraged to tell stories with words and pictures about the experiences they had with our company’s website. We also observed them using the website in their homes and offices, and interviewed them about their usage behavior. Finally, they were interviewed over the telephone about their activities over a 30 day period, recognizing that financial activities tend to re-occur in month long cycles.

Internally-focused and customer research data showed that the great majority of effort on creating and maintaining the guidelines was wasted. While the production-level concerns of the existing guidelines certainly were important, their impact on the user experience was far less significant than more serious failings of the overall execution of the website strategy. Customers of the site generally had little difficulty navigating the site to move between pages or log on to their accounts. But they had little motivation to use the site as it was intended-to research and buy financial products like credit cards, home loans, and small business services.

The advantage of researching and buying financial products online wasn’t evident to customers from the site design, and even when it was, customers were not sure they could trust the site to be as safe, easy, or efficient as doing it through another channel, like over the phone or in a branch. Furthermore, the website failed to communicate the company’s overall value proposition-consolidating multiple financial products at one institution, online or otherwise. Consequently, customers wondered why they wouldn’t be better off going to different specialists for each of their piecemeal needs.

The origins of these failings were evident in the findings from our internal research. Product managers were held accountable for decisions about their specific products (e.g., home loans). The user experience team was held accountable for page-level decisions about the website’s design. No one within the organization was responsible for thinking across products, from a customer’s point of view, in order to drive home the primary value proposition for banking online: to aggregate all products in one easy-to-access, always-available location.

Organizational change
What started as a project about redesigning and updating a guidelines document developed into a program for prioritizing projects, organizing business units, increasing group level accountability, and identifying more effective governance models across the web channel. Senior executives became involved in the analysis and formulation of new action plans, and shepherded the transition to new organizational structures that built in incentives for managers and rank-and-file employees to improve their communication with other business units. Product and functional groups were encouraged to collaborate on decision making and share responsibility for the overall success of the web channel, rather than focus exclusively on individual product sets. New investments were made to the overall design of the site to more closely align it with the company’s overall communication strategy. And a content management system was installed to enable easier maintenance of routine upgrades to the site, as well as to act as an automated solution for enforcing the production level guidelines, which were now built into the page templates.

Closely monitoring the quality of the site user experience became a key part of the company’s metrics program, along with mechanisms for identifying and implementing incremental improvements. The existing user experience team began to be recognized as key contributors to the success of the company’s overall business strategy and were included in high level planning meetings that determined project priorities and budgets for the next calendar year.

Even though all of these changes were relatively recent and are still in progress, initial examination already suggests dramatic successes. Industry analysts rated the new site as being the best overall in the financial services industry. Aggressive sales goals were set for the channel, and were being projected on target or slightly better than planned. Teams reported feeling more cohesive and integrated. Productivity has been increased, and complaints about the website to customer service were down.

Conclusion
Certainly not all of these successes can be solely attributed to our guidelines project. Modern day organizations are dynamic, living entities, and it is unrealistic to expect that any one project can ever completely redefine a company’s business operations. But by revealing the connection between the way our company approached creating its website (how it designed) and the quality of the site it produced (what it designed), the guidelines project catalyzed a significant cultural change within the company. That change dramatically improved the organization’s potential for recognizing and responding to the evolving needs of its customer base and the competitive marketplace, and enabled the company to integrate user experience concerns with its everyday business operations.

“Rather than see usability, design, and product management as separated by a rigid wall akin to the division of church and state, we must pool our skills in a common pursuit of outstanding products.”Future design
This article calls into question two complaints we have heard from people most frequently over the past several years-from the most junior practitioners to leading experience design gurus.

“It would have been great if only they had listened to us.”
“Our innovative approach would have been revolutionary if the dotcom bust had never happened.”

Our skills, methods, practices, and know-how would have made successful products if only “they” had listened to us or if the boom had continued indefinitely.

We take issue with both complaints. Declarations of righteousness may resonate with other peers who have experienced adversity despite their best efforts. However, blaming business people for not listening to our great ideas makes it seem that “their” need to listen to us exceeds our need to communicate effectively to others, a core skill most designers and consultants would claim. Do we not share responsibility for others’ failure to listen to us?

Flush times should not be a pre-condition for the success of our work. Given the inevitability of business cycles of boom and contraction, our value must be in aiding businesses even when resource constraints are greatest. This transformation signals a break from late stage design and usability work and a shift towards less familiar territory.

The case studies illustrate how skills we share with other researchers and designers have worked within real world constraints and succeeded in making user experience more central to product strategy and organizational effectiveness. Conducting research with product developers employs the same research and modeling skills we already have. Mapping the disconnected world of distributed product development extends research and design work from “patching” problems to creating a product strategy that aligns customer demands for clarity and simplicity with organizational capacity.

To create innovative and useful products, our most common approaches are insufficient. We must be ready to sacrifice traditional style guides and a fixation on formal concerns that promote surface consistency and instead strive for new frameworks that ensure consistency of user experience. Rather than see usability, design, and product management as separated by a rigid wall akin to the division of church and state, we must pool our skills in a common pursuit of outstanding products. Rather than transfer blame for failure to business people’s bad decisions and failures to listen to us, we must take responsibility for better communication to decision-makers and for the ultimate success or failure of our products and companies.

Achieving the highest levels of user experience in products and services isn’t possible with an exclusive product and making focus, but requires engagement with organizational planning and decision-making. While the end state is still unclear to us, the methods come from our existing skills sets:

  • Using our customer research and modeling skills to understand the internal operations of organizations;
  • Creating frameworks for decision making about organizational potential rather than product trade-offs;
  • Prototyping and iteratively adjusting business strategies;
  • Visualizing existing and future processes; and
  • Supporting decision-making at the senior executive level and communication throughout an organization.

The economic downturn only accelerated the need to make a choice. We can continue with research and design as usual and seek to build bigger departments that have increasingly less impact. Or we can re-imagine our roles, using our existing skills to form the customer-centered organizations of the future.


  • John Zapolski manages multidisciplinary design teams at Yahoo. He is very active in developing the user-centered design community, serving as advisor and former director of AIfIA, and as the new chair of the AIGA’s Experience Design community.
  • Jared Braiterman is an anthropologist working in product development and organizational change (Stanford PhD, 1996). You can learn more about his consulting work at jaredRESEARCH.

Searching for the center of design

by:   |  Posted on
“In the user experience community, we’re valiantly fighting against the infection of chooser-centered design, and the antidote we prescribe is user involvement.”Design is driven by many considerations. But on each project I’ve worked on, there seems to be a consistent center—a driver that determines priorities, direction, and the metrics used to measure success.

The most common driver I’ve encountered is “chooser-centered” design: Whoever runs the show sets the agenda. That doesn’t always mean the VP is in charge–the “chooser” might be a gung-ho lead developer. As Cooper illustrates in The Inmates are Running the Asylum, techies who are focused on the latest whizzy server platform can be just as unbalanced as a CEO obsessed over expressing the corporate mission, or a creative director who prizes aesthetics to the detriment of all else.

The key isn’t to point fingers at the culprits—it’s to find solutions. I know I’m preaching to the converted when I point out that client-centric, portfolio-centric, technology-centric, marketing-centric, and business-centric approaches abound, and all are flawed. We see the symptoms across the Web with CEO mug shots and vision statements on the homepage, or edgy visual design that wins awards but not customers. So what’s the answer?

In my mind, I hear your response: “We know better. We have the answers!” In the user experience community, we’re valiantly fighting against the infection of chooser-centered design, and the antidote we prescribe is user involvement. It’s the common rallying cry of the UX community: “Put the user in the process! Embrace user-centered design!”

Unfortunately, it’s the wrong answer.

Let me rephrase that—it’s only a partially right answer, and not the key consideration either. User-centered design (UCD) suffers from three significant drawbacks that disqualify it as the ultimate candidate for the center of design.

  1. In placing the user at the center of the process, UCD often ignores other aspects and the process and projects become unbalanced. In reacting to the prevalence of chooser-centric decisions, we grasp UCD with such zeal that we lose sight of the bigger picture. Kent Dahlgren’s CHI-WEB post Usability Contributed to My Layoff vividly illustrates the consequences of extreme user focus.
  2. Putting the user at the center of the process and setting the metrics for project success implies that user-centered design is the “right” approach. Assuming UCD is THE right approach suggests that there is a sort of moral imperative to pursue a user-centered methodology. This has a number of detriments. For people who tacitly adopt the moral imperative position, attempted evangelism can come off with a preachy “I told you so” attitude. When others don’t buy into doing things the “right” way, they are often dismissed as unenlightened luddites who don’t understand the importance of what we do. Thus, some practitioners develop a UCD inferiority complex–a resentful feeling that we’re not appreciated or understood. Often this results in the practitioner’s return to more comfortable territory–conversations within the UX community about methods or tools, or how engineers or marketing just don’t get it. And that leads us to what might be the biggest drawback of UCD.
  3. UCD information is rarely put in terms that resonate with others outside the field–the reality is that user-centered design evangelists often aren’t user-centered at all. We might address ROI, but in the same sentence we use jargon like contextual inquiry, controlled vocabulary, or experience map. While jargon is useful inside the community, and business decision makers are smart enough to pick up our vocabulary, it points to a deeper problem. We naively expect our audiences to learn our lingo, rather than understanding their needs and addressing executives and other decision makers with language and messages tailored for them. We don’t practice what we preach.

None of this means that user-centered design is wrong or worthless. But it’s only part of the picture–necessary, but not sufficient. To see the complete picture requires stepping back and developing a balanced perspective. Individually, practitioners often recognize the other factors at play, but collectively we don’t express the recognition very well.

To connect with decision makers and the people who influence them, we should treat them as “users” of the user experience message. And in this case, being user-centered means not blurting out “User-centered design is the answer!” at the first available opportunity.

While there are a number of alternatives for approaching user experience evangelism, I’m going to share one perspective that has worked for me to begin conversations with decision makers. I call it value-centered design.

(Before we go further, a caveat: Value-centered design isn’t the ultimate answer either, but I hope it helps in your own efforts to connect to decision makers).

mcmullin_090803.gifThe basic premise of value-centered design is that shared value is the center of design. This value comes from the intersection of:

  • Business Goals and Context
  • Individual Goals and Context
  • The Offering (While it sounds like the title of a low-budget horror flick, “offering” is general enough for a wide variety of situations. For a particular project, this might be a product offering, service offering, or content offering)
  • Delivery (How do we get it from the business to the individual?)

Consideration of these goals leads to a particular offering from the business to the individual, delivered through a specific channel. Together, the offering and delivery method create a solution that drives return on investment for the business, and “return on experience” for the individual—return where she gains some benefit for the time, attention, or money invested in the experience. Both parties are satisfied, and this satisfaction establishes the foundation for sustainable initiatives and an ongoing relationship. Meeting business and individual goals creates value, and that’s largely what design is about.

When value is explicitly placed at the center of design, we no longer have to explain what we mean by user-centered design. Our user experience toolbox merely becomes part of the complete picture, working to produce a great solution that meets individual and business goals. User needs are set on equal footing with business needs, and the solution is explicitly a means to achieving those ends, instead of an end itself.

While space doesn’t permit great exposition on the implications of value-centered design, I want to address some key questions I get from my peers in the user experience community.

  1. Isn’t VCD incredibly generic? Isn’t everything about creating value?

    Well, the generality of value is what lets VCD speak to a wide variety of people and situations. However, it’s important to remember that VCD isn’t just about value as a platitude or ideal; value explicitly comes from meeting business and individual goals. The meeting of goals puts individual user goals on the same plane as business goals, which tremendously changes the conversation with business decision makers. In fact, when value is defined this way, everything isn’t about creating value. All those different centers we touched on–award-centric, technology-centric, self-centric approaches–all fail to generate value because they don’t satisfy both individual and business goals (and sometimes neither).

  2. Isn’t VCD just a reframing of current ideas?

    The quick answer is yes. But it’s not “just” a reframing. It’s a reframing that does two key things: puts the user into a business context as an equal player with business goals, and uses language tailored to business decision makers. It also helps me get over my personal “I told you so but nobody listens to me” complex that I seem to share with many in the user experience community. Most importantly, “value” provides a common platform for taking current ideas and introducing them to a much broader audience in a way that “user” can’t.

  3. For something so broad, what real concrete tools come from value-centered design? How can I apply this in my daily work?

Well, I hope B&A will let me talk some more about this at a later date, but for now, here are three ways I apply VCD day to day:

  1. Building buy-in for user experience;
  2. Applying user experience tools to the business side of the equation (ask me sometime about business personas); and
  3. Creating a framework for looking at projects and the tools that they need to generate value.

Of course there are more questions about value-centered design. It’s not perfect, and it’s still evolving within my own practice.

Value-centered design starts a story about an ideal interaction between an individual and an organization and the benefits each realizes from that interaction. How that story ends is still being decided with every new project we pursue. I hope that VCD will spark the first chapter in some great success stories about using a balanced approach to create lasting, sustainable value for businesses and the individuals they work with.

Jess McMullin is a user experience consultant who helps companies innovate products and services. Through value-centered design, Jess works to maximize return on investment for his clients and return on experience for their users. A founder of the Asilomar Institute for Information Architecture, he runs the popular IA news site iaslash. He is based in Edmonton, Alberta, Canada. Jess can be reached at banda(at)interactionary(dot)com.

What’s Your Idea of a Mental Model?

by:   |  Posted on
“We should create these mental model descriptions during user analysis to document users’ current understanding. Then, during a design phase, we should create the target model to show the mental model we want users adopt.”

As usability and design professionals, we often use the term “mental model” loosely. Part of the problem is that there isn’t a clear English definition, though there are several serviceable academic ones (for some examples, see Johnson-Laird, Girotto, and Legrenzi’s introduction and Martina Angela Sasse’s excellent Ph.D. thesis on the subject).

Even in these works, however, mental models aren’t defined more specifically than a mental representation of something. How, then, do you tell people in other disciplines, such as managers or developers, what they are? I often use examples to convey what a mental model is. If I tell them that I recently ordered a steak at a restaurant, they might assume that I was met at the door by a host or hostess, seated, and presented with a menu. They assume these details, and others, that I never actually mentioned because they have a mental model of how restaurants operate. To illustrate the consequences of having a mismatched mental model, I describe a person who goes into a buffet restaurant and waits for someone to take their order. The person’s mental model of how that restaurant operates doesn’t match the actual situation, and he would experience confusion and frustration until he modified his original model to include buffets.

Defining mental models by example is not sufficient if we want to treat them more formally, however. All mental models have a few key characteristics:

  • Mental models include what a person thinks is true, not necessarily what is actually true.
  • Mental models are similar in structure to the thing or concept they represent.
  • Mental models allow a person to predict the results of his actions.
  • Mental models are simpler than the thing or concept they represent. They include only enough information to allow accurate predictions.

But how are mental models constructed? We need to know the parts that each mental model contains if we are to document them correctly.

This article proposes a formalization for mental models. This formalization is still in its infancy—I have not yet used it on a major design project. I’m hoping it will stimulate discussion and feedback about mental models and how we use them. It is also designed to be practical, however, and it can be a useful way to describe users’ perceptions and expectations during the design process.

Why do we need to document mental models?

Mental models should serve as an analytic tool, allowing us to clearly document users’ current mental images, vocabulary, and assumptions. Once the mental model is documented, we can create a target mental model—the model of the product that we want our users to have. If there is a difference between the two, we can design the UI and user assistance material to transition users from their current models to the target model. Additionally, we should be able to provide clear and credible specifics when we tell our colleagues that there is mismatch between user and system mental models. This formalization lets us do that.

We can portray mental models using several key parts:

  1. An image (needed if the mental model is of a physical thing)
  2. A script (needed if the mental model has a process)
  3. A set of related mental models
  4. A controlled vocabulary
  5. A set of assumptions

An Image. If the mental model is of a physical object, the model should contain a simplified image that serves as a template for that object. Consider a graph. For most people, it has a vertical and horizontal axis, representing the upper right quadrant of a Cartesian plane. There are probably labels near each axis. There may be a legend. The “content” part of the graph may consist of lines, data points, bars, or other visual things that show a relationship among data on two dimensions. We can easily represent this type of mental model as a schematic diagram. It doesn’t include every last detail of what might appear on a graph, but only the essential things that would lead someone to identify it as a graph.

A Script. If the mental model is of a process, it should contain some sort of description of that process. The best way to present the script will vary—it might be a series of steps expressed verbally, a flowchart, or a decision tree. Perhaps a finite state diagram works best. Let’s consider the process of creating a graph from a spreadsheet. First, you might check to see if data has already been entered. Assume it has. You then create a graph and tell it in which rows and columns to find the data. If the spreadsheet application’s designers wanted it to be helpful, it might take a guess at the axis titles based on row or column labels for the data spreadsheet or database. Then, you have to choose the display style (line, bar, etc.) and choose any other settings there may be (background color, graph title, legend details, etc.). Maybe you want to pull in data from other sources too. Finally, you’ve got the thing looking the way you want. Does it show a useful relationship? Does it solve the problem you are trying to solve? If so, you might want to polish it up and use it in a report. If not, you might want to change settings, add or remove data, and so on. Scripts may be the same as task models, though they show a person’s expectations and beliefs rather than the true process.

Related Mental Models. Mental models are composed of other mental models. We can quickly get lost in a fractal mindscape, wondering where to begin and where to end. The art of documenting a mental model is choosing the right representation and showing how it relates to other models. For a particular model, list the two to four most important mental models that are its building blocks, and then list the two to four mental models for which it is a building block.

Take the car. A typical commuter has a mental model for personal transportation that includes her car, but may also include a bus system, subway line, network of friends with cars, etc. If she were a fleet manager for a police department, however, the car would also be a key building block of her fleet. Selecting the right related models shows designers how users think and relate to their larger context.

Controlled Vocabulary. Each mental model has a set of key definitions and variants. Information architects and librarians are adept at creating controlled vocabularies, and mental models should contain a small controlled vocabulary (see “What is a Controlled Vocabulary?” for a good primer on the subject). The model of the nuclear family has a set of definitions that include mother, father, and child. Each of these terms has a set of alternates, however. Define each term and state other terms that can be used for them. A mother, for example, is the female parent. Other terms used for mother include mom, mama, and ma. If it is important to the mental model, include any subtle variations in meaning for these alternates. If you document user mental models during analysis, the terms you identify and define can form the basis of the standard terminology for the product’s UI.

Assumptions. Mental models contain assumptions that allow people to predict behavior. Carrying forward the model for the nuclear family, we might assume that if the child misbehaves, one of the parents disciplines the child. There may be further assumptions about the method as well. There could easily be thousands of assumptions for a given model. The key is to state only those assumptions that affect the product at hand.

Using the formalization

The two mental models shown here are based on a combination of recent projects (I have modified the models involved somewhat). The first shows a user’s interpretation of an academic article while the second shows the system designer’s model for an article. The system’s model for an article includes two separate databases, one for the article’s metadata and one for the article’s full text. This solution was a compromise because including everything in the same database caused searches to take too long.

Many parts of these mental models are the same. There are some terminology changes, but the key difference is highlighted in the models’ assumptions. Users do not make a distinction between the back-end databases and presume that articles are stored completely in a single online catalog. This difference affects the Scripts shown. Because the databases do not have fields in common, the system needs a separate search page for each database. Users, however, will have trouble making this distinction and will expect to see only a single search page. The ideal solution to this problem is to restructure the databases so they can both be searched from the same search page. If that is not possible, the designers must help users develop a new model of the search interface through a combination of instructions, tips, and clear error messages and results pages.

Since this formalization is, in effect, a model of mental models, it does not necessarily include every aspect of an actual mental model. This method for documenting them includes only those details we need to conduct our analysis and complete our design. I see this technique as being similar to that of developing personas. Both are short, perhaps one or two printed pages. For any given project, there should usually be one or two major personas and perhaps a few more supporting personas. Similarly, there should be only a few mental models for a UI and perhaps a few more supporting ones.

We should create these mental model descriptions during user analysis to document users’ current understanding. Then, during a design phase, we should create the target model to show the mental model we want users adopt. Comparing the current and target models, we will be able to guide the users’ transition from one to the other, if necessary.

Conclusion

I’m looking forward to using and refining this formalization for mental models further, and I welcome any criticism and critique. My hope is that a tool like this can help us clarify our thinking about mental models and incorporate that thinking into our information architecture and UI design projects. We can then begin to use mental models with more certainty and conviction, including them in our design process in the same way we use personas, navigation architectures, and use cases.

Scott McDaniel is a user-centered designer with Cognetics Corporation. He has more than seven years of experience in designing and documenting software, networks, and telecommunications systems. As a designer, he helps establish vision and direction for products, researches prospective users, determines requirements, and provides detailed designs and specifications for both software and web. Scott first discovered usability upon joining the Society for Technical Communication as a novice technical writer. After several years of applying user-centered design methods to documentation, he made the switch to user interface design.

Leading from Within

by:   |  Posted on

About this time last year, I was a student in a sort of impromptu seven-week “master class” on user-centered design, taught by Marc Rettig. When I heard about the class I jumped at the opportunity to be involved, not only because Marc was the instructor, but because it was a chance to be immersed in a totally positive and constructive design environment, one removed from corporate politics, strained budgets, and misplaced egotism. It was a chance to talk about, learn about and practice user-centered design techniques in a room with sympathetic colleagues—people who didn’t view me as the “usability police.” It was a chance to learn better how to understand users, without having to convince people that understanding users was a good thing to do in the first place.

The class was fast-paced, and although we covered a lot of ground in a short time, I loved every minute of it. But for every moment of the class where I felt totally in my element—challenged creatively, intellectually, working through problems I had a passionate interest in solving—I felt a twinge of disappointment that I wouldn’t be able to practice the same methods back in the “real world,” in my job as an information architect. I knew that, as much value as these user-centered approaches could add to the work we did for our clients, there just wasn’t room for them in the project budgets, or the processes, or even in the company’s overall culture at the time. I believe many of my classmates shared this frustration at the contrast between the “ideal” process scenarios we talked about in class and the reality of what we’d be able to incorporate into our jobs. At the end of the last class, someone said out loud what many of us had been thinking. “This is all great, we believe in the value of it, and we’re dying to go out there and do it. But, realistically, how can we possibly get our teams to work like this?” Marc responded, very simply: “By virtue of the job you’re doing, and the work you’re doing, you are all leaders in your organizations; you’ll create the opportunity to work this way.”

Since the final class session a year ago, that sentiment has remained with me and has materialized into a truth I’ve come to accept and embrace: Being an IA, at this point in time, also means being a leader—ready or not, like it or not. Information architecture is still a nascent field, and as a result we often encounter uncertainty in our organizations and with our clients (sometimes even within our own profession) about the role we play on a design team. Only as leaders, who are able to skillfully educate, guide, and influence those around us, will we be able to succeed as practitioners at the forefront of this emerging field.

While there are practicing IAs fortunate enough to work in companies that wholeheartedly embrace user-centered design (and an IA’s critical role within that process), there are many more IAs whose biggest challenge on a daily basis isn’t the work itself; it’s finding the opportunity to do the work, at the right time, in a meaningful way.

To create opportunities to practice fully as information architects, and in turn, contribute fully as a member of the larger team, not only do we have to become experts in the stuff of our profession—site architecture, user scenarios, prototyping, conceptual models, etc.—but we have to become skilled in things like change management, process engineering, negotiation, persuasion, team building, and organizational politics. And, in most cases, we have to exercise these skills from a position that is not, by default, one of authority in the company, possibly not even one of authority on our respective teams.

Because many of us don’t have the opportunity to influence change from the top down, we have to be resourceful and find ways to effect change from within. In other words, if we are committed to creating an environment where we are fully utilized, one that enables everyone on the team to do their best work for our clients and their customers, we have to take the initiative and lead from within.

What does it mean to lead from within? J. Donald Walters, author of “The Art of Leadership,” envisions a good leader as “an artist whose medium is the dynamics of human cooperation.” He believes leadership is a role that is people-oriented, not position-oriented, and as such is guided by principles that can be applied to any situation that involves working with and influencing others. He offers “principles for leaders to live by,” many of which are relevant and helpful to an IA (or anyone) interested in making change in their organization. Some of these include:

  • Persuade people with the power of your conviction. Involve others in your vision, and inspire them to also be visionaries.
  • Be a good listener, and be willing to listen to other points of view, even if at first they seem to conflict with your own.
  • Focus on the job to be done, more than your own role in the task, however critical your role may be to that task; always keep the big picture in mind.
  • Be willing to take risks yourself, instead of waiting for other people to take them. With this comes the obligation to take responsibility for failure, as well as success.
  • View your role as a service to others—clients, employers and coworkers; there is strength in humility.
  • Work with people as they are, not as you would like them to be. Realize that it takes time to bring people to new points of view; be patient.
  • Adapt your actions to reality (what can be) rather than theory alone (what you think ought to be); be flexible in your ideas of perfection.

While some people believe leaders are born, it’s more accurate to say that leadership is a set of learned skills and sensitivities, born out of a strong commitment to and passion for an idea. If you’ve accepted the challenge of creating change in your organization, there are a few ways to get started on the path to becoming a strong, successful leader.

  • Become an expert in your field. Immerse yourself in the subject matter—read everything you can, attend professional conferences, participate in discussions with colleagues. While passionate commitment is the cornerstone of good leadership, knowledge is a leader’s greatest resource.
  • Identify people in your life you consider to be good leaders, people who have been successful in motivating others to share their vision. If you can, observe how they work, and how they influence people around them. Take note of how they handle mistakes, and failures, and successes. When you encounter obstacles you can’t overcome in your own efforts, consider asking them to act as your mentor, to share their expertise and help you through the rough spots; chances are they won’t say no—good leaders know everyone benefits when they teach others what they’ve learned.

    If you’re unable to identify people in your personal or professional life you consider to be good leaders, you can turn to history for examples. Biographies of great leaders can be a rich source of guidance and inspiration.

  • Look for opportunities to take on active leadership roles, personal or professional. Start a special interest group, or volunteer to lead an initiative in an existing group. Non-profit organizations are a great learning ground for things like taking risks, accepting accountability, facilitating teamwork, and overcoming obstacles creatively—all skills that are critical to becoming a good leader.

One of the things I remember most about that class last Fall was the weekly update from a pair of intrepid classmates who combined what they were learning in class with an enthusiastic desire to change the way their company approached design. Motivated by a commitment to their customers, and supported by our instructor’s advice and encouragement, these two coworkers took each week’s lesson back to their jobs and applied the approach to a product under development (and then they came back to class and shared all the juicy details with us!). Even though they had setbacks and encountered resistance, it was encouraging to hear that—even in that short seven-week span—they made progress in the incorporation of users in their company’s design approach.

Making change can be an incredibly rewarding experience; it can also be an excruciating process, and along the way you may question whether it’s worth the stress and frustration you experience, or if you even have a chance of succeeding. Be confident that if you believe in yourself and your vision, follow your instincts, arm yourself with knowledge, and gravitate toward people who support you, you will be successful as a leader, and you’ll inspire others to follow along.

CEOs Are From Mars…

by:   |  Posted on

I’m pretty much a professional half-breed. You see, with both a television production background and an M.B.A., I have spent the past 20 years trying to bridge, heal, soothe, mend and otherwise repair the pervasive gap that divides “suits” and “creatives” in the business world. Along the way, I’ve played a number of roles including ringmaster, referee, coach, ambassador and even secret agent.

In an ideal world, both sides would meet in the middle and split the distance 50/50. In reality, many business managers are simply unable to reach across more than 20 or 30 percent of the distance.

What I’ve learned is that the antagonism, hostility and resentment often felt on both sides of the equation is the outgrowth of a basic failure to understand what makes the other side tick.

What we have here is a failure to communicate
I used to believe that hard-core businesspeople actually understood their Photoshop-toting colleagues but chose, proactively and aggressively, to dismiss their skills, capabilities and talents as inconsequential fluff. The truth is much worse: many businesspeople simply don’t have the slightest idea what separates “good creative” from “bad creative.”

I’ve had executives admit to me that they couldn’t tell the difference between two competing portfolios, designs or layouts if their lives depended on it. At the same time, it’s fair to say that many designers are equally oblivious to the underlying business issues that drive decision-making in their organizations.

But, here’s the catch: design teams are the ones most likely to lose out when business requirements clash head-on with design imperatives. Because executives must stay focused on bottom-line results, aesthetic elements that seem indirectly related to the company’s business goals are easily dismissed in the corner office.

The hard part is that these design imperatives are, many times, a large part of the bottom-line results. To bridge the gap that divides business and design teams, it’s important that IAs and designers:

  • understand and respect the fundamentally different world views that separate them from most business managers,
  • commit to meeting business managers halfway (or more) when it’s time to define and articulate project goals and expectations, and
  • commit to educating themselves more completely about business issues, ideas and trends.

The view from the corner office
Try to put yourself in the CEO’s natty suede loafers for a moment: As the keepers of the fiscal flame in an organization, most executives are, understandably, more focused on the more quantitative elements of a corporation’s daily life.

They’re tasked specifically with both generating revenue and saving costs. And, at the end of the day, will be measured and compensated (or penalized!) by results that are summarized at the end of each quarter on a spreadsheet. Qualitative factors including user experience, design, content strategy and customer experience are considered a means to reach end-of-year financial goals, not an end unto themselves.

In fact, compared to complex quantitative calculations and projections, design and content architecture issues seem relatively straightforward and simple. With no spreadsheet to consult, final decisions about design, customer experience and navigation elements might seem to be based on personal preferences, favorite colors and an armchair quarterback’s appreciation of what’s stylish and hip.

Most quantitatively-focused managers simply don’t comprehend the relationship between business strategy and customer experience, or how design and content architecture serve to facilitate and articulate strategic corporate goals in the marketplace. And, without a clearly articulated business rationale to support IA and design priorities, they never will.

Finding the middle ground
Most deadly of all is every businessperson’s deep-seated allegiance to their own creative point of view. As I learned in business school, you can never convince a “qualitatively challenged” M.B.A. that a) they can’t write, b) they have limited people skills, c) their PowerPoint slides are dull, or d) they have no creative aptitude.

Redefining user experience issues in terms of business impacts and “domino effects” empowers business managers to defend and explain initiatives to other senior managers further up the chain of command.

Make no mistake: when it comes to design and customer experience issues, most business managers have stretched themselves as far across the divide as they’re capable. In an ideal world, this would mean meeting their IA teams in the middle and basically splitting the distance 50/50. In reality, many business managers are simply unable to reach across more than 20 or 30 percent of the distance.

In this context, it becomes imperative for IAs and designers to take action to close the gap. And while this may mean that design teams have to take on more than their “fair share” of the burden, it’s important to not lose sight of the overall goal: delivering the best work possible.

By learning to frame creative issues in business terms and to draw meaningful connections between design efforts and the corporation’s bottom line, design teams and their projects are more likely to survive the corporate gauntlet.

The intersection of art and commerce
First, it’s important to take a close look at the organization from the inside out. Understand who’s writing the check for the project and what results they are being held accountable for. Ask:

  • How do project goals connect to the overall mission of the organization (if at all)?
  • Who stands to benefit from the project’s success?
  • What expectations—right or wrong—are associated with the project?
  • How long will it take the organization to see a return on their investment in the project?
  • How will the projects success and/or failure be measured at a corporate level?

For example, many corporate websites are created, primarily, to reduce costs associated with customer service (e.g., call centers, product documentation, software upgrades). To that end, the extent to which call center volume decreases and use of web-based tools or FAQs increases provides management with some indication of the site’s effectiveness.

Then, consider your project and the organization from an “outside in” perspective. Ask:

  • Are internally-driven corporate goals aligned with real customer needs?
  • Which customer needs is the project meant to address?
  • How are your company’s competitors responding to these emerging needs?
  • How will the new project impact other stakeholders (e.g., vendors, partners)?
  • How is success defined in this larger context?
  • Are there any related examples in your industry (or in other industries) that you can reference and learn from?
  • Have similar initiatives worked for other companies?

In the case of the customer service-focused website described above, it would be important to understand whether or not users are likely to accept a new form of customer service. Would an online option solve a problem for them or cause additional complications?

Armed with these two critical perspectives, a design team can begin to craft arguments that are solution-oriented and in line with the corporation’s bottom line.

Returning to the online customer service solution one last time, a business-savvy design team would focus on those elements that have the greatest impact on a user’s customer service needs. In this case, superior content, information architecture and user interface design are critical to the customer’s ability to find information and, by extension, solve the immediate problem that brought them to the site in the first place. If a customer in need becomes confused by the site’s navigation or search capabilities, they will never return to the site. By extension, their opinion of a company offering such a sloppy and incomplete solution will surely diminish.

Defining these kinds of business issues and “domino effects” also empowers business managers to defend and explain initiatives to other senior managers further up the chain of command. By anticipating questions and providing managers with the language to describe each design choice and associated business solution, projects are more likely to be spared endless rounds of questioning and negotiation.

And don’t forget to embrace and support those rare business managers who actually understand and support of your design team’s issues. These managers can be terrific allies and can also serve as a resource while you’re crafting the business case for your project.

A mind is a terrible thing to waste
You certainly don’t need an M.B.A. to understand basic business principles. It’s simply a matter of engaging your curiosity and beginning to make business issues relevant to your particular situation. On an ongoing basis, make a personal commitment to increase your general understanding of business issues, ideas and trends.

You certainly don’t need an M.B.A. to understand basic business principles. It’s simply a matter of engaging your curiosity and beginning to make business issues relevant to your particular situation.

By taking the time to study various industries and macro business issues, it becomes clear that there are business basics that drive every company. By finding parallels and lessons in other industries, you can begin to make better sense of your organization’s issues and challenges.

Understanding, for example, that Southwest Airlines actually considers its primary competitors to be railroads and bus lines (versus other regional airlines) not only provides you with insight into their business strategy, but also offers a great lesson in thinking more broadly about the dynamics of your business.

Begin picking up a Wall Street Journal once a week or, very simply, browsing the business section of your local newspaper. For more in-depth stories, the Harvard Business Review, despite it’s lofty and journal-like appearance, is a wholly approachable and practical source for new ideas, case studies and best practices across a number of industries. In fact, I have often recommended an article called “The Ultimate Creativity Machine: How BMW Turns Art Into Profit” from the January 2001 issue. It describes the challenges faced by the head of BMW’s German design studio as he seeks to ride the line between aesthetic, engineering and business requirements. For yet another look at emerging business trends, monthly magazines Fast Company and Business 2.0 scour the world for the most innovative and radical new ideas, companies and executives.

Business classes and seminars offer an opportunity to connect with other students to share new ideas. They are also a valuable resource for expanding your network of professional resources. This face-to-face interaction is critical. Imagine trying to learn a new language without having someone else to talk to.

Can’t we all just get along?
Remember that corporations are living, breathing ecosystems that are given life by the people who populate them. By making a conscious effort to focus on the big picture and bridge the gaps that divide the organization, you are contributing to a company’s overall success and, along the way, making your day-to-day working life, ultimately, a little less stressful.

Alma Derricks is the founder and principal of REV, a unique business strategy consultancy that provides firms imaginative strategic guidance, new revenue-creation models and fresh insight into what motivates and inspires customers. She can be reached directly at .

The Evolving Homepage: The Growth of Three Booksellers

by:   |  Posted on

Web design is expensive. Web designers earn upwards of $50,000 a year1, information architects earn even more.2 During the heyday of web design—the late 1990s—designing a large commercial website could cost as much as designing a medium-sized building. During this period, commercial websites were created and then often completely replaced with redesigned versions a short time later. Today the redesigning continues, albeit at a slower pace. What is the return on this design investment? A report on online ROI from Forrester finds that many commercial sites fail to even try to measure the effectiveness of design changes.3

What lessons have we learned about how design improves the interface between customers and companies?

The web has been with us for about a decade now. We’ve seen some obvious trends, such as greater use of multimedia, search engines, and increasingly sophisticated markup techniques. But these trends were facilitated by changes in technology. What lessons have we learned about how design improves the interface between customers and companies? Perhaps we can start by asking how websites have actually changed over time, and from that we can learn how websites should change in the future.

To start working toward an answer, I compared three eCommerce sites: Borders.com, BarnesandNoble.com, and Amazon.com. Much of the media’s coverage of these websites, especially coverage of Amazon.com, discusses the business models, corporate cultures, and finances of the companies. Since the medium of interaction with these companies is the website, it’s ironic that the media rarely critiques the site design and its effect on business performance.

Because it is the homepage that carries the most responsibility for guiding customers, I examined the homepages of all three sites from a number of years, using screenshots from the Web Archive4. Presumably these large retailers had a great deal to gain, and lose, with these substantial online ventures. By comparing design decisions over time among the three sites, I hoped to discover lessons from their extensive and expensive design experience.

The companies
Competition is fierce in the online bookselling market, currently erupting in offers of “free shipping.” All three companies have annual revenues in the billions of dollars.

Barnes and Noble, which runs a large chain of stores in the United States, claims the largest audience reach of any bricks-and-mortar company with Internet presence.5 Yet, both they and Borders were put on the defensive when Amazon’s growth rocketed. During December, 2001 BarnesandNoble.com attracted over 10 million unique visitors,6 compared to Amazon’s 40 million visitors.7

Borders is the second largest bricks-and-mortar book chain in the U.S. 8 In April 2001, after operating their own online bookstore for several years, Borders announced an agreement to use Amazon’s eCommerce platform to power a co-branded website.

Amazon claims to be the leading online shopping site, having expanded their selection to music, video, auctions, electronics, housewares, computers and more.9 By February of 2002, Amazon, which had pursued a get-big-quick strategy typical of internet companies in the late 1990s, announced its first profitable quarter.10

Criteria
I first studied these sites quantitatively looking for clear trends over time. I then critiqued them in a more qualitative way based on my own experience as both an in-house website designer and as an information architecture consultant.

There are many criteria that could be examined in such a study. I limited myself to those that would, I hoped, reveal as much as possible about the business intent of the design. I looked at criteria such as the type and size of layout, the type and amount of navigation, the amount of images and text, and functionality specific to the industry. Detailed results can be seen in the attached spreadsheet (PDF, 75k).

Analysis

Chart showing growth in length of homepages over time
Click to enlarge.
Note: Missing data due to imperfect records at the Web Archive.

All three sites use very long screens to display content on their homepages.
Using a browser window with a constant width, we can compare the vertical size of each site (all screen references assume an 800 by 600 pixel monitor). The Borders.com homepage grew from a vertical size of about 917 pixels in 1996 to over 3,000 pixels in 1999. Barnes and Noble’s homepage has hovered around 1,500 pixels for the last several years. Amazon’s homepage, which began at only 626 vertical pixels in 1995, stands at roughly 2,156 pixels today. In a web browser, that equals five scrolling screens of information.

Borders.com homepage above the fold, 1999
Borders.com above the fold (1999) Click to enlarge.
Barnes and Noble homepage above the fold, 1999
Barnes and Noble above the fold (1999) Click to enlarge.
Amazon homepage above the fold, 1999
Amazon above the fold (1999) Click to enlarge.

Note: Incomplete web pages are due to imperfect records at the Web Archive.

All three sites evolved to use three-column layouts.
In 1995 and 1996 respectively, Amazon and Borders.com used single-column layouts. By 1999, both of these sites as well as Barnes and Noble used three column layouts.

Amazon has consistently placed more links above the fold.
In 1999, the Borders site displayed only about eight links “above the fold” (the top portion of the screen that is viewable without scrolling). Both Barnes and Noble and Amazon had significantly more links above the fold in 1999, 30 and 48 respectively. Amazon averaged 43 links above the fold between 1999 and 2002 versus only 27 links for Barnes and Noble during the same period.

Through the years, the density of links on Borders.com was half of that on Barnes and Noble or Amazon.
The density of links has varied over time, but as of 2002 both Barnes and Noble and Amazon stood at about one link for every 15 vertical pixels of screen real estate. Historically, the highest link density at Borders.com was one link for every 28 vertical pixels.

Amazon communicates using images and links rather than text descriptions.
From 1999 through 2001, Amazon used more images and fewer text descriptions than Barnes and Noble. In 2002, both sites used about 560 words per page, yet the density of words was 33 percent lower on Amazon; Amazon distributes the words across the page as links rather than bunching them together in paragraphs. Over time, Barnes and Noble is becoming more like Amazon in this respect.

All sites eventually included navigation targeted at specific audiences.
Audience-based navigation—navigation labeled for a particular audience—appeared on Borders.com in 1998, on Barnes and Noble in 2000, and on Amazon as early as 1999.

Invitations to subscribe to an email newsletter were offered inconsistently.
Borders.com didn’t include this feature until 1998. Barnes and Noble included it only in 1998 and 2001. Only Amazon consistently included this feature from 1995 to 2002.

Online and offline design
So what lessons can we learn about how these sites changed over time? How has design contributed to Amazon’s high growth and significant lead over the others? In general, Amazon found a winning formula and applied it consistently over time. In my mind, the successful design elements emulated offline shopping experiences in many ways.

Personally, I was surprised at how long these homepages had grown. Combined with the three-column layout, each page contains a great deal of information. This is quite like the perceptual experience of browsing in a physical store. When you walk down an aisle in a bricks-and-mortar store you can visually scan the shelves quite quickly. On these websites, the long, scrolling pages are analogous to aisles (major groupings of items) and the columns are analogous to shelves (more specific groupings of items). With a similarly natural, efficient motion, a visitor can scroll down the page and visually scan the three columns of product listings.

Amazon homepage
Amazon homepage
(January, 2002)
Click to enlarge.
Barnes and Noble homepage
Barnes and Noble homepage
(January, 2002)
Click to enlarge.

Amazon’s higher number and density of links, and placement of those links above the fold, also reminds me of the aggressive product positioning in a physical store. It’s like walking into a food market and immediately being overwhelmed with rows and rows of colorful fresh fruit, stimulating our eyes and engaging our appetites.

The prominent use of images and sparse use of text on Amazon again harks back to physical objects with simple labeling.

The arrival of navigation intended for specific audiences seemed inevitable. Especially for the book market, a children’s section was developed surprisingly late on these sites given the disproportionately high revenues that come from children’s books in traditional shopping venues.

In general, many of the functions of these pages have become commodities: search engines, shopping carts, authentication and store locators. But Amazon’s extensive personalization sets this site apart functionally. Personalization mimics a personal shopper or a local store employee who knows you. While the online recommendations aren’t always right on, neither is a human assistant.

Rate of change
Many studies have found that our performance using a software application improves over time as we become familiar with its interface. Gerald Lohse and his associates translated this finding into the realm of eCommerce websites using statistical analysis.11 They also found that website visitors learn to use a site more efficiently over time and that this increases their purchase rate. In simpler terms, it means familiar sites are easier for people to use, so familiar sites are where visitors will make purchases.

It follows that sites that can be learned more quickly will more quickly become familiar, increasing the amount of purchases. So a faster learning rate equals a higher purchase rate.

Furthermore, Lohse found that familiarity with a particular website makes visitors less likely to switch to a competitive site because of the effort and time needed to become familiar with another site. He refers to this behavior as “cognitive lock-in.” Essentially, we are creatures of habit. He applied this analysis to several eCommerce websites by measuring the number of visits per person, length of sessions, and timing and frequency of purchases. He found the learning rate significantly faster at Amazon than at Barnes and Noble.

The rate of design change supports this finding. Amazon had no major redesigns from 1999 to 2002, only adapting their design gradually to changing needs. Barnes and Noble significantly altered their navigation in 2000 and 2001. Borders.com implemented major homepage changes in 1998 and 2000. Fewer redesigns make it easier for visitors to remain familiar with the site.

Conclusion
Many design elements on these websites are reminiscent of physical store layout, an approach to web design we should investigate further. Like physical stores, those designs should only change gradually to keep visitors buying. Continued analysis of other sites will hopefully help confirm or deny these findings.

It may be a fallacy to state, “Amazon is a successful business, therefore their website design is successful,” since many factors have contributed to their business success. And yet it’s hard to imagine them having such great success with a mediocre site. A similar eCommerce site launching today could do worse than examine and emulate the design elements that Amazon utilizes.

View all End Notes
Victor Lombardi writes, designs, and counsels, usually in New York City. His personal website is http://www.noisebetweenstations.com.