Before I was an instructional designer I worked as an electronics technician in the Navy and in high technology manufacturing: fixing things and doing stuff to things to decrease the chances they'd break. Better uptime meant more time for liberty ashore and profit sharing in the corporate world.
Here's where this is going: my technical and manufacturing background makes me want to work efficiently. I'm a big fan (and believer) in measurement, particularly the statistical process control (SPC) kind. I've lately been wondering how I could apply SPC to the process of instructional design. One measure that comes to mind is cycle time: the time required to produce a course (or to complete a step in the process of creating one).
Like a lot of ideas I get this one was on the back-burner for a while. What made me think about it again was a blog post I read earlier today: Rapid Intake's take on instructional patterns. I'm not a big fan of rapid authoring tools. I prefer to use rapid instructional design processes to speed things up. Tools like Rapid Intake's speed up development time by using pre-built shells an instructional designer pours content into. Rapid instructional design processes, the A and D in the ADDIE instructional design model, speed up ideation and prototyping, decreasing cycle time.
The difference between the two, rapid development and rapid instructional design, is subtle but significant. If you think about it, you don't get much benefit from a rapid development tool until after you've analyzed a learning problem or opportunity and come up with a design to solve it. Development, you'll recall, is the second D in ADDIE. It doesn't make much sense to jump right into rapid development if you don't have stuff to pour into it.
Rapid instructional design is done up-front. Put succinctly, you get the instructional designer(s) in a room with the customer(s) or subject matter expert(s) and then you come up with ideas for creating a learning experience. It's a lot like brainstorming. I think the most effective tools at this point in the process are a pencil and paper. Working within the constraints of your artist you sketch out prototypes based on your ideas. It's easy to come up with, and shoot down, lots of prototypes. At this step in the process the deliverables are two or three prototypes that can be shown to others to see if they get what you're trying to convey. Changes at this stage are cheap: pencil and paper, remember? Changes made during development, even if you're using a rapid development tool, are a bit more costly.
Anyway, you can see where this is going. When you finally pick up your authoring tool of choice you work from the paper (some designers I know create PowerPoint slides from their sketches) prototypes the customer or subject matter experts have helped you create. This really helps out later by decreasing the need for lots of reviews (and changes).