Institutionalization of UX: A Step-by-Step Guide to a User Experience Practice, Second Edition (2014)

Part II. Setup

Chapter 9. Knowledge Management

Large-scale user experience design operations are different from small ones. The key difference is their knowledge management requirement.

Conventional approaches to knowledge management are associated with overwhelming problems.

Good knowledge management requires object-oriented user experience design.

Linkages are critical to accessing user experience design content.

Putting an industrial-strength user experience design knowledge management facility in place presents challenges.

There is a quantum difference between doing user experience design with a small group on a small scale and approaching it with a serious, well-staffed team and/or across an enterprise. One of the by-products of a greater UX investment is an exponential growth in the workload, based on the growing recognition of the value of user experience design projects (see Figure 9-1).

Figure 9-1: Growth of user experience project load for a large pharmaceutical company

When you approach user experience design in the conventional, small-team way, each project is represented by a set of documents—that is, you create slide shows and Word documents. At first, it might seem as if everything is going fine. But all too soon, you have terabytes of materials. Anything you want to know about is effectively lost in the black hole of your document management system. For example, you might have 40 projects that involve the “Digital Native” user group. If you want to collect what is known about the Digital Natives, you would do a search, only to discover that there are hundreds of documents to review. You find documents from the projects focused on Digital Natives—many of which are peripheral, containing perhaps a nugget of information about this user group. It becomes so difficult to read all the documents that most teams end up doing the research again.

Of course, you could make a special file for Digital Natives and keep the contents there—but user experience design work is not just about user profiles. It is about users and scenarios, environments and artifacts, needs, methods, standards, projects, and designs. You might need to know everything about an environment, such as a bank branch, or you might need to know about an artifact, such as an eye wash unit in a lab. (We call each of these items a UX object.) On top of that, you often need to look at the items based on linkages—and almost all of them are interlinked in some way.

With a small user experience design team, knowledge of users, scenarios, environments, and other UX objects is stored as a shared understanding within the team. Yes, the loss of a team member is a serious setback, but with just a half-dozen people focused on a limited domain, the organizational memory is usually not too difficult to retain. You can save methods and standards in physical or electronic folders. If the team wants to know something based on the linkages, such as which methods have already been applied to a given user group, someone probably remembers. If they want to find which applications have applied a given standard, they simply need to scan through perhaps a dozen different systems.

An organization may distribute the user experience design operation among a number of small teams, each focused on a single domain. The real challenges then come when looking at the way methods and standards are applied across the organization. It is a rare organization that has truly isolated domains: domain knowledge is so valuable that an organization’s growth will almost always be based on an interrelated set of channels and business areas. As such, there is no good way to carve up user experience design work into small, siloed work teams without overlap—nor is there often a good business case to be made for doing so. Your retail and commercial banking operations might be fairly discrete from one another, and there is likely to be only modest overlap between the personal and business domains (e.g., your businesses owners have personal accounts that they would expect to have conventions similar to their business accounts). When your retail and commercial banking operations expand to a level that requires at least 50 user experience design professionals for each domain, however, you will have gone far beyond that easily managed small team—the one that kept all that knowledge in their heads and on their desks.

Why Conventional Knowledge Management Fails

Let’s take a minute to break down the main methods used by conventional repositories to manage access to their terabytes of valuable data. Certainly, all repositories allow the author to affix meta-tags to each document. For example, you might create a report on middle market and mass affluent customers, using mobile devices, at home, in branches, and while commuting. In such a case, all the words in italics can go into the meta-tag. You can then easily find only those documents that are about middle-market customers using mobile devices. To some extent, that could be useful. Nevertheless, your search will not have given you a full picture of everything there is known about middle-market users or mobile usage. Instead, it shows only the documents that refer to both middle-market users and mobile usage. For your purposes, however, you might need to access the contents of a spiffy study on the emotions of middle-market users responding to high-pressure sales situations, or ecosystem insights into mobile device usage in emergency situations.

Another problem with meta-tags is that they are very much dependent on the diligence of practitioners in setting them up. To find the necessary content, you must resort to keyword searches—which finds relevant documents, but also gives you loads of irrelevant hits.

A strategy that many teams try is to set up a folder structure and to save documents based on that taxonomy. You can create a set of folders around different types of UX objects, for instance. You might have a folder of methods, for example, and a folder of standards. But what happens when you need to see all the projects that used a given method? What happens when you want to see only those middle-market user scenarios that take place in a given environment? When you have a little team and a handful of documents, this taxonomic approach works well. Once you begin industrial-size user experience design, it fails catastrophically.

The Cost of Failure

Most large-scale user experience design operations are like goldfish: they end up with a three-second memory. As a result, new studies are commissioned to research areas that have already been studied. At HFI, it’s not uncommon to have a large company approach us with two or three requests for expensive international research. Each study is basically the same; the requests just come from separate, uncoordinated teams.

The cost of duplicate research is high, as a serious ecosystem study will cost at least $250,000. But that is not the biggest cost. Truly catastrophic costs are incurred by making design decisions without the power of the knowledge that an organization could apply—leading to suboptimal strategies, missed innovations, and suboptimal designs.

Consider the valuation of an organization. For many companies, the real value of the firm is how well it knows its customers. In today’s business environment, an organization can no longer rely on the cultural memory of a team, with recollections about working in the field or doing projects for the customer segments. The workforce is moving toward shorter tenure within organizations and more free-lance staffing. Consequently, user experience design capabilities need to be more organized and sustainable. The result of object-oriented UX is a model of the customer, a key intellectual property.

Object-Oriented UX

The software industry went through a transition a few decades ago, in which it moved toward object-oriented programming. Originally, programs were written in a single flat file. This file mixed up screen calls with algorithms and data. Today, no programmer would use this method. Instead, programmers write modules of code for discrete tasks, and then call those modules repeatedly, so as to optimize reuse. In the same way, the user experience design field is starting to make its own transition to object-oriented design. Instead of doing all their work in a “flat file” or a document or slide show, UX teams are creating separate objects and then “calling” those objects inside of documents.

To see how it works, consider the UX Enterprise software service offered by HFI. To work properly, the user experience design team needs to work on the object and then, just as in programming, the practitioner calls the object when needed. Thus linkages are inserted inside of documents.Figure 9-2 depicts a sample “stamp” that is clicked to link to an object, Figure 9-3 shows a project report that uses stamps to reference the detailed objects, and Figure 9-4 illustrates a user profile object that contains everything that the team knows about one type of user.

Figure 9-2: A UX Enterprise “stamp.” Clicking on the stamp links directly to the object. Inserting the stamp in a project document links that project to the object.

Figure 9-3: A project slide deck that uses stamps to link to detail UX objects

Figure 9-4: A UX object holds everything the team knows about this user profile

Of course, many different types of objects are possible—users, scenarios, environments and artifacts, designs, projects, methods and standards, and various types of training and research. The structure of each type of object is different (see Figure 9-5 for an example of an artifact), and to some extent the objects need to be customized to the domain of the organization (see Figure 9-6 for an example involving South African languages).

Figure 9-5: An artifact is a tool or object that is used, but not designed by the team

Figure 9-6: An object customized for South Africa

Professionals Don’t Start from Scratch

One great thing about a “design by object” approach is the ability to copy objects and edit them, as opposed to creating everything from scratch. Why write a methodology when you can copy one and edit it? In making user profiles, we find the closest match we can and then edit it. For example, we might take an American surgeon profile and import Japanese cultural dimensions. There is no question that you can be far more productive when building on previous work. At www.uxmarketplace.com, you can find an open market for buying and selling all types of UX objects.

Linkages

Once a team starts working on a shared set of objects, instead of flat files of documents and slide shows, a valuable cloud of objects will grow steadily. But for this set of objects to be useful, the team needs to be a way to use the linkages between objects to view the data. For example, you might need to find the following:

• The projects that did usability testing on a given user profile

• The scenarios that a user completes in a given environment

• The scenarios that have a given need (or problem)

• The designs that apply a given standard

The only way to identify these subsets of objects is to store the objects in a relational database, and to create the linkages in as painless a way as possible.

With a relational database that allows you to access your cloud of UX objects, you can collect and view an entire ecosystem. Today the ecosystem view is critical, because we have to design for multiple actors, in complex environments, with embedded and ubiquitous digital channels. But what defines an ecosystem from a data structure viewpoint?

Practitioners draw charts of ecosystems, but charts have different centers of focus. They might show the ecosystem around a student, for example, or they might consist of the ecosystem around a mobile device. They might also depict the ecosystem within a given environment—or a single scenario. They can even illustrate the ecosystem of a need or strategic challenge (such as everything related to transitioning customers to a digital channel). Given the many possibilities, we must be able to let the practitioner identify the focus of the ecosystem model and then have the system concatenate the objects that surround the core focus (see Figure 9-7 for an example of an ecosystem model).

Figure 9-7: An ecosystem of objects related to a bank branch (demo data only)

Summary

If your operation will be bigger than a small, manageable team of five to six practitioners, you should consider working in an object-oriented structure. That means breaking the habit of putting everything into slide shows. It also means having a toolkit that supports object-oriented user experience design. The result will soon be a valuable cloud of knowledge about your customers—core, corporate intellectual property that also makes the user experience design team stronger, more sustainable, and more valuable.

The transition from programmers coding in flat files and object-oriented programming took about a decade to accomplish. The transition to object-oriented UX poses a challenge as well. We have seen serious impediments around long-established habits, patterns, and vested interests. Given this reality, you shouldn’t expect to pop in a tool and instantly change the way your user experience design practitioners function.