Working with the End User in the Prototype Model
One of the most challenging tasks in software development is aligning the product with the product owner's vision. This process is not easy, as sometimes misunderstandings arise, and sometimes goals change. In any case, when the vision and the result do not match, a moment arrives when no one is satisfied.
In traditional models, such as the waterfall methodology, the product owner and the end user play a very passive role. After requirements analysis is complete, developers start working, and until the project is ready for deployment, there is virtually no interaction.
Other methodologies, including iterative models, see this as a problem and find value in involving both roles throughout the project. The idea is that software development is not a linear process, and constant feedback helps improve the work and create a better solution in the long run.
Introducing the Prototype Model
The prototype model is a software development method where a prototype is created, tested, and iterated until a satisfactory result is achieved. Subsequently, this prototype serves as the basis for developing the final product.
While there are many approaches to prototyping, they all follow a similar pattern:
- First, project requirements are defined with the highest possible level of detail. The owner and end users are thoroughly interviewed by the team to gather project information.
- The development team gathers and studies the collected information, creating a foundation for the prototype.
- The first prototype of the project is created. It is a bare-bones, scaled-down system that approximates what the development team intends to build.
- The prototype is demonstrated to a select group of users, who after using it provide their feedback, both positive and negative. The development team collects this information and analyzes it.
- Based on the feedback, the team decides on next steps, such as adding new features or removing them.
- Then the prototype is refined and a second prototype is created.
- Steps 3-6 are repeated as many times as necessary until users are satisfied with the prototype.
- Then the final product is created, using the prototype as a blueprint.
- The product is thoroughly evaluated, deployed, and maintained.
Prototypes are built using shortcuts and placeholder code. The idea is not to create fully functional, bug-free software (that comes later). The prototype is a demonstration sample, like a sketch of a blueprint or a building model.
If anything, a prototype is like a sandbox playground. It's a place for experimentation where each project participant can tinker and make changes as they see fit, without fear of breaking something or making commitments that might later become problematic.
Before we delve deeper into the user's role, a word of caution: Prototypes are wonderful tools, but they also have some drawbacks.
Perhaps the biggest issue with prototypes is that creating them takes time. This time can be well spent, but not every project can afford a long development cycle. In cases where project speed is a critical factor, agile methods prove more reliable.
User Guidance in Prototyping
Users play a key role in the prototype model. They are the authority, those whose recommendations help developers shape the final product. The user's role is relatively straightforward: sit down with the prototype, play with it, ask questions, provide feedback, wait for another prototype to be ready, and repeat.
However, users who overstep their authority or do not understand the essence of the prototype model can hinder the process. Here are a few tips to keep in mind.
Inform the User
Developers, do not create a prototype in a vacuum. You should always present the prototype with documentation that clearly states the prototype's goals, existing systems, the type of feedback you expect, and possible bugs users might find. This helps manage user expectations.
Users, when reading the documents, remember that the prototype is not the final product. What you dislike or find unattractive might actually be placeholders that will be changed in future iterations.
Seeing a 'bare' tool can be discouraging, but remember that this is just the first step in a very long process. For example, your development team might present their first prototype as an Excel sheet, but that doesn't mean it will stay that way when the product is ready.
If you are unsure what to look for, ask the person guiding you through the prototype.
Understand the Type of Prototype Being Tested
There is no one-size-fits-all approach to prototyping, and understanding the difference between throwaway and incremental prototypes will make you a better tester.
Throwaway prototypes are proof of concept – they are built quickly and discarded twice as fast. They are used to demonstrate a specific feature or a preliminary approach to the project.
For throwaway prototypes, feedback should focus on the specific features being tested. Do not think about how to improve the prototype beyond its scope, as it is likely to be discarded after the feedback is processed.
Evolutionary prototypes are an ongoing process: the same prototype is refined and expanded with each feedback cycle. Since all work is done on the same prototype, it saves time and effort. To date, this is the most common type of prototyping.
Users should pay attention not only to the prototype itself but also to how it evolves with each iteration. Try to find where your previous feedback was applied in the project and check if it matches what you wanted.
With incremental prototypes, the final product is divided into various subsystems. A prototype is created for each part of the project, and after all prototypes are tested and refined, they are combined into the final product.
As with throwaway prototypes, your role here is focused on providing feedback on the core functionality you are testing. Again, if you don't know why something is missing, check the documentation or ask the developer – maybe what you expected is actually part of another subsystem.
Throwaway prototypes are proof of concept – they are built quickly and discarded twice as fast. They are used to demonstrate a specific feature or a preliminary approach to the project.
For throwaway prototypes, feedback should focus on the specific features being tested. Do not think about how to improve the prototype beyond its scope, as it is likely to be discarded after the feedback is processed.
Evolutionary prototypes are an ongoing process: the same prototype is refined and expanded with each feedback cycle. Since all work is done on the same prototype, it saves time and effort. To date, this is the most common type of prototyping.
Users should pay attention not only to the prototype itself but also to how it evolves with each iteration. Try to find where your previous feedback was applied in the project and check if it matches what you wanted.
With incremental prototypes, the final product is divided into various subsystems. A prototype is created for each part of the project, and after all prototypes are tested and refined, they are combined into the final product.
As with throwaway prototypes, your role here is focused on providing feedback on the core functionality you are testing. Again, if you don't know why something is missing, check the documentation or ask the developer – maybe what you expected is actually part of another subsystem.
Prototypes Are a Communication Tool
Prototypes are a way to communicate between developers and users, because, as they say, a picture is worth a thousand words. In this case, the prototype is the link between your vision and actual development.
The prototype model is one of many software development approaches that understands that users are an integral part of the process, and keeping them in the loop ensures a faster development cycle and a better outcome in the end.