Week 7) Learning by exploration

Tick tick tick... I'm thinking about counting down to the final showcase showdown next week. Just seven days to go! I have a lot of work to accomplish in these seven days to put the final touches on my project and work out any programming kinks.

I've just been reading Dr. Stephen Draper's article More than we think. This is really interesting because he points out the differences between designing a product and using a product in the context of human-computer interface (HCI). Essentially, programmers create actions that match actual tasks that users may perform. While this will work for these specific actions -- there is little to predict how one individual will approach a specific task. So, user testing may uncover many different features of a product that are dysfunctional or inappropriately labeled. He proposes that instead of designing individual tasks for each action, that instead actions need to be viewed as being the result of sets of tasks.

This article points out a number of areas where designers may fail to grasp a user's difficulty with their product. For instance, even while the icons may be cleverly designed and logically (to the design team, no less) placed -- as user may not get this meaning. Three things can happen -- 1) the user completely ignores the icon, not recognizing its importance or function, 2) the user chooses the icon out of curiosity, frustration, or boredom when attempting a task, or 3) the user chooses the icon with no idea of its function and thereby assigns it a personal function unlike the original purpose. I find it especially interesting that users relate to an interface entirely at a personal level. There must be some similarities between groups of people as they become more experienced with a particular program or have expertise in similar fields. That aside, a user may gravitate towards and assign behaviors to interface elements based on shape, color, or location, with no regard to function! I like this because it demonstrates just how wildly diverse individual cognition can be.

This exploration of programs can be labeled as “learning by exploration”. Downe divides this concept into three groups of experience: “guessability (first time use), learnability, and EUP (experienced user performance).” It is important to grasp the range of experience and expectations that our users bring to the table when using the products we develop.

Learning by exploration is such an important concept that includes the experimentation and successive failure and triumphs we go through when approaching a new interactive program. At the somewhat meta level of this is my role as a designer of a product that will be used by a learner (for instance). Even as I am attempting to preempt how my product may be used, I am in turn interacting with a different program to complete my product! I find myself interacting with Flash like this a good bit. Sometimes I know what I’m doing and have a straight shot at a solution, other times it’s much more of a meandering path of errors and successes.

This reminds me of my methods to programming. I’ve learned my way around more dynamic code on an essential trial-and-error basis. I find myself able to communicate with the hard-core programmers yet have often been addressed as “approaching this like a designer’ (implied – not a programmer). Clearly, my own cognition for the tasks I complete has been modified by my own experience.

Project testing this week:

• graphing

References:

• Draper, S. (1996). More than we think: Facing up to the plurality of goals, methods, needs, and resources in HCI. Australian Journal of Information Systems, 3(2) pp.31-35. Retrieved April 19, 2007, from http://staff.psy.gla.ac.uk/%7Esteve/oz.html