Low/High Fidelity Prototype at Work

There are many different ways to prototyping web pages and applications. In this post I want to mainly touch on low and high fidelity prototypes and which fits best at my company currently. I work in an agile development where the software engineers tend to work faster (at least that’s the case at my workplace), which means the engineers would have a “working” prototype for demonstration prior to going over a low fidelity prototype. Perhaps the engineers should hold off until the low fidelity prototypes are approved and signed off, but that does not seem to happen in the agile world.

When I created low fidelity prototypes (very few times), I thought it generated valuable usability conversation, arguments and suggestions, but unfortunately the scrum team (engineers, BA, PM, QA) thought it decelerated the development process. Whenever there is a meeting (backlog grooming, project planning, design) that debates a feature, the teams would want to see the big picture (high fidelity prototypes) right of the bat.

The quality and usability of the applications at my workplace could be highly improved by at least fifty plus percent if the teams take the role of design in software product development seriously. In Bill Buxton's book, a clear representation of design, engineering, marketing, and sales in all phases of the product development process shows that the engineering team’s role in the design phase is very little, which means that the engineering team would have no room to demonstrate a “working” prototype.