Prototypes are excellent in communicating workflow and active elements that would otherwise be lost from static mocks. They can vary in their depth of visualization, typically separated as low-fidelity or high-fidelity. Both options are valuable and provide an excellent resource for designers and both come with different costs.
Low fidelity prototypes typically are little more than the mocks strung together with specific clickable areas. This means that there is little extra time needed to create more screens or assets. Since the program is also tied into the mock making (Ex. Sketch, Figma, Invision) then designers can easily collaborate together or across department on the fly.
High-fidelity prototypes are usually difficult or timely to alter. The cost of effort for simple navigation and page changes is a little more difficult in their system, but the real cost comes in the fact you need to often need to recreate these screens in the tool itself.
High-fidelity prototypes are typically as close to looking like the real application as possible making them highly valuable in communicating final ideas to audiences that need it. This would typically include stakeholders as they are interested in the final outcome they’ll be driving to and supporting. Another example would be in user testing, where a lesser presentation of the feature could create a bias.
Hover states and simple pre-defined transitions are really the most advanced their presentations can be. This is a hard line that low-fidelity simply can’t cross - they can’t illustrate haptic feedback or much of any animation type.
The level of prototype depends greatly on the specific need. If you need collaboration and rapid discovery, then keep it simple with basic prototypes. If you’re looking to showcase the finer details of a completed app, then go for the full prototype.