I was recently involved in a project that involved the creation of a "status economy" on the web, i.e. a system in which businesses reward loyal users with stuff — a representation of increased status, better service, cash, etc. The parallel in the real world is the loyalty program, but the word "loyalty" seemed to imply a sort of exclusivity that is inconsistent with fluid and flexible world of web commerce and relationships. The web already has a variety of ways of displaying status, and the word "economy" more appropriately spoke to the web's transactional nature.

Enterprise resource planning systems must, by their very nature, serve the needs of a wide variety of people, and the implementation of these systems can result in the needs of one person being sacrificed in order to meet the needs of another. In an article on Forbes.com, Dan Woods does a nice job of laying out the pitfalls and frustrations attending ERP and other monolithic business software.

We particularly like the article because he mentions Alan and credits him for formalizing the use of personas, but it's also a sophisticated look at how system design is begging for effective tools to understand the network of human needs that must be balanced in order to create effective solutions:

...[S]ome users get more value from software applications than others. This is because software is written from a certain user perspective. In many cases, the problems and challenges faced in making software work can be explained by the tension created when the design of software is dominated by one perspective over another. In CRM systems, for example, the sales reps who must do the work of entering data about contacts and meetings often must be bludgeoned or bribed to do so. They get little benefit from such tracking, as opposed to the VP of sales, for whom the data is a vital way to understand what is happening.

Check it out "One Software Doesn't Fit All" on Forbes.com.

Luke Hohmann, author of Innovation Games: Creating Breakthrough Products Through Collaborative Play will be here at Cooper to teach an intensive, two-day class about Innovation Games, March 30-31, 2009.

When: March 30th-31st, 2009
Where: Cooper, 100 First Street, 26th Floor, San Francisco
Price: $995 per person, $895 per person for two or more attendees
To register: visit the registration site. For group discounts, send email to info@enthiosys.com

I was intrigued by the Enthiosys display at the Agile 2008 conference. Every time I passed by, the booth was filled with folks filling out colorful stickies and pasting them on posters containing grids and trees. Once I overheard a group of people engaged in passionate discussion about the relative benefits of different kinds of sunglasses. I asked what was going on, and learned that this was an Innovation Game called "Buy a Feature."

Because I am somewhat skeptical about feature-collection as a product design mechanism, I asked Rich Mironov to explain this to me. Did he really believe that you could ask people what features should be in a product and use that information with any confidence? Rich explained that you didn't listen just to what people said they wanted, you need to encourage discussion about why those features would be valuable, and how they would be used if they were available. At last, I suspected I'd found an ally in the product management world who understood that you needed to get behind feature requests to the human needs those features serve.

After I read Innovation Games: Creating Breakthrough Products Through Collaborative Play, I began to see potential for new ways to engage with my clients in a more fun and collaborative way. Several of the techniques described are similar to the techniques I use in my research: Me and my Shadow, The Apprentice and Show and Tell. Another set seemed to be new ways to collect some of the information I collected through direct research, but in a new way: Start your day, Spider web, Remember the future, Give them a hot tub.

As an experiment in trying new things, and to build better understanding between the Agile Product Management community and the Interaction Design community, Cooper has invited Luke Hohmann to come teach a session of his Innovation Games workshop at Cooper. We hope you can come join us!

As my fellow Cooperistas will attest, I’m passionate about a lot of things: interaction design, birthday cake, shoes… But product packaging? No, I wouldn’t have included that last one in the list - at least, not until I caught myself swooning over Amazon’s new Frustration-Free packaging.

Suddenly, it all came back to me in a rush of emotion: the anger, frustration, and threat of serious injury when struggling to extract a tiny memory card from its giant plastic “clamshell” package. The tedium and anxiety of twisting countless plastic-coated wire ties in a seemingly never-ending effort to release toy components from incarceration before the child loses interest and starts playing with an empty box instead. The disbelief and disgust over the trail of excessive plastic waste left behind after opening a single product. And I am not alone. To tap into the packaging-frustration zeitgeist, Amazon has encouraged customers to post pictures and videos of their worst experiences to the Gallery of Wrap Rage, and the responses are pouring in.

These consumer-hostile packaging practices are a perfect example of business needs trumping user needs. For far too long, companies have designed packaging that serves only two masters: product marketing and theft reduction. Mark Hurst's This Is Broken features a particularly rich example of product packaging that fails to address the need to get the item out of the package.

Because Amazon doesn’t have to deal with retail display or shoplifting, they were in a unique position to sidestep the usual drivers for package design and think (pardon the pun) “outside the box”, focusing on customers’ goal of liberating products from the package so they can actually use them! And as Amazon founder and CEO Jeff Bezos notes in his letter to customers introducing the program, “in addition to making packages easier to open, a major goal of the Frustration-Free Packaging initiative is to be more environmentally friendly by using less packaging material.” According to their FAQs, products with Frustration-Free Packaging can often be shipped in their own boxes, without an additional shipping box.

Just in time for the holiday consume-a-thon, Amazon delivers human-friendly, eco-friendly package design. Now really, who wouldn’t be passionate about that?

Here at Cooper, we’re pretty well known for our holistic and methodical approach to design, but don’t let that fool you - when the situation calls for it, we’re more than happy to get all “mavericky” with our clients and provide some good old fashioned ad-hoc consulting.

For example, I was recently asked to provide management support to a client who is in the midst of implementing a Cooper re-design of their robust web application. As I immersed myself in the project, I was quickly reminded of my previous life as a project manager and business analyst at a large software company, and how easy it is to fall into the many efficiency traps that often permeate large-scale development projects.

Over the course of my recent engagement, I identified several critical success factors for effective project teams, and some specific things that both project managers and team members can do to ensure project success.

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.

By day, Brad Brooks is a technology executive in Vancouver, BC. By night, he is a popular local talk radio host. Brad recently read my book, The Inmates are Running the Asylum and became a convert to the concepts I wrote about a decade ago.

He quickly asked to interview me on his show. Brad clearly sees the problem and its solution, and the interview neatly recaps the basic ideas in the book. The sad thing is that so little has changed. It all just means that we have to continually beat the drum for design otherwise we will drown in hard-to-use high-tech products.

You can listen to the interview on the Brad Brooks Show Web site.

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.

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.

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.

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?

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.

The industrial age is over. Manufacturing, the primary economic driver of the past 175 years, no longer dominates. While manufacturing is bigger than ever, it has lost its leadership to digital technology, and software now dominates our economy. We have moved from atoms to bits. We are now in the postindustrial age.

More and more products have software in them. My stove has a microchip in it to manage the lights, fan, and oven temperature. When the deliveryman has me sign for a package, it's on a computer, not a pad of paper. When I shop for a car, I am really shopping for a navigation system.

More and more businesses are utterly dependent on software, and not just the obvious ones like Amazon.com and Microsoft. Thousands of companies of all sizes that provide products and services across the spectrum of commerce use software in every facet of their operations, management, planning, and sales. The back-office systems that run big companies are all software systems. Hiring and human resource management, investment and arbitrage, purchasing and supply chain management, point-of-sale, operations, and decision support are all pure software systems these days. And the Web dominates all sales and marketing. Live humans are no longer the front line of businesses. Software plays that role instead. Vendors, customers, colleagues, and employees all communicate with companies via software or software-mediated paths.

Most people think of Goal-Directed Design techniques as focused on product design, but they work equally well for services. A service is comprised of the various "touchpoints" between a customer and a business. Touchpoints include public-facing systems such as web sites and web-enabled software, but can include other channels as well, such as brick-and-mortar stores, points of sale, interactive voice response systems, email and postal mail, too.

A service model best fits offerings that are intangible, distributed in space, or play out over a length of time, especially on a routine basis. Some obvious examples include: electricity, hotels, mobile phone service, or even a government. The touchpoints you design as part of your service are critical to the user's understanding of your brand. Increasingly, many touchpoints are interactive systems rather than human contact, so paying careful attention to the design of these things from the user's goals is vital.

If you work for a large company, or have one as a client, you've probably heard about Six Sigma. Many companies report great success using Six Sigma initiatives to improve the quality of their products and services, measured by increased customer satisfaction and millions of dollars saved.

At the core, Six Sigma and Goal-Directed design share some of the same values and provide tools to solve some of the same problems. Six Sigma seeks to understand and quantify the functions that matter most to users and provide improvements in those most leveraged areas. Goal-Directed design seeks to delight users and increase loyalty by creating products that are powerful and pleasurable to use. Six Sigma identifies and tracks faults "critical to quality" (CTQs). Goal-Directed design uses personas and goals to define and communicate interaction design decisions.

There's a dirty little secret that nobody in the design community wants you to know: it's actually possible to build and ship a software product…without designing it first! There. I said it. Now my time is short; even as I type, assassins with square-toed shoes and goatees are stalking my whereabouts.

But just because you can construct software products without designing them first, why on earth would anybody want to?

The analogies are endless: you wouldn't point a construction crew to an open lot and tell them to build a structure without giving them blueprints, would you? You wouldn't ask a doctor to re-set a broken bone without looking at an x-ray; you wouldn't storm the beaches of Normandy without a battle strategy and a good map; you wouldn't even don your shoes before putting on your socks.

Executives chuckle warmly at these analogies, and agree wholeheartedly that yes, it's always best to design products—the things that their companies sell for money—before building them and putting them in the hands of customers. Yet even though business decision-makers of all stripes acknowledge the merits of design, it's the designers and usability professionals who are the first to get jettisoned from a project plan when the going gets rough.

It's a given that we at Cooper—and most of you reading this article—believe design is the right tool for translating market needs into tangible product specifications. The people who hire us to design their products or who attend our Cooper U courses think the same thing. Unfortunately, the best designs and the best intentions won't always lead you to success, because the problem goes beyond your product and beyond your design or development process. Building better, more innovative, and more profitable products requires organizational change on a deep and difficult level.

When design pilot projects fail, it endangers everyone's willingness to adopt design methods. Over the course of doing hundreds of design projects and teaching our methods to more than a thousand people, we've seen that several reasons for failure keep showing up. A discussion of these reasons follows, along with some solutions to consider. Let's start with the easiest ones and work our way up.

People often ask how interaction designers should fit into their companies. If the company cannot take good advantage of it, the most brilliant interaction design in the world won't help as much as simple, workmanlike interaction design will benefit a company that uses that design well.

In my recent travels I have noticed a growing malaise in the community of programmers. Sadly, it is the best and most experienced of them who are afflicted the worst. They reflect cynicism and ennui about their efforts because they know that their skills are being wasted. They may not know exactly how they are misapplied, but they cannot overlook the evidence. Many of the best programmers have actually stopped programming because they find the work frustrating. They have retreated into training, evangelism, writing, and consulting because it doesn't feel so wasteful and counterproductive. This is a tragic and entirely avoidable loss. (The open-source movement is arguably a haven for these frustrated programmers—a place where they can write code according to their own standards and be judged solely by their peers, without the advice or intervention of marketers or managers).

Programmers are not given sufficient time, clear enough direction, or adequate designs to enable them to succeed. These three things are the responsibility of business executives, and they fail to deliver them for preventable reasons, not because they are stupid or evil. They are simply not armed with adequate tools for solving the complex and unique problems that confront them in the information age. Now here I am sounding like I'm slamming people again, only this time businesspeople are in my sights instead of programmers. Once again, to solve the problem one must deconstruct it. I'm questing after solutions, not scapegoats.

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.

Are your customers getting a helping hand or the cold shoulder?

The great thing about big American businesses is that they give us many of the stories that become the fabric of our lives. Frankly, we'd rather not endure the circumstances that result in the stories, but like train wrecks and tornados, they are entirely unforgettable and we talk about them for years. I'm talking about customer service horror stories, of course.

We all have many of them. The stories get particularly interesting when they relate to monopolies or near monopolies, otherwise known as oligopolies. Why? Because any interactions we have with such firms are biased from the get-go by the distrust we have for important players in our lives over whom we have little influence and control. We feel victimized before we even pick up the phone to attempt to do business with them. From their business perspectives, this should present them with an interesting challenge: how do we make our customers trust and love us, so that they won't find ways to live without us? Unfortunately, such firms rarely seem to rise to the challenge.

A good example would be a very unpleasant run-in I had recently with my oligopolist ISP (Internet Service Provider). The setup for the story is that I moved about six months ago. I called my ISP during the move to have them disconnect DSL at my old address and transfer it to my new address-simple enough. Six months later, still no DSL; however, my credit card bill continues to be charged. I decided to give them a call, but having already called them three times previously in recent months, it's fair to say I was already not in the best of moods and pessimistic about the quality of service I would receive. Suffice it to say that they lived down to my expectations. The customer service interactions went like this:

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.

In my article last month, Innovate, one step at a time, I discussed how the process of innovation easily derails during difficult economic times, such as today's. When creating software and digital products, innovation typically spans many months, and it can become disrupted by unobservable or frequently changing business conditions that make it extremely difficult to form and evaluate viable options. When people can't see where they're going, they typically just stop. This is tragic with respect to innovation, since it is innovation that propels business and society forward.

I believe most things run in cycles: the economy, the stock market, fashion, moral codes, even one's own personal status and influence (your personal "stock price," so to speak)—sometimes you're hot, sometimes you're not. The past couple of years have been particularly harsh in reinforcing a history lesson for us: when the pendulum swings very hard and far in one direction, it will most assuredly swing just as decisively in the other eventually.

During recessions, uncertainty prevails, and like a driver trying to weave his way along a mountain road in heavy fog, many businesspeople eventually tire and just pull their businesses over to what seems like a safe embankment, turn off their engines of innovation and progress, and wait for the fog to lift. But how long can one afford to sit on the roadside? At what point does it become riskier to do nothing than to proceed with caution? One has to wonder if there's a better way, a way to keep moving forward in measured, confident increments, rather than eventually creating an additional element of uncertainty by deferring innovation altogether.

"Necessity is the mother of taking chances."
-Mark Twain

Occasionally I encounter a motorist on the highway who is driving very slowly, some 20 miles per hour slower than the flow of traffic. This driver undoubtedly believes himself to be driving in a reasonable manner, equating his slow speed with safety. Unfortunately, he fails to recognize the greater risk of a much faster car plowing into him from behind. His slow speed has made his car into a barrier rather than part of the traffic flow, and yet he cruises on, oblivious to the squealing tires and honking horns directly behind him.

Is this really a safe practice? Not on the highways in Silicon Valley.

We talk to a lot of technology companies here at Cooper, and over the years we've seen some clear patterns emerge. On the positive side, more and more companies are realizing the importance of a good user experience and of the overall usability of their products. Unfortunately, we also continue to see companies falling into the same product development traps, to the detriment of their products, their customers, and their business.

These traps can be hard to spot, because they often appear to be standard business practices (especially when the company has never done it any other way), but when you take a step back you see that those practices really don't make much sense. If you have the nagging feeling that there's something not quite right with your product development initiative, it may be because you're falling into one of these traps. To help you recognize bad practices and work to avoid them, here are three common development pitfalls.

When companies plan out a new product (or service, or business process) they often think of the effort as the coordination of two teams solving different problems. Engineering addresses the question "what can you make?" Marketing addresses the question "what can you sell?"

You could engineer a combined toaster and cell phone, but you could never sell it. Marketing would tell you that you have a product no customer would buy. Likewise, you might successfully market a car that runs on tapwater, but the impossibility of building one makes it a meaningless product idea. Smart organizations know that they need to combine the insights from both marketing and engineering to find products that they can both make and sell.

High-tech companies are in a hurry—as well they should be—but many hurt themselves by trying to move products out the door too quickly. I often hear executives repeat homilies like "Ship early, ship often," and "Launch and learn." They assume that there is no penalty for simply slapping something together, shipping it, and then upgrading their product or site in a rapid iteration cycle. Unfortunately, there is a big, hidden cost associated with this tactic.

Rapid development environments like the World Wide Web have promoted the idea of simply iterating many versions of a product or service until something works. Arguably, the Web is in its nascent stage and companies are still experimenting to see what works and what doesn't, yet this should not be an excuse for iteration without planning, nor should "speed to market."