In an ideal world, there is an inverse relationship between the amount of time/effort you spend in developing and visualizing an idea versus what stage in the development process you are in. In other words, early on in the process you want to be able to very quickly iterate over a large number of ideas. So the idea is to spend not very much time and only capture visually the important parts. Prototyping is a way to do that.
In more business terms, it is a tool for risk mitigation to help make sure you are actually building the right thing before wasting lots of money. In the traditional waterfall development process the product is never tested/evaluated until development is done (this is simplistic but roughly accurate). It's not unheard of for developers to spend months or years on implementing something based on poor user requirements only to find out it wasn't the thing that was actually needed/wanted by users.
What is important to capture? At CHI 2010 I attended a great course given by Jonathan Arnowitz and Dirk Jan Hoets called Developing an Effective Prototyping Strategy. They talked about a matrix of fidelity in your prototyping - that is, if you want to quickly convey visual design ideas then your prototypes might be non-functional but very visually polished. But if you want to convey interactive ideas then you might do wireframe-level visual fidelity but go deeply into the mocked-up interactions.
I apologize, the link they gave three years ago appears to be dead. Here is a link to a similar book by Arnowitz: http://www.amazon.com/Effective-Prototyping-Software-Interactive-Technologies/dp/0120885689
Sorry I didn't answer your whole question. Given your target user group I would say it's probably a good idea to get prototypes of varying fidelity in front of at least a handful of potential users. Both interactive as well as visual fidelity should be tested, since users in those age bands may have issues with fine motor control and/or degrading vision.