It's a bit frustrating to spend my days concentrating on writing for the beta of the next version of DPM, yet not being able to say anything about it here. It makes perfect sense, of course -- not mentioning features or functions prematurely. After all, if I wrote that we were thinking of having V2 generate an alert whenever a file is deleted from a server and a zillion companies cancelled their plans to order V2 because they (rightfully) consider that a terrible plan...or that V2 would perform on-the-fly defrag of each protected server, and somebody made their business plans counting on the availability of that feature...then V2 didn't generate an alert and didn't defrag server volumes -- well, you see the problem. So, I can't talk about V2 yet. (Just for the record, V2 is not generating an alert for each deleted file or performing on-the-fly defrag while backing up data...I made those up.)
So, let's talk about prototyping instead, just because the User Interface Engineering blog posted an excellent collection of resources yesterday. I wrote a bit about our usability testing last year (has it been that long already?). We used a prototype then, although it was a bit more sophisticated than the paper prototypes mentioned in this article. Although there are great arguments for paper prototyping based on costs and time and efficiency, I think the emotional one is key. As the author explains:
"Modifying a paper prototype is much less painful than for the developers than modifying an actual product. With a real product, because of the substantial amount of work they've put in, the team has an emotional investment in the status quo and will naturally tend to "defend" their design. Even when the team clearly understands the need for changes, it's tough to throw away all that hard work. In contrast, because paper prototypes are so easy to create and modify, there is less invested effort to defend. As a result, development teams become more flexible and willing to try new ideas."