CHAPTER 9
Constructing the Prototype
Now that we've explored the essence of a prototype and why we build it, we will discuss the essential steps involved in constructing a prototype.
THE HELPFUL PROTOTYPER
A good prototyper is a uniquely talented individual who wields not only the essential technical skills to build functional prototypes quickly, but also the ability to listen carefully to discussions, synthesize information, and formulate designs that embody the strength of the group's combined ideas. If not a skilled instructional designer, the prototyper must be able to partner effectively with a designer to incorporate sound instructional principles.
A good prototyper:
- works quickly and strategically
- reflects ideas of the group
- demonstrates what works and reveals possible problems
- avoids temptation to embellish more than necessary
- listens carefully and thinks of ways to meet multiple criteria
- eagerly explores and demonstrates alternative approaches
- appreciates good instructional design and good graphic design
- discards his or her work with little hesitation.
While this list of requirements is more than challenging, it also includes something of a perverse twist. If the prototyper is a skilled programmer, there will be the additional challenge of abandoning some habits and constructs that are important in developing good software. The careful structuring of code, purposeful naming of variables, and systematic organization of data are unnecessary and even unwelcome where they delay the presentation of a prototype.
Talented prototypers are good at faking things and cheating on development strategies in an effort to build quickly. They are fast, sloppy in some ways, and able to turn imprecise descriptions into prototypes that appear more functional than they actually are. In order to explore as many ideas as possible, these individuals construct prototypes with the least amount of effort possible. They are always on the lookout for shortcuts that save time and effort—shortcuts that would be shunned in their role as a professional courseware developer or programmer.
Because many highly proficient developers cannot abandon their professional scruples, even if they're willing to try, teams shouldn't automatically request their best developers to prototype. It seems sensible to select a talented developer to build prototypes, but others may actually be better suited to the role. Sometimes a limited level of software proficiency is an asset to be preferred over software engineering strengths. Although many talented developers can be outstanding prototypers, this role is much more about speed than perfection. Consider as well junior developers, media artists, or others who possess rudimentary development skills but can cleverly implement ideas quickly. Find someone who is very comfortable taking directions from the team, listening to ideas without judging the approach, and is inherently limited in their ability to overdesign the prototype.
PROTOTYPING TOOLS
Tools affect the ability to prototype quickly and effectively. In some ways, a pencil is the ideal prototyping tool. It is useful for sketching ideas for any instructional approach. It can write over and erase. It's fast and inexpensive. It has a very low learning curve. Whiteboards and markers, flip charts, and other low technology aids can be excellent as well.
Moving up the technology path, there are now effective touch screen sketching tools that are easy to learn. They allow for quickly sketching, erasing, and modifying ideas, and projecting them for the team to review. They take varying amounts of time to learn, but most people can become proficient quickly. The prototyper shouldn't be learning to use the tool during iterative design cycles, of course, as it's important for prototypes to be produced quickly enough that they can be reviewed while the group is still assembled.
For e-learning, visual interactivity is a key aspect of design considerations. Animation, effects, controls, and input gestures are basic components of the learner experience and all have timing aspects that affect how they are perceived and how they contribute to the experience. When drawings are converted to functional software, they often produce interactive experiences that differ significantly from what was expected. While pencil sketches have value, they fall short in providing evidence of design suitability the team needs. Minimal levels of interactivity are required to evaluate alternative design ideas.
There are now many tools that support the rapid development of e-learning. They typically achieve speed by using templates or by optimizing for preset instructional paradigms. While these tools have their place, they may not provide the flexibility to explore a sufficiently wide range of instructional alternatives.
The capabilities of the prototyping tool can strongly affect how the team thinks, what possibilities are considered, and what opportunities go unrecognized. Choosing the wrong prototyping tool can mean choosing the wrong instructional approach.
PowerPoint as a Prototyping Tool
I am often asked about the effectiveness of using PowerPoint as a rapid prototyping tool. While many people have some familiarity with it and it is readily available as part of the Microsoft Office suite, I don't promote its use for prototyping (or e-learning in general) with enthusiasm.
Presentation tools support creation and delivery of presentations. They are nearly always honed for linear content presentation, rather than interactive, individualized, user experiences. As a prototyping tool, presentation tools limit the interactivity most prototypers can build or simulate. So, even if the design team proposes clever interactivity, the prototype built in a presentation tool is not likely to provide a suitable means of evaluating it.
Sure, folks can create some custom animations and transitions from one slide to the next, but we probably shouldn't be talking about slides in the first place. If the prototyper is unsure how to build an interactive element, given the need for speed, she is likely to compromise the design idea or employ an alternative approach. Neither of these fulfills the requirements of useful prototyping.
In summary, the prototyping tools the team chooses should provide the opportunity to partially implement a variety of designs quickly. Prototypes should be presented to the team in a form that can be revised quickly and with very little effort. Revision is expected and desired. Prototypers can use different tools either based on their personal skills or based on the appropriateness of the tool to the type of learning experience being considered. Linear tools should be used with great caution when prototyping interactive experiences.
A Private Word to Prototypers
Prototypers are the unsung heroes of a Savvy Start. And, like most heroes, they have a tough but vitally important job to do. If you are responsible for prototyping, you will hear the team discussing a lot of ideas and they will give you vague and probably conflicting directions on what to prototype. Almost as soon as you start you will mostly likely have questions about details that weren't discussed. Don't worry. You should feel free to fill in the blanks and do whatever you need to do that will help the team visualize their design in application. While you shouldn't deliberately misinterpret what they wanted to explore, the process of rapid prototyping is important because different people do—almost always—visualize verbally communicated designs differently. Prototypes are so helpful because they surface differences in expectations, and through iteration help groups come to common expectations and consensus.
It is easy to commit to a design idea too soon and miss the unexpected twists that come from brainstorming. Where you can, try to be true to the group's design of interest. Even if you have had a lot of experience with successful instructional approaches, hold your input and judgment back to let the group explore their ideas and work through the successes and failures that come along. If you have some suggestions, feel free to create an alternative prototype to be shown after the group reviews their design in prototype. The more prototypes, the better.
Brainstorming is a collaborative process, and not all groups brainstorm effectively. The room is purposefully filled with people who bring different viewpoints. With all of the challenges of group brainstorming—the chemistry of the people, the place, and the time allotted—everyone needs to feel their contributions were welcome and heard. Sometimes you have to prototype something you're quite opposed to so that the team can see why an idea wasn't really a good one. You should attempt to make the most of each idea. In doing so, the problems of bad ideas will become crystal clear.
More Tips on Brainstorming and Prototyping
It's a back and forth process: some brainstorming (but not too much) and some prototyping (but not too much). Small steps avoid unnecessary investment in dead-end ideas.
Don't go too far too soon—When the group gets their momentum going, it may be tough to keep them from attempting to design the entire learning product. But diving deeply into the content or tackling too much of it limits the creative consideration of primary alternatives. It's better to begin with small chunks—hopefully, chunks that are representative of larger segments of content. This practice will enable the team to be creative and to share their thoughts. Later you can encourage the team to brainstorm on how to bind smaller chunks into larger learning events.
Less content is better—Promote the idea of less content and more active opportunities to learn and apply new skills is almost always better than a lot of content with minimal learning activity. But people need to know all these things. Do they? Or has it simply been traditional to include superfluous content? Provide any concerned team members this comfort: Additional content, where it's truly needed, can and will be blended in later as activities and learning contexts require it. If, at the end of the process, there are content items that haven't been selected, it's likely that this content can be eliminated or made available as a reference tool.
Hopefully, the team will accept your recommendation and avoid lengthy discussions about the utility of every potential content element. You want to keep the focus of discussions and brainstorming on the learning experiences and the learning they promote, not on content nuances.
Don't design the final product—In addition to the tendency to prototype too much, the team may also want to design in detail. Details do make a difference, but the brainstorming team should be focusing on large design issues and major paradigms, not refinements. Quantity is better at this point than thoroughness.
Mistakes make magic—Making mistakes (and lots of them) is the magic of prototyping. Most of us want to create everything perfectly the first time, but that's just not realistic. Prototypes allow us to see how things might work, what makes sense, and where there's room for improvement. Use prototypes as a sandbox in which to make mistakes quickly and early so that they can be recognized and won't be costly later. Encourage the team to be creative without worrying about making mistakes!
Building the foundation for the prototype may include the team listing all of the contexts, challenges, activities, or feedback opportunities that the team can come up with quickly. The team only needs to think of some representative objectives, performance contexts, challenges, and activities. They are brainstorming, not designing. Omissions are expected and even necessary to use the available time wisely. They will be filled in when additional design work is done and content development begins in earnest.
STARTING TO BUILD YOUR PROTOTYPE
The designer and the prototyper need time to construct the prototype(s) the group has discussed. Other group members can take a break, check email, make phone calls, or just stretch their legs while prototypes are being built as rapidly as possible. The designer and prototyper need to be free of group discussion to synthesize and create. There is much to accomplish in little time.
The full group may be scheduled to return after a preset time, such as in 45 minutes, or be on call. While there needs to be adequate time to construct the prototype, SAM intentionally allows little time to construct each prototype. Prototypes need to be rough to prevent acceptance based on the heavy effort invested or because they weren't completed in time to discuss them.
A pragmatic consideration is that giving the team too much away time can allow some to become sidetracked in other activities, resulting in a dwindling team unable to reach the vital consensus of all stakeholders. To keep from spending too much time in prototyping and also to prevent team members from drifting away, it can be best to preset the time to reassemble. All participants should agree to be back on time.
For larger projects there can be two or more prototyping teams. This allows the brainstorming and design team to continue working while prototypers step out to work concurrently. Although not for beginners, large experienced teams can find this process keeps people productive and fully engaged.
Build an Instructional Event
There are many ways to construct a prototype quickly and effectively. The team's prototyper may have previously assembled a basic framework or have some components to choose from and combine. The instructional designer may have outlined a design that needs to be illustrated and built out a bit. There may be some existing materials or models that just need some modification or infusion of new content.
Rapid prototyping can be performed by a single individual with broad skills or a small team usually limited to no more than three: the project leader, an instructional designer, and the prototyper.
Typical Rapid Prototyping Session Agenda |
|
| 3-5 minutes | Determine the prototype(s) to be constructed. |
| 2-3 minutes | Decide who will do what and when it will be finished. |
| 25-30 minutes | Construct the prototype(s) and write choices/feedback. |
| 1 minute | Have a quick progress check. |
| 5 minutes | Review prototypes. |
| 5 minutes | Make any necessary revisions and call the group back. |
The goal is to create one or more prototypes that instantiate the team's design ideas. If it's a classroom activity, the prototype materials should be sufficient that the team can actually enact the activity as instructor and learners might do it. If it's an e-learning activity, some parts of the learner input gestures should be active so the courseware responses can be witnessed.
Not a lot can be accomplished in the short amount of time allowed and there will always be more the designer and prototyper would like to do. In nearly all cases, however, a rough and incomplete prototype is all that's needed for the group to determine if the design is going in a desired direction or if another approach really needs to be tried. If the results aren't conclusive, another round of prototyping under the team's direction is likely to do it.
REVIEW THE PROTOTYPE
Group members will be excited to see what has resulted from their discussions. Responses may range from extreme enthusiasm to disappointment. During the review of the prototype, all reactions are welcome and helpful. They represent greater project insight and are a step forward, regardless of how positive or negative.
Perhaps the worst outcome in prototype review is a hesitant, irresolute response from the group. While it's easy to confirm or discard a design based on intense reactions, muted responses fail to provide direction. Not to worry, SAM handles even this outcome comfortably, because even if the group's response was euphoric, the process imposes the challenge of setting the current design aside and composing another. It's very common that a design winning unanimous appeal is superseded by one that's even more appealing.
Review the Prototype Quickly
Depending on whether the prototyping is being done in the Savvy Start or iterative design, it is usually necessary to keep prototype reviews to no more than 45 minutes to an hour—even shorter, if possible.
In the Savvy Start, prototyping is about allowing key stakeholders to consider alternative approaches, consider available resources, and determine project preferences and guidelines. Much design work will be done in subsequent phases, so design is not really the primary outcome objective; rather, it's confirming backgrounding information and answering such key project questions as who is in charge, who is essential to achieving project success, and so on. So Savvy Start prototype reviews must transition quickly into What else should we try? How can we overcome the biggest concerns about this prototype?
In the iterative design phase, more time can and should usually be spent reviewing prototypes. More time will have been spent preparing these prototypes as more detailed issues are being explored with each iteration. Each successive prototype will be less about looking for entirely new approaches and more about deciding exactly what the design will be.
Prototype Walkthrough
Since prototypes are skeletal expressions of learning products, the team will need to be walked through each one, giving some guidance and direction to skip over incomplete or nonfunctioning components. As a way of developing a picture of the user experience, the prototyper may direct attention: Let's say the instructor has just explained…After the e-learner has incorrectly chosen…
The prototype presenter shouldn't rationalize or justify the design as the prototype is being presented. Other than explaining what would happen when the prototype is missing text, visuals, or functionality, the presenter should let the prototype stand on its own. The team needs to be experiencing the design to the extent possible, without commentary learners wouldn't have.
As the group discusses what they like and don't like, the leader creates a list of discussion points on a flip chart, whiteboard, or projected computer document. No time is taken to reach consensus; rather, focus remains on the experience provided by the prototype. These points initialize the evaluation component of the cycle to come next.
Evaluate
After the group has reviewed all of the prototypes, they return to the list of discussion points to determine what should be improved, revised, or removed from the prototype for the next iteration. Always keeping the learning objectives in mind, the team considers whether each of their dislikes is a design flaw, a content error, or possibly just a misunderstanding by the prototyper.
Unanticipated Discoveries
During the review of prototypes, especially during the Savvy Start, the team will reflect on many of the variables involved. Do our students do their homework? Do our employees have convenient access to mobile devices? How many different languages do we need to include? Are coaches available in all locations? How often does the content change?
Background information used to initially define the project may be incorrect or incomplete. The delivery means assumed to be appropriate may not seem so appropriate anymore, or multiple means may now appear to be necessary. The group may well consider the need to change the targeted behavior outcomes during the review of the prototype.
Such considerations have traditionally been part of the ADDIE analysis phase. These are considerations important to any development process. The foundation needs to be correct or the structure built on it will be ineffective. Prototyping is perhaps a disguised, but nevertheless highly effective, way of asking the questions that make sure critical considerations occur. When the team asks itself whether a prototyped solution will work, it's natural to reconsider the assumptions upon which a design is based. Such reconsideration is vital early in the process, and with SAM, it typically happens much faster with more accuracy and communication in the context of considering the rather specific learning activities represented by prototypes. But to be sure, it's important not to blindly build successive prototypes without stepping back during their evaluation to be sure the solutions being considered are appropriate in every way.
User Feedback
Even the most talented learning design team is handicapped in its capacity to define the best experiences for a select group of learners because they aren't those learners. Thinking and reacting as a person without the knowledge and skills you have is far more difficult than it appears. With prototypes available so early in the process, SAM provides the invaluable opportunity to get reactions from both recent learners and representative learners. This process difference alone may be sufficient reason to abandon ADDIE.
The traditional ISD approach calls for learner access to learning products after analysis, design, and development (in some instance, not until after implementation as well). That is, learner responses and evaluation aren't gathered until the products are very nearly complete. Of course, ADDIE can be modified to include learner interaction much earlier. That makes a significant improvement. But many organizations fear that by having learners review an incomplete application, great anxiety and confusion will ensue. There is too often a concern that nothing can be gained from inexperienced users this early in the process.
Most of this apprehension is due to the design and development approaches being used. If specification documents are being used to convey the initial design, learners will be challenged to provide any meaningful input. These are often complex documents that are meant to communicate design approaches between experienced instructional designers and developers. They are not meant to be used by learners.
Advantageously, with SAM, everyone can have early access to prototypes that support a more authentic learning experience. And there is so much to gain when there remains in-budget flexibility to make changes. Learner reviews early in the process provide a vital validation of design assumptions that can so easily be off. The SAM design team uses prototypes to challenge their initial assumptions, and interaction with learners provides another level of design challenge and validation.
During learner review, it's important not to editorialize about the design, but it is necessary to explain what is intentionally missing and incomplete so learners won't flounder or think they are misunderstanding. Delaying such explanation, however, until the learner makes inquiries is often the best approach. To the extent possible, learners should experience prototyped learning events as genuine learning events.
Checking designs with learners should occur often during the process, not just at the beginning or end. Reviews in the prototype stage will provide insight into the fundamental design, while later reviews will help to test wording, instructions, illustrations, interface, navigation, feedback, and so on. Involving learners at every stage of design and development benefits product design and helps ensure effectiveness.
WRAP UP
Prototypes are simple in design and functionality and provide a means of conducting analysis cost-effectively, stimulating creative design, and gaining learner evaluation and perspectives very early in the process. The advantages of successive approximation become apparent through the iterative production and review of prototypes.