Introduction: Wireframing and Prototyping
Wireframes and prototypes – as well as software used for wireframing and prototyping – make the process of creating an app, a website or any software or hardware product notably easier – by simplifying the product and allowing all involved in its development to focus on the product’s functions and user interactivity. Everyone in the production team – from stakeholders and information architects to project managers and quality assurance personnel – needs to understand how an application or website will work and what it is intended to do. For that purpose, wireframing and prototyping are not synonyms, technically speaking. Let’s look at their differences and similarities.
Wireframes Talk. Prototypes Work.
If you don’t have the time to do five more minutes of dense reading, read this paragraph… and you will know how wireframes are different from prototypes. Simply put, wireframes make a useful (and usually purely visual) representation of what the intended product is designed to do and enable everyone in the team to collaborate in the early stages of product development. Prototypes, on the other hand, take the process further by deploying a simplified “bare-bone model” of the product that often has some simplified functionality attributable to the desired final product (and can be held or manipulated if it is a scaled or unscaled hardware model). Using the words of a wise man (Can I be a wise man today please, mom?), a wireframe talks, while a prototype works. A prototype may work poorly and may have many unsolved corner cases in its look, feel and performance, but it does work! A wireframe doesn’t do that – it simply communicates.
A Semi-Objective Comparison
I feel it is not entirely fair to “compare” prototyping and wireframing: although they overlap quite a bit and are often used as interchangeable terms, they are different in intent. I don’t blame you if you believe that wireframing and prototyping are synonyms. But historically, wireframing has been defined as a very specific and narrow (not meant to sound negatively) spectrum of activities intended to represent the desired product – usually software or a web page; result of wireframing is exactly that – a wireframe, which typically has no testable functions and lacks the features to establish the product’s look-and-feel baseline.
Prototyping, on the other hand, is a deeper representation of the product and often includes a working product model (commonly with use of color and other “feel elements”). Alternatively, with regards to hardware, a prototype means a tangible three-dimensional form that has some functional characteristics of the intended final product. In other words, wireframing – in most working contexts – should be viewed as a simplified subset of the prototyping discipline, or perhaps a blueprint for the prototype.
Lo-Fi vs. Hi-Fi and the Associated Costs
It should be further noted that there is low-fidelity and high-fidelity prototyping. Low-fidelity (lo-fi) prototyping is characterized by a quick and easy translation of high-level design concepts into tangible and testable artefacts. Lo-fi is also known as low-tech, as the means required for such an implementation consist – most of the time – of a mixture of paper, cardboard and post-it notes In the Software Development Life Cycle context, many designers, developers and product managers will agree that wareframes vs. prototypes are like PNG files exported from Balsamiq or Illustrator vs. testable page mockups from Axure.
Whatever the context, a clear advantage of lo-fi prototyping is its relatively low cost and the fact that non-programmers can actively be part of the idea generation process. In contrast, the high-fidelity (hi-fi) prototypes, which are characterized by detailed representation of the design concepts, result in partial or sometimes “complete-but-limited” functionality. The latter, naturally, implies higher costs, both temporal and financial, and necessitates good programming skills to implement. The main advantage of hi-fi, high-tech prototyping is that users can truly interact with the system, as opposed to the sometimes awkward facilitator-driven simulations found in lo-fi prototyping. Obviously, there is a continuum from low to high-fidelity prototyping that usually stretches out from early to late design. This comparison on Wikipedia is an effective attempt to identify the differences between the key prototyping software on the market today.
Does Pixel-Perfect Mean Successful?
Successful products are clearly not just about wireframing and prototyping (if they were, applications would be developed by graphics artists and visual designers). Instead, they include a broad spectrum of tools and approaches to assist teams of designers, strategists, developers, managers and stakeholders in executing projects effectively, including diagramming, modeling, visualization and other processes. Clearly, good wireframes become good prototypes, and then good prototypes become good products. So, you could say that wireframes often precede prototypes, although in the hands of some of the most exceptional designers and engineers wireframing and prototyping are often part of a single unified process – process that is supposed to help the development team define the product’s most efficient roadmap.
At the end of the day, however, one thing is true: over 90 of all new products and services – in all industries, at all times, and on all continents – fail within 2 years. That’s an undisputed statistic that applies to all digital and tangible products as well as to ideas, methods and processes – in all business models… including an equal proportion of products that had pixel-perfect prototypes to begin with (Mom, why doesn’t it make money if it looks so nice?). That said, let’s not forget that sleek-looking wireframes (or prototypes) don’t compensate for lack of proper business analysis. In turn, this is why so many successful products are so ugly-looking, while so few good-looking products are successful. Think about it: does pixel-perfect mean useful or functional or valuable? Not really, unless your goal is to create a work of purely visual art.
Trackback from your site.