On Prototypes
It’s been a busy week. On Tuesday I finished building a prototype that represents the initial phase of a fairly elaborate software product. I had spent the previous month: researching, designing task flows & wireframes, drawing user experience storyboards, and putting all of these design artifacts together into a requirements document.
After reviewing the requirements with stakeholders, I felt it would be appropriate to build a prototype so we would have something more tangible to react to. What follows below are a few thoughts on this process.
Prototypes bring requirements to life.
Prototypes reveal the good, bad, and ugly sides of requirements. Not every requirement we document is correct. We should feel gratified when our requirements are right but, gasp, openly admit when they’re wrong. This isn’t a bad thing so don’t dwell on it. Just move forward knowing you’re doing what’s best for your audience.
Prototypes put stakeholders in the shoes of their audience.
I’ve often heard, and believe, good designers bring a sense of empathy for the intended audience to a project. By having stakeholders use a prototype, it really causes them to experience requirements in a different light. When they have to browse, fill out forms, and ultimately spend their valuable time using a product, it should cause them to question their requirements too.
Paper is nice, but interactive is better.
An interactive prototype tells a different story than walking someone through a series of paper wireframes. I know many people feel it’s faster to put together prototypes using paper. I find the marginal amount of extra time spent building a prototype with html, css, javascript, and server-side programming to be worth the expense.
Leave a Reply