At a recent meeting, one of my colleagues mentioned that increasingly people weren’t throwing away prototypes. Which prompted reflection, since I have been a staunch advocate for revolutionary prototyping (and here I’m not talking about “the” Revolution ;).
When I used to teach user-centered design, the tools for creating interfaces were complex. The mantras were test early, test often, and I advocated Double Double P’s (Postpone Programming, Prefer Paper; an idea I first grabbed from Rob Phillips then at Curtin). The reason was that if you started building too early in the design phase, you’d have too much invested to throw things away if they weren’t working.
These days, with agile programming, we see sprints producing working code, which then gets elaborated in subsequent sprints. And the tools make it fairly easy to work at a high level, so it doesn’t take too much effort to produce something. So maybe we can make things that we can throw out if they’re wrong.
Ok, confession time, I have to say that I don’t quite see how this maps to elearning. We have sprints, but how do you have a workable learning experience and then elaborate it? On the other hand, I know Michael Allen’s doing it with SAM and Megan Torrance just had an article on it, but I’m not clear whether they’re talking storyboard, and then coded prototype, or…
Now that I think about it, I think it’d be good to document the core practice mechanic, and perhaps the core animation, and maybe the spread of examples. I’m big on interim representations, and perhaps we’re talking the same thing. And if not, well, please educate me!
I guess the point is that I’m still keen on being willing to change course if we’ve somehow gotten it wrong. Small representations is good, and increasing fidelity is fine, and so I suppose it’s okay if we don’t throw out prototypes often as long as we do when we need to. Am I making sense, or what am I missing?
I’ll point out additionally that the cost of making a software prototype has come down so far that it can actually be cheaper to prototype in software than on paper. That’s because when you prototype in software you get something that runs, not something that you have to -imagine- would run. The thing unsaid is that usually when we talk about prototypes (of products) we are talking about prototypes of software systems. So prototyping in other areas can still suffer the fate you describe — when you embody something physically, then you may have invested so much you don’t want to throw it away.
Now, that said, in learning, one of the things you want to do is check your knowledge, or check your proficiency, early and often. So taking in information is like the “sprint” phase, then you try applying that knowledge, then you revise your models or you seek new information, and so forth. So the principle that makes most sense is to take small steps when learning — small ingestion of knowledge, small practice, small application, small corrective steps, and cycle frequently.
Ah, the other thing is you talk about “increasing fidelity” — this presupposes there is a correct way, or a correct model of a real situation. That idee fixe view of the world doesn’t work as well as it used to. Most of the time when we’re learning in real life, business, science (etc.) we are trying to understand systems that are constantly evolving, so there may not be as much of this “increasing fidelity” as there was 20 or 30 years ago. That’s certainly a core reason that -agile- works when it comes to software development — we don’t have a good idea what we want, and the prototyping and development helps us understand that.
Let me be more radical and push for more than just elaboration of working designs in sprints. Following lean startup ideas, every release should be a viable product on its own.
In a Prezi I did a few years back (https://prezi.com/c75ncmsqv8m9/3-transformative-agile-ideas-for-education/ — Dramamine recommended), I pushed for assessment-first experiences focused on small but standalone useful skills, e.g., “can build a web page to do simple calculations” not “can write a FOR loop.” (Before would have come a module on “can build a web page” etc.)
A lean startup approach to developing such things would begin with building assessments for the skills we’d like to teach, and testing their viability. Can experts pass our assessments? Do they accept them as valid? Do target learners fail these assessments in the way we expect? Do they also accept them as valid? Can we generate instance of these assessments ad infinitum? If the answer to any of these questions is no, already we have a problem. We have failed fast, as they say. Otherwise, these assessments are in themselves a viable useful deliverable.
The second release would be developing the simplest activities that could possibly work to help students learn how to pass the test. Drill and practice, challenge and defend, construct and measure, etc. The test of course is how well students do on the assessments from the first release.
Rinse and repeat.