Process vs. Goal Orientation
When my wife asks me to do something, she first tells me where to go, then what to get, and finally what to do with it. For example, today she told me "In the bathroom, under the sink on my side, there are some disposable wipes. Could you clean off that stain on the landing?" I, of course, had already cleaned off that stain, but with paper towels from the kitchen.
This exchange points out one key difference in our thinking. She is a process-oriented thinker while I am a goal-oriented thinker.
Quite often, she will ask me to help her with software. It might be a program that she has never used before, like when she was learning Picasa (now she is a Picasa guru). Or it might be a program so complicated that it is new to her every time she uses it, like Word. In either case, she tells me what she wants done (the goal), and I figure out how to do it.
When I'm finished, she asks me to repeat the steps for her. After that, she can execute that same process over and over again.
Generally speaking, programmers are goal-oriented. We have to be. The program is a blank canvas. We have nothing to help guide us except the requirements. There are many ways to accomplish the goal, and no one way is the right way.
Many other people are process-oriented. A lot of these people use our software. So when we programmers write software for ourselves, we alienate a large subset of our potential users.
A programmer will generally create a program with many tools that can be combined in uncountable ways to achieve any goal. Examples of these kinds of programs are Word, AutoCAD, and Photoshop. These tend to be very powerful programs that take a long time to learn. And, with the exception of one member of this class, they tend to be designed for specific audiences. AutoCAD is for engineers. Photoshop is for artists. Engineers and artists, like programmers, have to be goal-oriented. Word is the exception that proves the rule: almost everybody uses Word, but they tend to use only the surface features. When they need more from the tool, they turn to someone who has spent some time to learn its nuances.
Process-oriented users need a different style of program. They don't want to see a bunch of tools, they want to be taken step-by-step through their work. Examples of these programs are Picasa, SketchUp, and Quicken. (Two of these, you’ll notice, have been acquired by Google. Hmmm...) These programs have fewer features, but those features are targeted to specific goals. The important thing to notice is that process-oriented people have goals, and they recognize those goals. They just focus their work on the process instead of the goal itself.
The software development team is responsible for identifying the audience for their program. If they are developing for goal-oriented users, they should create a set of small tools that can be combined in multiple ways, and leave the goal up to the user. If they are developing for process-oriented users, they should discover the users goals ahead of time and design a process for each one.