“When was the system installed?” I ask. The doctor—let’s call him Dr. Jones—quickly responds with an unusually specific answer: “July 10th, 2010.”

Our lives are marked by dates we’ll never forget—a marriage, the birth of a child, the death of a parent. This physician has another landmark date: the launch of the system that would change the way he practices medicine.

Should have known from the start

Beginning on July 10, 2010, and throughout the next two weeks, there was something about the new system that just didn’t seem right: That something was an EPIC employee who followed the doctor around every minute of every workday, coaching him on the use of the new system. Dr. Jones thought that this seemed a bit extreme and likely not a cost-effective way to deploy a product, but he wondered if perhaps his instincts were wrong and this was just the way that things were done in the newest era of computerization. Looking back, this oddity was fully indicative of the new normal—a system so difficult to use that it would require more than the physician’s own hands and mind to operate it successfully.

The whole patient – The whole record

Dr. Jones recognizes the value of a single patient record shared across the whole of the health network. Unfortunately, interacting with the electronic system he’s been given is so awkward that when he examines a patient, he can only concentrate on the here and now of the encounter by recording the current data. Accessing and reviewing all the available historical information—the patient’s full medical record—is just too difficult because of the way the data is organized.

Before the electronic system was installed, Dr. Jones had available a copy of his patient’s paper chart, a set of documents that could contain eight or more years of information. He would begin an exam by thumbing through that collection of papers, looking for trends and utilizing his professional experience to quickly familiarize himself with the data patterns in his notations that describe this patient’s path to this moment. He would then bring to the exam a solid, informed historical perspective. In the EPIC system, information for each patient is scattered across multiple screens, and it’s not possible to quickly navigate among them to obtain a summary. With this system Dr. Jones can only hope that he has some recollection of the patient’s previous visit—for example, a finding of an elevated cholesterol count—but he has no expectation of being able to view the patient’s electronic historical record without an expensive, time-consuming effort. The alternative which Dr. Jones and many of his colleagues have adopted is to print out the paper records which comprise ten or fifteen pages for each patient.

This physician also is frustrated by the fact that the electronic system restricts the ways in which he adds data to the patient record. Data entry is quite possibly his most difficult challenge. The notes that he can input must be minimal and by their nature they’re cryptic—not nearly as rich as the notations that are possible within a paper-based system. He knows that other doctors feel the same way, and he knows that their notations are usually less informative and even more enigmatic than his own.

A hired hand

Verifying new notations as they’re added to the patient’s record presents another challenge. How can a doctor complete all the required fields in an electronic system’s displays during a patient visit and make sure that his notes are accurate and the chart is closed properly after a final review? Increasingly, the answer is to delegate. Like many of his colleagues, Dr. Jones employs two assistants whose job description didn’t exist until recently: medical scribe.

A medical scribe’s job is to follow a doctor into every exam room and input all the data that the doctor directs the scribe to enter into the electronic system. For Dr. Jones, this process of dictation goes on all day, for each of the 60 or 70 patients he sees each day. Unfortunately, this is not the end of his work with the system. At the end of every exam, or at the end of the day, he needs to close each of the open files on the system by reviewing the scribe’s work, certifying that all the information is correct, and finally hitting the “Close” button on the display of each record.

To review each patient record takes a doctor three or more minutes to complete. This can add up to several hours of additional work to be carried out during the day—or on the weekend. For many physicians, this extra time commitment is unacceptable. Something has to give. Like other workers, physicians are figuring out how to deal with the system in a way that serves their best interests, and their solution is anything but desirable to the business concerns of their hospitals.

Business is bombing

For many physicians, the EPIC system has added an extra person to the exam room. I’ll leave it to the social scientists to tell us how this might affect the confidential nature of the patient-doctor dialogue. From a business perspective though, the impact is clear.

These doctors are salaried professionals who are paid a specific amount of money for their full-time work in their practices. The two scribes hired by Dr. Jones are a direct cost to his practice—he is paying their salaries out of his pocket at a cost of about $50,000 so that he can continue to see the same number of patients as before.
Doctors in practices adjacent to his in the building we visited have a different approach. Because their lifestyles require their entire paychecks, these individuals are not willing to pay for scribes, and because they value their time with their families, they’re not willing to work the many extra hours the system requires of them. They are simply seeing fewer patients.

For patients, this means longer waits to receive care. For the hospital, a reduced appointment schedule means fewer reimbursement dollars.

The advances in the practice of medicine that will be made possible by electronic record-keeping will one day be truly epic, but at this early stage the technology is a work in progress that requires a much more thorough examination of its human requirements.

Read about how the form of medical chart can influence the course of treatment.

Harold Hambrose is the founder and CEO of Electronic Ink, an international design consultancy specializing in business systems, and the author of Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate (John Wiley & Sons).

The widget manufacturers of the nineteenth and twentieth centuries had a pretty good idea of how well their products fit an existing need and how well they were performing, because if their widgets weren’t quite right, they heard about it from their customers. A widget-maker’s brand was identical to the quality of his product, and he didn’t need a focus group to tell him how it was perceived.

But as smokestack industries evolved into World Wide Widget companies, relationships between manufacturers and their customers became impersonal and indistinct. As the physical distance between the two groups has widened, the personal contacts that once provided a conduit for the steady flow of information about the strengths and weaknesses of a product have been replaced by research techniques such as customer surveys, interviews, focus groups, proxies, and personas. At the same time, the distinction between customer and user has become blurred, especially among buyers of software products—typically, CIOs, CTOs, CFOs, and other executives—and the larger groups of men and women who use the products on a daily basis. When a software manufacturer focuses its customer-satisfaction surveys or usability testing on buyers rather than users, the communications gap expands and the confusion is compounded.

Just as the identity of customers for business systems has become unclear, the identity of the products themselves has become ambiguous. Manufacturers of electronic business tools such as off-the-shelf software and cloud-based systems commonly market their products as services. Because the physical presence of these products can seem ephemeral, it’s easy to forget that these marvels of technology are just a new form of manufactured goods—machine-made products that are engineered, built, marketed, and sold. Yet unlike Industrial-Age consumer goods, the newest products of business technology can be difficult for customers to compare, and two systems with similar functions and features may be structured in ways that provide very different experiences to the people who use them.

The most visible part of a software product is its package—the way in which graphics are used to enhance its appearance onscreen—so it’s easy to confuse the packaging of these electronic products with the products themselves. That’s why so many companies try to improve an underperforming portal by amping up its graphic design, mistakenly thinking of the “user interface design” as the colors, graphics, and letterforms that make up the display rather than the experience one has with the system.

Package design has a long and honorable commercial history, but it’s not the same as product design. Throughout the 20th century, packaging became increasingly important as a marketing tool for a wide range of products, including nearly every mobile phone, every bottle of perfume, and every box of cereal. Today so much attention is lavished upon package design that it’s often confused with product design, the content and structure of the product itself. The confusion is greatest when the product is electronic.

In the technology domain it’s become an unavoidable cliché to cite the iPod, the iPhone, and the iPad as exceptional examples of a great product in a great package—imaginative, beautifully engineered products packaged in innovative, interactive shells. If only our electronic business systems were so thoughtfully organized and so cleverly packaged! Instead it’s more common to see a system with a convoluted navigational structure and obscure vocabulary overlaid with colorful graphics.

Old-school manufacturers knew that what counted most about a product was the user’s ultimate experience of ownership. When Motorola, Westinghouse, and Zenith began producing tabletop radios with shiny, candy-colored casings made of a new plastic called Bakelite in the 1930s, they recognized that as innovative as the new plastic was, most people really didn’t want to know about the molecular structure of the casing or the internal workings of the radios—they just liked the way they looked and the way they worked. If the colorful casings had been wrapped around shoddy products with confusing controls, the new models wouldn’t have succeeded for long. Their manufacturers recognized that producing an inferior product, no matter how attractively packaged, wasn’t a viable business strategy for the long term. But when the companies made their reliable old products look more attractive, the experience of owning them became even more satisfying.

Industrial-Age manufacturers could easily identify the owners of their products, evaluate their experiences with those products, and respond accordingly. But the owners of electronic business systems are typically not the people who use those products, and software manufacturers need to be honest with themselves about whose voice will matter most in the long term.

Our industrial ancestors never forgot the difference between how a product looked and how it worked. The women of my grandmother’s generation had a saying: “Handsome is as handsome does.” Because in those days it was common knowledge that beauty is only skin deep.

Read about what can make data beautiful.

Harold Hambrose is the founder and CEO of Electronic Ink, an international design consultancy specializing in business systems, and the author of Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate (John Wiley & Sons).

Fine-tuning the design of business software is commonly treated as a troubleshooting issue that’s addressed after a system is deployed, a procedure typically undertaken by technologists working with business analysts, experts in the business domain at which the software tool is targeted. This process is often thought to be an activity that requires no specialized training in design, one that can be performed by any capable technologist collaborating with someone knowledgeable of the business.

In fact, this is exactly how most business software is designed—by technologists and business analysts who have no training in design. That’s why so many of our brilliantly engineered business systems are nearly impossible to use. (Full disclosure: I was trained as a designer at Carnegie Mellon, and this is what I do. But please bear with me.)

Even our most sophisticated business systems are the products of a relatively young industry that’s still in the adolescent stage of defining itself and developing all the skills that will be needed in order to fully mature.

Owners of small, young companies typically wear many hats until they have the resources to recruit additional expertise. Like startup companies, industries and professions also evolve into groups of experts with closely defined job descriptions. In the building trades, it was once common for carpenters to lay bricks, install plumbing, and hook up the electricity. In the early years of automobile manufacturing, little distinction was made between engineering and design—that’s why the Model T had a hand crank that was such a nuisance. But as automotive design became a specialty, automobiles became easier to operate and a lot more fun. In medicine, a profession in which at one time every physician was a general practitioner, we now also recognize the expertise of epidemiologists, pediatric surgeons, hospitalists, and many more specialists who bring an understanding of the human context to traditional methods of diagnosis and treatment.

I would argue that the software development industry is still at a stage comparable to a young, energetic business that cultivates within its ranks an entrepreneurial spirit, a willingness to pitch in to do whatever is needed to get the job done, and a self-confidence that sometimes blinds it to its own limitations. Working within the industry are multitudes of talented information architects, application developers, data modelers, and many other specialists, including thousands of professionals who hold the title of User Experience Designer or Web Designer. But many of these so-called designers are technologists, business experts and usability professionals who are being asked to do the work of designers.

Many members of the software development industry have yet to recognize that creating a connection between a product and a person isn’t something that just anyone can do—that design is a profession built upon long-established methods of solving problems for human beings. Designing a product that works well in the hands of its users is a job for professionals who are trained to diagnose human problems, identify human needs, and translate an accurate definition of those needs into a satisfying form, whether the product is an enterprise system or an SUV.

It’s true that some of the research methods used by designers—direct observation, interviews, and language-assessment tests—are widely practiced within many professions, and these techniques are taught in executive process-management seminars that have become a growing business in themselves. So couldn’t your technologists or business analysts learn to perform a contextual analysis of your business processes, perhaps organize a card-sorting exercise to assess the suitability of language in your software system, and estimate the potential impact upon productivity of proposed modifications? Maybe—but would that be the best use of their time? And how precise would the results be? You are likely to build a rich body of data representing what the business is doing and what functions a system may need to deliver. Unfortunately, what will be lost will be an opportunity to gain an understanding of why the business is behaving the way it is – knowledge that is the catalyst for innovation.

Whenever resources are available, it’s much better to work with someone who has specialized expertise. Professional training is no guarantee of excellence, but it can make a big difference in the performance of any job, no matter how small. Anyone with a pair of scissors can give you a haircut, and you could even learn to do it yourself—but when it’s time for a trim, where do you turn? I’m betting that you make an appointment with a professional. The design of a business system deserves no less.

Read about how to evaluate a designer or design consultant.

Harold Hambrose is the founder and CEO of Electronic Ink, an international design consultancy specializing in business systems, and the author of Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate (John Wiley & Sons).

The first step is to untangle the twisted wreckage and assess the damage. The business process may have been bent into some bizarre new form, or the men and women who have been forcibly interjected into that process may be so traumatized that they’re essentially shell-shocked.

If it sounds as if I’m overstating, here’s an example:

Ideally, workers will have an opportunity to interact with one another in a collaborative environment with access to brilliantly engineered software to help them execute their everyday tasks. Such software is abundantly available, as are open-plan office spaces in which people can freely exchange ideas. This is just the kind of environment in which my team of designers recently discovered a large group of workers to be in a complete state of misery.

The company’s sophisticated software system was supporting the business process in exactly the way that the company wanted the work to be done, but people were profoundly unhappy. One man said, “This is no joke—I’m not kidding—this system is wrecking my marriage.” When I asked, “What do you mean?” he said, “I’m in this open-plan environment where we’re supposed to collaborate, and we talk and we interrupt one another to discuss things, but if I leave the system idle, it times out and I lose my work. So I take my work home at night because I can’t complete it in the office.”

It was obvious that the efficient, inflexible behavior of the system was in complete defiance of the physical space occupied by the human beings charged with using it. Either the system needed to be reconfigured to be more flexible, or the company needed to start throwing up walls between these people.

If only some consideration had been given to the human requirements of the system from the very beginning, at the same time the business requirements were specified—before the selection process for the system had even begun! The best-laid plans of highly specialized business analysts and expert technologists routinely vaporize whenever their process fails to include someone who is trained to analyze the messages that will be sent by the system and who can predict what those messages will mean to the men and women who receive them.

Any company that doesn’t make it a priority to avoid sending mixed signals to its workforce is taking a big risk: It’s an accident waiting to happen.

Read about how to evaluate the signals that a business system is sending.

Harold Hambrose is the founder and CEO of Electronic Ink, an international design consultancy specializing in business systems, and the author of Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate (John Wiley & Sons).

We all know how important it is to define our requirements before we commit to any new business system, but it’s easy to overlook some of the most important requirements of all.

For systems that support a basic operation such as sales, the requirements would seem clear: a solid framework to store data and generate reports about companies, contacts, and opportunities at each stage of the sales cycle. Many readymade tools packed with features are available both off the shelf and in the cloud, and some of the newer ones look deceptively simple and beautiful—until they’re put to use.

When people sit down to use a new system for the first time, it often becomes clear that no one has considered the requirements of the users: Does this new tool make it easier for members of the sales force to enter their data, or will it represent a hurdle? Will routine tasks such as expense reports become easier, or will they turn out to be more time-consuming? If training will be needed, how receptive will the sales force be? How quickly can they learn, and how much will they retain? How many of the system’s features are useful to them?

If this tool represents a good fit with the sales force, will that satisfy the user requirements? Of course—as long as no one else in the company uses sales data to do their jobs. But the fact is, the instant a piece of software is installed to support one part of a business, it interfaces with other areas. The COO needs to understand the timetable of the sales cycle to know how to allocate resources to deliver the product or services that have been promised. The CFO needs sales information to consider whether increased staffing is justified. It’s well worth asking how else it might be possible to slice and dice the data. For example, not every company wants to run weekly weather data against tabular sales data, but for companies that rely on trucking and airlines, it’s essential.

Software vendors do a great job of defining standard business requirements and providing technological solutions to those requirements, but they’re ill equipped to identify the human requirements within each industry, not to mention the human requirements of individual companies. The technology offered by various vendors may differ just enough to provide dramatically different experiences for people in two closely related companies.

Unless you take time to define the human requirements in your own business and match them against what’s available before you commit to a purchase of new technology, you may later find that things are moving much more slowly than you expected.

Read about ways to evaluate business software.

Harold Hambrose is the founder and CEO of Electronic Ink, an international design consultancy specializing in business systems, and the author of Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate (John Wiley & Sons).

A few decades ago, business software was typically housed in a mainframe computer so gigantic that it needed its own office. As smaller central processing units were developed in the 1990s, software systems migrated to desktop computers, each one representing an individual installation requiring periodic updates with floppy disks. Then came the Web, and everyone said, That’s it! A web browser is the way to distribute software—that will work! And it does.

Businesses are quickly adopting software as a service (SaaS)—software called down from the Internet on demand. Cloud computing can be a highly cost-effective way to license tools for basic business operations such as sales, accounting, and HR. But cloud-based systems can cause considerable confusion because many of these fluid new systems are organized in a way that’s as amorphous and as transitory as a cumulus formation.

Recently one of my clients and I had a conversation with a sales rep for an SaaS product who explained that since his company has moved its application to the cloud, all their concerns about design and usability have vanished. They reason that because they have the technology to make updates to the software’s user interface as frequently as they like, they can tweak the product as user complaints filter in, almost in real time. I keep thinking that this is like a homeowner who has just discovered a patching compound for his leaky roof—a product that allows him to quickly paint over a crack whenever a drip appears on the ceiling.

Back in the day, developers would ask their customers to evaluate their products, and when members of a user group reported that they disliked 20 different things about a system, developers would spend months monkeying with the system and guessing at what to deliver to the desktops as an upgrade. In the cloud, developers can tweak the software and issue a new release in a cycle of 24 hours. There’s almost nothing analogous to a product with such a fast production cycle.

But God help the users! What we have now are tools that are constantly being reshaped, often without rigorous testing or a comprehensive design to show how today’s update will affect tomorrow’s plan.  When I hear development shops say, We can update the software every day! I wonder, How can you possibly be producing a coherent product? Even with the world’s best coders, no software product will hang together in a cohesive way without a design that provides a framework to predict the impact of each modification.

Every software developer tests its products, sometimes by using other software and sometimes by having developers just bang against it to see if it works. The question is, How rigorous is the testing process, and what does it actually test? Does the test confirm that the update works, or does it confirm that the update will provide a better way for people to work?

Updates also need to be documented. Recording what was done, and why, is very important because an explanation of what was done last week enables you to understand that the way you feel about it this week may not be a good reason to change it. Documentation also prevents software from developing eccentricities that become inexplicable: Why was that change made? Why does this thing work this way? In the cloud, where there’s an opportunity for instant updates, there’s a temptation to write down fewer things because that slows the process.

For all the opportunities that this new platform affords technologists, there’s no escaping the need for a plan and the importance of design, testing, and documentation. A plan isn’t expensive and won’t defeat the flexibility of a system; in fact, it will make that flexibility more valuable because it provides it with a framework. When software is designed and built according to a plan, input from the field can be compared against models both current and future, threaded into the model as appropriate, and used to demonstrate the impact of updates before making those changes.

With every leap of technology we tend to believe that the innovation will create a better experience for the user, and in some sense this has happened—now I don’t need to sit at my desk and update software with floppy disks. Yet when it comes to the design of how one interacts with these “cloud” apps, things aren’t much better.

The ability to make constant changes to these products is no substitute for a designer’s planning process. Without that process, the result is just another unusable compilation of features and functions—but now these assemblages are being built in a matter of days rather than years. Talk about a missed opportunity for planning! But I guess that’s the risk when your head’s in the cloud.

Read about a few questions to ask vendors before you sign your next software license.

Harold Hambrose is the founder and CEO of Electronic Ink, an international design consultancy specializing in business systems, and the author of Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate (John Wiley & Sons).

Electronic devices are the safes where we store some of our most important assets, and I keep wondering why data assets aren’t as rigorously protected as money, gold, and other valuables. The finest safe in the world is only as strong as the policies and procedures that regulate its use, and its weakest link is any person who has access to it.

To preserve the security of a database, it’s essential to give people the right tools—keys in the form of good software to operate the system—but setting policies to control the use of a database is even more important. How much sense does it make to allow sensitive data to be transported on electronic devices that can be borrowed, lost, or stolen, even if the data is encrypted?

The BP laptop disappeared March 1 during “routine business travel,” according to a company spokesman. BP reported the loss to law-enforcement authorities, and after more than three weeks, when no Good Samaritan had appeared at Lost and Found to turn in the laptop, BP sent letters to those whose data is missing to notify them of the loss of their personal information.

Residents of Louisiana, who are still feeling the effects of the massive oil spill last April, reacted to the disclosure just as you’d expect. Beau Weber, a fishing guide in Lafitte, LA, told the Associated Press, “It’s very disturbing. It’s like another gallon of gas thrown on the fire.”

To make amends and to try to repair this new dent in its brand, BP has offered to provide free credit monitoring to each claimant. In the meantime BP is attending to the tasks of generating press releases and responding to queries from media and the public—all in all, an unwelcome distraction and a big embarrassment.

Data is misplaced much more often than we’d like to think. Last fall two health insurers announced that a travel drive containing the shared records of 285,691 Medicare patients in Pennsylvania—including names, addresses, and Social Security numbers—had gone astray.  A representative for Keystone Mercy and AmeriHealth Mercy health plans told The Philadelphia Inquirer that the two companies had been working on an initiative to encrypt all company data, “especially flash drives,” but the project had not been completed when the travel drive disappeared.

The Privacy Rights Clearinghouse reports that last year something similar occurred 67 times within the healthcare industry alone, when portable electronic devices containing 2,492,592 medical records were lost or stolen.

Stories like these remind me of my grandmother’s “security box,” which she kept under her bed. It contained cash, credit cards, and her will. The box had security features—it was metal, and it was locked—but it was hardly a security solution in itself. Encryption that protects portable data is like that metal box: Someone with enough determination and the right tools can crack it. But if my grandmother’s personal policy had been to keep her security box under the floorboards, her chances of losing what she stored there would have dramatically dropped.

What’s on your laptop?

Read about how the quality of technology can affect a company’s internal brand.

Harold Hambrose is the founder and CEO of Electronic Ink, an international design consultancy specializing in business systems, and the author of Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate (John Wiley & Sons).

The good news is that we have more data than ever before to measure, analyze, and predict risk for nearly every aspect of business. The bad news is that it can be difficult to quickly interpret the data and convert it to meaningful information.

Many businesses have wisely invested in storing vast amounts of data to document their historical record, but the single biggest challenge facing information technology right now is how to present that data. One of my clients recently told me that his company’s highly skilled IT specialists have been churning out charts and graphs till they’re blue in the face, with no apparent benefit.

“They put these 60 apps together in no time,” he said— “but” (he whispered) “we don’t think anyone is using them. We know they’re cool, but we don’t see how they’re useful to us.” At the same time, he told me, people within the company want more data but don’t understand to ask the system to generate reports, so they waste valuable time trying to figure out how to retrieve data and assemble it in a meaningful way. Once you learn how to request the reports they can be generated more quickly than ever, thanks to new versions of enterprise software, but often they’re the same kinds of reports that were being produced twenty years ago—compilations of isolated data.

For a while the business community embraced the fad of dashboards, but what we’ve discovered is that many of these dashboards don’t display data in a way that makes sense to most people. Often the data is irrelevant, outdated, or based on obsolete business processes, and even when dashboards are current, most people don’t know how to read them.

Companies that are mining the greatest value from their repositories of data are those that have turned their attention to the points at which decisions are made. They’re asking, What actions must be taken to accomplish the business goals? How are people making decisions to take those actions? What kinds of information do they need to predict the outcome of those decisions? What sources of data do we have that will yield that information? What are the most effective ways to communicate that information as quickly and as accurately as possible?

The capabilities of data warehousing offer tremendous opportunities to access historical information, gather predictive data, make new comparisons, and test theories. But it’s not just a matter of marshalling the technology. The cost of data that’s hard to interpret can be very high, and it has no value unless it can be clearly and quickly communicated to everyone who needs it.

In reviewing the Japanese government’s response to the recent catastrophic chain of events, Chief Cabinet Secretary Yukio Edano has said that “In hindsight, we could have moved a little quicker in assessing the situation and coordinating all that information and provided it faster.”

Every business needs to gather, interpret, coordinate, and communicate essential information in order to mitigate its own potential risk factors, whether the threats are physical or financial or both. In considering how to anticipate and manage those risks, now is a good time to ask, How can we do better? The greatest opportunities lie in a closer partnership between business, technology, and design.

Read more about what makes data meaningful.

Harold Hambrose is the founder and CEO of Electronic Ink, an international design consultancy specializing in business systems, and the author of Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate (John Wiley & Sons).

Some innovations result from lucky accidents or chance observations, but more often they’re the result of a step-by-step process of exploration that begins in the present and points to the future.

In order to imagine what might be, it’s necessary to understand what is. Gaining an accurate picture of the present is one of the trickiest parts of this exploration, because business processes often work quite differently from the ways that they’re expected to work. Most managers, if asked to describe a typical business process in their companies, will describe a direct route that’s as smooth as a freeway. But a trained observer who follows that path from start to finish will usually discover traffic jams, roadblocks, detours, and rocky back roads in the form of workarounds, not to mention some stranded travelers. Identifying patterns of congestion and delay, and recognizing their causes, are just a few of the things that can be accomplished through direct observation.

Once it’s clear what’s really happening, then it’s possible to create models of alternatives: Would certain data be more informative if it were displayed differently? Could some transactions become more efficient if they were performed in one location rather than spread sequentially across several time zones? What would happen if we—? That’s when the fun begins.

But how can you experiment with these kinds of alternatives? When you have the spark of an idea, how can you ignite it? How can you create a model and push and pull on the variables to see what else might happen? How can you test an idea before you commit resources to it?

The traditional design process is organized to do just that, with drawings and diagrams that describe business processes that are performed by people, and with wireframe prototypes that describe screen views. This process has almost nothing to do with technology, because technology won’t be the innovation: Technology will be in service of the innovation. By using inexpensive prototypes to test alternatives, stakeholders and decision-makers can imagine all sorts of possible scenarios without risk until they agree on what the next step should be.

Innovation isn’t a matter of streamlining the status quo. Innovation is a new process or a way of presenting information in a new form. Innovation can create a new object, and it also may cause objects to disappear. It can change the way people work, and it can even reinvent the nature of work.

Innovation can be a sudden stroke of genius, but for many businesses it’s the predictable result of a methodical process—a process of observation, prototyping, and testing that places a high priority on asking What if?

Read about some of the ways in which prototypes are used to innovate.

Harold Hambrose is the founder and CEO of Electronic Ink, an international design consultancy specializing in business systems, and the author of Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate (John Wiley & Sons).

For many businesses, striving to create a great experience for the workforce just isn’t part of the corporate culture. Cynics will argue that you can never make people happy, and that even if you could grant every wish, it’s not realistic for most businesses to offer an on-site food court and a gym. But those kinds of conveniences are beside the point, because all the amenities in Mountain View can’t boost morale and raise retention rates if the business processes are outdated and the desktop tools are balky.

Professionals want to be able to do their jobs with a minimum of stress, and the technical support they receive from the business systems they use can mean the difference between a sense of satisfaction that comes from a job well done or a host of medical problems caused by bruxism–persistent grinding of teeth. For a business, it’s a question of the bottom line: People who are given the right tools to do their work are happier, more productive, and they tend to stick around.

So it’s good business to figure out which tools people need. To do this it’s necessary to specify two sets of requirements: the business requirements and the human requirements.

Many businesses make the mistake of fixating on features when they evaluate technology. They ask, “How fast can this system produce these reports?” when the question should be,   “Does this system generate reports that will make my people better, faster decision makers?  Will all this system’s data equate to more informed executives, managers, staff?” That’s a huge disconnect.  Businesses need to be asking for systems that can be easily mastered, so that within ten days of implementation, people can use them to run reports, assess the data, and make decisions.

What many companies still don’t understand is that every screen presents challenges to the people who face them, and at the edge of every new platform is a precipice over which people can tumble. In order for a business system to communicate clearly, someone needs to evaluate each component on every screen from the human perspective, not just for the function it serves, but for its ability to prompt the correct response from its audience: How easily can the right response be learned? How likely is that knowledge to be retained? How quickly can an error be corrected? Answering these questions is beyond the scope of technologists and business analysts, despite their best efforts.

Not long ago I visited the international headquarters of a European bank whose facilities are breathtaking in their lavish display of electronic gadgetry, splendidly installed in spacious rooms. But when I pulled up a chair next to an analyst who was trying to enter his expenses, I could see that he might as well have been confined to a dungeon. He was wrestling with an application on his desktop that had virtually forced him into a corner, and there he sat, pounding away at the keyboard in frustration and moaning, “Why can’t I. . . .”  while not fifty feet away was a state-of-the-art, wall-sized screen projecting a stream of information from around the world. Amid all the technological wizardry that surrounded him, he was essentially working with a broken pencil.

Throughout our industrial history we’ve produced products that succeed because they’re designed to put us at ease. The car I drive does much more than take me where I need to go—it makes me comfortable and gives me a sense of well-being. Most of today’s business systems are fast, faithful transmitters of data, but is it really enough for a system to “just do its job”? Although many frustrated executives would gladly settle for that, we ought to expect so much more!

It’s entirely within our capabilities to routinely design graceful, intuitive business systems that anticipate our needs and respond accordingly. The savings in training costs alone make it well worthwhile, and when a system truly supports its users in performing a task, everything about the performance of that task improves: its timeliness, its speed of execution, and its accuracy.  When using a system feels like second nature, chores that were typically postponed because they were so painful to execute can be quickly accomplished, making time for work that’s more important—or just more fun.

Read about the secret of developing software systems that people like to use.

Harold Hambrose is the founder and CEO of Electronic Ink, an international design consultancy specializing in business systems, and the author of Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate (John Wiley & Sons).