 |  |  |
| Main | |
Discarded Software #3: A Design To Love
Mountains of Discarded Software is an essay I wrote in 1999 posted here in four parts. This part tries to go "outside of the box" and challenge you with an unorthodox way of approaching design in an example budget coordination work-flow scenario.
When laying down a high-level design the foremost question should be: "what is the computer good at?" Anything that seems like a daunting task for the computer is suspect. For example, the difficulty of managing user roles and permissions is evidenced by the problems we have all had with getting access to something when we need it and have every reason to it, but the computer just doesn't seem to understand! If customers are successfully doing business with nothing more than the operating system's security, why jump immediately to a design that involves another layer of security issues?
Sometimes when we are discussing design our disagreements may just be a matter of opinion. So what I propose is an incremental design approach that we might be able to agree upon, and then in following this approach we are guided to make better choices. The approach is geared to make the smallest impact on the customer's current business processes. Its different from incremental deployment which attempts to design the whole puzzle and then implement it piece by piece. The goal is to identify something small that would enhance the way business is already done, to put our sights on one piece that is attainable and represents a tangible improvement for all users.
Take, for instance, "budget coordination" software, which refers to the exhibit/form based process used to bring together the big budget justification books submitted to congress. Department of Defense budget analysts share information by e-mailing or otherwise sending database files, Excel spreadsheets, Word documents, and PDFs around. There is no need to make these people learn a complicated new program, they are already participating in the electronic age. Enough of them already know how to copy these files, attach them to e-mails, ftp them, and work on them through different applications.
The budget coordination information is ultimately arranged in exhibits which are basically forms. Some information is entered in Excel or Word, or through dialogs in database programs. The standard software design approach is to take on the entire coordination system in one big client server application that requires all users to tie into a central server.
But here is my idea: develop a document type to compete with the file types currently in use (XLS, DOC, DBF, PDF) without trying to replace them wholesale at first. This alternative document type would be an exhibit document with a client application helping the user to enter the correct information better than is possible in Word and Excel and without the hassles of a database setup.
If you give the customer something that is immediately useful without a paradigm shift, they can start using it without any training or manuals or user ids. The customers can continue to maintain and pass around the exhibit files as they do currently with the Excel and Word files and at headquarters they can continue to compile the books from separate documents as they do currently, until the exhibit format gains the maturity to become the standard. And as the exhibit application becomes accepted, the next phase for automating the coordination of documents will become apparent. Notice how the first design phase can be completed without any design work on subsequent phases.
The last part of this series is called "Connecting With Users."
| Main | |
