As seen on Computerweekly.com.

Many executives reason that their employees can learn to operate almost any business system, given the right training, and that if technologists can deliver sophisticated electronic tools that automate routine tasks, the least people can do is to put up with a few quirks in the way the software performs. Some employers expect workers to recognize that it is in their best interest to adapt to whatever challenges their tools present to them: After all, what choice do they have?

According to this philosophy, most of the problems that people have with software can be explained in terms of a learning curve, and as workers become more familiar with the software they use, their proficiency will improve. When this doesn’t happen – when significant numbers of workers have trouble using a business system, and familiarity breeds only frustration, resentment, and hostility – the common assumption is that more training is needed. All too often, the result is low productivity and an endless cycle of training as experienced workers are replaced by new hires.

It’s true that some people manage to adapt surprisingly well to even the most counterintuitive software, and it’s not unusual for some to become experts in navigating the maze on their desktops. But asking people to use inferior tools, or placing the right tools in the wrong hands, can have unintended consequences.

When we find ourselves facing a barrier that seems insurmountable, we look for ways to work around it. When software raises an obstacle, business executives, brokers, lawyers, physicians, and other professionals often work around the problem by delegating the task. Those who can’t delegate must find other alternatives.

Business software that’s easy to use lowers the cost of training and raises productivity. Sales agents who can do their jobs without assistance feel less stress and provide better customer service than agents who need to put their prospects on hold and interrupt their co-workers to ask for help. Software that’s intuitive also promotes innovation by creating opportunities to think creatively about new ways of gathering, organizing, and using information. But when the act of using software is a struggle, most people simply leave it to someone else to rise to the challenge, master the system.

Some idealists believe that all software should be so easy to use that there would be no need for manuals or training sessions. That’s a realistic goal for software that runs an ATM, a search service, or a website. However, we accept that it takes training and practice to drive a car and to operate most other complex machines, so even though manufacturers may claim that their software is easy to use, it’s reasonable to expect that some training will be needed for most new technology. The question is, how much training-and how often? More importantly, what is actually being trained, and what will it cost?

Training is a major portion of the cost of implementing most business software.

As a rule of thumb, the process of implementation usually costs at least as much as building, buying, or licensing the software – sometimes twice as much. For software with a price tag of seven figures or more, the training costs can be staggering.

Why does it take so long to learn to use so much of our business software?

If the people who use these products are the source of the problem, then there’s little that businesses can do to avoid making continuous investments in training. But if the problem is caused by a failure of communication between the partnership of business and technology and their intended audience, there’s a better solution.

Architects who specialize in commercial buildings are expected to organize the interior and exterior spaces of their buildings in logical ways and to observe other conventions that will enhance the tenants’ experience of occupying these spaces, and long before they begin to write specifications they meet with their clients to define their needs and learn about their preferences

The best business software is built through a collaborative process that parallels the architectural process, both in its methods and in its division of responsibilities. The most effective development teams include not only the client (stakeholders and subject-matter experts from the business side) and the builder (software developers), but also designers who can interpret, balance, and communicate to technologists the business requirements as well as the needs of the people who will use the product.

The designer’s job is to find out what the client wants, identify what the client genuinely needs, and to design the physical form of the product-and in doing so, to also design the experience of using it. Accomplishing this requires close communication between business, design, and technology, with visual prototypes and frequent reviews. Most software, however, is developed without Designers or their methods, with Business Analysts and programmers inappropriately assuming this role and its responsibilities.

In a perfect world, during the design phase of software development the client will be shown prototypes for evaluation and testing at regular intervals so that adjustments can be made to match the technical performance of the software to the work processes of the company and the needs of the people who use it. In the real world, deadline pressures compress the review process, and despite the best intentions of stakeholders, life gets in the way: Travel schedules, sales conferences, and other priorities intervene. Even worse, the development process may be organized in a way that excludes some of the people who need to be at the table. Those most likely to be left out of the process of developing software are the people who will use it.

Unless the business requirements and the technical requirements are informed by human considerations, the finished product can roll off the assembly line, a piece of solid technology that fully complies with every business and technical requirement, before its fundamental deficiencies are discovered and its full potential can be explored

• This article is an extract from A Wrench in the System by Harold Hambrose, CEO and founder of Electronic Ink. ISBN: 978-0-470-41343-2

As seen on PharmExec.com.

With the UK NHS under pressure to justify expenditure and the national economy stretched tight, there is no more room for error or delay in its National Programme for IT (NPfIT). An electronic medical record (EMR) system for the NHS Ñ or for any healthcare system — requires the flexibility to gather and visualize data, while supporting tasks within many different medical settings and physician specialties. Moreover, systems must accommodate the hectic pace of real clinical settings and the diverse ways medical staff work with patients, record data, delegate tasks and review results. Other sectors of the business community have been receptive to the new ways technology can transform data into usable information. However, the healthcare industry remains fixated on traditional ways of displaying data.

By bringing qualified designers to the development process, effective EMR systems can be developed. The design process provides business with an opportunity to explore alternatives, and invent and refine concepts in order to first figure out exactly what they need, and then define a form that meets that need most effectively. 

For example, for decades a pen-and-pencil, paper-based record tracked the patient’s treatment and served as the main conduit of communication among a team of caregivers during the patient’s hospital stay. Within the patient record, is the nursing flow sheet, where nurses record their observations and measurements of the patient’s state and record interventions and assessments, organized according to time and date. No one else providing care to the patient writes on this page.

Computerizations of the nursing flow sheet usually have a nurse leading the product design process by translating the paper-based world to on-screen requirements for data display and system functionality — a computerization of the current world. Whenever there is a question as to the correctness of modelling the new world according to such a strict translation of the old, nerves become raw and concerns of user adoption and acceptance drown out any challenges to this approach: ”Nurses understand the flow sheet, so that’s what we need to deliver.”

Dr F. Philip Robin is a practicing lawyer who also is a physician with a long and successful record of winning medical-malpractice suits. According to Dr Robin, the very design of the patient chart is at the root of his successful record of litigation. He could point to almost any patient chart and identify where communication broke down and how the patient’s treatment had run amuck. He pointed to the flow sheet as a primary culprit. 

Dr Robin describes the structure of the patient chart as a collection of separate and distinct narratives. What we understand about the patient’s care will depend upon what narrative we choose to follow and when. Physicians create and monitor a narrative that is separate from those of the nurses, the radiologists, and the laboratory technicians. One hospital administrator who is also a physician explained his concern that nursing notes are never actually read by others during the patient’s treatment. Clearly, designing another computerized flow sheet will hardly improve this situation.

Experts have been telling the technology industry for years that better outcomes will result when end users participate in the design of business systems. For the most part, this has happened through standard techniques such as surveys, questionnaires, focus groups and working sessions that ask users to describe what they do and how they believe things should work. Unfortunately, these inputs are too often taken as gospel and used to define a set of design criteria that are not the best guidelines for constructing a system. These audiences are just too close to existing tools and methods and do not have the skills to design a software system, even when that system’s sole purpose is to support their work.

If people can’t tell you what they need, how can you find out? They can show you. When done well, the design process provides the opportunity for innovation that can invigorate a business. The results can bring satisfaction to all concerned.

 As seen on smartplanet.com

According to Harold Hambrose, founder and CEO of the design consultancy Electronic Ink, the software you use may be causing delays, squelching innovation, lowering profits, and…if your business is health care, potentially endangering lives?

How? According to Hambrose’s new book “Wrench in the System” software that doesn’t communication clearly with the people who use it is a major problem.

Not just wreaking havoc but also costing business billions of dollars in waste. Hambrose, who helped design the interface for IBM’s OS/2 and has consulted for Fortune 500 companies such as British Petroleum, Comcast, McDonald’s and Research in Motion, is no stranger to design challenges.

So…with so much riding on the software in our daily lives I’ve asked Harold to spend some time with us.

Harold, How do we know when the software we are counting on us is actually hurting us?

We know it when the software makes a task so complicated that we avoid it; when it discourages good work and innovation, rather than encouraging it; when it puts us at risk. There are plenty of examples. The Northwest Airline pilots – two smart guys struggling with shift-scheduling software. Obviously, their timing was terrible – maybe criminal, but you have to wonder, “What was that front end like?”

 And with the increasing use of software applications in hospitals and insurance companies, every one of us now has a life-or-death stake in whether or not our medical records and other hospital technology can stand up to the realities of the emergency room, the operating room, and our local pharmacies.

How can we correct the problems? Any low cost solutions?

We correct software usability issues through a researched-based, user-centered design process led by trained designers. These aren’t just people with good taste and a sense of organization; they’re professionals who have made it their life’s work to understand how people interact with technology. They’re experienced at leading an organization through cycles of research, ideation, modeling, testing, and refinement to arrive at the best solution – a solution that is collaborative, fast and affordable.

We can usually find a design solution that will save our clients money and work within their budgets. We can jump in anywhere in the design process. Ideally, we like to be involved from the very beginning asking questions about the things that developers and stakeholders might not be thinking about yet. But improvements post launch are still incredibly effective. A professionally designed UI and information architecture can make a frustrating system much more user-friendly.

How can we reduce our training expenses?

By creating software that’s easier to use – that’s intuitive. You want to create software that mimics the way people work. They shouldn’t need a manual or have to memorize a set of instructions, and they shouldn’t have to reconceptualize how they do their job or learn new terms for the tasks they do every day.

Thoughtfully designed information architecture reduces training because it doesn’t ask people to reconceptualize their work, rename their activities, or learn a lot of configuration or workarounds. It’s simple and intuitive. That alone reduces training costs significantly.

What are some tips for the manager thinking about using software as a solution to a business problem?

Ignore your instinct to throw more technology and training at underperforming software. Take a step back and assess the situation. Does your software do what your users need it to do? Does it invite use or discourage it? If it discourages use, don’t assume you have to live with the system or buy a whole new one. Instead, realize that there are people out there – my company and lots of others too – who can come in, really listen to you and your users, and make what you have work.

Where’s this all going? How do we get smarter software and how does the social web fit in to innovation?

I believe software development should follow traditional product development. In traditional product development, you have to prove that a design is going to work before you expect a customer to buy it. Also in product design, the user is always at the forefront of the innovator’s mind. So it should be with software.

Smart software is software that reflects how we work and play. At the risk of sounding glib, I think we need as many anthropologists and artists involved in the software development process as there are data analysts and software engineers. Traditionally, software development happened in a vacuum, which invites narrow thinking and trouble.

People are using social software in all kinds of places: they want flexibility, accuracy, security – and even a little bit of fun. Obviously, social networking has opened the conversation to all types of people, which will open the door to new ideas. The challenge now is how to process all the diverse ideas and innovations to their best effect.

Thanks Harold!

by Vince Thompson

I’d like to share my response to comments on my interview with CIO.com:

Thank you for your passionate responses to this subject. Upon reflection, I probably started off my interview painting with too broad a brush. The definition of a business analyst deserves more discussion and analysis than I offered. Maybe I can clarify my position and we can continue the conversation. I take your point – “business analyst” means different things to different people, and on top of that, it’s a continually evolving role.

In fact, much of what’s been said in the CIO.com blog captures my sense of the business analyst pretty accurately. The business analyst brings considerable skill, talent and creativity to the development of an application on behalf of the business stakeholders—not on behalf of the user.

For example, the entry dated April 28, 2008, titled What Do Business Analysts Actually Do for Software Implementation Projects, runs through a list that resonates with my own experience with BAs:  they “interpret business needs” help “spell out project details and requirements,” and “represent project stakeholders throughout the process.”  The BA’s role can continue right up through user acceptance testing – but don’t be deceived: UAT is not usability testing. It does not observe whether or not the application works easily, intuitively or well for end users in the workplace.

More recently, the CIO.com blog noted that the business analyst role is evolving, (Business Analysts: Role Changes Require New Skill Sets). This evolving role, according to a recent Forrester survey and analysis, includes working within different development methods, like Agile, but again, it doesn’t suggest any growth that would consider the end user to any greater degree.

In my experience, business analysts do not focus on the needs and goals of an end user – that person who is going to have to use the technology to get his or her job done in a setting that has its own constraints and demands, be it the factory floor, an emergency room, or the trading floor of the New York Stock Exchange.

That is why I say that a business analyst cannot take the place of a designer. Think of design as something that includes but is much more than aesthetics. Designers are trained to investigate, understand, and translate to both business stakeholders and developers the language, culture, and context into which the proposed tool is going to be injected. What are the user’s expectations? What pressures do they operate under and what expectations must they meet? What are the limitations under which this tool is going to have to operate?

Listen to Harold’s interview with Live, with The Vic McCarty Show on WMKT -AM 1270 AM Charlevoix, MI

Listen to Harold’s interview with Live, with Business for Breakfast on KFNN-AM Phoenix, Arizona.

Listen to Harold’s interview with Bill Kearney on Live, with Financial Spectrum WKXL-AM Concord, NH

Listen to Harold’s radio interview on the Kathryn Zox Show on WMET 1160 AM Gaithersburg, MD.

Part 1:

Part 2:

Software design expert Harold Hambrose’s new book, “Wrench in the System,” says poorly designed software is costing U.S. business $60 billion annually. Too many apps, he says, are still “pig ugly,” confounding users, instead of helping them. Here’s his advice for getting out of the rut.

By Thomas Wailgum / CIO Magazine

Thu, August 13, 2009 — CIO — Wondering why your company’s staffers are using only a fraction of the software features and functionality that your bounteous enterprise software offers?

Harold Hambrose can give you an answer. In fact, Hambrose, founder of Electronic Ink, a consultancy specializing in designing and developing business systems, wrote a book about what he claims is the $60 billion that U.S. businesses will waste this fiscal year on poorly designed software.

The new book, Wrench in the System (Wiley), takes a scathing look at business software development practices, especially the products of enterprise vendors. “Software manufacturers are generally confident that their products will succeed on the strength of their technology,” Hambrose writes. “But products that don’t appeal to their users can be self-defeating. Whenever software systems create obstacles—technical jargon, ambiguous messages, illogical sequences or visual clutter—the people who use these systems will respond in a variety of ways.” That typically includes undesired behaviors that users (and CIOs and applications managers) know all too well—frustrating and inefficient workarounds, complete disregard for business process, or abandonment of the application altogether.

Hambrose went to Carnegie Mellon University for graphic design and, later, contributed to the user interface for IBM’s OS/2 and the first computerized patient record for First Data, notes his bio. He founded Electronic Ink in 1990 and has since worked with British Petroleum, Comcast, McDonald’s, Research in Motion, among other Fortune 500 firms on software design issues.

In his book, Hambrose offers advice and explains low-cost development changes that can make a huge difference. CIO.com Senior Editor Thomas Wailgum recently talked with Hambrose about user frustrations, why most packaged vendors apps are poorly designed, and why he wrote the book.

“I wanted to be able to give a larger audience the tools to push back on IT vendors more effectively and perhaps give some power to people in trenches to stand up and say: ‘This is why this system sucks for me,’” Hambrose says. “I hope the book appeals to not only the CIOs out there, but to the doctors, nurses, stockbrokers and whoever else is wrestling with systems that have been put in their hands with the best intentions, but yet they’re still wrestling with them.”

CIO.com: What’s the biggest pushback you hear from potential customers or software vendors?

Harold Hambrose: In the larger ERP environments, the biggest pushback you hear is: “Oh, you’re a design team, and you’re going to propose we customize our SAP or Oracle system.” And that’s just not true. What we represent is a method to configure the system—prelaunch—that improves usability and adoption.

Another pushback I hear is: “I have business analysts around the table, so don’t they do what you folks do?” No. In fact, we want you to replace business analysts with designers. We know that you folks understand the business. What designers afford you to do is to model that in new ways and all those models allow you to change the way you’re thinking with this tool.

The last one is: “Can’t this all be taken care of with training and change management?” Our belief is: If you do this right, there’s no training involved. And there’s no change-management budget necessary.

CIO.com: When it comes to the discussion between application aesthetics versus usability, which one is more important?

Hambrose: I think the software industry is confused about usability and design because they are two separate things. The software industry has known about usability for a long time, definitely in my 20 years. They’ve built usability labs, and they’ve hired usability professionals. Those people have come from the world of ergonomics—measuring the effectiveness of a design in the hands of a human audience.

Usability is really a subset of design. Design is a verb. It says: You move through inventing something a certain way and one of the outcomes will be usability. Another outcome will be beauty. But the two things are interrelated.

[Design expert and author] Don Norman has made the case and said it one of his more recent books: “The beautiful things work better.” These software applications, when they’re pig ugly, they’re getting in the way.

CIO.com: What about the effect of cloud computing and software-as-a-service—delivering apps over the Web?

Hambrose: We don’t see the Web browser as anything different than, say, apps created in Visual Basic, or any other development environment. But I think once things appear in a Web browser, people think about them as websites, almost, and they know that when you’re designing a website, you really have to think about design.

The problem we see with that, though, is that a lot of websites are concerned with aesthetic or visual appeal. And so we’re seeing more attractive applications, but not necessarily more usable applications inside Web browsers. They’ve involved designers, but only from the point of view of aesthetics. They’ve not changed the process by which they put these things together.

With the Web browser, the notion of online banking, and some of the more sophisticated transactions the masses are performing online, has those same individuals coming to work everyday, and saying, “Well wait a minute: I manage a Facebook page and I keep my family’s books, why is it so hard for me to use this billing application inside my company?”

CIO.com: Are there any enterprise software vendors—not named Apple—that are doing a good job with software design?

Hambrose: We get to see a lot of systems driving business. And we do see some pretty fanatic software driving the larger banks. A lot of trading applications in financial services industry. But these are typically one-off applications.

But for applications out-of-the-box, I’m hard-pressed to name a really well-designed piece of software out there. That sounds terrible!

CIO.com: OK. So, Apple. Are you a fan of Apple and impressed with what they’ve done as a model for design success?

Hambrose: They are an excellent product design company. There’s not doubt that their monitors and keyboards are just beautiful objects. However, when it comes to software, their operating system and iTunes, they are prettier [than competitors], but I don’t think they represent significant design difference than a Windows-based environment.

When they moved into the iPod space and started to create those products, I think they changed as a company. They played to their strengths. The iPhone is a beautiful product: The software and hardware are so closely woven together that it really becomes a single object.

But go back to the PC space: The software and hardware are so dramatically different from one another. Apple’s software isn’t nearly as elegant as their hardware. Their OS, their desktop, is plagued by the same design flaws as the Windows desktop. I don’t understand why they’re not applying their successful product design practices to the design of their software.

CIO.com: In corporate circles, the rise of the dashboard has been pretty significant. Business leaders and managers want dashboards, though the results have been mixed. But it’s a tough position for CIOs and their development teams, trying to give these businesspeople what they want.

Hambrose: It’s the same problem, different day: dashboards, CRM systems, or whatever is coming down the pike this month. And the dashboard suffers from same problem. The consumers of the technology—the business side of the house—don’t know how to ask for what they need. They ask for what they want. That’s different than understanding the need. The tech group on the other side of the house, they’re ready to buy or build what’s asked for.

So what the book argues for is that what is missing from that conversation is design. You would not ask the driver of the car to specify what the next Mercedes-Benz is going to be, because drivers, although they use the tool—that product—they don’t know what could hurt them. They don’t how to ask for innovation. They can only describe their experience by what they know. Car companies employ these huge design teams to listen to those requests but do lots of other things they need to do and then employ processes to make sure whatever we’re inventing is right before they go to the assembly line.

Instead, we’ve got technologists saying: “Hey, guess what? Now that we’ve got all the companies data in one bucket, we can pull it up and show it to you any way we like.” And the executives are saying: “Oh, yes, please, let’s have a dashboard to see that.” Then they shoot it up to the desktop without an understanding of what these people genuinely need. We see a lot of dashboard technology that is just an abysmal failure on corporate desktops, and it’s not because it’s bad technology, but because no one has a means of figuring out precisely what these people need and how they needed it presented.

CIO.com: You say that you sometimes accompany your clients during product reviews and vendor demos. How does that sit with vendor sales and account management people?

Hambrose: They hate it. They reel. On more than one occasion, they have asked to have us removed. Because the nature of what they’re doing: It’s snake-oil sales. They come in with the application customized to a workflow that the client has given them. And they come in and magically click through this workflow, and typically the users do what most human beings do in front of software: They say, “I guess I’ll figure that out eventually.” Or “I’m not a big computer user.” Or “I guess training will make that clear to me.”

We sit there and say: “No. You people know this business. I’ve watched doctors at product demos scratch their heads and say, “Well, I’m not quite sure how they did that, but I guess I’ll figure it out later.” You’re one of the most highly trained people in our society, and they just confused you! That’s ridiculous. You should stand up and throw a tomato at the guy.

When we’re there, we prompt them: Ask them the questions you’re afraid to ask. Ask them why they call it that and not something else.

CIO.com: For our readers, what would be one thing to think about when, say, the requirements process starts up for a new BI application?

Hambrose: I’d like them to recognize the opportunity that is ahead of them: They are moving into a product design process. And people have done this before successfully in other industries, but within software development, they have typically done a poor job of it.

So first thing: Recognize what you are up to. You are about to design a tool; you’re probably not qualified to do it; and the people around the table are probably not qualified to do it. Actually, the people around the table are probably only qualified to make computers do things.

You’re faced with the same opportunity that someone about to design a skyscraper is faced with. This could end up being a signature building on the skyline of the city, or it could kill people as it falls to the ground. I really want the former to happen rather than the latter. Appreciate that this is a design event; we can make computers do anything at this point. The biggest challenge is making the computers do precisely the right thing for you business as well as your workers.

As published in CIO Magazine

Listen to Harold’s interview with Peter Solomon from WIP 610 AM in Philadelphia, PA.