I sat in on a webinar today entitled “A Roadmap for Building the Right Solution” (Slides are now posted.) It was sponsored by iRise, a company that I greatly admire (even though I didn’t choose their prototyping tool). At iRise, as at Axure (the tool I DO use–almost every day), they have some great thinkers who know that people are visual in nature, and, as Kurt Bittner, the speaker in the webinar said today, requirements documents are rarely read. It was a refreshing reiteration of the value of visualizations in software development. In order to build a software solution that truly satisfies the business need, you need to use a communication vehicle that’s visual–and a requirements document just isn’t visual enough to show people what you mean. That’s where rapid prototyping using a tool like Axure or iRise comes in.
Requirements documents serve an important purpose, but it’s not the way they’re usually employed. Typically, businesses write up requirements documents and hand them over for someone else to “review and comment” on. Now, for someone to really review and comment on a requirements document, they have to not only read it, but also form a mental picture in their minds of what the writer had in mind when they wrote it, and then structure some sort of response to that. All of this takes a lot of time. And time is money. If you write up your requirements and then spend a lot of time (a.k.a., money) reviewing them, you may still be no closer to solving the business problem than you were when you started. You may know how fast it has to go and how reliable it has to be, but does it really answer the right questions? Do the right things? Is it usable? You can’t really answer that until you have something visual in front of you.
We should use requirements documents–absolutely we should! But they should be the formalized notes stating the decisions resulting from our discussions. Use other methods (with a visual, interactive prototype early in the process) to get to the decisions. If we do it this way, we get a lot closer to delivering what the client really wants/needs, rather than what the client SAID they wanted.
I am involved in quite a few projects, all with the same client company, and it’s amazing how different the requirements process was for each one. There was always a requirements document, but we always introduced a visualization early in the process. We took what our clients asked us for, interpreted it by creating a visualization of the solution using Axure, then used that as a focus for our discussions. Usually that resulted in some changes to the requirements document, and we moved on from there. Once we’ve agreed that it’s what we want, the engineers then go and build to the prototype, with modifications as noted in the requirements document. The most successful (and enjoyable) project we’ve had involved a very short description of requirements, which we took and then built a visual prototype which showed the solution in action. This prototype was the center of our discussions as we molded this solution to become a viable result, simplifying even further as we began to more fully understand the problem and cut out all unnecessary elements to make the interface even easier.
They have posted the presentation from the webinar at irise.com. This is a drastic change from waterfall software development where the requirements are defined in great detail before anything is ever prototyped and some people might find it a dramatic shift in thinking. But it’s much more successful. Because of our visual nature, humans need a visual communications medium to SHOW us the idea, not just tell us. Words are great, but pictures, especially interactive pictures that show us the behavior of the solution, go a lot further towards getting to an effective response to the business need.
World of Usability 