The Web App: imagining the next version

Most applications have their weak points, and by the end of a testing session the test team is painfully aware of them. This is certainly true of the application we’ve been testing the last few weeks. It seemed worth my time to suggest a fix while everyone was still thinking about the system, so I spent today and yesterday putting together a proposal.

Describe the problem, Dabbler: The system stores electronic copies of documents which record information about two or more clients who have a business relationship. Generally speaking, the clients come in two varieties, and who is in each role is crucial to the specific record. Our back-end vendor stores this client information in a single table, with appropriate flags to tell which client is taking which role for this document.

Since the client data is stored in a single table, the original web developers chose to create a single data entry screen, which the user is expected to repeatedly fill in until the client information is fully specified. Client-type is selected using a radio button, as are a couple other variants. The person doing the input then moves on to two more forms, which describe the contents of the document the application is being asked to create. At that point, if all has gone well, the user moves the document-information to the shopping cart, where it stays until he or she completes the purchase.

Why this is a difficulty:

  • The number of clients is unknown: Until the user tells the application to stop adding clients, the application just keeps cycling through the same screen. Since the designers chose to use one screen for both types of client, the design is very flexible–but precisely because of that flexibility, every tester has reported that the screen is cluttered and confusing.
  • A further annoyance resulting from the multi-purpose design is that the buttons at the bottom of the screen are pretty confusing: One recycles the screen, another goes to the “Next” screen, and a third exits the application. It turns out that none of these labels are obvious to the users.
  • One last aggravation reported by every tester is that pressing the browser’s [Back] button has undesirable results, as the users are presented not with the just-input data but find a totally empty form, and an array of required fields (which the software enforces).

This is not a show-stopper, but since every tester found the screen difficult, it’s going to give our support staff headaches.


My main proposal is to separate the two types of input. Specifically, I propose duplicating the existing client input page, then disabling specific options on each copy so that the users would necessarily fill out all the instances of one type of client before moving on to the other client type. This should reduce the radio-button clutter on the screen, and will permit putting better navigational clues on the buttons. I expect this is an inexpensive win.

A secondary proposal is to redesign the input screens so that an “empty” screen stops being a trap; specifically, I’m proposing that submitting a screen with no fields filled bypass the screen edits, and that the record be discarded.  I expect this proposal to have some technical difficulties, and that the web coder will offer an alternative solution.

Of course, no one was around on this day-before-the-holiday, so only Margie and I have actually seen the write-up. We’ll see what everyone else thinks next week….