« Three business books from long ago you've got to read | Main | Foursquare - social, game-like learning »
Thursday
May272010

Instructional design and games design - leaping the chasm (cont.d)

Since first writing about how instructional design and serious/learning game design appear to have different cultures, I've been asked to talk about this quite a bit.

A few weeks ago I did a short presentation on this at the Informatology conference in London, as part of the "Unconference" Pecha Kucha programme. A quick recording of the presentation is below.

 

 My previous postings on this subject are here and here.

Reader Comments (1)

Interesting. I would love an ISD to have some of the perspective of game mechanics and problem solving applications. However, I'm not sure attempting to blend yet another design / problem solving vertical into an already fragmented discipline is healthy.

Most ISD's I know don't have the skill attributes to build a good learning experience that is not a game. I'm not sure how we can adjust our expectations higher with a more complex design activity.

I see three main categories of design that go into an instructional solution. Sometimes these overlap, but I firmly believe that a competent focus from each category is REQUIRED for a worthy output.

I see these categories as:

Instructional - the problem solving category focused on recognizing, solving, and validating learning and performance problems. This category is absolutely critical to the success of a product and unfortunately I think we water this down with the expectation that they will be *good* at this AND other problem solving disciplines. I think it's unfair for everyone, and particularly unfair for the learner.

Representational - the problem solving category focused on the user experience, what they see, how they experience the design. The inputs to this discipline category ARE the instructional requirements. I place visual and written communication, in addition to multimedia specialization squarely in this category. It may seem terribly prejudicial to exclude these problem solving activities from the ID problem solving category. This is intentional... In my experience, the ID category suffers - as do the representational outputs - when scattered dabbling is the norm. Graphic artists / designers are designers... not 'doit-bots'.

Technical - another design category specifically defined to resolve technical challenges. Programmers are, or should be considered, designers.

Very few folks have the capacity to cover all of these areas. The output suffers and we see volumes of terrible solutions that result from over-the-wall-waterfall design and development hand-off. It is my opinion that the reputation of ID's in the industry won't reach a professional / craftsmen level until we focus on what we do best, balance resources, and consistently build good solutions.

Inputs, Design, Execution. Weaken any side of that triangle, nothing you do to shore up the other two sides can help. The output is going to suck.

I shudder when I see folks talking about turning ISD's into game designers. It's a leap beyond something that folks have failed to master onto something much more complex. It's another discipline. It's too much wood to carry.

Use the perspective to enrich the primary discipline = yes.
Try to be a game designer to mask poor ISD skills = no.
June 10, 2010 | Unregistered CommenterSteve

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
All HTML will be escaped. Hyperlinks will be created for URLs automatically.