Last spring a company that supplies food services to millions of people around the world mentioned to our team that they were interested in taking a closer look at one of their operations in Philadelphia, at the ball park that’s the home of the Phillies.

Citizens Bank Park has 43,637 seats, and last season the stadium was filled to 103.5 percent of capacity, leading national league attendance with a total of 3,647,249. That’s a lot of hot dogs—but receipts from food concessions weren’t corresponding with the surge at the box office, and the company wondered whether its point-of-purchase terminals should be redesigned to process sales more quickly. My company offered to investigate.

As a first step to evaluate the technology we needed to see it in use, so five of our designers and design researchers headed for the ball park to observe the concession stands during a game and gather data on how well the point-of-purchase terminals were performing. Our researchers quickly determined that the terminals were operating smoothly and efficiently, and they saw very few lines of customers waiting to pay for their orders. But the company’s suspicion that there might be a problem was correct: There was a big bottleneck. However, contrary to the company’s expectations, the bottleneck wasn’t at the end of the transaction. It was at the very beginning.

To place their orders, customers lined up in front of ordering stations. Our researchers saw as many as nineteen people standing in each of these lines—seldom more, because as the lines snaked out from the concessions in random patterns, the twentieth person would be bumped out of line by the heavy crowds flowing around the concourse. And despite a multitude of workers behind the counters ready to take orders, the lines moved slowly. The reason was simple: The menu displays were so poorly designed that only the first few people in line could decipher them, and by the time customers reached the head of the line, many of them needed more time to decide or felt so confused that they began ordering things that came to mind rather than items listed on the menu. Workers on the other side of the counters were under so much time pressure to take orders that they were rushing their customers and causing further confusion.

Any technology is only as effective as the form in which it’s presented and the context in which it’s delivered, especially the human context. That’s why raw metrics seldom tell the whole story.

Making a meaningful design analysis of any product that’s used by human beings requires research techniques that consider both the product and the people who use it: direct observation followed by analysis, proposals for alternatives, and a process of evaluation to test those alternatives among a representative group of men and women. Often a design analysis of a business system will reveal that what appears to be a technical deficiency is a human problem, one that can be remedied with low-tech solutions as basic as redesigning a two-dimensional graphic display and establishing an arrangement of orderly queues to channel customers to their destination.

What the data can tell us about a business problem is immensely valuable. But when we understand how technology performs in the highly volatile environment of a public arena, it’s a whole new ball game.

Read more about how design research can solve business problems.

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).

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).

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).

A SaaS product is a piece of software that end users purchase access to, rather than purchase to install on their computer. A wildly successful example is Salesforce.com-a software tool that allows a company’s sales professionals access to Saleforces’ features and functions, and the company’s own sales data wherever there is an internet connection. This means salespeople who are on the road most of the time can update the company’s sales data real-time from the road. It also means that the company no longer has to wrestle with software upgrades and data integrity issues related to individual physical computers (e.g., salespeople updating files once they are back in the office).

“We’re running a SaaS model now, so changing the product’s user interface is a snap. We can change it every day if we need to. So we don’t have to worry about usability problems anymore.”

This evolutionary quality is a welcome change for software companies whose previous product release schedules were plagued by missed release dates and grandiose unveilings that often disappointed customers. SaaS applications can be updated incrementally and deliver new features and user interface designs to end users whenever they log in. This capability has given some folks in the SaaS world the impression that these products are immune from the usability and user adoption problems that plagued their browser-based and client-server predecessors. Unless design and design process drive the evolutionary changes of products, changes may keep genuine innovation and improvement from being a reality in this new world.

Once again, it sounds like a new technological capability is being mistaken for design and design process-things that are painfully rare in the software world.