Using UI Prototyping to Assist Requirements Gathering and Development

Sep 24, 2009
Lauren Bopp

I've been reading a lot of articles lately (at Boxes and Arrows and ia play) about the value of prototyping and debates over whether prototyping is more valuable when devoid of design, such as hand-sketching, or when it looks as close to the final product as possible.  I don't have a strong horse in that particular race, save to say that I agree with arguments that high-fidelity prototyping opens you up to risking a lot of re-work.  If you're ready to move to HTML you might as well create HTML you can use in the final product.  However it got me thinking...


Since Oshyn is often partnered with a design shop on client projects, we don't spend a great deal of time working through interaction flow ideas in the way that a clickable or animated prototype would be useful.  Even when we are doing the IA the project schedule or budget constrains us from delaying development until the UI is finalized.


So why did I spend the better part of yesterday researching and testing IA prototyping tools?   


A web site or web application is an organism.  It starts as a mere sparkle in someone's eye and gestates all the way from requirements gathering through UAT and finally launch.  Every project, without fail, will go through a series of growing pains where much of the pain stems from managing the project scope.  It's natural for scope pressure to arise as a project comes together and morphs from "what we thought it should do" to "what it does."  We don't resist it—heck, that's why we like Agile—but that doesn't mean we don't always strive for greater efficiency so that when code needs to be thrown out or changes need to be made it's because the client's priorities changed, not because the requirements or expectations weren't established clearly enough in the first place.


This is where the prototyping tools can help.  Many of them let you marry the expected end result (the graphical representation) with the functional specification in a way that flat documentation cannot.


Of the tools I looked at so far, Protoshare really impressed me.  It's a web-based service that lets you build a sitemap of pages, and attach wireframes and comps to those pages, then attach annotations and feedback threads to those wireframes and comps.  So rather than build a wireframe in Visio, write a functional spec in Word, seek stakeholder comments through email, and try to maintain each process separately, you can use something like Protoshare to keep it all in one place.  Centralized, there is greater transparency about the real-time evolution of the requirements, which helps the developers stay up-to-date with the most accurate specifications when they're ready to build something out.


And for those who really need to distribute a traditional Word func spec, Protoshare will gather screenshots from your wireframes and take all your annotations and generate one for you. A really nice feature!


I also really appreciated the intuitiveness of Protoshare's own UI.  I'm sure there are a number of features I haven't discovered yet, but it was easy to get up and running with the basic workflow.   Two abilities I would love—and I haven't discovered whether Protoshare does this or not so if you know please correct me—is if you could:


  1. Isolate components or modules from off of a flat image, like an uploaded comp, and annotate at that level rather than the page level.
  2. Maintain separate annotation sets to build specs for different team members—one set of notes for the front-end developers, one for the back-end developers, one for the testers, etc.

But even without these features Protoshare seems like a really promising little tool to add to our kit here at Oshyn.  As to the greater debate—whether hi-fidelity or low-fidelity, I think prototyping can add a lot of value beyond figuring out the UI by merging the clients' expectation of what they're getting with the developers' understanding of what they're building.