One of the most important processes during the entire product development process is to explain the features to the other members of the team. The product manager coordinates the requirements and the feature flow, the experience designer then converts these into a actual feature flow (screen by screen, and UI element by UI element), and then finally this is converted into an actual working application (whether this be a desktop or web or mobile application). Now, even though the different team members can be an integral part of all the discussions that have happened, and well aware of how the developer is delivering the software, there are still grounds where there can be discrepancies in the understanding between the developer and the tester (there was a case where I was deeply involved where the product requirements researcher and the developer had been interacting daily for the feature, and yet, after around a month, when the feature was developed and the researcher had a chance to look, the features were off by around 5%). I am not for a minute suggesting that such things can get down to 0% deviation, but we should all be doing steps that help in reducing the possibility of such deviations.
These were simple cases. There can be more complex features, where the feature work forms the background of another feature, or the feature needs to be tested by multiple testers, or the Help document writer has to write about the screen and element by element flow in the application, and needs to understand everything in detail (and not being involved since the beginning, I could understand why in many cases, the documents so produced led to frustration among the team and needed multiple iterations), and in the worst case, the testers are in a different time zone and different geography from the developer.
This is one idea that I saw a developer doing. He had figured out that these kind of problems above can be very frustrating, and even though he would be frustrated, and his development manager would back him up, there would be multiple times when he would have to explain the same screens (in a particular workflow that he done, there were many UI elements in the screen and some UI elements were dependent on the values entered in the other UI elements); he almost dreaded the explanations he would have to do to multiple people. What he ended up doing was, during the unit testing he was doing, he would have a screen recording application running and he would provide some running commentary while doing this. In the end, he would have videos that essentially ran through the entire gamut of options for the screen workflow and it required much less effort after that to make them run in an order that was relevant for somebody else trying to understand. He would also have explicitly budgeted for the time required for this, and was able to show the advantages of doing this (although there were always some developers who were against the idea altogether, maybe more of their personal feeling that they would end up spending too much time on the video part).
These were simple cases. There can be more complex features, where the feature work forms the background of another feature, or the feature needs to be tested by multiple testers, or the Help document writer has to write about the screen and element by element flow in the application, and needs to understand everything in detail (and not being involved since the beginning, I could understand why in many cases, the documents so produced led to frustration among the team and needed multiple iterations), and in the worst case, the testers are in a different time zone and different geography from the developer.
This is one idea that I saw a developer doing. He had figured out that these kind of problems above can be very frustrating, and even though he would be frustrated, and his development manager would back him up, there would be multiple times when he would have to explain the same screens (in a particular workflow that he done, there were many UI elements in the screen and some UI elements were dependent on the values entered in the other UI elements); he almost dreaded the explanations he would have to do to multiple people. What he ended up doing was, during the unit testing he was doing, he would have a screen recording application running and he would provide some running commentary while doing this. In the end, he would have videos that essentially ran through the entire gamut of options for the screen workflow and it required much less effort after that to make them run in an order that was relevant for somebody else trying to understand. He would also have explicitly budgeted for the time required for this, and was able to show the advantages of doing this (although there were always some developers who were against the idea altogether, maybe more of their personal feeling that they would end up spending too much time on the video part).
No comments:
Post a Comment