There are many different authoring metaphors and approaches. Exactly which is best depends on what you are creating and how you are delivering it to the end user. Here are a few common issues and ideas.
A few authoring systems use a page metaphor: they let you create discrete units (pages) of information/interaction that are linked together to form a sort of "book." Books have been used for centuries to share information; millions of textbooks are used for education. As you might logically expect, a book metaphor works very well for building CBT projects.
Recently, the page metaphor has become even more popular because it is the primary one employed on the Web. If you anticipate eventually moving your CBT projects to the Internet, using an authoring tool with a page metaphor now will make your job much easier in the future.
Many authoring systems employ a flowchart/timeline metaphor: they let you assemble materials into a sequence, as if you were creating a sort of "movie." This metaphor can be useful for a project that has a definite starting point, path, and ending point, such as a presentation, animation or game.
It is generally accepted that the flowchart/timeline metaphor is less than ideal for CBT projects. Surveys of thousands of CBT authors have repeatedly indicated that a flowchart is, by far, the least desirable feature in a CBT authoring system. CBT projects often need to branch in many different directions based on user input, scores, etc. Trying to create and maintain such complex branching is very tedious, if not impossible, with a timeline metaphor.
Most authoring tools use icons in one form or another. An icon is a pictorial representation of an object, container or process. An authoring system may contain icons for text, buttons, pictures, etc.; often, clicking on an icon lets you then modify the item it represents.
There are both good and bad aspects to icons for CBT projects. Icons help you visualize the content of a project, and they can be easy to manipulate for simple projects. However, if the icons grow too numerous, they become confusing. Icons are not substitutes for programming. There is no way an authoring system can have enough icons to support all the things needed by CBT developers. Attempts to do so typically result in projects with a mind-numbing array of indistinguishable icons. That's where available programming comes in.
Several systems offer a programming approach to authoring. Programming refers to a series of explicit instructions that the computer performs. A program in a CBT project could resemble:
IF score > 70 THEN BRANCH pass ELSE BRANCH fail ENDIF
In general, programming is more difficult than visual authoring with pages, flowcharts and icons. The main advantage: programming lets you control the detailed aspects of the operation of a project. The main disadvantage: programming is more time consuming.
Some authoring tools offer only icons, others offer only a programming language. A few systems let you use either approach; you might see it described as "visual authoring plus available programming." In general, an authoring system with both approaches gives you the flexibility to create almost anything, and helps you maximize your productivity.
A final note. Programming languages come in two flavors: proprietary and standard. A proprietary language is unique to that system; a standard language is a version of a popular one, such as Basic or C. An authoring system vendor can tune a proprietary language to match user needs. However, fewer people will know that language, and therefore labor costs will be higher. It's probably better to go with an authoring system with a standard programming language, as it will typically be easier to learn (thanks to more books, help sources, etc.), and your development costs will be lower.