Multimedia authoring tools, which allow interactive models to be hastily constructed and as hastily deconstructed for the purposes of revision, can facilitate the design process at even the earliest levels of program planning: concept creation and testing.
While those involved in the writing of an interactive multimedia program may go about things in a manner which suits their own creative talents, there are some basic guidelines which serve many in the interactive design community. For instance, after settling on an idea for an interactive program, the production of a test-of-concept model is generally recommended. A too-detailed model at this stage is to be avoided, in case pinning down ideas now might preclude broadening, or otherwise altering, the concept later. Focussing on a central element of the program, something that encapsulates the essence of what the program is about and how it might be presented and used, is what the model should concentrate on.
The test-of-concept model could be totally paper-based -- a sketch treatment, indicating program structure and the sort of features (interactive and otherwise) to be included. Personally, I favour building interactive sketch models and, for this, I find Hypercard an ideal program. With Hypercard on the Mac (or other similar authoring programs), interactive models can be quickly thrown together in a form that is easily adjusted and gives more concrete expression to the way those involved in the initial design process are thinking. In this way, decisions about what will and won't work are easier to make. And working in this way can make later phases like content-writing a lot easier (See "Speeding Up the Content Writing Phase").
Note that there is a definite danger in test-of-concept models which concentrate on only a limited aspect of the program. The danger is being mislead into believing that, just because one section seems to work alright, other sections containing substantially different ingredients will, too. (QUOTE FROM BLAKE HERE) One of the objects in testing the program should be to investigate how the elements work together, and whether they contribute towards a unified overall concept of what the program is about and how to get the most out of it. To borrow a metaphor from Nicolas Lewis (interactive designer for Future Media) who, with clients, likens programs to a house structure, what the model at this stage is illucidating is the structure of the house, not its furnishings, although it may come about later that the nature and dimensions of some pieces of furniture may require some structural redesign.
The extent to which screen visuals should be incorporated at this stage is debatable. You may wish to avoid showing anything too graphical for a number of reasons. Throwaway ideas sometimes can develop lives of their own, becoming accepted just because they were there first. Or the client might think that a rough sketch is what the finished product is actually going to look like and take fright! You might have an idea of how wonderful the finished graphic will look, but the client has still to be convinced. I remember showing to a working group a menu screen containing the sketch of a scrollable landscape. The point of the presentation was to focus us on defining the program structure but, because a particular hill reminded one group member of a burial mound which was inappropriate to the historical period represented by the landscape, almost twenty minutes were lost in the discussion which ensued.