I have come down from the mountain

I've been very quiet the last several weeks as I have been wrestling with a long-standing inner conflict of mine. I have scoured my soul and I now know my mind. I am ready to make my public statement about...

[ominous fan fare in background]

ending a parenthetical statement with the smiley face icon.

Often, I want to soften a strong statement or add some context to a comment by putting a self-deprecating or explanatory comment with terminal smiley face in parentheses at the end of the sentence (as if my sentences aren't long enough :-))

See!!! See the problem? Is that Mike smiling inside parentheses or is it Mike with a double chin?

I sometimes solve it by using an em dash instead of the parentheses--in this case a double hyphen, but that sometimes offsets the contextualizing comment too much :-)

So I've decided to let the smiley face icon serve as both a smile and a closing parenthesis (thus saving ink in these oh must be so green days :-)

At any rate, problem solved for me.

BTW, went to the Atlanta STC Currents conference this weekend. Wow, I like my chapter.

Afternoon in the Garden of Good and Evil

This week I visited with a ladies' book club in Pine Mountain, Georgia, to discuss my novel, Iron Hoop. It was a classic Southern experience right out of "Midnight in the Garden..." The group were well-to-do retirees who lived in a very upscale neighborhood situated on Piedmont lake. Well dressed, genteel, and with Southern accents that flowed as sweetly and lazily as praline.

Needless to say, they all liked the character Grandmother Tillman--all being grandmothers themselves--and envied the relationship she has in the book with her grandson. The general conclusion was that they needed to tote guns as she did so they would be remembered for being more than just someone who said, "wash you hands" all the time.

The book deals with racism, and we had some interesting discussions about that common aspect of our Southern heritage.

And as many people are, they were interested in the process of creative writing. "Where did you get your ideas?"

It was a marvelous afternoon, sipping wine, having a light dinner, and being the center of attention in a room of gracious Southern ladies.

It's good to be a writer.

Analysis of a Diagram

Just because you like something you created, it doesn't mean:

• It's any good
• You have a big ego

But it can be useful to stop and ponder something you did that you particularly like--so that you can understand your own design priorities a bit better.

I recently created a diagram for an article in UXmatters that I liked:



The article was about the differences in the roles of User Interface (UI) developer and User Experience (UX) designer. I wanted a diagram that showed that each had distinct areas of expertise and that there were areas of overlap as well. Duh, Venn diagram, that's the easy part. My normal instinct would have been to abstract the areas and give them awful nominalizations probably. I decided to use concrete examples instead and to leave the abstraction to the reader. In the article I said:

The area that tends to fall under the exclusive domain of UI development includes the programming skills and knowledge. If you had a pin labeled Ruby on Rails, the UI development role would be a good place to stick it. The area that tends to be the exclusive domain of User Experience relates to user research and usability testing. Thus, if you had a pin labeled card sorting, the UX side of the diagram would be its predictable home. The area of shared expertise between the two roles includes knowledge of UI patterns and standards—the widgets and elements that make up a user interface—as well as knowledge about the software development process.

I like the simplicity of the diagram and for some reason, I especially like the stick pins. I'm reminded of a story about the famous educator John Dewey. He was visiting a classroom once as a superintendent, and the teacher asked the class, "What is the center of the earth composed of?" The students eagerly raised their hands and the teacher called on one. "Igneous rock," came back the answer. Dewey then interrupted and asked, "If I could reach my hand all the way to the center of the earth, what would happen to it?" No one could answer.

My "If you could put a stick pin labeled..." approach seems to have the level of concrete understanding that Dewey was looking for. I like that a complex classification has been explained in terms of a physically familiar task such as putting stickpins on a board.

Doesn't mean it's good.
Doesn't mean I'm being egotistical to say I like it :-)

Regression Testing for Usability

I just had a bad user experience at my bank's ATM. I'm not blogging to whine, they're a good bank, but I want to understand what went wrong with the experience and more importantly, the design process that led to it.

I drive up to the ATM and insert my card. New screen, bright and shiny oooooooh.

First new thing, it tells me to cover the keypad as I enter my PIN. Hmmmm, Not sure how one does that while sitting in a car, so I pointed to the sky and yelled, "Hey look, it's the Goodyear blimp" hoping to distract any lurker who might be there to steal my PIN.

OK, I got my PIN entered and the next screen asked me what I wanted, and I pressed "Get cash."

Then something happened that's never happened before, it gave me a list of accounts to select from. One said "Savings-123456," another "Visa Platinum-7654321," and then one said "CRWN-987654."

Nothing said "Checking." I figured the 1st one was my savings account and thought the second one was probably my credit card. That left me concluding that CRWN-987654 was my checking. We're talking money here and all of a sudden my ATM is giving me practice questions for the SAT. If all men eat turnips and John is a man, does John eat turnips?

So to be on the safe side, I decide to check the numbers on my card to see if they match 987654. Oops, card is in ATM. Cancel transaction to read numbers off card. Ooops, numbers no longer displayed on screen because I canceled transaction.

I'm in the business so I know what happened here. Product management decided to make my membership more valuable by now allowing me to select from multiple accounts when I withdraw cash. That's a good thing. But in doing so, the product has disrupted my familiar experience--turning a satisfier into a dis-satisfier.

When I was at CheckFree, whenever we introduced an enchancement to our online bill pay, we did what I called Usability Regression Testing. In QA, regression testing is when you make sure that a new feature doesn't break existing functionality. I think you have to do the same thing with usability, make sure that new features do not disrupt the comfort and familiarity of the user's current user experience.

Had they tested it they would have seen the whole number on the card in the ATM vs number on the screen thing.

They would have also figured out that CRWN did not mean "checking" to me. By the way, I checked it out with my wife, and apparently that's the marketing name for our service "Crown Checking." Marketing people are bad about that, they assume we are all in love with their product names and therefore familiar with them. Also, it was a huge screen with only 3 accounts, they could have said "Crown checking account" and I would have been OK.

Designers beware. When we improve the feature set, we run the risk of breaking a comfortable user experience. A little regression testing is always good.

Incremental-decremental (excremental)

I just changed cable providers, and this one has the same UI problem as the last. In both cases, if you view the guide (program menu), the channels start at the top of the screen and are listed in incremental order. That is:
001
002
003
...
So if you want to see the next channel after you reach the bottom of the screen, you press the down arrow key. This means you are pressing a DOWN command to go UP in number. For example, to go from seeing channel 7 to channel 8, I press DOWN. No problem, really, because the screen scrolls in the direction I indicate.

But if I am actually watching channel 7 and I want to go to channel 8, I press UP. Of course, I habitually press the DOWN button because my frame of reference is the menu screen.

There is a simple solution: They could list programs on the menu screen starting with the top channels and then decrementing. That way DOWN means DOWN no matter what.

But then you start with the specialty and premium channels on the menu and the not the common choices.

Excrement!

The point is that UI design is snarly stuff and not only must you accommodate user models and technical limitations, but sometimes business rules and market objectives as well.

Squirrel!

Dug, you gotta love him! But I seem to get involved in discussion threads where it seems a cyber squirrel runs through the conversation and everyone gets distracted. It's a good thing we didn't have discussion groups in the old days.

Churchill: Things are looking rough on the continent, the axis forces are massing to eliminate free civilization as we know it. This could be our darkest hour.
Roosevelt: Wow speaking of dark, the power went out last night and Elinor and I had to scramble for candles.
DeGaulle: I hate that, you never know where you put them.
Churchill: But the Nazis and the Fascists!
Roosevelt: Let them get their own candles.
DeGaulle: We can't provide candles for the whole world.

Bleeding Edge

Neil Perlin is looking for participants for the "Beyond the Leading Edge" presentation at the STC Summit in May. Where I stand (click to enlarge):

Click to enlarge.

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.

New award, and a cry for help!

My NSS award goes collectively to all of the accessibility web sites on colorblindness that advised me to offer an alternative to using color to convey meaning.

An open question for my readers:

If an IP address in red means one thing and an IP address in blue means something else, what alternative approach would you recommend for this kind of scenario?

Hump-day Humor 2010-4

Don't you just love working on distributed teams?

Click cartoon to enlarge it.

I have so been here!

I just had to chuckle when I read Dilbert yesterday. I think a lot of UX departments go through this phase. I hate hiring onto a job and then showing up for this as my first meeting (it's happened more than once).

Hump-day Humor 2010-3

Got so busy this week doing real work I totally forgot my Hump Day cartoon.



Click image to enlarge it.

Cause and Effect: A Two-way Loop

Had coffee this morning with my friend Ken Hilburn from Juice Analytics. Essentially, they are in the business of helping customers visualize data. Naturally, we talked about dashboards, a big emphasis of his company. The conversation helped close a loop for me between data dashboards and decision-support embedded user assistance.



Any follower of this blog or my column in UXmatters knows that I am a big proponent that user assistance needs to focus more on domain expertise rather than on how to interact mechanically with the user interface. For example, see my article User Assistance in the Role of Domain Expert.

I've always looked at it primarily from the viewpoint of decision support when asking a user to enter a parameter or make a selection on the UI. Essentially the pattern I support is:

1. Define what the parameter controls.
   
2. Advise what a good starting value is.
3. Advise when the user might want to make it higher or lower (including any tradeoffs).
4. Advise what the user could monitor to assess the impact of their decision, e.g., specific reports or status screens.

What came out of the coffee klatch discussion with Ken was to link the parameter setting directly to the that part of the application where its impact would be evident--and vice-versa. For example, if lowering a heartbeat threshhold parameter could impact server bandwidth, provide a link to the dashboard or system health screen that monitors bandwidth utilization. That way the user sees the baseline value and knows where to monitor for any negative impacts.

On the reverse side, if you have dashboard readouts that are affected by decisions the user makes in an application, provide that information at the dashboard and provide links back to where those decisions can be modified. For example, the bandwidth utilization dashboard should inform the user what kinds of things can make utilization go up (such as lower heartbeat threshholds) and link back to where those parameters can be adjusted. That way, information is linked to action.

And if you're not going to act on information, what's its value?

Embedding User Experience in the Product Life Cycle

I have a new column out today in UXmatters.

All UX professionals, not just user assistance developers, face the problem of integrating their work into the product development lifecycle. At lower levels of organizational usability maturity, too often, the contributions of User Experience tend to be reactive. Usability professionals test the usability of a given product, then designers mitigate any shortcomings they find, and user assistance developers merely document what is already there. This column takes a look at the full scope of the product development lifecycle and how UX professionals can add value. [go to article]