Hi Oleg, On 6/3/08, Oleg Krupnov <[EMAIL PROTECTED]> wrote: > > > I've had a discussion with a professional and he claimed that for his team > and process, lo-fi prototypes are not practical. They a) scare the customer > b) too different from the final product look so that the customer's opinion > may change when he sees the product and c) mix together wireframing > (documenting) and prototyping (implementing) and so are an additional > effort > and productivity leak. He advocated lo-fi prototypes only for low budget > projects. I'd like to validate this point of view.
> They a) scare the customer In some cases, yes. I don't know who your customers are, but for some of the clients I've worked with this has definitely been true. I've found that it's people who need to rely on the system for their work and are not technically savvy who tend to be the ones who get scared. If both of these characteristics are true of your customers, then this point is definitely valid. If it's not true, then this point is not valid. > b) too different from the final product look so that the customer's opinion may change when he sees the product You're not looking for the customer's opinion during early-stage prototyping. You're trying to find out if the interaction design & IA works or not, which is something you can observe during testing. If you're doing later stage prototyping, then the more nuanced aspects of experience become more important. So this point is not valid for early stage prototyping but somewhat valid for late stage prototyping. > c) mix together wireframing (documenting) and prototyping (implementing) and so are an additional effort and productivity leak. Erm. When you do all this at once, you actually *save* time. Since the beginning of my career I have advocated for prototyping, but only when I discovered and started using Axure was I able to actually do it. Why? Because the wireframes (which I would do anyway) *were* the prototype. Yes, it takes a *little* extra time to make your wireframes interactive, but WAY less time than it would take to manage an entirely separate prototyping process. Also, it seems like your colleague believes that the prototype should evolve into the code. In most cases, this is absolutely NOT the way to go. Trying to make the prototype with code of the quality required to be launched would slow down the process and make it much less useful. So yeah, this particular aspect of the argument is totally invalid. : ) I hope this helps! - Fred ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
