Going high-fidelity early in the design process

The term fidelity means how perfect a prototype is made (if you want to read more on this subject, you might want to read my article Balancing fidelity). As with perfection in any other area, perfection in prototyping comes at a cost:

It makes the design process rigid. Obviously, creating and making changes to a high-fidelity prototype takes more effort than to a less perfected prototype. It’s a labour-intensive approach and doesn’t lend itself to a creative and dynamic design process where we want to explore alternatives and be able to quickly change things that don’t work out as expected.

We get attached to our creations. We all hate making changes to things that has taken us a lot of effort to create. Since high-fidelity prototypes take blood, sweat, and tears to build, we are more likely to become reluctant to improve them. We get attached to our initial ideas and will settle for less than good enough. Also, managers are likely to be highly reluctant to support costly changes to something that has already taken its bite of the budget.

We waste time on things that will be changed anyway. Prototypes are built to get answers to questions that are important to the product design. The longer it takes us to create the prototype, the later we will get the answers we need. And the more time we use polishing our prototype, the more time we risk wasting on something that won’t survive the next iteration.

We will have to struggle to get the feedback we need. If we present a detailed prototype to our clients, their eyes and attention will inevitable be drawn to the details. Issues, such as colours, image quality, logo treatment, typography, spelling, data validity, stability, and response time will put the conceptual aspects of interaction design and of information architecture in the shade. Form will trump function, and minor flaws and temporary solutions will stand out. While the details have to be discussed sooner or later, it’s counterproductive if the design is still in a conceptual stage. We will get a whole lot of input, but will have to struggle to get feedback we need.

Usually, i love the articles at GUUUI but i don’t agree with this post.

One of the big drawback of low-fi prototypes is that we have to ask a lot from our customers to envisage the proposed idea.

Quite apart from tools like Axure. A wealth of CSS and JavaScript frameworks exist to speed up this process. (Blueprint and jQuery are my personal favs). Plus we get the distinct advantage of creating a prototype which can be tested with real users earlier in the design/development life cycle.

With some planning, these can be easily changed to support future development so the cost of development isn’t wasted. Let’s not pretend that the prototype won’t be re-used. (Build one to throw away is one of the biggest fallacies of the software development process)

Sure you have to remind clients the design isn’t finished or that it’s not pulling real data from the database but in my experience, that’s more than made up by the client getting the idea being proposed.