A prototype is an early sample, model, or release of a product created to test a concept or process. Typically, a prototype is used to evaluate a new design to improve the accuracy of analysts and system users. It is the step between the formalization and the evaluation of an idea.
Prototyping is an essential part of the design process and a practice used in all design disciplines. Architects, engineers, industrial designers, and even service designers make their prototypes to test their designs before investing in their mass production.
A prototype aims to have a tangible model of the solutions to the problems already defined and discussed by the designers during the concept/idea stage. Instead of going through the entire design cycle based on a supposed solution, prototypes allow designers to validate their beliefs by putting an early version of the solution in front of real users and collecting their opinion as quickly as possible.
Prototypes often fail when tested, and this shows designers where the defects are and sends the team to refine or repeat the proposed solutions based on genuine user opinion. Because they fail at the beginning of the process, prototypes can save the final product, avoiding wasting energy, time, and money in implementing weak or inappropriate answers.
Another advantage of prototyping is that, because the investment is small, the risk is low.
Qualities of prototypes
Prototypes have four main qualities:
- Representation — The basic form of the prototype, i.e., paper and mobile, or HTML and desktop;
- Precision — The fidelity of the prototype, meaning its level of detail, polish, and realism;
- Interactivity — The functionality open to the user, e.g., fully functional, partially functional, or view-only;
- Evolution — The lifecycle of the prototype. Some are built quickly, tested, thrown away, and replaced with an improved version (this is known as “rapid prototyping”). Others may be created and improved upon, ultimately evolving into the end product.
Types of prototypes
In the IT industry, there are many types of prototypes, ranging anywhere between these two extremes:
- Low-fidelity (lo-fi) prototype is a quick and easy way to translate high-level design concepts into tangible and testable artifacts. The first and most crucial role of lo-fi prototypes is to check and test functionality rather than the product's visual appearance.
- High-fidelity (hi-fi) prototypes appear and function as similar as possible to the actual product that will ship. Teams usually create high-fidelity prototypes when they have a solid understanding of what they are going to build. They need to either test it with real users or get final design approval from stakeholders.
Product teams choose a prototype's fidelity based on the goals of prototyping, completeness of design, and available resources.
Forms of prototypes
Prototypes can take various forms:
- Storyboards that capture user experience in a series of images or sketches,
- Role-playing expressing users’ emotions as a result of using a product,
- Rough paper prototypes of digital interfaces,
- Basic digital prototypes.
Limitations of prototypes
Engineers and prototyping specialists seek to understand the limitations of prototypes to simulate their intended design's characteristics.
It is essential to realize that prototypes will compromise the final production design by their very definition. Due to differences in materials, processes, and design fidelity, a prototype may fail to perform acceptably, whereas the production design may have been sound. The counter-intuitive idea is that prototypes may perform acceptably, whereas the production design may be flawed since prototyping materials and processes may occasionally outperform their production counterparts.
Prototyping is also used to revise the design to reduce costs through optimization and refinement.
It is possible to use prototype testing to reduce the risk that a design may not perform as intended. However, prototyping generally cannot eliminate all risks. There are pragmatic and practical limitations to the ability of a prototype to match the intended end performance of the product, and some allowances and engineering judgment are often required before moving forward with a production design.
Building the full design is often expensive and can be time-consuming, especially when repeated several times—making the full design, figuring out the problems, and solving them, then building another full design. As an alternative, rapid prototyping or rapid application development techniques are used for the initial prototypes, which implement part, but not all, of the complete design. This allows designers and manufacturers to rapidly and inexpensively test the design parts that are most likely to have problems, solve those problems, and then build the full design.
Computer programming and computer science
Prototype software is often referred to as alpha grade, meaning it is the first version to run. Usually, only a few functions are implemented. The primary focus of the alpha is to have a functional base code on which features may be added. Once alpha grade software has most of the required features integrated into it, it becomes beta software to test the entire software and respond correctly during unforeseen situations during development.
Often, the end-users may not provide an entire set of application objectives, detailed input, processing, or output requirements in the initial stage. After the user evaluation, another prototype will be built based on user feedback, and again the cycle returns to customer evaluation. The process starts by listening to the user, followed by creating or revising a mock-up, and letting the user test the mock-up, then back. There is now a new generation of tools called Application Simulation Software which help quickly simulate applications before their development.
Extreme programming uses iterative design to gradually add one feature at a time to the initial prototype.
The need for prototyping
More and more companies that want to define their original product, new ideas, and new solutions developed by software houses decide to participate in design workshops. Such workshops aim, among other things, to create a prototype based on ideas generated in the workshop, ready for testing by future end-users.
There are many advantages to using prototyping in software development – some tangible, some abstract.
Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in development, the early determination of what the user wants can result in faster and less expensive software.
Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications. The presence of the prototype being examined by the user prevents many misunderstandings and miscommunications that occur when each side believes the other understand what they said. Since users know the problem domain better than anyone on the development team, increased interaction can result in an end product with more significant tangible and intangible quality. The final product is more likely to satisfy the user's desire for a look, feel, and performance.
Using, or perhaps misusing, prototyping can also have disadvantages.
Preliminary analysis: The focus on a limited prototype can distract developers from properly analyzing the complete project. It can lead to overlooking better solutions, preparing incomplete specifications, or converting little prototypes into poorly engineered final projects that are hard to maintain. Further, since a prototype is limited in functionality, it may not scale well if the prototype is used as the basis of a final deliverable, which may not be noticed if developers are too focused on building a prototype as a model.
User confusion of prototype and finished system: Users can begin to think that a prototype intended to be thrown away is a final system that merely needs to be finished or polished. It can lead them to expect the prototype to accurately model the performance of the finished system when this is not the developers' intent. Users can also become attached to functions included in a prototype for consideration and then removed from the specification for a final system. If users can require all proposed features to be included in the finished design, this can lead to conflict.
Developer misunderstanding of user objectives: Developers may assume that users share their goals (e.g., to deliver core functionality on time and within budget) without understanding broader commercial issues. For example, user representatives attending enterprise software events (such as PeopleSoft) could see "transaction auditing" demos (where changes are recorded and displayed in a different grid view). Unfortunately, they have not been told that this feature requires additional coding and often requires more hardware to support other database access. Users might believe they can demand auditing in every field, whereas developers might think this is feature creep because they have made assumptions about the extent of user requirements. Suppose the developer had committed delivery before the user requirements were reviewed. In that case, developers are between a rock and a hard place, mainly if user management derives some advantage from their failure to implement requirements.
Developer attachment to prototype: Developers can also become attached to prototypes they have spent a great deal of effort producing; this can lead to problems, such as attempting to convert a limited prototype into a final system when it does not have an appropriate underlying architecture. (This may suggest that throwaway prototyping, rather than evolutionary prototyping, should be used.)
Excessive development time of the prototype: A pivotal property to prototyping is that it is supposed to be done quickly. If the developers lose sight of this fact, they may try to develop a too complex prototype. When the prototype is thrown away, the precisely set requirements it provides may not yield a sufficient increase in productivity to make up for the time spent developing the prototype. Users can become stuck in debates over details of the prototype, holding up the development team and delaying the final product.
The expense of implementing prototyping: the start-up costs for building a development team focused on prototyping may be high. Many companies have development methodologies in place, and changing them can mean retraining, retooling, or both. Many companies tend to begin prototyping without bothering to retrain their workers as much as they should.
A common problem with adopting prototyping technology is high expectations for productivity with insufficient effort behind the learning curve. In addition to training for using a prototyping technique, there is an often-overlooked need for developing corporate and project-specific underlying structures to support the technology. When this underlying structure is omitted, lower productivity can often result.
Outline - step by step
The process of prototyping involves the following steps:
- Identify basic requirements;
- Determine basic requirements, including the input and output information desired. Details, such as security, can typically be ignored;
- Develop initial prototype;
- The initial prototype is developed that includes only user interfaces;
- The customers, including end-users, examine the prototype and provide feedback on potential additions or changes;
- Revise and enhance the prototype;
- Use the feedback; you could improve both the specifications and the prototype. Negotiation about what is within the scope of the contract/product may be necessary. If changes are made, you may have to repeat steps # 3 and # 4.
A few tips for beginners
Now, you may think that the process of prototyping may seem time-consuming, but you don’t want to waste even more time and money on the next project you are about to start without a prototype, and you decide to go for it.
To make this process easier and more effective, here are some simple tips you could follow:
- Just start building – it will help you materialize your ideas and quickly decide if they are worth exploring. Once you get to work, you can build up on the simple things to explore more concepts and dive deeper into the user journey.
- Don’t spend too much time on it – the longer you work on it, the more attached you get to your ideas. The whole point of prototyping is challenging assumptions and experimenting with new concepts, remember?
- Always think of the user. Their needs and behavior are what should guide your work at all stages of product development. The initial analysis will provide you with relevant background information, while the testing phase will verify your assumptions. Use this knowledge to build great software.
- Remember what you are testing for – don’t lose sight of the goal of your prototype. What is it that you want to test? Simultaneously, be open to other lessons you can learn in the process (and there will probably be many).
If you have enough time, it might also be a good idea to focus on choosing the right tools. You can create quick and straightforward low-fi prototypes that can be tested immediately or - more complex high-fi prototypes - that are closer to the final products in terms of interactivity, look and feel. Still, their production is more time-consuming and might potentially delay the whole project. On the other hand, many valuable and detailed insights can be discovered while creating a hi-fi prototype–so it’s your call to make. Base the decision on your goals.
If providing a good user experience is the project's goal - and it should be - then prototyping has to be part of the UX design process. It is crucial to choose the most effective prototyping method - minimizing work and maximizing learning - depending on the needs of the product. The result will be an overall improved design based on prototype testing.