Charles B. Kreitzberg, Ph.D.
President
Cognetics Corporation

Everyone struggles with software. Information Technology professionals struggle to understand technology which constantly changes. Users struggle to install, learn and use software products. Technical management struggles to maintain quality in the face of unrealistic budgets and deadlines. And business management struggles to control and understand the return on the 200 billion annual investments it is making in information technology.

Some of this struggle results from the inherent complexity of the technology, and may always be with us. But some of the struggle is unnecessary and can be reduced by re-thinking the way in which software is developed and by incorporating user-centered design into the software development process.

The software struggle is placing stress on IT departments and making it difficult to demonstrate the value of their activities and ideas. It is harming user satisfaction. And because it is difficult to create optimal business solutions in the context of confusion, the quality of software suffers.

It's time to end the software struggle.

The Software Paradox

It's a paradox. Computer technology, which has profoundly and fundamentally changed the way people work and redefined the structure of the corporation, is increasingly being seen as having failed to deliver on its promise of improved productivity. Why has this happened? Some of the problem is simply due to the magnitude of the change. In the brief 14 years since IBM introduced its first PC, we have completely restructured the relationship between information technology and the corporation. From a controlled, centralized environment in which information technology departments managed hardware and software, the technology has diffused throughout the entire corporation. IT departments serve many more users, with needs quite different from the those of the mainframe era.

But there is a problem. Software is not as usable or as well integrated into the work process as it should be, And this failure is reducing productivity and customer acceptance of software products.

Much has been made of Government figures which suggest that information technology has not yielded the expected return on investment. While investment in information technology has increased 10,000 times, the productivity of white collar workers in the service sector has declined during the entire micro-computer revolution. An analysis of IT budgets from 138 big US firms between 1988 and 1994 indicated that a 67.4% gain in IT budgets increased much more rapidly than revenue, which was 29.6%., and profit, which was 39.7%. According to Computerworld. these differences reflect unfavorably on the contributions of IT.

These are disturbing statistics that IT professionals must take seriously. While there are clear examples in which information technology has paid off, in this era of downsizing, technology has become a target. Budgets and schedules have been tightened; at times the demands on IT have become unreasonable. Because of this, life in the information services department is not fun. A recent survey by Computerworld, reported that only 36% of CIO's are very satisfied with their job and only 22% percent of systems engineers report real job satisfaction.

Just a year ago, an article in Forbes stated

Though it has been well documented by the likes of Stephen Roach of Morgan Stanley, not much has been done about it. Lots of dollars spent on productivity tools, and no productivity gains to show for it. It's time for heads to roll…. Fire your MIS director-the whole department--and immediately start over. Rare is the MIS director financially motivated by productivity….The concept of information technology as a tool to increase the output of your company remains just a concept. What a shame.

A recent commentary in Fortune Magazine stated bluntly, if inelegantly,

The trouble with software is… it sucks. That's not a nice thing to say...but it is a fundamental truth. Software customers--you, me, CIO's of multibillion-dollar companies,...have learned to live with mediocre software. We do not count on software to be intuitively easy to understand or to work consistently. Instead, we make do.

These are strong words and I am not suggesting that this bombastic journalism be taken entirely at face value. But as information technology professionals we should be concerned. Research supports the contention that there are serious problems in current software products. Professor Thomas Landauer of the University of Colorado, (former head of Cognitive Research for Bellcore) conducted an exhaustive review of software research and found that the average software program has 40 design flaws that impair employees ability to use it . The cost in lost productivity? Up to 720%.

The problem is not technical, it's organizational. It occurs because the methods most organizations use to develop software are rooted in a technical culture which evolved in an era of expensive, centralized mainframes. These remnants of traditional IT culture are not well-suited to the current environment of distributed, interconnected, personal computers and discretionary users. By fostering new vision about the role of software and the process of design, the problem can be solved.

Why We are Having this Problem

The core of the problem is that we do not do a good job of designing the front-end of software. As a result, the software we produce is difficult and frustrating to use. Software does not always mesh seamlessly with the business process it is supposed to assist. Technical staff, both software engineers and managers, are often unaware of the seriousness and importance of this issue.

The reason that technical staff underestimates the need for software usability is that they are individuals who have a deep personal interest in information technology. The struggle to master technology is part of the challenge they willingly undertake. And if it is not always fun, it is at least, satisfying. Technical staff members do not relate to the non-technical users' desire to avoid involvement with the technology and they underestimate how confused the user really is.

As a result, programmers are generally not good at designing the user interface. I am not talking about technical design here (the bits and bytes) but business design. The failure is in fitting software to the business process and the user's needs and skills. Yet although programmers are not well-suited for it, traditionally, we task them with analyzing the user's needs and designing a software product's look and navigation.

Before the personal computer, IT departments were responsible for operating computers and delivering results to their clients. Since the people who set up and ran the software were internal, a technicality-oriented interface was appropriate. Within the information technology organization, everyone spoke the same language. Today, the end user maintains and operates the technology. These users do not speak the same language as programmers and they do not share the same level of understanding of technology. Therefore we must build a different type of user interface than in the past.

The advent of GUI interfaces has helped considerably, but by itself is not enough. It still requires too much effort for non-technical users to learn and use software. And since the usability of software tools directly affects the work process, we are losing productivity.

To solve the problem, we need to change the way that software is developed so that the end product is better designed. We must integrate user-centered design into the systems analysis process. And we must demand the same of our vendors.

The first reaction of many IT executives to the suggestion that user-centered design be incorporated into the software development process, is to express concern about the time element. With increasingly tight time schedules and budgets, this is a serious concern. The good news, is that introducing user-centered design reduces both time and cost. It is well-known that time spent on technical design and specifications pays-off in software development. This is equally true for front-end design. Research suggests that attention to user-centered design can cut development time by 30%-50%. I suspect that these numbers are optimistic but even if you don't achieve this level of savings, you will experience significant reduction in development time.

The savings in development time and costs comes from avoiding the need to re-think portions of the project half-way through the development cycle. These often occur because non-technical users fail to understand the implications of what they are agreeing to. It is not until they see early stages of the product that they voice their concerns. By designing and prototyping early, this problem is eliminated. Incorporating user-centered design into the software development process will allow the development process runs far more efficiently when the design has been nailed down. It's the difference between driving with a good map compared to finding your way with mediocre directions. Precision pays.

Structuring Software Development

Software development efforts should be divided into three phases:

1. a design phase in which design specialists work with users to develop a rapid prototype of the product. The prototype is used both to make certain that the users understand what they will get and as specification for the programmers.
2. a build phase in which the technical design is completed and the product built and tested.
3. A roll-out phase in which the product is introduced to the user community with a great deal of support.

Many of the problems in software design and development have their roots in organizational traditions that began when computers were far different from today's technology. Management which mandates good design and concern for the users will reap significant benefits in productivity and profit.

Outsourcing and Third Party Vendors

Many IT departments, dissatisfied with the cost/performance of their staff, are looking at alternatives, including outsourcing and purchasing product from third party vendors.

Outsourcing

Outsourcing may be a cost-effective alternative to maintaining in-house staff. It may not, however, increase ease of use or the software's fit to the business process. There is little reason to assume that the front-end design skills of vendors will be superior, and outsourcing brings in technical staff who are not familiar with your organization's business process. Because of this, the initial phases of development - needs analysis through completion of the prototype - should be conducted in-house or with consultants working closely with staff. There should always be technical representation on the design team to evaluate the implications of various design decisions on performance and development cost. A clear design can also help keep vendors cost-conscious since it allows you to ask more than one vendor to bid on the programming.

Purchasing Software

Another solution that is being used is to purchase of software from third party vendors. As with outsourcing, this can be a good decision. But care must be taken with the design of the user interface.

Third party software can be cost-effective and reliable. However, because the vendor needs to sell to a wide market, the interfaces tend to be generic and overly complex. For an example just look at "standard" office software such as Microsoft Word. The first screen has over 70 unlabeled icons and 110 menu items. Many of the features are superfluous to most users. In addition, when several third party programs are cobbled together, there may be inconsistencies in the design.

The best situation is to make certain that third party programs have an applications programming interface (API) or other method of creating a custom interface and seamlessly integrating with other software. Often a custom interface can be inexpensively developed in Visual Basic or a similar rapid development tool, providing the strategic advantages of customization and the cost advantages of purchase.

Keys to Success

The benefits of mandating user-centered design are significant; the costs are actually less than traditional development strategies. But do not assume that usability, like peanut butter, can be spread on existing structure. User-centered design must become a core value and core competence of your department. Nurture talent when you find it. User-centered design skills take both time and talent to develop.

The points that follow are the ones which I consider central to successfully accomplishing this goal:

1. Before you allow software to be developed, outsourced or acquired, make certain that a clear product concept and business objectives have been developed. These elements should be developed formally, carefully documented and circulated for review and revision. While this may seem obvious, it is often overlooked or performed haphazardly. Lack of a clear, agreed-upon product concept produces conflict in the development cycle, wastes money, extends development time and damages the quality of the product.
   
   
2. Because time schedules are always tight, begin the user-centered design process as early as possible. The best time is during the initial consideration of the project, while the software concept is being considered, Develop the initial product concept, business objectives and a few prototype screens as part of the funding process. An early start not only avoids conflict with the programming schedule but it allows for a "go - no go" decision after the design is complete. Think of the prototype as a model which is presented to the client for final approval before the major expense of programming is initiated.
   
   
3. Separate the user design process from the technical design process. Employ high quality user-centered design experts to develop the front end. Typical software development projects mix the two different types of design and user design is performed in a haphazard fashion. User-centered design can be accomplished fast; and if it is started early will have major benefits throughout the project.
   
   
4. Prototype during the needs analysis phase. Non-technical users cannot visualize a software product and need concrete screens to look at. Use a rapid prototyping tool and have prototypes reviewed for usability flaws by usability experts and for business process flaws by the users. Make certain that evaluations of the design are performed frequently. The least expensive and most productive evaluation technique is expert review. Empirical testing in a usability lab is always useful and should be performed when you are developing a consumer product or a mission-critical application.
   
   
5. Make certain that users are satisfied with the design before coding begins. Just as an architect shows a customer a model of the house before construction begins, the software customer should be shown a reasonably well-developed prototype before coding begins.
   
   
6. To the extent possible, negotiate a reasonable development schedule. Do not allow time pressure to become an excuse for skipping the user design and evaluation stage. Properly performed, attention to user-centered design will reduce the time to delivery as well as development cost.
   
   
7. Do not allow the business client to be vague about who is their product manager. Make certain that you have a product manager on the business side identified as the client. This individual needs to be actively involved in the project and should have a good feel for quality interactive design. The product manager should identify two or three experienced, concerned users who will actively consult with the design team. The client should be prepared to make decisions about features and must be held accountable for delays on the business side which affect the schedule.
   
   
8. Make software usability and its seamless fit to business process, a mandate. Help technical staff understand that they have a different relationship with technology than the average user. Some technical staff tend to regard non-technical users with disdain. Look carefully for this because perceived arrogance will make it difficult for users and technical staff to relate. Make it clear that customer satisfaction is the major criterion on which success will be evaluated.
   
   
9. When you are purchasing software or including third-party components in your products pay careful attention to the quality and appropriateness of the interface. Generalized software tends to have complex interfaces because it must please a wide market. Software components which allow the purchaser to develop a customized interface should be favored.
   
   
10. Begin the involvement of user support, documentation and training, at the very start of the project. Make certain that all technical designers and writers have a profound knowledge of the product and the business environment in which it will operate. Emphasize to your staff that the attitude with which users receive the product will depend on their ability to install and learn it with a minimum of hassle. Make it clear that you value and expect high quality support material.

Conclusion

There is a real opportunity to improve the quality of software development efforts. Following through on this opportunity will reduce the struggle, improve productivity, reduce costs and vastly increase customer satisfaction. Because realizing this opportunity requires that people re-think their perceptions and ways of working, it will require thought and commitment. However, the results will more than repay the effort.