Zero-base design means you discard the past and start afresh. In rapid development, you do not have time to go through all the specifications and documentation of the old system. Doing a quick zero-based design can result in significant benefits in developing a prototype. We do not discard the existing system; instead, we borrow the idea of Po from Edward de Bono. (Po: Beyond Yes and No. Penguin Books, 1973.) Po is a method to encourage lateral thinking, to find solutions that are outside the usual view.
When we complete this first prototype, we will meet with the user for an exchange of ideas about how the system would go together. I call this meeting: "I will show you mine, if you show me yours." Our purpose is to generate the requirements that are needed, not just to clone existing systems, thereby inheriting their shortfalls.
There can be human interaction problems with this approach. When approaching the user, you should describe your prototype lightly: as some doodles to spark ideas, as some ideas that the user may wish to entertain. The user should not feel that you are imposing or even suggesting this design. The developer should be very positive about the user's system and wishes. Instead of using leading phrases like, "We could do this ..." or "It would be easier if we ...," choose phrases that give the user the feeling that he or she is in charge. This cooperative approach usually results in more of your ideas being used in the end. Some example phrases:
The end of the meeting should have both sides exchanging hard copies of their screens, forms, and other documents. These copies will be discussed at the next meeting, the GUI meeting. The application is left crude or unfinished so that there appears to be much work to do.
The goal of the third day is to generate paper copies of screens and the program flow between screens that the user wants. During the process we will identify the captions the user wants next to the fields, the name for each form and report, and other format issues.
A successful system means success with hardware, software, and humanware. My preferred approach to doing GUI design with the user is to return to old-fashioned methods. For resources, I would come equipped with Post-it™ notes, glue sticks, scissors, many copies of our "one-day wonder" prototype screens, and documentation of the user's system. The user and I would sit down and create the new application by cutting paper copies of forms and reports, pasting stuff on sheets. No high-tech design software or computers are allowed. The reason is very simple: Software and computers empower the developer and intimidate the client. Cutting labels and applying glue sticks reduces all the parties to peers and improves communication.
We now have had two whole days without coding!