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

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

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

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

Nearly every industry honors its outstanding performers. So why are there no prestigious awards for Best Performance by a Business System?

Is it because a totally satisfying business system is as rare as a black swan? Or is it because we haven’t yet defined the standards that lead to outstanding achievement?

We set the highest standards for the technical capabilities of our business systems, and the best of these systems are astonishingly fast and accurate. Yet each new release is typically followed by an arduous process of debugging, patching, and training.

In every industry, to consistently produce an outstanding performance requires the right process—usually, a rigorous process of iteration—and I would argue that the software development industry will never be able to consistently produce excellent business systems until it sets a different standard for its development process.

Most of the standards we have for business systems concern technology (Does it comply with standard coding practices and WC3 standards?), functionality (Can it quickly and accurately add, subtract, and aggregate?) and usability (Can people actually use this system?). Most of these so-called standards are nothing more than conventions—general guidelines that have been cobbled together for the coding, engineering, navigation, appearance, language, and accessibility of these systems. These basic rules are incomplete and inconsistent, and some (especially those for usability) are still quite primitive. Strict adherence to these minimum standards will provide no guarantee of quality because rarely do they fully satisfy all the usual requirements of an industry, let alone the special challenges that characterize individual businesses and even the qualities that differentiate one group of employees from another.

To raise the standards and elevate the average performance of our business systems, the solution isn’t to compile ever more detailed technical manuals of specifications and exceptions. Instead we need to advance the process of software development.

In some ways, the software development industry is similar to places where buildings are designed and constructed by the same craftsmen. Many of these buildings serve well enough. Yet with the help of an architect—a trained designer who works with the builders to translate the needs of a client into a practical, agreeable form—any structure can be more functional, more convenient, more energy-efficient, more sustainable, more adaptable to future needs, and more innovative.

In their race to deliver applications, software developers have yet to routinely include in the initial planning process the professional designers who have so successfully bridged the communications gap between business and technology to build our cities and develop our most successful products, from automobiles to iPads.

The typical business system development process brings just two groups of specialists to the table: business analysts and technologists. Members of these two groups speak two different languages. The resulting miscommunication would be comical if it didn’t so often lead to the construction of systems that are profoundly flawed.

In product design, the traditional approach to development is for representatives of business and technology to collaborate with designers at the outset and to repeatedly test products at every stage, usually by creating inexpensive prototypes such as drawings or models. This makes it possible to identify problems and find solutions before a product goes into production. In software development, it’s more common to invite designers to enter the process during the final stages of development or even after release, when alternatives are limited and solutions are costly.

Our business systems need to reflect a higher standard, a collaborative effort in which representatives of business and technology are joined at the earliest stage of ideation and development by designers who are trained to perform research, define needs, and visualize solutions.

Every spring, users of business software in the U.K. nominate candidates for the Software Satisfaction Awards, rating products according to their reliability, ease of use, functionality, and value. To honor business systems that reflect the highest standards of performance in the U.S., perhaps what we need is a Mercury Medal, to be named for the swift messenger who also promotes trade and commercial success—because any company that develops a better process for delivering business information deserves a medal.

Read more about the software development process.

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

Join senior executives from the energy, pharmaceutical, healthcare, and financial industries as well as leading professional services firms to debate the role of Design in business. Learn about the competitive edge Design affords successful companies and its impact on business transformation and the bottom line. Participants will hear how global corporations which have already implemented design thinking have achieved significant results.

Electronic Ink and Cass Business School will offer a lively debate moderated by David Rowan, Editor of the award-winning magazine WIRED. Join us afterwards for Q&A, drinks, and conversation. The panel members include:

• Dr. Sara Jones, City University London, RCUK Research Fellow Creativity Applied to Design and Engineering, School of Informatics

• Conrad Troy, Lead Partner IT Enabled Business Transformation at KPMG

• Dave Weller, Chief Enterprise Architect of Thomson Reuters, former CTO of Factiva

• Harold Hambrose, founder and CEO of Electronic Ink, a leading user-centric business systems design company, author of Wrench in the System

• Henry Dodds, Operations Director, Nomura International PLC

Successful organizations are starting to balance technological know-how and business acumen with a genuine commitment to Design. Thoughtful, intentional design is essential for the usability of an enterprise system and can drastically improve user adoption. With a fairly modest investment, existing business systems can often be made substantially more effective through user-friendly design. Companies that acknowledge and embrace a partnership between technology and design will be better equipped to meet the challenges of the future.