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?