Thanks (yet again) to Twitter, I came across a post by Karen from Langevin Learning Services (@karencar_ID) who shared an offering from the folks at Bottom Line Performance in Indianapolis (@BLPIndy). The substance of this post was whether or not Rapid Design and Rapid Development were possible. BLP’s inspiration was another entry from the widely read Rapid e-Learning Blog.
My immediate reaction was, “Yes, but, there are some caveats.”
(For sake of disclosure, from early 2009 to mid-2011, I served as the platform and process whiz for the SH!FT rapid e-learning ecosystem so I have some first hand knowledge of the journey from ‘traditional’ learning design to facilitating rapid output. I also want to note this is not a critique of the article, just some observations based on my own experiences in the ‘Rapid’ world and they are offered as food for thought)
Tools like Articulate and SH!FT are really labour-saving devices for learning asset development. Where complex programs like Flash require specialized expertise to generate finished output, rapid development tools take a lot of the “guesswork” out of some of the repeatable efforts, like simple text and graphic/media positioning.
The other element of the process is design. Those coming from the Instructor-led world are familiar with ADDIE, or may have some expertise in other instructional design models. The challenge with these linear models is them waterfall/gated method for moving from one phase to another. BLP also hits the nail squarely on the head with this observation:
Review cycles. If we can go from design to alpha with no script reviews, then we can be very rapid. If the client wants three review cycles on scripts/storyboards before we move into programming, we are in trouble in terms of rapid.
While all that is said by the Rapid e-Learning Blog and the BLP entry is correct, I believe there are a couple of unspoken assumptions that will facilitate rapid development the way in which it’s laid out above.
Assumption 1: Content and Objectives
If you’re passing on information about a new corporate policy, or just aiming for awareness, content can be designed and developed rapidly. If you’re building simple assets that share or showcase SME expertise, they can also be done relatively quickly. If you start digging deeper into Bloom’s Taxonomy for your objectives (e.g. beyond “describe”, “explain”, “identify”, etc.) then things get more challenging. If the objective the content is to equip the participant with decision-making skills, or to provide more exploratory learning, then the design process (and subsequent development) becomes much harder to accomplish in a “rapid” fashion with most of the current “rapid development” tools.
Assumption 2: Interactivity
Over the past couple of years, I spent a lot of my time in IMI Level 1 and Level 2 content design, particularly during my time with the SH!FT platform. When the learner’s control over their environment is reasonably low, the design becomes simpler because there’s almost no consideration for branching activities, conditions, loop points, and detailed feedback. Even things like Software simulations and interactions become incredibly simple to produce as long as a solid workflow exists and the various tasks are broken down clearly, the designer can manage the creation of the simulation in relatively short order.
Assumption 3: Concurrent Activity (e.g. Design with Development)
While frameworks like ADDIE have some small elements of concurrent activity (e.g. two designers could be working on stuff at the same time during the design phase), each phase is really distinct and most folks in the L&D community usually prefer (not without reason) to get things correct at one stage before moving on to the next stage. In the days of instructor-led training, this worked very well. However, with the advent of multimedia development as part of the technology-based training, the variables on the development side became significantly more complicated than the well-established practices of building manuals, reference guides, and the like.
One of the culprits of this new wrinkle was the use of the paper-based storyboard. There exists a chasm between the medium used for detailed planning & scripting and the actual output. With a linear design process, a team of designers and reviewers could spend months hammering out a storyboard and then find – once the design of the user interface and content began – that the output may not match the individual visions. This chasm was often manifested in a collective “Meh” as the reaction on first sight. By moving to models like Rapid Prototyping (e.g. Tripp & Biechelmeyer) or Successive Approximation, design and development can proceed concurrently with incremental changes/edits addressed along the way. The result is that much of the time spent in design is managed more effectively and the solution evolves in lock-step with the design.
Assumption 4: Stakeholder Culture
This is likely the biggest variable in any design/development effort. If we can assume that all of the key stakeholders are engaged in the process and understand their roles, then the review process can become more manageable. The key to success is getting the buy-in from reviewers (particularly sign-off authorities) to commit to the time required for the reviews. Otherwise, as BLP correctly notes (and as I have experienced in painful fashion) this is where things can get very bogged down, essentially negating all the time saved in the rapid design & development process.
As solid project management approach can mitigate this risk to the project, but people are human…so it often remains ‘the great unknown’ in a design & development processes.
To sum up, there are tools and processes out there to help make “rapid” a real possibility, but in a number of respects, we’re still playing “catch-up” on a few things if we want to extend those design & development gains beyond the simplistic Level 1 & 2 offerings. There’s also a requirement to re-think how we approach and manage projects as a whole and communicate this approach to stakeholders so they know what’s at stake, but also what is to be gained by following the “rapid” path. The folks at Bottom Line Performance raise some excellent points and I agree that Rapid Design and Rapid Development are both possible. However, the tools are only one piece of the puzzle; the underlying processes and approaches deserve equal consideration.