Jonzing to take part in another 120-mile speed-skating race? You might have to wait 18 years, which is the likely interval between one Elfstedentocht and the next, owing to the effects of global warming.

As you wait for the ice to thicken, you can drive (in an energy-efficient manner) to one of the sustainable dance clubs popping up all over, and sweat your prayers.

So we can (almost all) agree the climate is changing. Not simply the climate that’s melting the ice, though. Also the economic climate, the one threatening to wash away your job. And the political climate, the one that can keep us all afloat.

Just a few months ago, business leaders habitually dismissed arguments in favor of ecologically responsible development because they were too busy pumping gobs of money out of the ground. Now that the price of oil has plummeted along with the rosy profit forecasts from Reykjavik to Whitefish, guess what some “hard-nosed realists” argue? You got it! Investing in clean- and green-tech is now unwise because of the credit tsunami sucking all the cash out to sea, an economic recession that promises to be as deep as it will be broad, hyperventilating stock markets, dazed and confused finance ministers, and a crumbling government in Washington that’s trying to bring down thousands of animal and plant species with it.

Who has time for the love of bugs and bunnies when the sky is falling and you’ve got mouths to feed! When the weather’s fine, there’s no apparent need to fix the leak in the roof. And, anyway, you’re too busy enjoying the sunshine. But when it’s raining nobody wants to go out on a slippery roof. In other words, it’s hard to set aside the time to look ahead. But in times of turmoil we all want to know what’s coming around the bend.

The best way to predict the future, as everyone knows, is to make it yourself. Particularly if you’re a designer, since your job is to anticipate future needs and desires and create what fits the bill.

So the question is, for what future are we designing?

There are always reasons to jettison green ideas, some sensible and some self-serving. But let’s not throw the baby out with the bathwater. Sure, we’ve been trained to dismiss anything the United Nations says, particularly when its Climate Change Secretariat urges governments to use the credit crisis as a pretext for greening their economies. But what to make of George Soros? He suggests we should stop investing in environmentally destructive businesses and instead place our bets on the engine of the next economy, green and clean tech. But what does Soros know about making money?

Then there’s Nobuo Tanaka, the executive director of the International Energy Agency who, after meeting with the oil ministers of Russia and China declared the end of the oil economy, but the beginning of what? Deutsche Bank is advising governments to invest in technologies to blunt the impacts of climate change, stimulate economies, and prepare for a future of dwindling oil supplies. The MIT Technology Review, meanwhile, recently reported that concerns over global warming and energy security means that alternative energy remains a good investment. McKinsey has written extensively on what businesses can do to thrive in a radically changing environment, by relying on available technologies. And for those uncertain where to start changing their culture, Deloitte just released a report outlining techniques for growing your business in more sustainable ways.

Oh, yeah, and there's the fact that the next president of the United States has an honest-to-goodness energy policy that demands the innovative ideas, courageous action, and physical muscle of a generation. Faith and hope has triumphed over cynicism and fear, but now it's time to get down to work.

But isn’t that all just a bunch of theory?

A UC Berkeley study released last month shows that California’s energy-efficiency policies have created nearly 1.5 million jobs from 1977 to 2007, while eliminating fewer than 25,000. Turns out that the biggest engines for growth this year at General Electric are those green products and services that fall under its Ecomagination initiative. Wal-Mart, meanwhile, is making a big push toward greater environmental stewardship, most recently in China. Some folks in Detroit who once built gas-guzzling automobiles now build windfarm equipment. And on a more mundane note, consider how better de-duplication software can save time, emissions, and cash.

The fact is that oil market turbulence and global warming are here to stay, and those people, communities, companies, and governments that can anticipate the next wave of change are more likely to ride high out of the current mess.

But why should interaction designers care? I’ll put it this way: how often is the best choice the most obvious one? We work on projects that often don’t get released for years, which is why it’s important to anticipate a world where oil prices are high again, markets for carbon are commonplace, income is less disposable, and people are hungry for products and services more closely aligned with the social, economic, and environmental ecologies on which they depend.

With markets for most everything tightening up, industry is making fewer things, they will transport them fewer miles, and people will burn less carbon to get them. The good news is that these changes will translate into a decrease in worldwide carbon emissions. We are granted an opportunity to slow down and take a breath.

As we reexamine our assumptions, we may ask ourselves about the wisdom of those executives and economists who have counseled against sustainable products and services. Are these the same folks who invested in shady Icelandic banks and screwy mortgage-backed securities? Surely, all the phony money in the world cannot equal the certainty that energy efficiency is going to pay off. Whatever else may be true, the economy will find a new level, the markets will return to life, energy will get expensive again, and only those who take this opportunity to invest now will reap the benefits later on.

The point is this: it’s the job of designers to keep our eyes on the horizon, so that present conditions do not cloud our vision of how to get where we're going.

What do you think? Join the conversation in Comments

Every product, service, or business model is defined in large measure by what designers take for granted. These assumptions can be held so deeply as to be invisible to the designers themselves. And yet their acknowledgment, and negotiation, are key to industrial evolution, profit, and harmonious relationships to various ecosystems.

In the early days, for instance, you could assume that those with access to computers were backed by organizations willing to invest the funds necessary to acquire or build the complex infrastructure required by computational behemoths. But with the advent of microprocessors and other such developments, that all changed. Now the intrusion of computers into every corner of our lives is nearly complete, with 11 percent of the people recently polled saying they’d like their email deliver directly into their brains in the ultimate post-media consumer fad.It used to be you could take for granted that people had the motivation and ability to employ Boolean logic to their advantage. You used to be able depend on your users. There was a time when they were qualified to use software. They had seemingly endless patience with text strings dozens of characters in length, and they didn't mind waiting til morning for the computer to process their command batches. But with the advent of graphical user interfaces, the de-professionalization of computing tasks, and other developments, this no longer holds true.

Now anyone and his cat can make use of computers.

Storage capacity was once scarce and expensive. You designed interactions which, by default, forced users to explicitly save data, to remind them of the precious nature of memory. This is no longer true. (Though the news has escaped the designers of some applications, including that of the one I'm using to compose these words.)

Once computers began arriving in offices and homes, the only folks who went online were researchers, hippies, and hackers. But not anymore. When designing products and services, you can safely assume that almost everyone worth reaching is online. And that nearly everything worth doing—including but not limited to the removal of your gallbladder—is possible, if not preferable, when done over the Internet.

Bandwidth? Please… it’s delivered by the bushel nowadays.

A profitable business model? I can spend all day snarfing my neighbor’s wireless connection to read a novel-in-progress in Chinese, talk to my Latvian developers, listen to music being played right now in a bar in Nigeria, and find a date for Friday night, all without paying a cent to a soul.

Over the years, we have watched one assumption after another fall like fruit from trees, planting the next crop of opportunities. In retrospect, it’s easy to believe limitations existed only to egg on our ingenuity. Nearly anything seems possible now.

But wait a minute. What are we not seeing?

What about the supply chain?

Sunday’s New York Times reports that higher energy costs are altering the balance of global trade by shortening supply chains and requiring designers, planners. and executives to rethink how they put stuff together and sell it. Then there’s server farms, which are not only more expensive to operate these days, but are subject to shortages that can bring down networks. (Interestingly, Microsoft has come to recognize that plain old analog human behavior is the biggest barrier to energy conservation at data centers.)

Think you work in a clean industry? Think again. Interaction designers live in and create worlds of abstractions. But if you looked at the supply chain of our industry you will see a tremendous drawdown of resources, while from the effluent pipe of you will see tremendous fouling of natural and social ecosystems.

Nicholas Carr calculates that a Second Life avatar consumes as much energy as a Brazilian.

It’s been said that while necessity is the mother of invention, poverty is the father. With energy in short supply—or, put another way, when energy use impoverishes your planet—how do you apply your ingenuity? Designers identify relevant tensions, then find ways to resolve them. The tensions with which we play include those between space and the stuff that occupies it.

Between stillness and motion.

Between effectiveness and efficiency.

Between thought and feeling.

Between options and actions.

Between certainty and doubt.

Between power and pleasure.

Between profit and sustainability

As interaction designers, we get to work in the warm and loamy convergence of vision, technical capacity, access to resources, and human desire. At this confluence of forces, we can amplify intelligence and divert bad decisions and feed our co-dependent ecologies. So, then, how do you design stuff that delivers more power to people while using less power to deliver it, use it, and retire it?

How to design a data back-up scheme for a cloud computing service that is reliable and unobtrusive… but which does not require computers to stay awake all night long for a 5-minute process?

How about a calendaring system that reduces the likelihood of meetings, thus saving on travel while increasing productivity?

Can you design an automated drafting system that’s powerful enough to build the tallest skyscraper, and which provides on-the-fly recommendations that boost energy efficiency?

Or come up with social networking solutions that simultaneously encourage collaboration, decrease real estate costs, and increase energy efficiency?

Or, how about thinking small: when you design a website registration form, do you offer that check-box which makes it easy to opt out of paper mailings?

Or smaller still: how about bringing the bad news to executives when your research shows that the potential user population doesn’t want what’s being offered... before it gets built and shipped.

After all, preventing the launch of a lousy product is a manifold gift to mankind.

If the first principle of Ecosystem-Centered Design is to put your own house in order, the second is to check your assumptions.

Don't ass(u)me!

My point is simple: why not ask ourselves, and those around us, whether what we are working on is worthy of the valuable attention, the creative activity, and the deadly carbon burned to make it, sell it, use it, and landfill it?

What do you think? Join the conversation in Comments

The Market Street grid, Courtesy: bricoleurbanism.

This week, San Francisco started choosing sides for another Market Street Mêlée, which we fight once every ten years or so. On one side of the double-yellow line are arrayed various assorted starry-eyed, bipedal dreamers who propose closing down the main artery of our fair city to most carbon-emitting traffic so as to give pedestrians and bicyclists a break, reduce pollution, and increase the beauty and overall mellow vibe of the grid. On the other side stand the self-styled hard-nosed rationalists who see in this as a pedal-powered economic and moral calamity in the making. What can get lost in all the hubbub is the fact that bicyclists (and pedestrians, of course) already outnumber private cars on Market Street, and that parking (and left turns) are famously illegal, anyway. Anecdotally, I’ll add, virtually every Cooperista gets to work by bus, BART, foot, or bike. So such a scheme would be no skin off our collective nose. Nor would this be a coincidence.

Our studio emerged from between the cracks of the suburban sidewalks of Palo Alto at a time when the software industry’s activities revolved around those who made analog and digital machines hum and whir. But by 2003, people, rather than software, emerged as the killer app. So the necessity of having operations in Silicon Valley began to diminish. Since nearly all Cooperistas lived in Oakland or San Francisco, anyway, doing our work in a dense urban environment was an easy choice. We got out of the faceless world of cars and instead got face-to-face with the people our work should serve. Turns out that several potential clients opened offices here as well… and it didn’t hurt that shortly after our move, BART finally opened a line to SFO, making it cheap, easy, and relatively eco-friendly for our clients and students to fly in for a visit.

By getting out of our cars, Cooper made a sweet little triple bottom line success.

This move is a small demonstration of the first principle of Ecosystem-Centered Design: by creating sustainable practices, the sustainability quotient of our design work will likely increase.

Oh, but Cooper is a long, long way from practicing truly sustainable business practices that meet the triple-bottom line. (Pardon the tangent, but in Sunday’s New York Times , Alan Blinder promotes a nice macro/micro triple-bottom line program called Cash for Clunkers.) Sure, we’ve achieved a degree of economic sustainability (knock wood!). And our social sustainability quotient’s pretty decent too. (Cooperistas tend to stay employed here for years, while a vibrant community outside the studio doors has formed around the application of our methods.)

And yet, our operations waste too much energy and materials, and we don’t source enough materials from green businesses. We are only now fleshing out Goal-Directed methods for Ecosystem Centered Design, and our new industrial design practice, while possessing every intention to promote sustainable practices, has yet to be truly tested in this respect.

One area where we fall short is an over-dependence on air travel. We have developed some fantastic remote collaboration techniques that reduce the need for face to face meetings with collaborators. And we are increasing our attempts at data and videoconferencing, inspired (in part) by other consultants embracing such technologies.

And yet, we spend far too much time on the road than we ought. The key conundrum we face is this: How does one perform ethnographic research into human contexts and needs, without visiting said context of needy humans? We’re open to ideas here, people!

What we try to bear in mind, through all of this, is that interaction designers occupy a privileged position, at the confluence of powerful forces of business, technology, and human desire. We understand we can channel these forces in positive directions, at the same time we’re mindful that by our example we can inspire others to do likewise.

To really pull out the stops, I’ll suggest that we aspire to meet Gandhi’s challenge: Be the change you wish to see in the world.

The point is this: We make choices every day.

We can get in the car — or jump on a bike.

We can improve our skills, broaden our mandate, and sharpen our vision — or we can grasp tight to what makes us feel comfortable.

We can show our collaborators how their operations are influenced by — and, in turn impact — the social, industrial, and environmental ecologies in which we all live and work. Or, we can sit around waiting for permission from somewhere on high.

We can reach beyond our monitors in an attempt to grasp the objectives of sustainable design — or we can simply automate the misery of the current system.

We can join common cause with others to achieve big things — or we can fiddle with our widgets while Rome burns.

What do you think? Join the conversation in Comments

Beautiful Monsters is a series by David Fore, head of Cooper's consulting practice. It is intended encourage conversation about how interaction designers can grow more sustainable practices, with the goals of improving our fortunes, our relationships, and the health of our planet. Start at the beginning, or read the latest installment below.

Critics may charge that I’m loving on WunderMap too much. But these guys have vision. They provide fantastic resources for visualizing many of the changes afoot, which is a necessary precursor to visualizing solutions. But what they haven’t done yet is provide us the coordinates of our honeybees, one in three of which have disappeared from these parts. Without honeybees we don’t have agriculture as we know it — and, ipso facto, culture.

"How would our federal government respond if 1 out of every 3 cows was dying?" a scientist recently asked a bovine Congress.While WunderMap is at it, I’d like also them to go get some fish: turns out California has misplaced its Chinook salmon. Theories for their disappearance abound, including a lack of attention to the interlocking social, industrial, and environmental ecologies of the delta, but in the meantime an entire industry has collapsed, along with its inter-dependent human communities.

Ours is not the first generation to expend resources in a profligate manner, and to heedlessly dispose of our waste in ways that damage our environment (check out this extremely shrewd whitepaper (PDF) on the subject, written by Robert Costanza, et al.) But our generation could be the last to do so.

Before the amplification of carbon-fueled technologies, it used to be that our wasteful ways were restricted to our immediate neighborhoods. Then, about 200 years ago, we began conducting this extremely cool experiment to see what happens when we change the chemistry of this test tube called Planet Earth. Problem was, we fired up our industrial-strength Bunsen burners without any kind of hypothesis as to the likely cultural and ecological consequences of industrializing society, loading our oxygen-rich atmosphere with carbon, and making our oceans into acid baths. Even if, at the time, some dreamers could have modeled the current rate of global climate change and the collapse of the planet’s natural systems, it’s unlikely they could have influenced the implacable course of industrialization. For one thing, early planners lacked the data, analytical tools, system models, organizations, and specialists (such as interaction designers!) that we have today. Also, they didn’t know what we know: that we are confronting a situation of massive complexity begetting massive change.

This experiment has taken a couple of hundred of years of greed-driven worldwide effort, the deleterious effects of which we must attempt to undo in a few short years. Many factors are required to effect such change, but none will be truly effective without massive collaboration channeled toward the achievement of personal goals, organizational objectives, and ecological balance. And since system thinking is the forte of interaction designers—and because our work so often determines the shape and behavior of what gets put into production, into use, and into landfills— we have the opportunity (nay! the obligation!) to participate fully.

Who are some of our collaborators?

Potential collaborators include anyone who takes a walk in the woods, or along the seashore, or looks outside their windows. At least that’s the supposition of the Encyclopedia of Life, which is creating a constantly evolving compendium of species that lives on the Internet, with contributions from scientists and amateurs alike. (Now there’s an interaction design challenge for you!)

Who else? Technologists, writers, philosophers, ethicists, and building engineers, have been working long and hard on these issues. Even the Pope is turning green. And of course there are whole communities committed to various kinds of sustainability, one of the more interesting of which is described in a recent issue of the New Yorker: A Danish town that has achieved a kind of carbon-neutrality.

Meanwhile, power producers, supply chain managers, manufacturers, and some retailers are trying to crack this nut. People who run data centers know that they have to do something about the energy suck of their servers; perhaps feeling the hot breath of WunderMap on their necks, some folks in Amsterdam are putting together 3-D weather maps of data centers to get a handle on consumption patterns. Fireman's Fund is launching a green insurance option for homeowners that will allow people with conventional homes to rebuild to the latest environmental standards after a loss.

Even VCs are getting into the act. While the current economic situation is forcing conventional startups to peddle pocket-protectors on the streets of Palo Alto, the San Francisco Chronicle recently reported that businesses which can claim to enable new sources of energy, clean water, and sustainable agriculture will continue to be hot targets for venture capitalists.

The point is this: If insurance companies can tell something is amiss, and are paying you to fix it, you can bet the odds are in. We must ameliorate, reverse, and prepare for these conditions of risk. Interaction designers determine what people need, then put computing power to work on their behalf. And computers make everything go faster. Which puts us in the catbird seat to help industries, individuals, and social systems to address the implications of their actions on the various ecologies on which we all depend. Read more about Beautiful Monsters and ecosystem-centered design.

What do you think? Join the conversation in Comments

It used to be that everybody talked about the weather, but nobody did anything about it. Not anymore. Through the magic of technology, I am empowered to make better decisions about where not to breathe. That’s because the good people at WunderMap have devised a smoke map. For a few days there, the smoke from local wildfires were absorbed by our (formerly) infinitely capacious atmosphere. So I didn’t think I’d need the smoke map. But then temperatures hit new epochal records, humidity took a dive, and the wind began fanning the flames again.

Should our misfortunes expand to include plagues of frogs, boils, and gnats, I know WunderMap will have my back.

In other news last week, the U.S. continued to emit vivid plumes of interactive graphics displaying our industrial might, which nobody can deny … it’s just that my emissions are necessary, while yours are not. World leaders at the G8 Summit in Japan, meanwhile, decided to postpone serious action on climate change for another few decades. Tomorrow’s always the best day to begin a diet.

Why on earth should such things matter to interaction designers? Put another way, why does earth matter to interaction designers? Turns out that if we fail to practice design in an ecologically aware manner, we will inadvertently diminish our business prospects, as well as threaten the social and environmental ecologies on which we depend. Over the past few decades, why did the designers at General Motors (and the unions and the politicians) enable the company to ignore these inter-locking ecologies? Last week the CEO had to publicize plans for ditching gas-guzzling brands and laying off tens of thousands of workers. (Dinosaur industries dependent upon dinosaur fuels? “You are what you eat,” says Doug LeMoine.)

Where is design in all this?

Many paths towards an Ecosystem Centered Design are possible, and several of our sister disciplines have already made progress down this road, including architecture, branding professionals, interior design, landscape architecture, urban planning, industrial design, IT management, and packaging design, to name just a few.

The recently launched Designers Accord represents one of the brightest signs of life to date. Still in its infancy, DA boasts 100,000 members of the creative community signing up to work together to make positive environmental and social impacts. Cooper is a member, and we’re in the process of adopting some business practices valued by DA members.

But while DA has tremendous potential, interaction design is only a small part of the discussion so far. Also, given that DA is an all-volunteer affair with a broad focus, its success depends upon the active participation of many people committed to developing sustainable design practices in each discipline.

By comparison, I’m afraid that interaction design is late out of the blocks. With some exceptions. Prof. Eli Blevis at the Indiana University School of Informatics has been thinking about sustainability in interaction design. His work won a best paper award at ACM-CHI 2007, and provides some principles for sustainable interaction design. Designers at Adaptive Path have commented on this subject, and Alexa Andrzejewski’s words struck me as particularly clear-eyed. While her focus has been user experience design, there are several ideas, and related comments, relevant to interaction design. Similarly, the workshop on Ubiquitous Sustainability held last year in Austria led to the publication of several papers, some of which bear on sustainable interaction design ideas. Shilpa Shulka’s blog also shows insight, and an unflinching view of the challenges we face.

(I'll be speaking about Beautiful Monsters at the Pecha Kucha-SF gathering this coming Wednesday, July 23. Originated in Tokyo, Pecha Kucha provides a venue for designers of every ilk to share ideas in a lay-back environment.)

But while these voices in the interaction design community are strong and clear, they are few. I believe this is owing to the relative novelty of the discipline of interaction design itself. (We’re still finding our feet, after all… and, anyway, we just design stuff that people point and click at, right?)

The inertia may also relate to the intellectual habits and interests of software makers with whom we collaborate. (Is there something about the focus required to write software code that makes one disinclined toward looking out the window at the lack of bees buzzing about out there?) Then there’s the nature of our principal medium, software, and its deceptively immaterial nature. (What do bytes have to do with business models, bugs, bunnies, and breathable air?)

The point is this: despite our delayed start, we’re in luck. Owing to the particular talents, methods, processes, and general dispositions of interaction designers, we can make fast progress.

Beautiful Monsters is an ongoing series intended to serve as an ongoing conversation about how interaction designers can move the industry toward an Ecosystem Centered Design to improve our fortunes, our relationships, and the health of our planet. Get caught up on the first entry, and take part in the conversation below.

What do you think? Join the conversation in Comments

From our position at the confluence of human desire, technology, and business, interaction designers can make a tremendously positive—or negative—impact on the biggest issues facing us today: the sustainability of commerce, human societies, and natural systems. Despite these opportunities, software makers are discouraged from thinking outside the aspect ratio of the computer ’s monitor.

This is the first in a series of articles intended to serve as an ongoing conversation about how interaction designers can move the industry toward an Ecosystem Centered Design to improve our fortunes, our relationships, and the health of our planet.

With such a late start, we best get moving

I write this as smoke obscures the sun over most of Northern California, the result of an unprecedented number of early-season wildfires that have charred hundreds of miles of land. We are visited by flames because we’re in the midst of the worst drought in decades, and because we experienced thousands of dry lightning strikes in a period of days, something as common in these parts as Leprechauns and snow leopards.

These 1,700 fires have created a weeks-long pall of smoke that has forced everyone indoors… not just the very young and the very old, but everyone.

To battle the flames, firefighters are draining our reservoirs’ stores of precious water, which couldn’t come at a worse time, considering we are rationing water in several areas of the state. Makes you wonder what will happen next time you open the tap. Meanwhile, there aren’t enough folks and equipment to fight all the fires, so many are being allowed to burn unchecked.

Weird weather or harbinger of climatological chaos? That’s the question that NASA climate scientist James Hansen was asked in last week’s congressional testimony. His conclusion was that the time for debate over such questions has long since passed: we are in the midst of a “planetary emergency” that requires everyone’s attention, ingenuity, and good will. Now. Not whenever we get around to it after we have finished what we're doing. Now.

Last week Ford Motor Company announced the death of the SUV. Turns out that there’s not an endless supply of cheap gas and piña coladas. The bill is overdue and we need to pay up.

So it's a propitious time to launch a series about how interaction design can, and must, take into account the social, economic, and environmental ecosystems on which we all depend.

In addition to whatever native wit and well-honed craft any interaction designer may possess, each of us also depends upon some form of User Centered Design (UCD) to create products, services, and systems that are hospitable and appealing. Placing human concerns at the center of the design of software-enabled systems has been quite a trick, given that doing so has meant moving technology to a role that is subservient to human needs. But this Copernican shift has led not only to better products, but better process also. That’s because doing interaction design in the proper way also provides everyone greater visibility into and appropriate influence over the development, use, and impact of the systems that are designed.

The problem comes when UCD is taken too literally, for it can also promote a myopia that blurs what’s outside the immediate reach of individuals, preventing us from clearly seeing the inter-woven social, industrial, and environmental ecologies within which people live and companies exist. This must change. Whether interaction designers hear it or not, we are being called upon to address the broader ecological contexts of the companies that build what we design, and those who use the product of our labors. It is, therefore, urgent for our design values, methods, and collaboration habits to evolve. Now.

What is called for is an Ecosystem-Centered Design, a shared set of ideas and methods to guide our way toward more sustainable creative endeavors that address vital social, organizational, and environmental influences upon—and consequences of—the creation, use, and retirement of what we design.

What do you think? Join the conversation in Comments

Organizations of every size are attempting to get a handle on their content generation, management, and publishing systems. This trend toward business process re-engineering (BPR) of content management is largely the result of an outsized proliferation of Web pages, intranet sites, and electronic communications strategies adopted by organizations, their partners, and customers.

Sadly, few organizations have seen much good come of content-management BPR initiatives so far. Of the many reasons for these failures, one stands out: these BPR initiatives—and the systems they spawn—are focused on realizing organizational objectives without sufficient regard for the context, habits, and goals of the people who will actually use the system. These new technology solutions are intended to create efficiencies, but they actually prevent people from achieving their objectives, which generally have to do with reducing hassle and ensuring their own personal effectiveness.

A typical content management system will include a meta-tagging normalization function to make sure attributes and information associated with the content remain consistent and thus easy to manage. But these functions are usually so difficult to use and foreign—particularly in collaborative environments—that few people have patience for them. Since people are more concerned with getting content in the hands of their audience than they are with meta-tagging normalization, they often skip this key step.

And so an ugly cycle arises in which organizational objectives thwart human initiative, and human behavior thwarts organizational objectives. Managers are then placed in the unenviable position of threatening people with their jobs if they fail to adopt the outlandish practices that are merely artifacts of a senseless system.

Look before you leap

The ultimate aim of the new generation of content management systems is generally the promotion of customer sales and satisfaction, along with an overall decrease in content management expenses. But what's rotten at the heart of the planning and development of these systems is pretty much what cripples stand-alone software application development: before understanding the problem, organizations select a solution. Rather than assessing the organizational objectives and human goals, it is common for business process re-engineers to go out and buy a system of technologies that sparkles with the promise of precision and control, purporting to solve all problems, so long as they are generic.

Part of the problem with this approach is that there is no such thing as a generic problem. Consequently, people spend a lot of cycles adapting the system to their needs, or (more commonly) they are forced to adapt their behavior to the unyielding system. This is a shame, for a system that disregards people will itself be disregarded by people. If the new system requires as much duct tape and bailing wire as the one that preceded it, the efficiencies hoped for are squandered and everybody loses.

Don't automate the misery!

So how to restore sanity? Business process engineers face a daunting set of challenges as they design, engineer, roll out, and monitor the effectiveness of new content management systems. To succeed, they must create coherent sets of roles, transactions, workflows, business practices, and technologies. They need to make allowances for reasonable differences in business practices throughout the enterprise. They have to garner support from line managers. They need migration plans that guide the organization in its adoption of the new system while minimizing strife. Finally, they must have visibility into and control over the system itself so it can change in accord with changing imperatives.

Everybody knows their existing systems are painful and perversely complex, so a palpable fear hovers among many that any new system will simply render into silicon the poor practices people have been trying to shed all along. In essence, nobody wants to automate the misery. But they can't help themselves. In fact, they pile it on. That is why it is particularly important for new content-management systems to understand and appreciate the often bewilderingly heterogeneous practices people use to manage content. Without an in-depth investigation and analysis, it is difficult to say whether any single practice was formulated by legitimate business contexts and goals, inadequate organizational or technical resources, or the eccentricities of highly-caffeinated individuals with too much work and too little time. Consequently, it is difficult to say whether it is worthwhile or counter-productive to incorporate any given process into the new system.

To make that distinction, you need to leverage the experience, judgment, and initiative of the people the system is ultimately intended to serve. Before choosing a solution, it is critical to first ascertain the habits, expectations, and goals of people—as well as the objectives of the organization—so that, ultimately, the system designed reconciles these when they come into conflict. One method is to develop individual and organizational personas—fictional representative users that are essentially inexpensive stand-ins for the real thing—and put them through scenarios emblematic of how they would use the system for, let's say, assigning meta-tags to content. These scenarios can then generate well-defined catalogs of needs that, in turn, can serve as the foundation for the new content-management system's most-favored practices and functional elements. The key at this point is to envision an efficient system of procedures and technologies that gives humans the guidance they need to serve the organization, while providing them the room they need to exercise their best judgment.

When building a content-management system, it's essential that it not only look good on paper, but that it avoids institutionalizing any dysfunctional dynamics in the organization as well. The best way to do that is to model the system ahead of time with organizational and individual personas, whose goals will determine the shape of the system. Only in this way can we stop thwarting one another.

What do you think? Join the conversation in Comments

A year ago, most software industry analysts were predicting that Content Management (CM) was going to be the hot sector this year. Unfortunately, sales for most CM software providers are not meeting expectations, and even CM insiders are suggesting that the cause could be a growing disappointment with CM implementation results. Anecdotal evidence from within the CM industry indicates that CM implementations fail to meet corporate expectations about half of the time.

Part of the reason for missed expectations could be poor usability. Forrester Research recently released a research paper on the subject: "Packaged Apps Fail The Usability Test." In it, they don't name the vendors, but they rate the usability of two popular CM systems. Both rated very poorly. Forrester's conclusion is that much better design is needed to win user adoption and higher rates of corporate satisfaction.

That said, it is not Cooper's first inclination to place blame with the CM software providers. Instead, we draw parallels to the failings of ERP systems, which largely resulted from corporations simply not being prepared on a holistic level to effectively drive the organizational change necessary to receive maximum benefit from the systems. As was the case with ERP systems, corporations implementing CM systems are looking for quick fixes and cure-alls for their overwhelming need to get information under control quickly. Unfortunately, that fix is not as simple as implementing a new software application. There are many non-system issues—from corporate strategy to individual employee task assignments—that must be resolved before even considering a technology solution. When such issues are not properly addressed, it becomes a matter of trying to overlay a system on top of broken processes. Anything resting on a weak foundation is not likely to stand for long.

To address these broader considerations, we have captured some thoughts that could be helpful to any corporation considering a CM implementation. Please read on.

Introducing Goal-directed Content Management

by David Fore, Director of Practice
with Pat Fleck, Caroline Toland, and Chris Weeldreyer

Many organizations today are overhauling their Content Management (CM) systems by introducing more software into the equation. Unfortunately, that software tends to be designed, developed, purchased, and installed with little respect for the needs of the people using it, much less the objectives of the organizations footing the bill. And while few managers would tolerate staff who behave in rude and random ways with one another (much less with customers), many somehow find it perfectly acceptable when their software behaves poorly. As such, it is imperative to take a clear-eyed approach to dodging the pratfalls of CM system design.

CM systems are so important because their job is to provide people both inside and outside an organization with the information they need to do business with you. The character of your CM system will determine your organization's identity, its ability to develop partnerships, its appeal to customers, and even its relations with employees. Not only can CM systems radically alter the way you do business—for good and ill—they can also be awesomely expensive, particularly when their installation triggers changes in time-honored roles, work practices, and relationships. After all, CM systems—like sibling systems such as enterprise resource planning (ERP), customer relationship management (CRM), and supply chain management (SCM)—are actually organizational re-design projects that masquerade as software-based systems.

The selection and roll-out of CM systems are too often haphazard affairs doomed to failure or, at best, mediocrity. This is largely because most organizations lack a sufficiently flexible and rigorous methodology for choosing their CM systems. Rather than setting off on a voyage of discovery to parts unknown when initiating a CM system effort, it can be more effective to adopt a decision-making framework focused on the goals of the people and organizations who will be affected by the new system. The eight phases of this Goal-Directed Content Management Method are summarized below.

Phase 1. Identify information customers

Before doing anything else, answer this question: With whom do we want to share information, both inside and outside our organization?

Don't restrict your answer to those who receive information from your organization by electronic means. Take into consideration those with whom you communicate via traditional media as well. This will illustrate connections between, say, the business card a sales rep provides a potential customer, and the Web link on the card the customer will follow for more information. For the complete picture, it is also essential to consider the needs of internal information customers, such as marketing/communication specialists who use white papers generated by R&D. Be sure to center your investigation around the future needs of your organization—today's information customers may not be the same as those you need to serve tomorrow. Also, remember that communication goes both ways. Consider who should be empowered to reach your organization, whether they are delivering content to you, or using information you supply.

Phase 2. Identify the goals of information customers

Humans being human, they will take action to subvert your new system if this helps them achieve their goals. So rather than build a system that simply automates the misery of your current system, determine the goals of your information customers up front. In other words: Why are these people interacting with our organization in the first place?

When undertaking a fundamental transition, tasks can be a moving target. For instance, it may no longer be worthwhile to mail out brochures, but distilling documents into PDF format for electronic distribution may be imperative. In both cases, the goal is the same: satisfy customers with useful information. Understanding the goals of your information customers is the most efficient way to ensure your system will be valuable for years to come.

Phase 3. Identify the content your organization generates and uses

Once you understand your information customers and their goals, analyze every class of information you are willing to share with them. This should include material that they (and you) would like to have accessible over the Internet; also consider email, fax, regular mail, and so on. Ask yourself these questions:

• What should information customers know about our organization?
  
• What do we need to know about them to satisfy our goals?
  

For each class of customer, determine what information or services you need to provide or acquire from them to satisfy their goals and yours. Consider the needs of internal customers as well, such as that mar/com specialist who uses white papers as marketing collateral for external information customers.

The information you share internally and externally defines the boundaries of your relationships with your information customers; in many cases, this information is your organization. From that observation, of course, follows another: not all goals are worth satisfying. Consequently, this phase requires a sanity check to ensure alignment with corporate strategy. In other words: What business are we in?

Phase 4. Define fundamental content assets used by information customers

For the purposes of planning a CM system, a useful definition of content is all the information that customers use to further their goals. This content can include paper documents and electronic files of all media types including text, image, video, and sound. Many companies often supply databases to their information customers who then fashion them into their own tools, so you may consider databases as content as well. Some CM system planners even include ephemera such as voicemail entries and information delivered through instant messaging services. In this sense, applications delivered to information customers, such as a mortgage calculator or an online order form, need to be considered as well.

Once you know the classes of content used by information customers, break that data down into its fundamental characteristics such as time sensitivity, sources, authors, purposes, size, etc. Do customers take this content whole, or do they use only parts of it? Do they combine it with other information, including their own? In other words: What are the smallest useful units of information, and what are their characteristics?

Phase 5. Analyze how fundamental content assets are currently produced

Next, take a snapshot of the ways your organization generates and uses content: How do you create and distribute content?

Is a single asset generated by multiple people, then combined by another person in another department? What procedures do they follow? What technology helps them along the way? How long does it take to produce and deliver content? How much does it cost to produce it?

In this phase, it is also important to take into consideration the non-fundamental content assets (those that failed to make the cut in the previous phase) in order to capture baseline data that will help you understand the costs of managing content in your current (and presumably inefficient) system.

At this point, your technical staff should undertake a study of the capabilities of available software and hardware solutions so they have a thorough understanding of the implications of a potential installation. Be careful not to let this process get out of control, though. While a benchmarking process may be a useful way to determine the acceptability of certain technology solutions, at this point it is still too early to begin signing agreements with vendors.

Phase 6. Model the optimal system

By now you should know the information assets you need to produce and why. You should also have a grasp of the basic characteristics of this content and how it is currently produced. Now you can look into the future and determine the characteristics of an optimal system.

The purpose of this phase is to shape a system of roles, relationships, information assets, procedures, and technologies that can produce and deliver content as efficiently and effectively as possible for the purposes you have identified. Ultimately, this model must provide coherent answers to the following questions:

• What roles will be required to meet the needs of information customers?
• How will these roles balance one another in the overall organization?
• What will motivate people to cooperate?
• Who will be responsible for monitoring and resolving conflicts?
• What customs, principles, and processes will guide decisions?
• What recruiting, training, or reporting structures will be necessary?
• Will a new kind of organization be necessary?
• How shall the system balance the goals of employees with the objectives of the organization?
• What metrics will be applied to the performance of the new system?
• What can be done by software, and what is best left to other means?

Since CM systems require an unusual degree of cooperation among a range of parties inside and outside the organization, orchestrating understanding and buy-in is critical to the success of the system.

That said, there exists a fundamental tension between the corporation's objectives and the goals of information customers. In many situations, particularly where high achievement is prized, information customers will do whatever it takes to be effective in meeting their goals. For these people, efficiency is secondary and its benefits seem rather abstract in their routine world. Organizations, on the other hand, are primarily concerned with efficiency—driving down costs or increasing profits—and empowering their information customers is merely a nice-to-have.

The key to a successful CM system is to bring this efficiency/effectiveness conflict to the surface and provide the means for its resolution. Wishing away problems or simply punishing reprobates will inevitably backfire on you. Instead, your best bet is to model a dynamic, evolving system that is transparent and rewarding to those who join together to meet its objectives. Such a system, however, will require definition of key negotiation points that balance the needs of all system participants, whether they be IT staff, information customers, managers, or executives. Moreover, in each negotiation, the authority and responsibility for ensuring successful resolution of conflicts must be made clear: the people who fill these roles must be skilled diplomats with the backing of the organization and trust of the staff. When change is afoot, people become fearful they will lose the control they currently have, and that the leaders of the organization will dictate new directions willy-nilly.

In addition to modeling roles, workflows, and negotiation points, you must also provide toolkits of best-known methods that participants in the system may use. A toolkit may include descriptions of workflows and best practices, arbitration guidelines, exception identification and escalation procedures, guidance for using metrics, and system terminology and principles.

One caveat: beware the allure of technology. If you discover that the most effective way for people to achieve a specific goal is to tape a note to a binder, then don't spend thousands of dollars on a software solution that would do the same thing but require significantly greater funds and training. Always seek out the most appropriate solution.

Phase 7. Implement the model

Your next step is to choose and adapt your technological solutions in the field. In other words:

• What techniques and technologies will satisfy the requirements of the model?
• How will these techniques and technologies be adapted to our specific needs?
• How do we introduce a new CM system while keeping the business running?

Every organization has its own speed limit and tolerance for change, which must be respected if you want to retain valuable staff and customers. Additionally, there are typically countless dependencies between functions, technologies, and objectives. That is why it is important to leverage previously useful processes as much as possible to ease migration from the old system to the new. Finally, be aware that, as novel technologies are introduced into the mix, unexpected processes may emerge.

Phase 8. Incorporate feedback

With your CM system in place, you must measure its performance both against the baseline performance you documented in Phase 5, and the criteria you defined in Phase 6. Doing so will provide you with the means to answer this critical question: How do we get ROI from this system?

Measuring performance against your success criteria also provides information that could lead to further changes to your system. Of course, not all feedback will be in quantitative terms. Feedback of a profound kind is sometimes difficult to anticipate with a pre-fab questionnaire. That is why it is the obligation of those overseeing the performance of this system to periodically question whether their data are valid, and to employ qualitative research methods for understanding what people really think.

Once your organization has decided to make changes based upon the feedback, remember to iterate Phases 1 through 7 of this process to ensure a consistent high-quality outcome. Do not be surprised if, over time, changes in your customer base, product area, and corporate strategy will mean that it is time to plan anew how your corporation manages its content, and why.

What do you think? Join the conversation in Comments

What’s a feature?

Features are often the currency of software development and marketing, yet few people can agree on what exactly defines a feature. The term can be used to describe a particular piece of functionality, an entire set of functionality, a capability, or sometimes even a possibility. The experts are no help. Typical is webopedia.com, which goes out on a limb by stating that a feature is, “a notable property of a device or software application.”

In other words, a feature is a feature of something.

What is telling, though, is that the vast majority of definitions refer to featuritis or feature creep, the seemingly endless proliferation of features that glom onto what was once, perhaps, a product with a clear vision. Everyone knows that features pop up during the product cycle like mushrooms after a rain.

Feature Creep

So it goes with the management of a software product’s development and marketing. A project is initiated with a particular set of features in mind. But as things progress, more features creep in. Fearful of losing control, executives use the tools with which they’re familiar—deadlines and budgets—to lay down the law: “The product will be shipped in October and will sell for 100 shekels per unit, and that's that.” Anxious managers will then turn to feature-control processes, such as a Requirements Stability Index, or RSI, to manage the situation.

Problem is, this sort of approach fails, expensively and miserably. (See Wayne Greenwood’s article, “Three Traps”). According to an oft-cited Standish report, 73% of projects were either canceled or failed to meet expectations due to insufficient requirements definition and analysis. In other words, feature creep. What happened, frequently, was that projects grew beyond the point where they were either financially or technologically feasible, because of what are deemed “uncontrolled client requests.”

This is expensive and aggravating for a development organization, and the hapless user gets stuck holding the bag. The product is delivered late, it’s beyond her price point, and it is accompanied by an unwieldy manual to get through all the features she’ll never use. When she asks the sales guy where Feature X is hiding, he fumbles around until he finds something that appears to do what she says she wants it to do, but it is unrecognizable to her.

When elephants fight, the grass suffers

It was not supposed to turn out this way. Discussions of a software product in terms of its features were intended to serve as a bridge between constituents who otherwise had few terms in common: users and software developers. Users want a product to satisfy their goals (why else use a productivity application?), while software developers need to know what to build (otherwise they will just make it up themselves). Meanwhile, marketers and sales folks want to discuss the characteristics of a forthcoming product. So everybody has been instructed to talk in terms of “features.” Customer needs are translated into a marketing requirements document, which serves as a vague template for software construction. But what started out as a bridge—features—has broken apart. Users stand at one anchorage and product developers stand at the other, both scratching their heads at the expanse of shark-infested waters still separating them.

Case in point, from a recent experience at Walgreen’s in Oakland, California. At the cashier’s station was a digital wall clock on sale for $29.95. On the packaging, in small type, it noted that the clock also displayed the temperature. Meanwhile, in 45-point type, it boasted “1013 MHz transmission.” I am not certain how many people in line knew that “MHz” stands for Megahertz, but I can almost guarantee nobody cared. On the other hand, I expect shoppers would be interested in how reliable the temperature reading was, whether it displayed both Celsius and Fahrenheit, and whether it was easy to switch between the two.

Features behaving badly

Featuritis is not the only problem with feature thinking. After all, there are some features everybody can agree on, yet those features sometimes fall flat. How come?

Take Microsoft’s Office Clipboard feature. (Please, take it!) The company heard its customers say they wanted to capture multiple items and paste them across different applications. In product management-ese, this would be described as “a more robust Clipboard,” and it sounds like a useful feature. Office 2000 featured a Clipboard with the capacity for up to a dozen items that could work across applications. But while it may “work,” it behaves horribly. As far as I know, there are no documented cases of users in the wild effectively taking advantage of more than one item in the Office Clipboard with anything approaching ease.

Why?

The floating Clipboard palette appears according to some esoteric set of rules, and sometimes when you least expect (and want) it. When it does show up, meanwhile, it is parsimonious with information about the contents of the clips it harbors, so if you make six clips from Word documents, all you see are six Word icons (at least the branding people got what they wanted out the development process). The user, meanwhile, is left in the dark, wondering where a particular clip is hiding.

So how did this happen? After all, Microsoft probably employed the tried-and-true language of features: “robust, multiple items,” “cross-application,” and other seemingly precise terms. One might be tempted to say that developers failed to read the mind of the user, but given that is not part of their job description, that would be unfair.

There is a better way

Start by imagining the Clipboard not as a “feature” but as a response to a constellation of needs tied to the context and goals of users. Such a process would begin with a few questions:

• Who is using it?
  
• Why are they using it?
  
• How might its appearance interfere with other key user workflows?

In order to answer these questions, managers need to interpret client requests and translate them into objective needs that are illustrated by true-to-life scenarios. These needs can then be expressed in terms of what the software product will do for a user, which amounts to your feature description.

Understanding user goals helps focus development and sales

To date, the acquisition and interpretation of user research for the purposes of product development tends to be so undisciplined and the collation of information so unstructured that the requirements coming out of this process are all but impossible to interpret with any degree of certainty. Users are afraid they are being perceived as too thick because they don’t know what “128-bit encryption” is, while developers are frustrated by wishlists filled with contradictory descriptions of large yet lightweight features that are black yet white, and which smell of apples yet of oranges as well.

Similarly, marketing and sales people are ill-equipped to speak about the product in terms other than its features. For instance, what if Microsoft’s next version of the clipboard, Clipboard Nouveau, actually had a winning conceptual and interaction design that anticipated and delivered on people’s needs for capturing, storing, viewing, and re-using clips of data? Certainly, using the language of features is going to fall flat, because of the degree to which the market’s trust in that kind of language has been degraded. To be effective in selling Clipboard Nouveau, Microsoft is going to have to take a different approach. They must begin by talking to customers and users in order to understand what they’re trying to accomplish when handling data clips and to understand the contexts in which they’re carrying out those tasks. Once that information has been collected, then Microsoft can demonstrate how Clipboard Nouveau delivers.

In other words, salespeople need to show in addition to telling. Features tell; behaviors show. Features get you in the door; behaviors close the deal.

Application behaviors serve human goals and help companies sell products

There’s no getting around it. While part of the discussion can take place using the language of features (for instance, the IT guy is going to want to know whether the product has “128-bit encryption”), the best opportunities and longest-lasting relationships are going to come when the language of goals and behaviors is introduced, because then you’re in the business of solving personal goals and organizational objectives, rather than feature checklists.

In the end, demonstrating interaction is the best way to express the value of an interactive product. A feature checklist on the spec sheet is not going to convey to a user what your product will do for him. Customer touchpoints need to be discussions about what users need; the product becomes the answer to those needs. Seen in this way, the problem of product definition and product marketing are one and the same. Not only must goals and behaviors be the foundation for how products are built but also for how they are marketed and sold.

What do you think? Join the conversation in Comments

An email from on high hits your inbox: the company is kicking off an initiative to "radically improve" the effectiveness and efficiency of its nationwide sales force.

Nothing new here, you think. This sort of thing sweeps over the land every few years, like locusts.

But as you drag the message into your Deleted folder, something new catches the eye. Your design team is being asked to carry out the first step of the initiative: conducting a research project to "gather requirements" for how to make the organization more effective.

Undo! Undo!

Aside from the fact that requirements are defined and not "gathered" (one pictures wine bottles hanging from grapevines), it's surprisingly level-headed to turn to interaction designers to examine organizational needs and propose solutions. Most of the time, it's business analysts and technology specialists who are tapped for these assignments. Analysts collect information about what makes the business tick; technologists, meanwhile, build and/or choose tools that work within a given infrastructure. But while the work of analysts and technologists is necessary, it is not sufficient. That's because they are rarely trained (much less asked) to describe usage contexts, identify goals, or design tools that satisfy people while also meeting the objectives of organizations. The result? Too often it's a new flavor of the same old thing, just more expensive this time around.

Now that your team has been tasked with an organizational design initiative it's up to you to pull it off without a hitch.

Time to start drafting a plan.

Get the right people on the job

The job of interaction designers is to provide pleasure and power to people through the design of products, services, tools, and processes that satisfy their goals. With the discipline of interaction design still in its infancy, some people believe the medium in which we work is pixels. But this is manifestly untrue. On the way to coming up with a design of an artifact such as a sales tool or an infusion pump, we must examine, and often change, the nature of roles, processes, and workflows. True, many of our recommendations are ultimately manifested in software displays and controls with which people interact. But by simply locating a widget on this screen rather than that one, we are profoundly, if not subtly, altering people's perceptions of their work...and often the outcomes as well.

Activities such as describing roles, values, priorities, business processes, workflow models, domain object models, toolsets, business rules, and the like are the bread-and-butter of interaction designers. Sure, you need to collaborate with others to get this work done—particularly the pick and shovel work, as well as change management—but interaction designers are uniquely skilled at synthesizing complex data, resolving contending points of view, and communicating processes.

Measure the right things to define success

Often designers are asked to begin their work with activities such as task analysis and eye-ball tracking studies. However interesting the data yielded by such research, it is time-consuming and often misleading. Partly this is a matter of confusing tasks with goals, while ignoring context. Assigning much meaning to quantitative behavioral studies can be a little like assuming that the guy with the drill in his hand wants to do harm to the woman lying there in the chair. Sure, he might be a madman. But more likely he's a dentist and she's his patient.

Focusing on such measurements is most dangerous when your organizational change team lacks people with design skills. You carry out a task analysis that records how people use CD players, but it will only tell about how people use CD players. It will give no insight into what people like about music. The result of such an effort? Perhaps the design of a better CD player…but you're never going to come up with iPod. You just can't get there from here.

So then why do so many people put stock in these methods? I daresay it's because eyeball movement can be tracked and measured. Which is to say, if it can be counted, it must be important. And if the conclusions of the study lead your efforts astray, you can blame the data, leaving your judgment unquestioned.

Moreover, many business and technology managers simply don't believe in the existence of someone with the skills and insight necessary to take a qualitative and creative approach to defining complex problems and designing appropriate solutions. And so they content themselves with incremental process improvements, the unofficial slogan of which is: Change is good so long as it resembles what we're already doing. But an organizational change initiative staffed, in part, by interaction designers can adopt a more productive slogan: Change is good so long as it satisfies the goals of people and the objectives of the organization.

This is no pedantic distinction. The difference between something designed around tasks and something designed to serve human goals is the difference between breaking ahead of the pack and biting the dust of the lead dogs.

Capture what's happening now, then articulate optimal processes

By now, we're all supposed to know that you have to record the baseline before changing everything. Otherwise, how are you supposed to know what fruit your efforts will bear? A great place to start in this case is by interviewing and observing sales folks and the people with whom they interact. You figure out what gets them up in the morning and what keeps them up at night. You find out how they make decisions and how they help others do the same. All of which is to say, you determine the processes, roles, and goals that comprise the organization, and the tools and information sales people use. These interviews—plus some observation—will give you a good understanding of the current state of affairs, and also reveal why people behave the way they do.

Let's take a simple example: say that your research uncovers that sales people are supposed to download a template for collecting information on each new sales contact. Great idea…except that nobody's going to use that template unless it works within their context and satisfies their goals (or at least doesn't thwart their efforts). After all, sales people want the sale. That's why they're called sales people. They care little, if at all, about the organizational efficiencies gained by everyone else using an identical template.

Once equipped with insight into people and their organizations, it's time to apply your design judgment. Sometimes that's going to result in better software; just as often, though, it might result in a better workflow. The point is, one can't be considered in isolation from the other. But what business is it of a designer to weigh in on process?

Improving the processes that people are doing is exactly the sort of thing that interaction designers do best. In fact, certain kinds of organizational design aren't merely analogical to the design of interactive products: they are the same thing. Sure, designing the perfect mechanical pencil is very different from drawing up a streamlined org chart. But the reach of an ordinary pencil is limited by the length of the arm wielding it, so there's little relationship between the process for its design and the design of an organization. But what happens when technology extends our reach beyond the breadth of our desks? When this happens, the line between product and process blurs, making it necessary for the design of tools to conform not only to the shape of the hands of those using them, but to the shape of the organizations for which they work. That is why any initiative aimed at improving an organization will benefit from the skills and insights of those whose job it is to design interactive products and services.

Create user personas and organizational archetypes

Once you've done your research, what do you do with your data? The methods used to describe system participants in an organizational change initiative are little different from those used to divine the needs of potential users of interactive products. Most importantly, it's vital to distill your findings into a set of personas that represent the population. You may spend more time than usual stepping them through current processes, with the not-unreasonable assumption that these processes shall persist unless otherwise shown to be inappropriate. Then you step your personas through scenarios that come out of their contexts and goals, while also taking into account likely technical constraints and critical business imperatives. It is from these scenarios that you formulate an inventory of user requirements, then make recommendations for meeting those requirements.

As mentioned above, it is particularly important to take into account the shape and objectives of the organization for which your personas work. That's where organizational personas come in. Like user personas, organizational archetypes are models based upon your research and defined by the patterns you identify. They differ, of course, in that they don't represent people, but rather the environments in which people attempt to achieve their goals. They express mundane things such as annual billings, numbers of employees, divisional relationships, business processes, infrastructure, sales targets, and geographic reach. But they also must express the values of the organization, the management philosophy, the prevalent work ethic of employees, and the over-arching objectives of the organization. The creation and application of organizational archetypes ensure that your user personas are not working in a vacuum, which means that what you ultimately design will make sense.

Stick to your guns

What happens next? The buy or build question must be answered. What's important here is to adhere to your principles and allow personas to guide the efforts of the entire organization.

Equipped with the requirements of users and organizations, it is important to set up collaboration sessions with business analysts, technologists and executives to work out how to satisfy persona goals while also meeting organizational objectives. In some cases a new technology solution can be bought off the shelf. But how do you ensure it won't spawn bigger problems than you're trying to solve? One way is to conduct thought experiments and run your personas through the use of the new tool or system, taking into account their contexts and goals along the way. To the extent the new product satisfies goals and objectives, that's great! But to the extent it can't, plans must be drawn up to satisfy the unmet goals and objectives, or at least to ameliorate the effects of the shortfall.

Sometimes off-the-shelf solutions just can't cut the mustard, and you must build your way out of the problem. In the case of new construction, use your personas to motivate a design that satisfies their needs while still being feasible and viable; of course, you need to use your design judgment to guide your hand in selecting the best possible solution, just as you would in a traditional product design effort.

Separate design from construction

In big, expensive organizational change initiatives, a conflict of interest often arises between the specification of a solution and its implementation. This can happen, for instance, when a technology integrator has several hundred hungry developers and partners who get sorely tempted to specify a design that plays to their technical strengths. But the beauty of an interaction designer's point of view is that we're platform agnostic: if the solution requires a new ERP system, all right…but if better processes can be realized by handing out more pencils and notepads, all the better! An interaction designer's approach must bear this in mind, providing level-headed insight to executives and precise direction to developers, so that the interests of the business and users are kept foremost in everyone's mind.

In the end, opportunities are what we make of them, not what is offered us. Just as identifying the goals of users is the first step to the best product design, the best way to work with well-meaning but ill-informed executives is to help them see the difference between what they say they want and what they really need.

What do you think? Join the conversation in Comments