Building a Great Prototype

So you've got a great product idea. It's time to start thinking about turning those scribbles on a whiteboard into a solid prototype, and dazzling product. Yet – beware.

Prototyping efforts can be extremely seductive. They can undoubtedly get creative juices flowing. Yet technology prototypes are often shaped by the available tools, rather than by user needs. The resources needed to work on the prototype can take your group's focus away from the business problems at hand. And worst of all, developers can easily find themselves caught up in an endless loop of refinement. Prototyping, like most things seductive, can get expensive.

Not prototyping, however, can have significant costs in terms of true usability. Apple is the king of this principle – in fact, in its User-Centered Design course it says you can follow every guideline in their Human Interface Guidelines manual and still have an unusable interface. They go one step further and argue that every good user interface violates at least one of those guidelines. Their advice? Stay tightly connected to the real-life user. Involve the user early, and involve them often. Not prototyping can also cost you big time in terms of competitive positioning for your product.

A great prototype demands great expectations. And those expectations need to be clearly defined. Those expectations can actually drive what type of prototype you should build. If you have a business workflow problem, you may need a functional prototype. If you have a technology need, you may need a technical prototype. If you need to visualize a potential product that would empower cross-functional teams (including geeks and non-geeks), you may need to build a proof-of-concept.

Prototypes, like children, need limits. A prototype should never become an actual product. The initial functionality needs to be scoped tightly in order to protect your productivity and bottom line. In the case that you are embarking on a huge, multi-year product effort, an incremental prototype model should be used in order to minimize cost overruns and efficiently utilize user feedback.

Idea Entity teams thrive on driving creativity – yet specialize in building business-focused prototypes that are grounded in real life.