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 rapid migration of business systems from desktops to iPads and other tablet technologies conspicuously illustrates the axiom by American journalist H. L. Mencken that “for every complex problem there’s a solution that’s simple, obvious, and wrong.”

The problem is clear: How to make business systems fully mobile as well as convenient, affordable, and effective. But the solution isn’t as simple as transferring basic business applications to sexy new platforms. Not that there’s anything fundamentally wrong with most tablets—they’re just the messengers, faithfully transmitting poorly resolved applications that are counterintuitive and counterproductive.

Everyone knows that our brilliantly engineered business applications are far from perfect at the point where pixels meet people. Although you may be able to seamlessly integrate iPads with your company’s enterprise technologies, you’ll also be seamlessly integrating all the bugs and eccentricities of your systems into every single iPad. And any problems that people currently experience with an application can be significantly compounded by a new context.

So before you deploy any application into the field, consider the context—especially the human context. Find out what aspects of your systems routinely slow people down. What workarounds are being used to circumvent idiosyncrasies in certain applications? Do you see handmade job aids such as Post-its attached to desktop monitors? Investigate the volume of calls routinely made to your IT department or your Help desk. When people run into trouble with an application in the field (and they will), how will they find a solution? Your Help desk may be expecting ten calls a day, but it might turn out to be ten a minute.

Quirks that may be somewhat entertaining at the office may bring work to a standstill in the field. If you’re running a complex system developed by SAP, you may occasionally be confronted by a German error message (something so commonplace that it’s even entered the popular culture as the name of an experimental folk band, German Error Message). Information in English may not be clear, either: If workers want to look up the company’s vacation policy, can they find it under “vacation,” or do they need to search for “holiday”? It may be amusing when a screen view advises, Bitte geben Sie den Wert in der Form -2,733.34 ein. But when workers are stopped in their tracks because they can’t find the information they need—and help isn’t immediately available—it’s not funny.

Even for workers who are computer literate, the process of adapting to a new device in a new physical environment can be daunting. Yet some companies are assigning iPads and other tablets to workers who have little or no prior experience with computers. For these companies, the challenge is huge: to provide tools that serve a business function in a form that people will want to use. Although some managers insist that people can be forced to master any tool “or else,” the consequences of foisting a new tool upon a workforce without making an attempt to match the tool to the people who will use it can be significant in terms of lost productivity and turnover. Unless a tool is easy to use, people will resist it, and the rate of adoption will directly correlate with the cost of training.

The best investment is always in people, and a careful consideration of the human context of business systems—the words that people use to refer to everyday processes and policies, the sequences in which they perform certain tasks, and their expectations in terms of how the systems they use will behave—can yield big rewards in productivity. Mobile computing can be an advantage, but it’s important to understand completely what this context affords by knowing the potential limitations and fully exploiting the opportunities.  The first step is to find out how effective your systems really are in meeting the needs of the men and women who use them. You will also need to see first-hand what mobility genuinely means to this audience.

Only when you’ve identified system trouble spots and understood mobility in this user community’s context through direct observation can you find ways to bridge the communications gap between the business requirements and the human requirements. You’ll probably find that what’s most needed is a modest investment in reconfiguring systems in order to clarify language, reduce visual clutter, simplify toolbars, and reorder certain sequences. Then it’s a simple matter to seamlessly integrate these solutions into a new platform—and put them to work in the palm of your hand.

Learn about one way to reconfigure a business system without incurring the costs and risks of customization.

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.

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.