At the beginning of every project, we develop a
vision document. The goal of this document is to provide a vision of how the product will work once the project is complete. The contents of this document are words and diagrams, pages and pages of writing in an attempt to bring imagination to life. The vision document is supposed to be the inspiration for the project, but often it is a flawed vision only approximating the actual results.
There are two good reasons why a vision document cannot possibly hope to communicate everything. The first is because of the
fuzzy front end. A vision document is meant to inspire, but the project could be killed at any point so only a limited amount of work is spent defining the edges of the system. Second, while the vision document may talk about personas, it often does not describe actual system users in the way that a novel might bring a character like Harry Potter to life.
One way to fully realize the environment and characters that will populate your software solution is to take a field trip to sites where the software will be used. Remember the acronym GOOB - Get out of the Building (or -- Get out of the box). Visiting a site brings concrete images to the abstract ideas summarized in the vision document. While it may not be feasible or affordable to bring the entire team on site, even video and phone calls give an enhanced understanding of the environment. The goal is provide a deep impression that will help with development later in the project.
 |
| Developer desk <> a dental operatory |
The most obvious observations to make are the workflows. The business analyst is best at this process. For the technical staff, the environment may play a factor in developing a solution. For example, dental operatories must be hygienic, so keyboards and mice are wrapped in disposable plastic covers. Since this makes touch screens unfeasible, we had to investigate voice and motion recognition solutions. In other offices, we discovered that staff had such cramped working spaces that they did not have desk space for their paper notes, so they ended up holding them in one hand and typing with the other, which raised a usability issue.
The field trip is a good time to put faces to personas. Previously you may have thought of the receptionist as “Receptionist 1,” but now you know her as Betty, who is extremely good at multi-tasking until it comes to her software. We would not have imagined the reception desk was such a hub of activity until we saw Betty interrupted nearly fifteen times in a fifteen-minute interval. Observing this not only impressed on the programmers and testers the importance of avoiding any software failures, but also provided data for system response times. Betty would be extremely unhappy to take time to call for support if something went wrong with the software.
There are other ways to observe the system: shadowing through screen-sharing sessions, conference calls, setting up role-playing scenarios at work, but none of these bring the situation to life as well as a field trip.
No comments:
Post a Comment