Helpless. When it comes to computers or technology, that one word describes more people than would ever admit to it. In my experience, this applies to almost all corners of technology be it product development for a public audience, private in-shop development, or a mix of both.

I’ve taken part in numerous discussions focused around how to communicate product feature changes and how much training would be required. From a technologist’s point of view, the changes were usually menial–a bit of aesthetics and a new button for consumers to press.

A single page of documentation (or email) would suffice. However, those versed in either the magic arts of “corporate training” or marketing, from their experience, anticipated large scale meetings, one-on-one training, and weeks of phone calls/on-site visits.

My reaction: What? Really?

In the most general terms, society demands we have someone to “show us” how to do everything these days. Perhaps it’s early “old timers” on my part, but that sense of digging in and just learning it seems to be missing lately.

I’d never heard the term learned helplessness until my peers referred to it while explaining the need for massive trainings and meetings during a recent project rollout.

In my experience, the idea of learned helplessness comes in two flavors:

1. having tried and failed while seeing peers/others succeed a number of times, they lose confidence and feel they will never succeed [feeling helpless] and give up creating self-fulfilling prophecy,

2. having become accustomed to receiving instant gratification if they ask for help and have, for all intents and purposes, lost their drive to figure it out on their own (“it” being just about anything).

It starts young.

“Mommy, I can’t tie my shoes, will you tie them for me?”

I love my parents, but most parents (and kids) these days would say I had a horribly strict childhood. Why? Because I started working young, learned the value of my work, and work ALWAYS came before play. They also instilled a deep drive for independence, exploration, and creative thinking.

• Not sure how something works–take it apart (then try to put it back together).*
• Not sure what that button does–press it.
• Not sure what something means–look it up.
• Not sure how to do something–try it anyway.

I tested this once when I was younger… I took apart the TV that was in my bedroom (and didn’t electrocute myself). That didn’t get me in any trouble at all. If I couldn’t put it back together again, I was toast. I managed to get it back together (eventually) and still have it today.

The worst that could happen would be you’d fail and failure was AWESOME because you learned something from it. I’m surprised my neighborhood survived my curious childhood. :)

“Experience is what you get when you don’t get what you want.”

Dan Stanford

Let’s take a look beyond the frame of desktop computers, hardware, and line-of-business software and head to the local grocery store or hardware store for another example of learned helplessness. Many stores now have self-checkout. These are fantastic–go in, grab a few items, check yourself out, and be in your way. I love it.

There are others–even in their teens and 20s–who are completely stymied by these mystical devices with laser lights. This has become common enough that most stores now either have a staff member to assist OR the staff member simply checks that individual out. Enough “I’m confused–help me” pleas and someone simply does it for them.

Why does this matter? As developers and architects, anticipating our common user–the baseline–is a must for proper system design. Unfortunately, learned helplessness keeps lowering the bar.

The Technology “Baseline” User

For many years, I’ve held my parents (who are edging towards 80) up as the baseline for my user expectations.

Neither worked or used a high degree of modern technology in their work; however, both briefly used early word processors and WYSE terminals towards the twilight of their careers. Today, they’re familiar with email, surfing the web (even using google as a verb–I’m so proud), finding deals on Craigslist and Amazon, and printing pictures.

They’ve never had any training classes and, for the most part, haven’t tormented me for much more than a quick run through of functionality.

What they did have was the drive to figure it out. Now, I’m frequently greeted with digital pictures in my email (or even MMS on my cell phone) from whatever lake they’re fishing at with: “Ha ha, we’re at the lake–you’re at work” attached to it. Yeah, love them.

However, my baseline is too high!

In general, I’ve found I can no longer use their core knowledge as a baseline. Every day, I come across working professionals who:

1. don’t own a personal computer,
2. don’t use their computer in their day-to-day job,
3. somehow (perhaps painfully) survived college without using a computer.

I realize there are technology-free career paths out there, but I assumed (always a mistake) that basic skills were still part of university curriculum or other avenues presented themselves along the way.

How do these folks work the ATM, Redbox, or the grocery store self-checkout? They don’t.

With these individuals, all analogies break down when explaining software. “Oh hey, this works like when you add an item to the cart on Amazon” loses it’s frame of reference.

When you ask them how they pay their bills online or buy books, they either don’t do those activities or have their kids/secretary/significant other handle it. Someone has always around to do it so there’s never been a drive to learn.

What can we do?

Here’s a few ideas that I tend focus on when rolling out a product update, press release, or anything to the masses.

• Reinforce a positive user experience and ensure the tech isn’t interfering with the experience. Using the grocery store checkout analogy, as long as the interface is good, shoppers do not need to know how the actual hardware scanners work.

• Focus on domain-specific language. If the organization or culture you’re rolling a product out to has a set domain language, use it. Use terms and ideas familiar to users.

• Focus on creating associations and common use cases. There’s no need to reinvent how a shopping card, checkout process, or queue works. Oh look, wheels! Use them.

• Make help or training available. If users are exploring and learning on their wn, don’t prevent them from finding the answer on their own.