Special topic: Intranets

Introduction to the Building Blocks

Written by: Joe Lamantia

The Building Block System

This story continues the Introduction to Building Blocks Series.

Part 1 of this series “The Challenge of Dashboards and Portals” discussed the difficulties of creating effective information architectures for portals, dashboards, and tile-based information environments using only flat portlets, and introduced the idea of a system of standardized building blocks that can effectively support growth in content, functionality, and users over time. In enterprise and other large scale social settings, using standardized components allows for the creation of a library of tiles that can be shared across communities of users.

Part two now outlines the design principles underlying the building block system, and the simple guidelines for combining blocks together to create any type of tile-based environment.

Overview

The building block system is a packaged toolkit that offers standardization across several layers of an information environment, including the information architecture, the user experience, the functionality, and the metadata. As a potential framework for standardization, it is most important to understand that the building blocks are inclusive rather than exclusive, and that they are neutral with regard to any specific software solution, vendor, package, programming language, system architecture, development platform, business rules, enterprise environment, or user experience design guidelines.

Consequently, adopting the building block system and approach – at the right level of formality for a particular set of business, technology, and information architecture needs – can help resolve some of the many problems inherent in flat portlet-only design approaches (the box of chocolates model) regardless of the context. Potential applications or contexts of use for the building blocks include:

Any experience defined by stock portlets
Any environment assembled from custom built or customized off the shelf [COTS] tiles
Intranets and extranets
Content aggregators
Collaboration environments and solutions such as SharePoint, eRooms, etc.
Personal publishing platforms and group authoring solutions
Wikis and other collaboratively authored knowledge organization structures
Web-based personal desktop services such as Google and Netvibes
Mashups services and platforms such as Yahoo Pipes and Google Gears
Social networking platforms such as Facebook, Myspace, etc.
The rapidly expanding collections of public domain widgets

The building block system defines two types of information architecture components in detail – building blocks (or Containers), and navigation components (or Connectors) – as well as the supporting rules and guidelines that make it possible to assemble complex user experience architectures quickly and effectively. The block system is not a pre-packaged dashboard or portal design. Instead, it offers modular components you can rely on to work together and grow coherently as the pieces making up a finished dashboard or enterprise portal. Using the blocks will help focus design efforts on the important questions of what content to provide, how to present it to users, and how to manage it effectively.

The complete package includes:

Basic principles and assumptions underlying the block system, and how it can complement other design approaches.
Assembly guidelines and stacking hierarchy which shows how to combine blocks into larger units while ensuring a sound and consistent information architecture.
Modular building blocks of all sizes (Containers)
Modular navigation components (Connectors)
Standardized Convenience Functionality for blocks, which recommends a baseline set of common capabilities such as export of building block content, printing Tiles, etc.
Common Utility Functionality which captures common productivity enhancements and capabilities linking the block-based system to other enterprise systems such as calendars and document repositories.
Suggested metadata attributes for blocks that support administration and management needs, as well as important classes of utility functionality including alerting, syndication, searching, collaboration, and system administration.

1. Basic Principles and Assumptions

A few basic principles inform the design of the building block system and establish its boundaries with regards to other design systems or paradigms. In sum, they outline an open, flexible, well-structured, and internally consistent system. While the building blocks are independent of many constraints for where and how they may be put into effect, they will be most effective when a limited set of assumptions about the underlying environment are true. Those assumptions include the availability of authentication functionality to verify user identities, a role-based security framework that allows security permissions to be set at the level of individual blocks, a reasonably robust network that doesn’t require design for asynchronous use, and standard service levels for source application and system hosting and maintenance to ensure the steady availability of aggregated content and functionality.

Principle:Openness

The building block system is open: using the building blocks does not mean that every piece of content must appear within a Tile (Tiles are the smallest building blocks, the de facto foundation level). In the same way that many sites supported by content management systems include considerable amounts of content that is not directly managed by the CMS, it is easy to mix block-based and free-form content in the same Dashboard or Portal, and even on the same Page. Mixing content may require you to give up some of the benefits of the building block system, depending on your platform and other infrastructure elements, but this is not sufficient reason to try and wedge everything into a poorly designed Tile.

Figure 5: Openness

Principle: Portability / Syndication

The building blocks support portability and syndication by design, under the assumption that individual building blocks or groups of blocks can and will appear outside their original context or in more than one context (if not immediately, then at some point in the future). With the right IT infrastructure and environment in place, it is possible to share defined blocks of all sizes amongst a suite of integrated dashboards/portals or other environments tailored to different audiences, or with other applications and systems. The structure, presentation, and attributes of the building blocks look ahead to the creation of a large library of assets that diverse consumers throughout the enterprise or in the broader community can use and reuse.

Figure 6: Portability / Syndication

Principle: Independence

Building blocks are wholly independent of one another, unless stacked together into a larger unit. This means that while one block may offer controls or functionality that manipulate its contents, neither those controls nor that functionality will affect neighboring blocks unless the blocks are stacked together.

Figure 7: Independence

Principle: Inheritance

The blocks follow a simple inheritance pattern, wherein nested blocks inherit the properties and behaviors of blocks with a higher stacking size stacked above them. (Keep in mind that the literal ‘size’ of a block – what kinds and how much content it can contain – is not determined by its stacking size. The purpose of the stacking size is to assist designers in creating experiences with consistent behavior and structure.) If a block at a higher level offers the ability to change its contents with a Control Bar, these changes affect all blocks stacked inside, cascading down from the highest level of the stack. If a block contains other blocks nested at several levels of the stacking hierarchy, and those blocks offer controls that change their contents, then changes affect all of the blocks nested within (or stacked below).

Figure 8: Inheritance

Principle: Layering

The building blocks work together as a coordinated system across multiple levels of the layer cake that comprises an information environment, from the user experience – visual design, information design, interaction design, information architecture – to functionality, metadata, business logic, and administration. It is possible to use the blocks to effect standardization at the level or layer of your choosing. For example, you could rely on just the presentation standards for identifying Container blocks to establish consistent screen layouts. Or you could put all the aspects of the block system into practice to drive the structure of a suite of integrated sites from top to bottom.

Figure 9: Layering

2. Assembly Guidelines and Stacking Hierarchy

The building block system relies on a small set of assembly guidelines and a size-based stacking hierarchy to ensure that it is easy to understand how to properly combine blocks together into larger units. The purpose of the guidelines and stacking hierarchy is to maintain the internal consistency of information architectures organized and managed via the building blocks. The hierarchy assigns each block a stacking size, ranging from one to seven, and specifies a few simple rules for stacking blocks of different sizes. To see if it is possible to stack blocks together, compare their stacking sizes in light of the rules below.

Note: The Container blocks will be defined in detail in Part 3 of the series.

Figure 10: Stacking Hierarchy
This illustration shows the stacking hierarchy of the Container blocks, from the Tile – smallest, with a stacking size of 1 – to the Suite – largest, with a stacking size of 7.

Here are the assembly guidelines to determine proper block stacking:

It is possible to stack blocks with a lower stacking size (“smaller” blocks) inside blocks with a higher stacking size (“larger” blocks).
It is possible to stack several smaller blocks inside a larger block, for example placing three Tile Groups [size 2] inside a single View [size 3].
It is not possible to stack a larger size block inside a smaller block. This means you can stack several Tiles [size 1] inside a single Tile Group [size 2], but you can’t stack a Tile Group [size 2] inside a Tile [size 1].
It is possible to stack several sequential sizes of blocks together inside a single larger Container. This is the basic pattern for assembling a complex user experience.
It is possible to skip a level of the stacking hierarchy when stacking several layers of blocks, for example by stacking Tiles [size 1] within a View [size 3], without placing them within a Tile Group [size 2].
It is possible to stack different sizes of blocks together at the same level inside a larger Container.

As an example of the last three rules, a single Page [size 4] could include a View [size 3] and two Tiles [size 1] stacked at the same level. Inside the View are one Tile Group [size 2], with two Tiles [size 1] stacked inside the Tile Group, and two additional separate Tiles [size 1].

Figure 11: Stacking Example

Social Building Blocks Mechanisms and Network Effects

Thanks to these largely open system principles and flexible assembly guidelines, the building blocks can provide a lightweight skeleton that allows communities and groups of any size to create and use tile-based content and functionality within coordinated structures and processes, and then benefit from the network effects and social mechanisms that common structure and architecture makes possible.

With the support of basic environmental services such as tagging, rating, linking, search or findability, syndication, notification, and clear status signals, the building blocks can enhance well-known social processes or collective effects including:

sharing
comparison and interpretation
synthesis
remixing and mashup
opportunistic discovery
the emergence of collective consensus
crowdsourcing
exchanges with affiliate networks
the formation of specialized sub-communities
functional diversification

The building blocks can support all these social and network effects across the continuum of transparency and social involvement, from fully closed enterprises, to private and semi-public forums, to fully transparent or public contexts.

In the near future, Part 3 of the series will define the building blocks in detail.

Better Content Management through Information Architecture

Written by: Masood Nasser

“To implement a successful content management system, we have to go beyond business process and technology and understand how the organization, as an organism, interacts with and uses its content.”

Everyone understands the business case for Content Management: Organizations drowning in information can’t learn from, act on, or leverage knowledge and resources trapped in assets that already exist. You lose the content’s value if you can’t find it to use it.

To solve problems like these, business often purchases a technology, assuming the former is a feature of the latter. In the content management world, we hear the same kinds of promises from IT stakeholders, again and again:

Our developers will provide forms that authors will use to update content online (and every one will live happily ever after).
We will use XML (and every one will live happily ever after).
We will buy This software from That vendor—off the shelf—and authors will use this to update content. We will customize These options to match our requirements. (And every one will live happily ever after.)

Unfortunately, business often confuses technology for the solution. Forms, XML, and software won’t manage your content. Neither will they help authors create content, nor do they help you leverage content for later use. When Content Management Systems go wrong – and they frequently do – you can end up with terrible nightmare scenarios:

Authors write content, and try unsuccessfully to use theCMS.
IT updates content in relevant format and uploads for authors to review. The authors make power point presentations with changes and mail them to IT.
IT reviews the PowerPoints and uploads the changes.
Authors approve the changes, and IT uploads the final version to the site.

To prevent these kinds of scenarios, we try to customize off-the-shelf systems or develop our own, but… IT and business, focused on issues with technology and business process neglect the system-wide ecology that governs how those technologies and processes will be used.

Four crucial factors govern the success of your content management system

Four crucial factors that govern successful CMSs
To implement a successful content management system, we have to go beyond business process and technology and understand how the organization, as an organism, interacts with and uses its content. Four factors are crucial to ensuring an organization can successfully manage its content:

Who will interact with the system? Who will create and manage the content? Also, who will need to find and use the content later?
What are we managing? What is mission-critical? What kinds of data do we need to manage?
How is the system managed? How is the content authored, approved, and managed? How does theCMS enable your business processes?
How is the content used? Who will use it, when, and why? How does this integrate with your Information Architecture?

Framing content management in this way helps move the discussion away from business processes and technology. Several familiar methods and tools can help organizations answer these questions and understand how content is created and managed into the system, as well as found and used out of the system.

Who uses your CMS? Authors, approvers, and users (oh my!)

One of the first steps in implementing a CMS should be to identify theCMS users: who will author and publish content? Gather data through user research and modeling.

Scenarios can reveal how the system will really be used, and personas can help business and IT better understand the goals, skill-sets, and motivations that directly impact how successfully the content management system will be used.

The following questions can be useful during user research:

What tools are used to author content? At one large research University, instead of composing content using the CMS’s forms, instructors copied and pasted existing content from old syllabi written in Word.
How is content authored? At a financial services consultancy, all content was painstakingly crafted by copywriters. In one city council campaign, content appeared as bullet points in emails (or on a whiteboard) that were translated and uploaded by (seemingly) random volunteers.
Do the authors and managers understand and use the information architecture? At a large development bank, authors rarely categorized content because they didn’t understand the interface (or its importance). Figure 1 shows a typical content administration screen. Do content authors and managers understand and use the interface?

Figure 1: A typical content administration interface.

Understanding how people use the content is equally important.

Who uses the content? In that city council campaign, the website was written for potential voters, but it was mostly used by reporters and precinct captains.
How do they use the content? At a large government agency, the system stored versions to help in production of final documents, but writers used stored versions to find examples to copy and paste from.
When do they use the content? One music publication published reviews of new releases as a stream of new content, but access was most common for users researching albums long-after they had come out.

In addition to helping you better understand your users, personas and scenarios can help you test and validate how the effectiveness of theCMS

What are we managing? Handling mission critical content.

What data really needs to be handled by a CMS? In a utopian situation, the database can manage any type of data or content. In reality, it does not work that way. Content management systems usually do not handle all types of data effectively, so you must prioritize critical data and workflows.

Where does the content come from? Is it created in-house? Does it arrive in feeds from outside providers? At a large entertainment website, most content came from licensed feeds from outside providers, but in important cases, content was created by onsite editors.
What formats do you need to manage? Large enterprises typically manage office documents created, like Word or WordPerfect files. Do you need to manage multi-media files? PDFs? Flash? Implementing search or a decent taxonomy for these formats is a different ball game altogether, and many content management systems simply do not have the ability to manage them efficiently.
How often does the content need to be managed? It often does not make financial sense to manage content that is updated on an infrequent basis. Content management systems typically do not have the ability to present brand vehicles – like annual reports – in formats that are aesthetically pleasing and reflect the company’s branding. That job is best left to your creative and marketing team.
What content is most important? Critical tasks deserve special attention. Regardless of how frequently critical content tasks must be completed, their importance may require the system allow you to manage their content quickly and flawlessly.

Along those same lines, it may be better to handle a few types of content well, than to handle all types badly.

A broad inventory that lists types of content, sources, and formats can help you understand the potential scope of content you need to manage. Rating the importance of each type of content can help you prioritize what the system must handle, as opposed to what would be nice.

In the example above, handling annual reports might be nice, but managing product descriptions may be imperative.

Along the same lines, task analysis of both common and critical tasks at your organization can further illuminate types of content to focus on.

Conclusion

To implement content management system that really works, business and IT must think beyond internal processes and technology. If your organization keeps in mind the users who will interact with the content as well as the range of types of content, then your CMS is much more likely to succeed.

However, users and content are only the inputs that go into your CMS. Understanding the content lifecycle is the final missing piece. In part two of this series, I’ll examine additional design methods that can help illuminate the early content lifecycle—how the content is managed—as well as the content’s end lifecycle when it finally lands in the hands of end-users.

The Challenge of Dashboards and Portals

Written by: Joe Lamantia

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

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

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

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

Portlets: MIA (Missing Information Architecture)

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

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

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

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

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

Escaping flatland

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

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

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

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

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

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

A vision: syndicated assets for enterprise portals

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

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

Figure 3: Tile Library

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

Figure 4: Vision: Shared Enterprise Assets / Tile Library

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

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

Succeeding at IA in the enterprise

Written by: James Robertson

As information architects, the core of our profession rests on the analysis of information, the identification of structure, the creation of taxonomies and site maps, and the development of wireframes and user interfaces. These skills are well-honed, and we play a significant role in the design and creation of many systems, from websites to web 2.0. The real challenge is making things happen and getting users to adopt the new solutions

Working within the enterprise, we are confronted with new challenges. There is a lack of clarity around needs and goals, organisational issues are paramount, and the real challenge is making things happen and getting users to adopt the new solutions.

This is the focus of what is often called “enterprise IA”, the application of information architecture in complex business environments. To be successful in these situations, we need skills and strategies that focus much more on people than on information.

This article explores some of the approaches needed to ensure that we are successful at implementing IA within organisations, with the goal being to encourage further discussion in the community about these issues.

Business strategy At the end of the day, enterprise IA projects need to be able to demonstrate that they have made a real and measurable difference to the core activities of the organisation.

More than any other skill set, enterprise information architects need to have a strong understanding of business strategy and planning. With so many possible issues to solve, the greatest success is achieved when activities are designed to support organisational strategy and to deliver tangible business benefits.

In practice, this includes:

Building a strong understanding of overall corporate strategy and directions.
Using this knowledge to select projects that will support organisational goals.
Designing projects to deliver tangible and visible benefits within the organisation.
Developing project plans that will deliver “quick wins” while building momentum for longer-term activities.
Conducting good project management, including working within project constraints and maximising the use of project resources.

At the end of the day, enterprise IA projects need to be able to demonstrate that they have made a real and measurable difference to the core activities of the organisation.

Top down and bottom up

Successful enterprise projects follow both a “top down” and “bottom up” approach that combines overall business strategy with an in-depth understanding of staff needs and issues.

This is illustrated in the following diagram:

Enterprise flow diagram

For an information architecture project, this means:

Working with senior management to obtain strategic input, including overall business goals and objectives.
Conducting in-depth research with key staff groups to identify major staff issues and needs.
Using the strategic view as a “lens” to select key activities that both support business goals and meets the needs of staff.
Developing a set of tactical (short-term) strategic (longer-term) activities to deliver improvements to information management within the organisation.

While this is not the only way that an enterprise IA project can be managed, it demonstrates different approaches that must be explored by information architects when addressing complex business problems.

Understanding staff

User research techniques such as interviews, focus groups, contextual inquiry, and workplace observation are well understood and widely practiced by most IAs. While these techniques are important in general IA projects, they are critical for enterprise IA activities.

For a typical website project, the starting point is to define goals, objectives, and broad functionality. Research is then done to determine the best way to design and deliver the solution, with user-centered methodologies driving interface design and site structure.

Within the enterprise, the order is reversed. The starting point, as outlined earlier, is to conduct research with staff. The purpose is to identify the needs and issues of staff, which then helps define the goals and scope of the project.

This research is much more open-ended than typical user-centered design. Staff aren’t asked questions about the intranet, portal or document management system. Instead, the aim is to build an in-depth understanding of how staff work, and the environment in which they operate. In practice, we’re looking for issues and needs that we don’t even know to ask about. (The “unknown unknowns”, to quote a now-infamous speech in the US political arena.)

This approach is much closer to ethnography than user-centered design, and we can learn much from this discipline when working within the enterprise. By building up this depth of knowledge, we can target the most important needs, confident that the solutions delivered will be useful (and used) in practice.

Organisational change

Enterprise IA projects are only successful when delivered solutions are actually used by staff. While this is more certain when solutions are based on an in-depth knowledge of staff needs, a comprehensive change management plan will still be required.

Organisational change becomes a key element of enterprise IA projects. Information architects working within complex business environments need to have a strong understanding of organisational culture and how to work effectively within it.

For example, the greatest enemy of our projects is not active resistance, but apathy. While information problems within the organisation are generally widely known, they are not seen as sufficiently urgent or important to be addressed as a matter of priority.

Enterprise IA projects must start by creating a sense of urgency within the organisation. A strong message and vision must be created for the projects, and communicated widely to build support at all levels of the organisation.

Technology

Enterprise information architects must be prepared to work across technology boundaries. This is about delivering a single user experience that provides a seamless work environment regardless of what technology is used behind the scenes.

This means that enterprise IA projects must at least have an understanding of:

intranets
content management systems
document and records management systems
collaboration tools
applications and databases

This is not to say that enterprise architects need to be technologists or developers. In most cases, enterprise projects will be supported by IT teams and departments that provide specialist skills in these areas.

Enterprise IAs must, however, understand enough of these technologies to create solutions, taxonomies, and designs that help to bring these systems closer together, towards the goal of a single user experience.

Working with others

There are many disciplines that are working to solve enterprise issues, including:

knowledge management
content management
information management
document and records management

There is no one group that “owns” the problem, or has all the skills, tools and resources to solve it. While each group has its own models and metaphors, each successfully addresses at least part of the overall problem.

This is where we need to build our skills in working with others, what Lou Rosenfeld calls our “horse trading” skills. This is not just about working in multi-disciplinary teams, it is about working with key individuals from other teams, business units or even divisions, all reporting through different chains of command.

(This is where establishing a “community of practice” focusing on enterprise issues can be very helpful. This approach is actually drawn from the knowledge management domain, further demonstrating the need for collaboration between disciplines.)

Successful enterprise IAs are those with people skills, perhaps ahead of their specialist skills in card sorting, taxonomies, wireframes, and paper prototypes.

A call to arms

The need to deliver better solutions within organisations is great. When driven solely by technology, enterprise projects almost invariably deliver unusable interfaces and poorly structured information that generates considerable resistance to change.

While information architects are not the only group working within the enterprise space, there is the opportunity to demonstrate leadership in delivering effective projects and solutions.

If this is to occur, then the information architecture community needs to build its knowledge in the areas of business strategy and organisational change. We also need the people skills to work well with many other groups within the enterprise, each of whom contributes some part of the overall solution.

This is not to say that all information architects need these skills. Designing interfaces and structuring information is a worthy challenge, and it remains as the core of information architecture.

Space must be found, however, to discuss and explore the unique challenges encountered within the enterprise. We must recognise that a strategic view is equally important as professional design expertise and enterprise information architects must be supported in their quest for best-practice approaches and techniques.

So much more can be written about enterprise information architecture, and this article merely scratches the surface. It is hoped, however, that it will contribute to the discussions in this space, and to help raise the visibility of issues already being wrestled with by information architects in many organisations.

Final words In an ideal world, information architects will be part of a broader team …. we must understand organisational issues, but are not responsible for resolving them.

All of this is not to say that information architects need to become specialists in business strategy and organisational change. We will certainly not be hired to develop business strategy for organisations (and nor should we be!).

In an ideal world, information architects will be part of a broader team within an organisation that includes change managers, professional communicators and other specialists. As part of this team, we must understand organisational issues, but are not responsible for resolving them.

In practice, however, information architects often work alone or in small teams. Even large corporations often leave IA projects with only modest support and resources, perhaps due to a lack of understanding of the full challenges involved in delivering enterprise solutions.

In these cases, information architects are then faced with two choices: become more proficient in the areas outlined in this article, or narrow the scope (and expectations) of the project.

In either case, enterprise information architects will always benefit by having at least a core knowledge of organisational issues and approaches.

Making Knowledge Management Work on your Intranet

Written by: Shiv Singh

“ …a genuine commitment to knowledge management (KM), a KM strategy centered in the application of knowledge towards specific business objectives, and tactics that use the company intranet as a platform to further those KM initiatives, will go a long way in realizing new organizational value.”

Introduction
In the information economy, the longevity of an organization is based as much on the sophistication of its knowledge management practices as it is on traditional differentiators such as the strength of its products, the talent of its employees, and its marketplace reputation and partner relationships. Simply speaking, as actionable and insightful information becomes the currency of an organization, there are few other ways to tap into any latent potential lost in the office corridors.

There is no one-size-fits-all, cost-effective knowledge management solution; nor is there a specific technology, product, or vendor offering that can help you differentiate yourself through your knowledge management practices. But a genuine commitment to knowledge management (KM), a KM strategy centered in the application of knowledge towards specific business objectives, and tactics that use the company intranet as a platform to further those KM initiatives, will go a long way in realizing new organizational value.

This article discusses typical KM challenges facing large organizations and how a company intranet can be leveraged to create lasting and measurable business value. It does this by examining the relationships between two aspects of knowledge management and how they contribute to a goal-oriented knowledge management initiative. The aspects of knowledge management discussed are people (in the form of communities of practice) and enterprise intranets as knowledge platforms.

What is knowledge management?
The first question often asked is what really is knowledge management? Is it simply the cataloging of all the documentation that resides on server hard drives, Outlook inboxes, and the filing cabinets of employees? Or is there something more scientific and strategic about it? Is it an archiving function appropriately delegated to a support team, or should it be something on the CEO’s radar?

The American Productivity and Quality Center defines knowledge management as “the strategies and processes of identifying, capturing and leveraging knowledge” (APQC, 1996 cited in Atefeh et al., 1999 p.172). For the learnings to be retrieved and reused, they need to be qualified and codified so that they are accessible and searchable. Furthermore, knowledge management can also include strategies to foster a culture of information sharing and the implementation of tools that make it easier for employees to share their learnings and, in turn, to learn from each other.

Typical KM challenges
All organizations are practicing KM in some fashion today. Sometimes these are management mandated, focused, and structured initiatives such as procedures to capture customer feedback on product features to help design new products. In other cases, they are basic grassroots efforts by enterprising managers who, for example, may encourage their teams to publish best practice documents on a file server. But while these organizations understand the importance of knowledge management, many of their initiatives produce mixed results. In fact, most knowledge management initiatives do not last more than six to twelve months. This is often because of the following factors:

The knowledge management initiative lacks mass appeal — the initiative doesn’t have enough enthusiastic supporters or institutional support to reach critical mass where the benefits outweigh the time and dollar cost to support the endeavor.
The initiative simply lacks depth — the repository isn’t large or diverse enough for its use to become a habitual activity for many employees. They visit once and never return.
The knowledge isn’t qualified — the knowledge captured by the initiative is not validated, resulting in each individual employee having to expend energy in searching and filtering to identify the actual knowledge from the professed knowledge.
Knowledge codification is ignored — the KM teams don’t put enough effort into adding metadata to the documents and organizing the learnings in a single repository, resulting in inefficient and duplicative KM systems from which it is difficult to search and extract knowledge.
Competing systems undermine the effort — the KM initiative competes with too many other internal and external systems and processes as an authoritative knowledge source for employees.

Issues like these not only hamper the KM efforts, but, more troubling, their perceived value to an organization. As a result, many managers are becoming disillusioned with the potential of enterprise wide KM practices.

However, KM is getting a second chance with corporate intranets gaining new prominence in many organizations. As Fortune 1000 organizations recover from the recent economic downturn by consolidating their operations, revisiting their product roadmaps, merging with other firms, and positioning themselves as being more customer-centric and principled, they’re looking to their company intranets to communicate their new values, business objectives, and operational strategies to the rank-and-file. These organizations are also discovering that investing in an intranet is an expensive endeavor and that they must look for other benefits when trying to make a strong business case for an enterprise-wide intranet. This is where knowledge management enters the picture.

The KM opportunity
Some senior executives make the mistake of believing that knowledge management is an end unto itself and attempt to manage and measure KM success with that in mind. Rather, KM initiatives should be treated as intellectual capital investments aligned with specific, long-term business goals. For an organization to do this more effectively, it needs to leverage the Communities of Practice (CoPs) within its organization.

What is a community of practice? Brooke Manville, Director of Knowledge Management at McKinsey & Co., defines communities of practice as groups of people who are informally bound to one another by exposure to a common class of problems. These groups share their learnings and knowledge resources continuously and informally amongst each other for mutual benefit. Every organization has groups like these, which are typically loosely structured, decentralized, fluid, and built on personal relationships.

These CoPs are perfectly positioned to support knowledge management efforts. They are continuously capturing and sharing relevant knowledge with each other. Often, though, the knowledge captured is not directed towards a business objective and isn’t codified or validated in any formal capacity. Nor is the knowledge stored in a format that enables easy retrieval.

An organization can leverage these CoPs to further its KM objectives by stepping back and creating a list of priorities for what types of knowledge to capture and share. These priorities should directly map to the organization’s business goals and should represent what the organization needs to know to be more successful in the marketplace both at the organization and at the individual level. In other words, these priorities should be a list of “if only I knew” types of knowledge.

Once the business priorities have been identified, existing CoPs should be approached to more formally capture and roll out these organizational learnings in a piecemeal fashion using the intranet. If there aren’t any communities of practice naturally aligned to the business priorities, then new ones should be organized. Some large organizations with a history of knowledge management successes have already structured their communities of practice to do this for them on a regular, focused basis. However, these aren’t always successful initiatives because the CoPs have a hard time striking the right balance between knowledge explorations and being focused on the business goals.

Nevertheless, there are opportunities to further focus these communities of practice when using the enterprise intranet as a delivery mechanism. This is because collaborative environments such as enterprise intranets force the participants to be focused, thoughtful, and careful in their contributions. Knowing that what is published may potentially be viewed by the whole organization, or that other users may have the ability to rate the article, forces the participants to be more disciplined in their contributions. In effect, the collaborative, real-time feedback environments of a company intranet encourage self-policing and more strategic information sharing. The downside is that it can also discourage participants from sharing any information whatsoever.

Let’s take a management-consulting firm as an example to study this a little further and discuss how knowledge can be captured and shared.

A consulting firm example
In most consulting firms, knowledge priorities can be broadly categorized as knowledge that:

supports the business development and sales process,
contributes to the delivery of services in the form of methodologies, tools, and processes, and
builds awareness among employees of industry and discipline issues.

Let’s say that of these three knowledge priorities, the consulting firm identifies supporting the business development and sales process as being of the greatest importance. Further, it determines that actively sharing business proposals and case studies, along with the individual learnings regarding each one, is most important to satisfy the KM needs in this area. The organization can implement this knowledge priority via their intranet by doing the following:

Choosing the right employees — Identify four to six employees who have been enthusiastic and informed KM supporters in the past to serve as community gatekeepers and monitor the publication of content if no existing CoPs exist that cover this subject area. If an appropriate CoP does exist, then gatekeepers from that community should be identified.
Coaching the gatekeepers — Educate the gatekeepers on how to develop and nurture a new community of practice with a focused objective — in this case, capturing knowledge that can support the business development and sales process. The business objective should be further studied by the gatekeepers to more deeply understand what types of relevant learnings can be captured.
Designing the collaboration environment — Create a collaborative space on the intranet for the distribution of these learnings. This space should allow for the submission, categorization, rating, and discussion of content. Careful attention should be paid to the structure of this workspace, from the labels used to who can access it and how much categorization is needed.
Establishing rules for participation — Actively encourage employees to publish their relevant content to this collaborative workspace. These employees should be invited to join the community. The rules of participation, the organizational and personal benefits for getting involved, and the “safety net” guidelines to prevent discussions from spinning out of control should be explained. This collaborative workspace should support notification features so that users can be alerted when new content is added.
Providing incentives — Tie in each participant’s KM involvement with his or her annual bonus. Reviewing how active the employees have been, whether they have been responsive and responsible community participants willing to share and learn from each other, and the quality of their contributions in relation to the business priorities should be included as contributors effecting their annual bonuses and raises.

An initiative like this doesn’t cost much and wouldn’t take long to implement. Once one knowledge community has been established, the organization could seek similar opportunities to create knowledge communities based on other business priorities. Thus over time it may have a network of interconnected communities that capture organizational and individual learnings related to specific business priorities. Remember that the more tightly defined the business priorities and the more motivated the community gatekeepers are, the more likely the initiative is to succeed.

Intranets as knowledge management platforms
Well-planned intranets make perfect platforms for your knowledge management initiatives. But most intranets aren’t deliberately planned, as they start out as grassroots, divisional efforts that are then leveraged across the whole organization. Many of these intranets hold valuable information but are wild, decentralized, and unstructured spaces. This can be a problem, as employees will only use the intranet as a learning, collaborative platform if they have confidence that it will consistently provide them with authoritative, validated, and qualified knowledge in return.

Your intranet can be optimized to support knowledge management initiatives if you make changes to the existing content, publishing processes, and information architecture of the intranet.

Evaluate your content
Existing content is the trickiest to deal with, as it is hard to know how much content is published online. Removing meaningless, orphaned, dated, and irrelevant content that is of little use to the employees is the first step in this process. This type of content has no place on the intranet and should be removed as soon as possible.

Another problem with the content on an intranet is that it could be published in the wrong place, in the wrong format, and potentially with the wrong amount of emphasis attached to it. Use professional content strategists and information architects to help you understand, manage, and evolve this content.

Make publishing more democratic
Publishing processes can really make or break the success of your KM intranet. Do not push the publishing of content down to the bottom of your corporate hierarchy. For the intranet to become a knowledge management platform with knowledge communities, every intranet user should know how to publish content and provide feedback on content already published.

Publishing should not be left to administrative assistants who don’t understand the content well enough to know where to publish it or whether it should be published online at all. Also pay attention to the actual publishing process, as this is your opportunity to codify individual learnings by forcing publishers to add metadata, categorize, and edit the content before publishing it.

Tweak the information architecture
Finally, if you hope to use your intranet as a knowledge platform to support your business objectives, pay particular attention to the information architecture. Research your users’ needs and, just as importantly, how the users relate to the current content and nomenclature on the intranet.

Consider categorizing all content by use rather than subject. Categorizing the content by the context of its use, the depth of the information, and the target audience will result in more distinct, intentional, and goal-oriented user experiences. It will also naturally limit the amount of redundant content published. Most intranets today organize content either by department or by Internal processes that only the process owners understand.

Conclusion
Knowledge management is becoming immensely important in today’s fast-paced, disruptive business environment. In fact, recent research conducted with 182 work groups at a Fortune 500 telecommunications company by Jonathon N. Cummings, assistant professor at the MIT Sloan School of Management, showed that teams that share knowledge, both intra-group and externally, perform better. These findings validate previous research and underscore the importance of knowledge management.

Still, organizations have struggled with implementing knowledge management effectively. Overly ambitious projects, a lack of attention to organizational cultures, and unsophisticated technology have doomed KM efforts in the past. The company intranet has been ignored or treated simply as a file server when it comes to sharing learnings.

But approaching knowledge management in a simpler, more tactical fashion where the emphasis is placed on the application of knowledge can be the key. Identifying your organization’s KM priorities, carefully focusing your communities of practice on these priorities, and upgrading your intranet to be a more of a knowledge platform will help you quickly develop a relevant, meaningful, and beneficial KM initiative.

References:

Kluge J., Wolfram S, and Licht T. 2001. “Knowledge Unplugged: The McKinsey & Company global survey on knowledge management,” Palgrave Publishing.
Cummings, Jonathan 2004 “Work Groups, Structural Diversity and Knowledge Sharing in a Global Organization,” MIT Sloan Management Review Winter 2004, Volume 45, Number 2, p. 5

Shiv Singh has been with SBI.Razorfish since 1999 and has worked in its Boston, New York, San Francisco and London offices. He helps clients leverage digital technologies to develop meaningful and value driven customer and employee relationships. Shiv primarily focuses on intranet and extranet design and likes to work at the intersection of business strategy and information architecture. If you want to learn more about him, visit his website at http://www.shivsingh.com