Working With the End User in the Prototype Model

In the prototype model, the user plays an important role. What is that role? And what can we do to do our best and to build the best product possible?
Share on facebook
Share on twitter
Share on linkedin

Get the best of
The Daily Bundle in your inbox every week

Get the best of The Daily Bundle in your inbox every week

One of the biggest challenges in software development is to align the product with the vision of the product owner. The process is tricky because sometimes miscommunication gets in the way, while other times goals change. Whatever the case, when vision and result don’t align you reach a point where no one is happy.

In traditional models, such as the waterfall methodology, both the owner of the product and the end user have very passive roles. Once the requirement analysis is finished the developers get to work and little interaction happens until the project is ready to be deployed.

Other methodologies, including iterative models, see this as an issue and find value in involving both roles throughout the project. The idea is that software development isn’t a linear process, and constant feedback helps you improve your work and create a better solution in the long run.

Introducing the Prototype Model

The prototype model is a software development method in which a prototype is built, tested, and iterated upon until a satisfactory outcome is achieved. This prototype will later serve as the basis to develop the final product. 

While they are many approaches to prototyping, they all follow a similar pattern:

  1. First, the project requirements are defined with as much detail as possible. The owner and end users are extensively interviewed by the team to gather information about the project. 
  2. The development team gets together and goes over the information, creating a framework for the prototype.
  3. The first prototype for the project is constructed. It’s a barebones and scaled-down system that represents an approximation of what the development team intends to build.
  4. A sample of the user base is shown the prototype who, after using it, gives their feedback, both positive and negative. The development team collects this information and analyzes it.
  5. Based on the feedback, the team decides on a course of action, such as adding new features or removing them.
  6. The prototype is then modified and a second prototype is built.
  7. Steps 3 through 6 are iterated as many times as necessary until the users are satisfied with the prototype.
  8. The final product is then built using the prototype as a blueprint.
  9. The product is thoroughly evaluated, deployed, and maintained.

Prototypes are built using shortcuts and placeholder code. The idea isn’t to create fully functional bugless software (that comes after). A prototype is a demo, like the sketch of a drawing or the mockup of a building. 

If anything, a prototype is like a sandbox playground. It’s a space for experimentation where everyone in the project can tinker and modify to their heart’s content without worrying about breaking something or committing to something that might be problematic down the line. 

Before we talk about the role of the user in more detail, a word of caution. Prototypes are amazing tools, but they also come with a few drawbacks.

Perhaps the biggest problem with prototypes is that they take time to build. It’s time well invested, but not every project has the timeframe to accommodate for a long development cycle. In cases where rapid delivery is a significant factor, agile methods tend to be more reliable.

The User Manual to Prototyping

Users have a key role in the prototype model. They are the voice of authority, the ones whose guidance will help developers shape the end product. The user role is relatively simple: sit down with the prototype, play around with it, ask questions, give feedback, wait until another prototype is ready and do it again. 

Having said that, users who overstep their position or who don’t understand the nature of the prototype model can actually hamper the process. Here are a few guidelines to keep in mind.

Inform the user

Developers, don’t create your prototype in a vacuum. You should always present the prototype with documentation that clearly states the goals of the prototype, the systems that are in place, the kind of feedback you are looking for, and the potential bugs the users might find. This will help the user manage their expectations.

Users, read the documents and keep in mind that a prototype isn’t the final product. Things that you dislike or find unappealing might actually be placeholders that will be changed in future iterations. 

It can be discouraging to see a barebones tool, 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 that it will like that when the product is finished.

If you are unsure of what you should be paying attention to, ask the person guiding you through the prototype. 

Be Aware of the Type of Prototype You Are Testing

There isn’t a single approach to prototypes, and understanding the difference between a throwaway and an incremental prototype will help you be a better tester.

Throwaway prototypes are proof of concept—they are built quickly and are discarded twice as fast. They are used to show a specific function or a preliminary approach to the project.

For throwaways, feedback should focus on the specific functions that are being tested. Don’t think about ways how the prototype can be improved outside of its scope since odds are that it will be discarded once the feedback is processed. 

Evolutionary prototypes are a continuous process—the same prototype is refined and expanded with each feedback cycle. Since all the work is being done with the same prototype this saves time and effort. It’s by far the most common kind of prototyping.

Users, pay attention not only to the prototype itself but to how it has grown with each iteration. Try spotting where your previous feedback has been applied to the project, and check if that aligns with what you wanted. 

With Incremental Prototypes, the end product is divided into different subsystems. The prototype is created for each piece of the project and after all prototypes have been tested and refined they are merged into the final product.

Like throwaway prototypes, your role here is laser-focused: giving feedback on the core functionality you are testing. Once again, if you are unsure of 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, as the saying goes, one image is worth more than a thousand words. In this case, it’s a prototype that acts as the bridge between your vision and the actual development. 

The prototype model is one of the many approaches of software development that understands that users are a fundamental part of the process, and keeping them in the loop guarantees a faster development cycle and a better result down the line.

Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments

How useful was this post?

Click on a star to rate it!

Please enter a valid E-mail address.

Get in Touch

Access the Top 1% IT Talent, leverage our expertise to
jump-start your business.​

  • This field is for validation purposes and should be left unchanged.
If you previously need to sign a non-disclosure agreement, please email us at [email protected].
Scroll to Top

Get in Touch

Jump-start your Business with the
Top 1% of IT Talent.

Need us to sign a non-disclosure agreement first? Please email us at [email protected].

ACCELERATE YOUR DIGITAL TRANSFORMATION

By continuing to use this site, you agree to our cookie policy.