The Needs of the Users

Back in the old days of computers, there were no users. Who needed users? The only ones manly enough to approach the hallowed inner sanctum of the computing systems were the programmers. Only they touched the vacuum tubes, connected the cables, toggled the front panels, and fondled the punch cards that provided access to the heart of the machine. These programmers were tough, and their programs, tougher. "We don't need no stinking users" was their mantra.

Then came the '80s, with its Greatest American Hero-inspired attitude and its personal "personal" computers. Now there were users everywhere. They were like the Blob, only with fewer computing skills. But they were the masters because most programs were written for them. Programmers rarely used the programs they wrote; they were simply the interface between the user and the heart of the computer. Programmers provided the element of control needed by both the computer and the users. In fact, that is a programmer's job: to provide highly controlled access to the computer and the data it contains.

Users have a lot of needs, most of which can't be met by a computer. But for those that can, the needs come in five parts: data and information, process, usability, commonality, and project-specific needs. The design process involves an examination of these needs and the subsequent massaging of those needs into a software product. By examining the current data and procedures, conducting user interviews, and performing other need-extraction methods, you gather the details you require to craft the right solution.

Data and Information

Your ability to provide convenient and specific access to the data and information required by the user is what makes you, the programmer, so loveable. Most users got along just fine before computers. They kept their information on 3-by-5 index cards, legal pads, scrolls of parchment, or in hermetically-sealed mayonnaise jars. But they had a reason to move to a computer-based storage medium: the convenience.

Data is the raw information stored by your program: names, numbers, images, or any other stand-alone values. Information is data in context: a customer record, an order, a slideshow. When you provide a quality program that moves data up to the level of information, you are providing the level of convenience the user needs to move from mayonnaise jars to silicon chips.

Process

When the user demands data back from the computer, you have three options.

1. Dump every single byte of data to the screen, printer, or disk, and let the user sort it out. Actually, this is the system that some users had before they started using a computer.

2. Protect the data from user access, insisting that the supplied password is invalid or expired, or that the data is unavailable. "Abort, Retry, or Fail" anyone? Actually, this is the system that some other users had before they started using a computer.

3. Present the data as information, in a format that is both usable and accessible.

Although the first two choices are indeed tempting, the third option is the best. And given the amount of data that your application will likely manage, you will have to dole out the interaction with it a bit at a time, and in an appropriate sequence. This is process.

Through the implementation of a valid process, you not only control the user's data, but also you control the orderly interaction with that data. Most users need to supply or retrieve only a small portion of their data at a time. But when they do, it will usually be in the context of some process. For instance, in an order-taking situation, the user (1) enters or confirms the customer's contact information, (2) enters or updates the order details, and (3) prints or electronically communicates the order information so that it can be fulfilled. Your application (surprise!) manages this three-step process.

Usability

If your program presents data and information to the user, and in a specific arrangement or order, but is difficult to use, your users will hate you. They will loathe you. They will spread mean stories about you, true or not. And when they appear in groups, their vehemence can get downright ugly. I heard this story about an Excel user's group . . . but perhaps it was just a rumor.

As a programmer, it is your job to make the computer, and the software that runs on it, as usable as possible. And while you may not be able to control many of the basic system features, you are the king when it comes to your own software.

The more ease and usability you design into your programs, the happier your users will be. But I must warn you, ease-of-use for the user always means more work for the developer. Always. It's one of those unfair laws of the universe, and there is no way around it. But sometimes we tryto the user's peril.

Many, many years ago, I wrote some programs to demonstrate a hot new version of BASIC that ran on the Motorola 6809 processor. This release could handle programs that were twice the size of the previous version: a whopping 32Kb of source code. I was charged with testing the system, writing "big" programs that would show off the new functionality. I set to work in a fever of activity, but as my program approached about 27Kb, things started to happen, things that involved a shaking table and the smell of smoke. Seriously!

Since then, I have subconsciously feared the development of programs that I felt were too large for a particular system. So when I went to work on Visual Basic, I brought to my projects some of this apprehension. I tried to make my programs easy to use, but I also held back on the number of forms I would add to my projects. It wasn't an irrational fear; the original versions of Visual Basic did impose limits on code size, the number of unique variable names, and the maximum number of forms. I once hit the limit on the number of unique variable names, but I never came close on the number of forms. Still, I held back. I was sure that if I added too many forms, my users would require medical attention for smoke inhalation.

Unfortunately, my users were still suffering. I had put too much data on each form, to the point where it was no longer communicating information. My phone would ring constantly with the same user-sponsored question: "How do I use the fields on such-and-such a form?" Of course I always said, "Why don't you press the F1 key?" But it didn't make a bit of difference, because my online help pages were as long and complex as the forms they sought to simplify.

There did come a day when I escaped my phobia of form-laden applications. And on that day, I came up with the following rules for my own programs.

1. Don't put too much information on a single form. When in doubt, move some information to another form.

2. Only present the most necessary information and data to the user by default. Only show additional information if the user requests it.

3. Make it easy for the user to access the enhanced data, but allow the program to run properly without it.

4. Use text, graphics, and colors to the user's advantage.

5. Simplify the application so that user documentation becomes unnecessary.

6. Always provide user documentation. Make it simple enough so that calls to technical support become unnecessary.

These rules are generic enough to work with any type of application, and in-your-face enough to make them meaningful to us, the programmers, and to them, the users.

Commonality

Microsoft constantly touts innovation, and the ability to innovate has moved software products forward at a tremendous pace. But unfortunately, users can handle only so much innovation at a time. Consider the telephone. I inherited an old oak-boxed telephone from my grandparents (see Figure 3-1).

Figure 3-1. What a great phone!

It's a fun phone and so simple to use. When you want to make a call, you pick up the handset and crank the handle on the side of the unit for about three or four seconds. When the operator comes on the line, you tell her whom you wish to call. What could be simpler? What could be more user-friendly? What could be more expensive than an operator-assisted call? But it was simple, and everyone instinctively knew how to use it.

Today's phones use buttons instead of cranks. Most of the buttons are simple digits that let you directly dial a specific phone number. But there are other buttons as well: Mute, Redial, Pause, Flash, #, and *. I'm afraid to push the Flash button, and what's with the SND and CLR buttons on cell phones? The problem is not the buttons themselves, but that every phone has a different selection of buttons. They have lost the commonality that made crank phones easy to use. Sure they have many more features, but if the average person can't figure out how to use that functionality, what is the benefit?

Getting back to software: Even new and innovative programs must retain some commonality with the operating system, and with other installed programs. As you speak to users about their needs and think about the great advancements in software technology you will provide, don't forget about commonality. Don't forget about one of the user's core needs: the need to not be overwhelmed by new ways of doing tasks they thought they already could do. Users need consistency.

Project-Specific Needs

Beyond the general user needs required of every project, there are needs specific to each project. As an application designer or software architect, this is where you spend most of your time. If you have a lot of programming experience, you may be able to fulfill the other needs without ever meeting with a user. But the project-specific needs require an understanding of the tasks that the user needs to accomplish with the proposed application.

Once the users discover that you have a real interest in their needs, they may dump on you. They might start listing off a whole wish list of features, more features than they could ever use. That's okay. When they hear how much time it will take or how much it will cost to implement, they may back off of a few requests. The important thing is to document everything. Write down what the user asks for, combine it with a reasonable time schedule (always) and cost estimate (if required), and return it back to the key user for confirmation. If possible, have the user sign a document that says he agrees with the specific requirements listed in the document.

It is essential that there be agreement on the project design, at least for the initial phase or release. Because user's needs are so often a moving target, it is vital that an agreement on the project exist at some point in time. Later, after you have begun work on the project, the user will come to you, probably on a daily basis, and say, "Hey, that's not what I asked for." When that happens, point to the agreement and say, "Hey, yes it is." Changes will occur; I'll discuss how to handle those a little later in this chapter.