Curling

The winter Olympics are here and so again is curling. I polish my miniature curling stone paperweight and put on my team USA curling sweat shirt and I'm in my quadrennial state of euphoria.

I discovered it about 10 years ago in Canada watching the women's national final on TV in a pub in Victoria. The teams wore plaid skirts as part of their uniforms. [...] Sorry, I was off in my happy place there for a moment. I'm back.

I worked for a guy who made an interesting metaphor using curling once. We were doing a workshop on employee empowerment and someone asked him what he would do if an employee made a big mistake. His answer was, "I saw a sport called curling last week. Someone slides a stone along the ice and the other team members go along side with brooms trying to influence its direction as it makes its way toward its goal. Unlike bowling, where you throw the ball and then stand back and watch. If someone makes a big mistake bowling, I'll fire them. If they make a big mistake curling, well, we'll learn our lessons and move on."

The other thing I like about curling is it looks like a sport you could play with a beer close by.

What makes experts expert

In my previous blog I throw some (well-padded) elbows at experts, and Isaac Rabinovitch rightfully takes me to task a bit. He makes the points that sometimes the gnarly explanation is needed--true, see my post on G2G (Geek-to-Geek) communication--and that technical communicators should not cut off experts during their explanations.

My comments were directed as much to us when we acquire expertise to be mindful of how much our listeners need to know (readers, friends, and family all included). Issac's comments do raise the important issue of how should we interview SMEs and then what is our role to our readers as surrogate SMEs?

Components of expertise

OK, let's the get the obvious out of the way: knowledge. JAVA experts know a lot JAVA syntax and stuff. Historians know a lot of events and dates. That's the easy part.

Studies of experts have discovered that experts see patterns that non-experts do not. For example, athletes talk about being able to "see" the court or the field. Part of why Payton Manning can call such effective audibles is that he can see the patterns in the defense (whereas you or I would see 11 people). When I taught electronics, I would like to start the week by showing a typical schematic we would be dealing with that week and ask the students to estimate how many components there were. The answer was typically "hundreds." At the end of the week I'd ask the question again and the answers were more realistic (20-30). What changed? The students now saw the schematic as a power supply, pre-amp stage, and amp-stage. They saw the patterns and that helped them process the previously overwhelming details.

Another thing research has shown about experts is that their knowledge is tacit--they no longer know what they know. They draw on their knowledge so instinctively they cannot observe their processes. I tried to document a couple of my Dobro picking patterns for a friend and it was HARD! Not the transcription and notation part, but just being able to slow down and see what I did instinctively.

So part of our job as communicators is to help SME's uncover their tacit patterns so we can pass those along to our readers. In that way, we start to transfer expertise instead of just information.

I remember once interviewing an expert and asking what a good starting value was for a particular variable. "It doesn't matter" was all he would say. So I finally said, "OK let's start with a million." In about five seconds we arrived at 35 is a good starting value. After that, it was just "When would you make it bigger? When would you make it smaller? How would I know if it were too big or too small?"

And this isn't just about technical writing. We are all SMEs at something. I've started writing music down and it's forced me to investigate the tacit patterns I've been applying. It's made me a better player and will enable me to be a better teacher if I can ever get one of my grandkids to take up an interest in Hootie's hillbilly music :-)

Three Mistakes Experts Make

As user experience professionals, we deal with experts a lot in the form of Subject Matter Experts. And in doing so, we become experts. Plus we deal with experts and expertise in a dozen different forms in our routine lives every day, so it is good to stop and talk about the three big mistakes experts make.

Mistake one: The infield fly rule

Imagine there is a group of you from work at a baseball game--you know, one of those team-building outings. Someone in the group is a non-American, say a Swede over on special assignment. Along about the third inning he says, "Oh I get it, if the fielder catches the ball before it hits the ground, the batter is out. Is that right?" The correct answer is "Hey, you've got it, let me buy you a beer."

But there will be an expert in the group who will feel compelled to explain the infield fly rule. "Well that is often the case but if there are runners on first and second and the batter hits a fly to the infield, then the batter is automatically out regardless of if the ball gets caught or not and the runners do not advance. The reason, of course, is to discourage the infielder from deliberately dropping the ball and then having force outs on all the bases."

Not only is it a buzz kill for the Swede (and anyone else in earshot) it is completely unnecessary. Who needs to know the infield fly rule? The batter? No, because no batter would ever hit a fly to the infield on purpose. The fielders? No, because their play is irrelevant; the batter is out regardless of what they do. The runners? No, they will not be allowed to advance.

So the only person who needs to know the infield fly rule is the umpire, and he can explain it to everyone on the occasional blue moon when it happens.

In many software applications, the computer is the umpire, and as long as it knows what it has to do, don't load down the user with overly technical explanations. Experts want their explanations to be complete and accurate, but user explanations just have to be viable. Agile development has the principle of JBGE "Just Barely Good Enough." An explanation just has to be complete enough and accurate enough to get the user to the desired end goal. In our example, the Swede's understanding of baseball was adequate to enjoy and understand the game he was watching.

Mistake two: Too many explanations

If there is more than one way to do something, the expert will explain them all. At most we typically only need two ways to do something: (1) the easy way to remember and (2) the expert shortcut. Think about getting directions. If you are not comfortable with a particular section of town, would you prefer directions that had only two turns and took you 2.5 miles or one that had seven turns but only took 1.9 miles? Probably the longer but easier. After a while, though, you would probably like to know the shorter way.

Mistake three: The most difficult explanation

My guitar teacher showed me a way to derive all of the naturally occurring chords in a scale on the Dobro (for the key of G). The really useful ones are G, Am, Bm, C. D, and Em. The last one is an F#minor with flatted 5th. This would be like having a group of guys named Al, Bill, Tom, Dave, Fred, and Throckmorton (how did HE get in?) For months I have tried to figure out why this anomaly occurs, this seemingly out of place chord. Today driving in to work I realized it is a D7, a great transitional chord and one that makes sense showing up with the others. (Like finding out Throckmorton is a nickname his great aunt gave him, his real name is Ted.)

But the instructor was right, it could also be called an F#minor with flatted 5th (or a F#dim for that matter). He let himself get distracted, I think, by the sequence of the notes and did not see it in the simpler context.

Conclusion

1. Look for viable explanations.
2. Limit the number of alternatives to one easy one and one expert shortcut.
3. Give the simplest explanation. (See Occam's Razor.)
   

postscript: In verifying my link I could not help but catch this irony (click to enlarge):

Smacksonomies

In my book Iron Hoop I portray a conversation between the local junk man and a crony about how the junk man arranges things in the junk yard. It is a very thinly disguised metaphor about the inherent problems I have with taxonomies.


The one I have a continual problem with and never get around to fixing is my folder arrangement on my computer. I have a folder called Presentations in which I file my PowerPoint presentations. Within that I have some subfolders for specific conferences or organizations.


But I also have peer level folders for those same organizations and conferences to collect documents and correspondence.

You guessed it; I'm inconsistent with where I store PowerPoint presentations and always have to scratch my head and wonder if it is in Presentations\STC or STC\Presentations.


Essentially I'm conflicted between Object\Audience and Audience\Object. I wonder if there is a natural taxonomy that would guide me, some world view that could serve as a model for these kinds of decisions. I've wondered about the Carnegie Mellon food|shelter|handle research, but that's not getting through.

Thoughts?

BTW, I used to have a similar dilemma with what goes in the columns and what goes in the rows in designing tables. I think I solved that. See my UXmatters column.

Content over form

What is it about the striking of the Submit button or the opening of the first manual off the press that makes me an expert proof-reader?

The first sentence of an article proposal I recently sent to an editor: "I have contribute in the past to the ..." Subject-verb disagreement in the FIRST THREE WORDS!

The happy ending is that they accepted the proposal anyway. Sometimes the message outshouts the grammar--ain't that the truth!

Nouns in 3D

Here's an interesting snippet of research coming out of Carnegie Mellon: How the brain arranges nouns.

Using functional magnetic resonance imaging (fMRI) technology, members of the Center for Cognitive Brain Imaging have gained deep insight into the way human brains categorize objects. In a breakthrough that demonstrates the interdepartmental cooperation here at Carnegie Mellon, neuroscientists Marcel Just and Vladimir Cherkassky and computer scientists Tom Mitchell and Sandesh Aryal have arrived at results that bode well for human-computer interfaces and neuropsychiatry.

Their research has concluded that humans represent all non-human objects in terms of three classes or dimensions. Just defines these dimensions as having to do with eating, shelter, and the way the object is used. He explained that when one sees an object, the brain thinks, “Can I eat it? How do I hold it? Can it give me shelter?” Indeed, all concrete objects are represented in terms of these three dimensions, much in the way that all places in space are represented by the three dimensions that we experience every day.

OK, sounds a little "out there" at first. But think about one of the most ubiquitous of icons and navigational constructs on the web: "Home." Does that say "Gimme Shelter" or what?

Thinking about it a little further, we consume (eat) data, we store (shelter) it, and we move it (hold it) around. I know, the jokes come too quickly. Consider the following alternatives to the traditional Save and Cancel buttons:



Still, I think the research findings are provocative and deserve some serious consideration for UI applications.

Hump-day Humor 2010-5

On-the-job negotiations.

Click comic to enlarge it.