#7: Hire McGyver

5 thoughts on “#7: Hire McGyver”

1. Pingback: The ToolBar, Episode 7 – Hire McGyver | onehundredfortywords

2. Another good episode. Thanks for the semi-anonymous mention:) A couple of quick notes.

   * On storyboarding. This is a point where Kevin and I agree STRONGLY. Staying away from technology can often be a really helpful strategy at the beginning of a design effort. Computers can be a serious encumbrance at best and a negative influence at worst. The pencil or pen and paper is a low risk and humanistic way to form and organize ideas. I use the blank backsides of whatever is on my desk and whatever writing instrument is handy.

   But I think there is a large swath of things that many folks neglect before we even reach the storyboarding or the storystorming stages.

   I outline some of the things I think about in this thread on Storyboarding (http://community.articulate.com/forums/p/5342/29471.aspx#29471). This graphic from a recent presentation I gave also defines the order I consider critical to establishing a solution that focuses on results:
   http://www.xpconcept.com/progression_of_consideration.040.jpg

   Far too many blocks of instruction and {airquotes}training{/airquotes} have a content-centric focus. By moving that focus to tasks, covert tasks, and seeking out practice and assessment opportunities, I think we can arrive at better conclusions, more relevant packages, and overall stronger solutions than a design that gets stanked up by steamy turds of content.

   The graphics are recent extensions of this effort to progress towards courses anchored in activities that matter (not just activities). These indicate a focus on activity over a focus on content. And a focus on tasks (both overt and covert) as the driver behind the construction of an activity through the identification of natural practice and assessment opportunities.

   http://www.xpconcept.com/anchor_supports.png
   http://www.xpconcept.com/objectives_to_opportunities.png

   * On the struggle to produce art and the do it yourself-er. This is where Kevin and I diverge a bit. While I can totally see how certain parts of the industry are expecting more breadth and less specialized skill – I still believe that some design disciplines are worth the focus. While “just good enough” WILL do the job in many cases, there are times where you are going to be better off for your $$$ getting professional help (narration, multimedia production services, programming). That’s all I’ll say about that:) Art is one example of a specialized discipline that isn’t easy. You can learn fluency if you apply it. But there isn’t an easy button for visual judgement or for fluency in the discipline.

   * On prototypes – I think this is one where “it depends on what you need to accomplish or evaluate and where you are”. In our case, the prototype shows us that the vendor (usually the lowest bidder) knows what they’re doing. If they don’t, it might be time to go to the next lowest bidder. For us the prototype is a confidence litmus test. Even so, there are a few specific types of prototype we might ask for.

   – The first is an instructional prototype. This is a low fidelity representation of the patterns and structure of the experience. This prototype would works in practically any form (dental floss and index cards would do the trick if you can deliver it in one piece).

   – The second is a technical prototype. This ensures that all of the technical configurations will work in our environment and includes SCORM packaging tests. We want to know early if the package is going to present problems.

   – The third is a functional experience prototype. This is the whole enchilada in a compressed form (a few functional screens that represents enough of the package / solution promise to give us the warm fuzzy). We will ask for this polished form of prototype from new vendors with whom we haven’t established a confidence rapport. Existing vendors have already run that gauntlet.

   – The fourth is a pattern prototype. This is for a new type of interaction. We have a three stage delivery expectation (Rough, Polished, Final). So the pattern prototype is usually delivered in a very rough form. Each party has the option to provide or request a pattern prototype for a small component. It’s a risk control component that prevents the vendor from working on a skyscraper behind a stage curtain – just to result in disappointment.

   There are probably more types of prototype. These have emerged from our needs as a government customer. OMMV.

   1. Hi, Steve! I believe we mentioned you at the same level of personally identifiable information as you provided in your comments… that’s me, steeped in health-care-industry protocols! 🙂

      I had the opportunity to attend a session on prototyping with Chad Udell at mLearning DevCon this past week, and it opened my eyes to many different levels and types of prototypes that, I suppose, would still be considered prototypes. Some of them I do on different projects, but I don’t necessarily call them prototypes. I guess the terminology isn’t as important as choosing the right methods for your purpose. Thank you for adding to the conversation. We definitely need to have a show about this soon.

      Here’s the deck for that presentation, by the way. I think it stands on its own pretty well. http://www.slideshare.net/visualrinse/prototyping-on-a-shoestring-with-virtually-no-tech-skills

3. Great episode. You should have Kevin back sometime!
   You all made good observations.. funny ones too.
   Favorite line: “It’s called Rapid Development; not Rapid Design.”

   1. Yeah, that was probably my favorite line, too, along with Judy’s “Hire McGyver?” 🙂

      Thanks for listening, James!

Comments are closed.