In prototyping, you create a model of the proposed solution. In business analysis, a prototype, or mockup, generally means a representation of a computer screen and examples of how the user will interact with the application to accomplish a task to solve the business problem. The business analyst creates the prototype, usually with help from the technical team.
Prototyping is a great tool to communicate what a software solution will look like. You just need to make sure that the solution doesn’t come before the underlying problem has been identified.
Sometimes, a stakeholder draws a picture showing you what he thinks the solution should look like. That initiative isn’t necessarily bad, but it puts the cart before the horse. In this situation, you still need to understand what the underlying problem is within the business domain.
Here are the reasons why prototyping is so great:
Prototypes give users something tangible to review. People are visual. Many people are interested in seeing what something looks like, and the prototype fits this bill.
When done properly, prototypes can speed up the project lifecycle. If a picture is worth a thousand words, prototypes save a lot of talking. In fact, in a commercial off-the-shelf (COTS) system, business analysts often start with prototypes because the screen has already been designed. The changes to the screen and the configuration will be modified on the mockup.
Be careful about using prototypes too early in the project. Users may get caught up in the aesthetics of the screen and want you to make the fonts sans serif or something like that.
Unless someone presents a valid reason for changing the aesthetics, remember the purpose of the prototype: You’re only trying to understand how the solution should function. In addition, make sure everyone knows the prototype is just a picture. Some prototypes may look, and even feel, like a real system. People tend to think the system is already built and ready to be used, but it hasn’t.
That said, sometimes aesthetic changes matter. Paul once created a dashboard for his manager that showed the health of the manager’s projects with green, yellow, and red boxes. Unfortunately, the manager was colorblind, so the red and green boxes weren’t useful. That is a valid reason to change colors!
Throwaway prototypes
You may be shocked that we’d suggest you throw away something you took a long time creating, but that’s essentially what you do with throwaway prototypes.
Throwaway prototypes are just pictures. You may draw them on a whiteboard or with an application like Microsoft Word or even on a napkin. These may be kept as artifacts, but they are thrown away in the sense that they are not used to build the system directly. Sure, they’re useful graphics, but that’s the extent of it.
The development team starts to build or update the application from scratch because the prototype can’t be leveraged (it doesn’t include code that developers can use when programming the solution).
Here is an example of a throwaway prototype for a computer application. What’s hard to notice is that it’s just a drawing. Nothing more. That means the developers have to start coding from scratch.
When you make throwaway prototypes, follow the concept of “just enough.” That is, spend only enough time on the prototype to get the project team to understand what needs to be done, and then move on. Time is tight, so you don’t want to spend any longer than is necessary.
Evolutionary prototype
Evolutionary prototypes let the development team leverage the effort of the analysis; basically, what starts as a prototype turns into the actual solution.
The advantage with this approach is that the expectations from the business are solid. They see the actual front end of the solution, and the developers make the necessary changes as the team works to clearly define the solution. Many times, the development team is involved in the creation of the front end and can guide the team on approaches.
Simulation prototype
Simulation prototypes are sort of like throwaway prototypes on steroids. Ultimately, the development team can’t leverage these prototypes for code (although at the time of this writing, some simulation tools are allowing some code snippets to be exported like in an evolutionary prototype).
The advantage with the simulation is it gives the business stakeholders something tangible to walk through. Users can interact with the solution and see how it works as they click and navigate through the proposed solution.
