- Web development
- Software development
- Contact Jeff Dickey
Step 2: Application Software Evaluation and Designation
Just as a Formula One race car or an armored personnel carrier is not appropriate for daily commuting (but will get you across town in a pinch), few people actually use more than a tiny fraction of the features and capabilities of applications sucn as modern office-productivity applications. Some people (to go back to our word-processing example) regularly create highly technical documents with heavy use of footnotes, cross-references and the like. Most people, however, deal on a daily basis with relatively simple documents of no more than three to five pages. These users with less complex needs tend to soak up the bulk of training and support costs within the organization because the applications that they use to get their work done have many more features and much more complexity than they need. Imagine a driver whose needs would be met quite satisfactorily by a compact car, being expected to drive an "eighteen-wheeler" tractor-trailer rig to the corner grocer. Let's get him out from behind the wheel of something he's likely to be frustrated and/or dangerous in, and give him a nice, comfortable Nissan (or Saab or Ford) sedan. To bring it back to IT, let's take the user who just wants to read and write short memos and papers out of the extremely complex, feature-rich environment that is Microsoft Word 2007 for Windows, and put him in front of a simpler, more self-consistent and discoverable application that happens to be able to read and write the documents he's likely to share with his colleagues and contacts. Even if that new application happens to come from Microsoft.
Actually, there are several such applications freely or commercially available (just as there are several different Excel-file-compatible spreadsheets, good Web browsers, etc.). It may well be that many users will have one set of needs for most situations (e.g., simple memos) but will occasionally need a larger, or different, set of features (for the Big Project). This almost always proves easier to support in practice than a single, all-powerful application that is ridiculous overkill 90% of the time, and only moderately excessive for the remainder.
The basic metaphor used to describe and track the user's needs is that of "user stories", borrowed from Agile software development (which borrowed it from several variations of the Lean manufacturing discipline). Each of these stories, quoting Wikipedia, is a software system requirement formulated as one or two sentences in the everyday or business language of the user. Since what we're trying to accomplish here is to enable the user to perform his or her work more effectively, with fewer system-related difficulties or failures, expressing the actions involved in that work in business/user terms is absolutelyessential in determining whether the end process actually works properly.
This will quite often involve a good deal of original research by or with the users in question. Many organizations have only a very hazy view of what their people actually do beyond "Using the word processor, create a weekly status report." Why? How is that information used, collated and acted upon? What would make the information more valuable/accessible/relevant to the people who are receiving these reports? By concerning ourselves with the "why" at least as much as with the "what" and "how", our client is able to gain more effective use of organizational as well as technical resources. Failing to look at the implications and effects of the user's work is in fact as great an error as miscategorizing the work itself.
After each of the user's needs have been mapped to candidate applications, generally the simplest for each that will do the job effectively, it's on to the next step: application software transition.