User Adoption: A War with Two Fronts

I know, I ride Rogers' old horse beyond its intended range, but it just stays a useful model for a lot of what I do.

We can identify a point in an acceptance life-cycle with a vertical bar perpendicular to the x axis and somewhere along it. Then essentially we can say that we've got the population to the left of that line on board, and the ones to the right are the resistors we are still trying to win over. So the traditional model in my mind has been "resistance lines up on the right."

But I'm becoming increasingly aware of a negative image to that model, where resistance lines up on the left. Innovators and early adopters will resist efforts to lower the entry threshhold to a technology, preferring to keep the club exclusive. "We had to learn it the hard way, so should they." Or "If you make it too easy, then anyone will be able to [do my job][look as smart as me]."

There are so many examples that I am embarrassed it took me this long to notice it to where I could articulate it. Linux/Unix "We don't need no stinkin' GUI" VCR vs. film, digital camera vs. film, sites like this one vs. hard coding HTML.

This means any user adoption campaign is essentially a war waged on two fronts: Trying to entice the later adopters to come on board while battling resistance from the early adopters to anything that makes it easy for them.

I suspect this problem is most pronounced in non-profit and governmental organizations that are not as driven by the economics of user adoption as commercial enterprises are. I also suspect it is higher in technology communities. No data, just hunches.

Sounds like a good conversation for over beers after your next professional association meeting. Do me a favor and save the napkins for me.

New Menu Idea

Just helped a coworker figure out how to reopen his style and formatting palette in Word. He had shut it down because it was getting in his way, and then he needed it back.

That happens to me a lot. It's gotten to the point that I am so reluctant to turn anything off because I'm afraid I'll never figure out how to reactivate it. Well, every problem is the seed for an innovation!



Hey, I want credit if Microsoft uses this!

Yes, Virginia, there are stupid users.

I just didn't think my wife was sounding diligent enough about looking out for the UPS delivery guy, so I decided to work from home this afternoon so I knew someone would be here to accept delivery of the new guitar.

As I was working in my loft, I periodically checked the UPS tracking site to see if the status changed to indicate it had actually been dispatched. The current status message was a bit vague.

I hit refresh (for the 30th time in 30 minutes) and sure enough the status changed--to Delivered!! That got me a bit anxious, as in "TO WHOM--NOT ME!!!" It said "Garage."

I panicked. They delivered my Mike Auldridge guitar to a garage!!! Then I wondered something, so I went downstairs and opened the door to my garage.

What do you know. A guitar. So much for Mr. Eagle Eye.

I am like so old school

You might remember a blog I did last year about how not to update your look and feel. Essentially it says not to let old people (moi) design anything you want to appeal to the up and coming set of users.

I navigated to one of my old familiar sites and it has gone through a revamping by someone who certainly took my advice:


If you are over 60 (doh! moi again) give yourself about 5 minutes to figure out where to log in. Yes I know it says in BIG letters LOGIN and has a BIGASS button that says LOG IN.

It also has smudges for input fields.

I'm not complaining, "Brave new world that has such creatures in it" and all-- just saying I'm feeling like I'm a kazillion years old.

Maybe it needs a Help file that says "Type your password in the Password smudge." That would help geezers like me.

Mother and baby doing fine

I feel like I'm sending out a birth notice. This afternoon, Mike Auldridge inspected the latest batch of his MA-6 resophonic guitars (his signature guitar made by Paul Beard Guitars). I'm buying one directly through Mike. After checking them out (he still personally inspects all of his signature guitars) I'm told he said, "This one sounds just like mine," and then he set it aside for me.

Wow!

UPS says it will be here Thursday. Someone's not sleeping for the next couple of nights.

Put Personas to Work

Read my column this month in UXmatters; Personas as User Assistance and Navigation.

Requirements vs. Constraints

I love "x" graphs, you know, the ones that show one domain diminishing while another is increasing. They form an x, and the point of intersection represents a sweet spot or break-even point. These days, I feel like I'm living the one shown below:

The more feature-rich a particular design approach is, the more it delights product management. Of course, that starts to overload available engineering resources which drives their delight down. Being a UX designer puts one in this position a lot. On the one hand, you want the product or service to be a differentiator in the market place, one that carries a lot of delight to the customer. On the other hand, it has to be build-able within the constraints of the organization's resources.

So you look for that acceptable area of compromise, somewhere close to the intersection of the two lines. Something achievable that represents enough delight to be a package you can take to market. You end up playing devil's advocate at times, pushing back on product management and goading engineering to stretch. You need to be sensitive to when to back off and say, "OK, I hear you, let me see how I can make the design accommodate that."

In the end, you have to have both sides at the table at the same time, otherwise you find yourself in a series of no-win situations where you are the bearer of the bad news (the areas shown in gray). It also helps the spirit of compromise if each side can be connected to the other's point of pain. Engineering is more willing to bend when they deal with Product Management directly, and Product Management is more willing to compromise when Engineering says "Our schema can't accommodate that kind of a query." Also, each side can hammer out alternatives a lot more efficiently when talking to one another. I'm always impressed how creative engineers can be if you share the problem with them instead of insisting on a particular solution.

This could be one of the most important skill sets a UX designer develops, the arbiter of user requirements and product constraints.

Thanks to TTU

I spent last Thursday immersed with the students and faculty of Texas Tech's online Technical Communication and Rhetoric (TCR) PhD program. Actually, it all started on Wednesday evening with a delightful dinner at Dr. Tommy Barker's home. Tommy is head of STC's Academic SIG and Director of Technical Communication at TTU. Texas-style, nothing was done small or half way. Tommy had even procured a Dobro for me to use so we could do some bluegrass/rock-a-billy picking after dinner. Tommy played a mean acustic guitar and fellow faculty member Ken Baake joined us on banjo. For those in need of a scary thought to haunt you through the day, I have two words: PhDs yodeling.

Thursday morning I listened to doctoral students talk about their research projects, and I gave a keynote talk during lunch on the role of PhDs as practitioners. I spent the afternoon with Dr. Joyce Locke Carter, the Director of Graduate Studies in TCR, sitting in her usability class and touring their usability and multimedia facilities. That evening the students invited me to a barbecue.

I feel like I have seen the future of technical communication, and we are in good hands. The students were engaged in exciting research projects and projected more energy than I have encountered in a long time. The quality of the program is impressive, from the faculty--which reads like a list of academic Who's Who in technical communication--to the caliber of the graduate students (the TCR program accepts only 20% of its applicants).

The students work online most of the year, but spend two weeks working through an intensive "boot-camp" style program every summer. What I find most impressive about the program is the community of scholars this is developing for our field. TTU has worked out an effective formula for combining distance learning with face-to-face networking. And because these students have become accustomed to collaborating online, they will stay connected and influencing each other for the rest of their careers.

Congratulations to TTU for an excellent program, and thanks for the hospitality. That, and a hearty i-e-o-d-lady-hoo.

Robert's Rules of Order: Essential for UX?

I'm always amazed when information acquired in one context emerges to be useful in an entirely different environment. As a member of the STC Board of Directors, and its current president, I've had to learn a lot about Robert's Rules of Order. I even have my own dog-eared version that I referred to a lot during some tricky proceedings this past year. One would think, what could be more esoteric and useless in the real world of user experience design than parliamentary law? It's not like we aply that kind of formality in our Agile scrum meetings every morning.

"I move we develop a regex to capture the time stamp field."
"I second that."
"Discussion?"

So I'm working these days on trying to design a report format around a particular data security standard. I've spent a lot of time trying to understand the standard and what it requires of users and what it would require of our product. I suddenly realized that my analysis was feeling like the kind of research I did on Robert's Rules. I don't think I could have critically analyzed the standard nearly as effectively had I not had the experience of trying to critically understand Robert's Rules so I could use them effectively to move my agenda forward.

I'm used to getting a lot of value from my involvement as a volunteer with STC; even so, I was pleasantly surprised to see that the legal-like research I had done on parliamentary law paid off in developing skills later useful for researching a data security standard for a technical communication project. It's taught me to be more mindful of what I can take while in the act of giving. And hey, there's nothing wrong with that. The more we let ourselves benefit from volunteering, the more willing we are to volunteer.

Mantra for today: Do good; get smarter.

Happy Monday

Thanks to [unnamed product]'s registration site for giving me the ability to leap through the torn fabric of time and space.


Either that, or their UI developer slept during the lecture on Boolean logic. Or they think I'm quite large.

Also, check out my new motivational poster at http://cheezburger.com/View/3534870016

Recalculating

We have a Scrum Master (someone who manages an Agile team) who has nerves of steel. No matter what goes wrong, he just recalculates the new path to the solution from the new location.

My hard drive crashed last week in Houston and the Gibson Original Acoustic Instruments factory in Nashville got flooded. They were to ship my new Dobro guitar to me in two weeks.

So there I am in the Sheraton business center trying to recalculate my life. I had once lusted for the Mike Aldridge signature guitar from master luthier Paul Beard's shop. Too pricey at the time. But maybe the Nashville flood was an act of God--literally. After all, I first got interested in Dobro almost 40 years ago when I heard Mike on the radio. I bought his album, Mike Aldridge--Dobro, and I still have it. My wife reminded me the other day that I've had that album longer than I have known her.

So I went to Mike's web site and it listed a number to call to order directly. Well, by direct they meant like Mike Aldridge answers the phone. I was dumbstruck and stuttered and stumbled through something like "OMG, you're my hero, etc." Happy ending, I order new guitar from Mike who will pick it out himself from the batch that will be done last week in June. (Sweetheart of a wife is financing the difference between this one and the other.)



So that part's handled. Now, I just have to restore everything I lost on my hard drive. From here on out, I'm doing everything in the cloud. Kinda goes along with the whole act of God thing.

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]

Usability Risk

Granted, I'm still in the honeymoon phase on my new team, but what a honeymoon! This week we had some great meetings with key players to define the role of the UX Architects and add that to the existing team roles. There's a double gasp here. First, this team already has a well-defined Scrum process that identifies all of the roles, and which documents what their activities are before, during, and after a project and a Sprint. Second gasp is that they are including the UX Architect role in that documentation to ensure that we all understand how we support the development of new services.

As we discussed the different things we could do and could produce, we noted that not every feature (or story) would need the full rigor of every UX activity and every UX artifact. So one of our important activities at the beginning of each project and each Sprint is to determine the level of usability risk each feature or story could have and to plan the appropriate level of UX involvement.

Usability risk is a concept that I first learned while working for my Usability Hero/Mentor Loren Burke. Loren had started his usability career at IBM as a project manager in charge of saving programs that had landed in the ditch. He developed a keen sense of the need to identify user acceptance issues that could kill a product or web app and then focus on those items. Shout out to Loren!

The other UX Architect and I now need to codify what criteria we will use to assess usability risk for our kinds of products. My own brainstorming would start with these considerations:

• Is there a UI? (No UI equates to low risk.)
  
• How complex is the UI? (Greater complexity means greater usability risk.)
  
• How much interactivity is in the UI? (The more ways there are to interact, the greater the risk.)
  
• How tied in is the UI to a critical business driver? (Don't spend resources on features that represent minor impact on the business success of the product or service.)
  
• How new are the interactions and content in the UI to the development team? (New stuff carries risk.)
  
• How new are the interactions and content in the UI to the user? (New tricks for old dogs are risky.)
  
• Where in the user task flow would the UI occur? (Earlier equates to higher risk--users are more judgmental during first impressions. Loren's greatest contribution to usability was creating the concept of "judgment window," the early user experience with a product or service that flavored their ongoing acceptance of the product or service.

What other risk criteria do you use? What would you add to this list?

The power of an example

I had a really stupid user experience yesterday, so I am trying not to squander my ignorance and understand what went wrong. More importantly, would a difference in the design have helped?

So I'm having to set up a two-layer authentication set of credentials for myself. I have a keychain fob with six digits electronically displayed, and the digits change every 30 seconds (these digits are in synch with the network I need to log onto). So I need to set up a PIN for myself, and then when I log in, I use both my PIN and the currently displayed digits from my fob. So if someone figures out my PIN, they still need my fob to get the digits du jour (or digits du demi-minute in this case) to log in. If I lose my fob, whoever finds it still needs my PIN to get into the network.

OK, for starters, that bit of conceptual knowledge would have been useful up front. I would have understood what I was setting up and how it needed to work when done.

I got an email with a set of instructions. There were liberal screen shots which initially made me feel good (even though I didn't want them to because I'd like to believe that users don't need screen shots.) As it turned out, the shots didn't help and even hurt in a way.

So the process had me create a PIN (4-8 alpha-numeric characters) and then asked me to log in on the screen shown below (click on image to enlarge it):


Up to this point, the instructions had talked about a CODE (the six digits on the fob) and a password (my original system password to get into this set-up-an-authentication task), but had never talked about a PASSCODE. The written instructions had a screen shot (just like the diagram above, but an actual screen capture) and said: Wait for the Next Code on your Token, then enter your PIN+CODE.

When I went back after finally being successful, I realized exactly what that meant and I wondered why I had had so much trouble. Here are the ways I got confused:

• The screen wanted two pieces of information but I had only one field.
• What does "response" mean?
• The screen capture with the asterisks didn't give me any clue as to what should be in there.
• What I call a fob they were calling a card.
  
• What the hell is a PASSCODE?

So I entered my new PIN and pressed Enter. Nope
Entered my system password. Nope
I experimented with CODE then PIN (because most applications I use with a PIN, that's the last thing I enter.) Nope.
Finally, I figured out that I had to type my PIN followed by the CODE on the fob and then click Continue. Well, that's exactly what the printed instructions said (after you wrangle with do you type a + sign or not).

Lessons learned:

• It's hard to bounce back and forth between screen shots of instructions and the actual screens.
• An upfront conceptual paragraph that described how two-level authentication worked would have helped.
• And how about this for the screen design (click on image to enlarge):

Since the code is always six digits and the PIN can be alpha-numeric, I think it's pretty clear what is being asked for once you see the example.

Hump-day Humor 2010-2

Click on comic to enlarge it.

Urban Camping

My wife is out of town this week so I thought it would be a good time to rotate some of my camping provisions, you know, packaged food with a half-life of radium. I keep a store of these items so I can go off in the wild for up to three days without going shopping first. But I think once a man hits the age of five a good guideline is not to eat anything that's been dead longer than he's been alive, and some of my SPAM cans are approaching that.

The exciting news is I discovered a new way to eat SPAM! I made SPAM gyros the other night. I stopped by the store on the way home and bought a small single serving of plain yogurt, a cucumber, and some dill. I mixed these together and that made the gyro sauce. I sliced the SPAM into long, thin rectangles and fried it in the skillet. I then lathered the sauce onto a low carb tortilla wrap, added some sliced onion, shredded lettuce, and the fried SPAM. SPAM lovers (and you know who you are) you must try this!

Management as a discourse community

We had a lot of organizational restructuring the past week at work, and a lot of managers flew in to communicate the changes and sell the positive impact they would have on the business and our lives as employees.

Personally, I was impressed by their coming, their genuine enthusiasm, and the content of their messages. But no good deed goes unpunished, and I've heard more than one smirking mimicry of phrases such as "leveraging the synergy" and other cliches popular in management-speak. This is not a local phenomenon, I see it all over, from Dilbert to STC meetings; people like to make fun of the way business managers talk.

Stop it! Every discourse community has its jargon and its cliches that are important vessels for cultural values and which are rich in meaning within those communities. Discourse community itself is a jargon-like word that I'm sure seems odd to someone not familiar with communication research. I made fun of it the first time I encountered it when I was starting my Masters in Technical Communication and ran across it in an article in the STC journal Technical Communication. Its only replacement would "a profession or otherwise socially-linked group that tends to communicate among itself and which develops a set of communication norms and vocabulary peculiar to itself." Gets to be a lot of words.

Cliches play an important role in efficient communication. Walter Ong talks about their importance in Orality and Literacy as being a cornerstone of oral tradition (making memorization easier and thus protecting the integrity of a message over multiple repetitions). Although English teachers would tell us they are empty of meaning, I think linguists and anthropologists would tell us they are rich in meaning beyond what the bandwidth of their symbology would allow otherwise.

So I put making fun of manager-speak right down there with comments such as "Is Google a verb?" Hey, we're trying to talk to each other here, folks; more listening and less critiquing would be helpful.

UX Design vs UI Development

One of the more interesting tensions I have observed since getting into User Experience (UX) design about five years ago is the almost sibling-rivalry-like tension between UX designers and User Interface (UI) developers. At the heart of the tension is that most UI developers consider themselves (rightfully so) to be UI designers. The coding part is like Picasso having to understand how to mix paint; it's not the value-add, just the mechanics of delivering the creative concepts.

When I was working on the STC Body of Knowledge task force, the interesting question we wrestled with was, "What value does a technical communicator add above what could be done by an engineer who writes well?" The UX designer or architect has the same problem to solve, what value do we add that differentiates us from a UI developer who is user focused? It strikes to the very heart of what differentiates us as professionals from UI developers. If we don't provide a compelling answer, the only one left is they code and we don't. Hmmmm, makes them sound like the better value proposition.

I was reminded of the import of this in a meeting yesterday where a UX designer lamented that he had approached a product manager of a new product with the question, "Have you thought about how to ensure the quality of the user experience?" The product manager's answer was "Oh yes, so and so is developing the UI," where so and so was a talented and user-focused UI developer. So how do we break into the process when that happens?

I thought about it on my drive home (on almost empty roads because two millimeters of snow had been predicted for Atlanta and the town was shut down in anticipation) and wondered how to counter when presented with the common pattern of "We have a talented developer working on it." I think I would come back with, "Great, he's good! Where is he going to get his user data?"

I think a mistake we sometimes make as UX designers is we believe that if the race starts at wireframing, we will win. But if that's where the race starts, we have no advantage over a talented programmer. It's not like we have the secrets about design patterns and best practices in user interactions. UI developers are there and in many cases were the ones who pioneered those patterns and best practices.

I think our professional value is in our processes and artifacts that help inform and validate design and development around user needs. I have a column coming out in UXmatters next week that goes into more detail, but my realization is that when we do a wireframe or prototype it should be a method of communicating data-driven or at least process-driven design considerations. Or, as it often was the case at CheckFree when I worked there, it should be a strawman that starts a collaborative process of review and refinement. (Sometimes it was like being a UI sketch artist--draw a nose, any nose, so the witness can say broader, thinner, whatever.) The best case is when it is both a visual communication of data-driven requirements and a working space for collaborative input.

So I think our value is that as professionals we follow a process that includes data gathering, data validation, collaborative design, and design testing. That way we channel the talents of the developers and support their design by informing them of user needs and then validating that the emergent design meets those needs.

If we just think of ourselves as better UI designers, we lose the true value proposition to talented designers who can code.

Hump-day Humor 2010-1

Click to enlarge comic.

New Year (Job) Resolutions

I'm starting a new job on a new team today, so it's a good time to summarize for myself the advice I give to others when they start a new position.

1. Let the others impress you. The problem when we join a new team is that we are eager to "show our stuff" and earn the respect of our new peers and bosses. But they are eager to do the same with us. A new guy is a disruption of the status quo and so you must let the other members of the team re-establish their status with you. Relax, you got the job--the starting assumption for everybody else is that you are coming in smart and successful from your previous gig.
2. Cater to the group's self-acknowledged areas of weakness. Try to assess how the team sees you as adding value. We have a tendency to want to recreate past successes, but first understand the new problems and how the team sees you as part of the solution. For example, if a team thinks they have lousy templates and that's what they want you to work on, but you think their standards and style guides suck, work on the templates! Don't try to force yourself as an answer to a problem they don't think they have.
3. Build something. You need to learn a lot, and there is a tendency to read, read, read. That just leads to forget, forget, forget. Build something that forces you to engage with the content you are trying to learn and that will give you a residual artifact. For example, don't just browse the portal you will be redesigning, build a site map of it. Build a Wiki that captures links to the resources you are discovering, construct a user matrix. Whatever.
4. Don't squander your ignorance. You are about to see a lot of things for the first time that you will never see for the first time ever again. Stay focused on what that experience is like for the user. (Keep you mouth shut, however, and pay attention to points 1-3.)
   

Happy New Year, everybody!

New title; broader mission

New year's upon us and it's time for some changes. I'll be starting a new assignment in 2010, as a user experience architect embedded into a development team for managed security services. I've moved somewhat from what my focus was when I first started this blog. Then my focus was on user assistance; now I have much broader responsibilities for shaping the total user experience. Of course user assistance stays a part of those broader responsibilities.

I now get to concentrate on an old passion of mine, going back to my CheckFree days, and that is how to integrate user experience design into the technology design and development process. I like being embedded in the design and development team, a model I worked in at CheckFree. I have a basic disagreement with Jabob Nielsen who measures the maturity of a user experience presence in a company by how independent its practitioners are organizationally. It takes me back to my old manufacturing days where we felt that Quality had to be managed by someone outside the production chain of command. Later thinking changed to putting it back onto the shoulders of those who made the product. I feel the same way about usability and user experience design--it is an intrinsic part of the product and should not be separated from the measure of good code writing. Code that works well but renders a lousy response time would not be regarded as good code; nor should code that renders a bad user experience.

I'm not naive about the implications that producers, anxious to meet due dates, will push out bad product if not overseen by third-party watchdogs. Well, that's the challenge that fascinates me. I think the solution is in well-defined processes and well-written requirements, not in separating functional requirements from non-functional.

The new Blog title is a bit of an homage to Jeff Raskin who wrote The Humane Interface. My focus will be on understanding how we as humans interact with technology and how to design technology to accommodate that.

Happy New Year, everyone.

Important message

Click cartoon to enlarge.

Click cartoon to enlarge.

Useful Web Site

Check this new site out:
http://www.indoition.com/index.html

It's a vendor web site with all kinds of useful links to get you to bookmark it and send other folks there. Doh! Got me!

Contest Results

See the contest.

OK, here's the official explanation, and then I'll reveal the winner.

First off, thanks to everyone for not challenging which character was Kitty and which was Maria. One person tried to at work, and I hit him. (Duh, the one's that's a CAT is Kitty.)

Panel 1 has Kitty citing Fitts Law, which basically asserts that the time to move to and click on an object is a function of the size of the target and the distance the user must move the mouse. Kudos to EagleSongs for recognizing the law, but that would make Kitty the UI layout designer, someone who would be interested in things such as button location and size.

Panel 2 has has Maria citing Hicks Law, which asserts that the time it takes a user to choose among options is a function of the number of choices the user is presented with. That would make Maria the Information Architect. (Note the base 2 logarithm, on the assumption that choices are binary and the search can take advantage of a decision process that progressively cuts the available options in half.)

Here is a UI that is optimized for both laws:


Panel 3 is, as several pointed out, the opening of Hamlet's soliloquy expressed as a Boolean formula. A more graphical representation would be:



That would imply that the two met while taking a course in English Literature.

Technically, Siska provides the right choices, but her linking Maria with Fitts Law is wrong.

Anindita provides the most elegant explanation of the layout designer and information architect rationale, and although her answer to the third question is different from mine, I'm going to accept it and name her the winner!

Congratulations, Anidita. Send me your mailing address and I will send you your very owned signed copy of Iron Hoop.

Geek Fight!

I'm doing the comic early this week and throwing in a contest.

Click to enlarge comic.

Click to enlarge comic.

Here's the contest

The first to answer the following questions correctly and sufficiently explain their answers (no guessing) wins a signed copy of my novel Iron Hoop [shameless self-promotion].

Kitty and Maria both work in the UX department and went to the same geeky school. They have a lot in common, but take two different looks at UX design.

1) Which is the Information Architect?

• Kitty
• Maria

2) Which is the UI layout designer?

• Kitty
• Maria

3) When they first met and became friends in school, what elective were they both taking?

• World History
• English Literature
• Economics
• Technical Communication

Submit your answers as comments to this blog post.

Elegance

If you think quality and craftsmanship are dead, and you think that design is a lost art, look at these two working pieces of equipment from Shubb. They are both accessories for playing Dobro. Santa's bringing me the capo (I already have the slide). If you think the slide looks nice, you should heft it and position it in your hand. Ooooh, makes me all goose-bumpy.

The Gary Swallows slide


The Shubb capo

Dominant and Passive

This one is too weird, don't even read it. I'm only putting it in a blog so I can find it later if I need to ask my doctor to up my meds.

I don't count sheep when I can't sleep. Instead, I try to visualize Dobro licks and how I would notate them on a treble staff. I had a couple of aha! moments the other night:

1. The middle three lines on a staff are the same as the G tuning on the dobro: GBD. This is important because I am a reaaaallllyy sloooooooowww reader of music. I usually have to start at the bottom and say Every Good Boy Deserves Fudge or spell FACE. I also have a hard time remembering what order the letters of the alphabet are in, so if I'm looking up a word in the dictionary, I have to sing the ABC song to figure out where in the dictionary to go. Fortunately, I can start with elemenopee if I know the letter is in the second half of the alphabet and that saves some time. Now, I can read the middle lines of the staff without having to start at the bottom. That's handy in much the same way as being able to start the ABC song at elemenopee.
2. I've been trying to decide in a certain song (Shenandoah) how many frets down to start a slide at "A-a-way you rolling river." I was doing it starting a half-step below the G and also a full step below the G. As I tried to notate the variants in my head, I realized that the choice was between going to the 7 note (F#, one half-step below the 8 note, G) or the flatted 7 note (F, one full step below). As I did the notation in my head, I realized that the full step, taking it to the flatted 7 note, was really establishing the dominant chord (G7) and setting up a nice transition from the I to the IV chord (G to C in this case). I would not have noticed that had I not been notating the phrase instead of just playing it by ear.

I've been rereading Orality and Literacy by Walter Ong in which he examines the assertion that literate societies think differently from oral ones (where there is no written language). It made me ponder, at point 2 above, if literate musicians (those who read music) think differently than folk musicians (those who have an oral tradition for learning and passing on music). I thought differently about the phrase when I read it than when I played it.

Then that led to thoughts about the dominant chord and its role in establishing transitions and the various ways we deal with transitions in written language. Joseph Williams in Style: Toward Clarity and Grace talks about using the given-new rhetoric. Make the thing or concept that is already known to the user (the given) the subject of a sentence and then make the new thing or concept the predicate or object. Then in the next sentence, you can take the concept that was the object in the first (the new) and make it the subject (the given) in the second.

For example, "The traditional newsletter is giving way to the blog. A blog (web log) allows readers to comment openly. These comments can validate or challenge the writer or even other readers."

This technique leads to an often overlooked use and justification for the passive voice: It allows us to make something the subject of a sentence (so it can occupy the "given" slot) that would normally be the object of the sentence in an active voice construction. Example, "The computer generates a configuration file. This configuration file is saved to the local disk drive at the end of the session."

One more observation about transitions. We often signal transitions with "metadiscourse," that is, discourse about discourse. For example, in the examples above (as well as in this sentence--gawd this is so surreal) I have used the phrase "for example" to signal the user what the role of the sentence is. Other metadiscourses are "On the other hand" (signalling that a contrast is coming) or "Consequently" (signalling that a conclusion is coming). I have become a firm believer that since these are signals for a shift in meaning, they should always come at the beginning of the sentence. Look at the following.

Different roles will expect different information. Engineers, for example, want to see....
Different roles will expect different information. For example, engineers want to see...

I like the latter, the metadiscourse is at the beginning of the second sentence and does not separate the subject from the verb. Not true in the first case. It seems a little less stylistic and dramatic, but technical communication is about clarity.

I'm thinking Ambien, large doses of Ambien.

Life with Mike

Click cartoon to enlarge it.

Click cartoon to enlarge it.

The new magic number

Miller's famous study on the ubiquity of 7 in short term memory aside, I have my own candidate for a magic number:

1/√ 2

The decimal equivalent is approximately .707, which is a kind of cool looking number (it's approximate because the square root of 2 is irrational, another cool aspect). But its real significance is that if you square it you get 0.5 or ½.



OK, why the math today? I'm trying to figure out how to cut my work in half. Why? Because if I get laid off I will hire myself out as a documentation consultant with my specialty being that I can reduce documentation by half. Hey, in a bad economy, sell hamburger and beer.

So here's my radical (pun intended for my mathy geek friends) approach:

1. Look across the breadth of what's being produced and reduce it by 30%. A 30% reduction is not that hard to find.
2. Look at the depth of what's left and reduce it by 30%.

The net result is that you're left with half of what you started with (actually a little less because of rounding).

Gotta run and get a copyright or a patent or something on this.

Editor Fight!

Click cartoon to enlarge

Click cartoon to enlarge

Reverse Engineering SIGs

This blog is very STC centric (as it seems a lot of my life is these days). I just got off a strategic planning call where we were discussing ideas for expanding our income base. I noticed that several of the areas that had been identified involved taking what we already have, e.g., webinars and training, and marketing them into other professions. Part of an action item I was assigned was to help identify what those other professions might be.

As I thought about how to go about doing that, it occured to me that many of our Special Interest Groups (SIGs) are really focal points for larger professions. Our SIGs, in those cases, focus on the technical communication application. For example, Usability and User Experience is a large profession outside of technical communication. Our Usability and UX SIG focuses on the technical communication specific applications of that field as indicated by their mission description: "The Usability & User Experience SIG focuses on issues related to the usability and usability assessment of technical communication..."

So SIGs are like areas where outside professions insert specialized instances of their expertise into our profession. But what if we could reverse that gateway?


Our SIGs could be an excellent outreach channel to market our specialized knowledge into those other professions.

For example, my "official" professional education is in instructional design and technology. As I was getting my PhD in that field, I found a great formula for getting published. I would specialize ID topics for technical communication, and then I would specialize technical communication topics for ID. Instructional designers are pretty smart folks, but you know, they don't know a lot about writing manuals! Look at the raw .doc file that a "classically trained" ID person does and you will not find a style tag anywhere in it. And what ends up in headers and footers is any body's guess. So I was able to use my technical communication expertise and spin it to meet what I knew their needs were, i.e., how to design and develop student manuals.

Our SIGs are a great opportunity for us to do the same as a Society. Look at the list of the current STC SIGs:

• Academic
• AccessAbility
• Canadian Issues
• Consulting and Independent Contracting
• Content Strategy
• Emerging Technologies
• Environmental, Safety, and Health Communication
• Europe
• Illustrators and Visual Designers
• Information Design and Architecture
• Instructional Design & Learning
• International Technical Communication
• Lone Writer
• Management
• Marketing Communication
• Online
• Policies and Procedures
• Quality and Process Improvement
• Scientific Communication
• Single Sourcing
• Technical Editing
• Usability & User Experience

Some, like the geographic specific ones don't meet this model, but most of them represent professions that could use training or other resources around technical communication expertise aimed at the specific needs or contexts of their industries.

So I'd like SIG folks to start thinking about what it is about technical communication that could be of value to the professions at large your SIGs represent. How can we reverse the star gate and insert ourselves into their worlds? Specifically, what are the professions and what would be good topics?

Dip Management

Make sure the chip is thick enough to scoop the density of...oh wait, it's not about that kind of dip. Today's blog is about managing technology acceptance and the negative dip in user performance and proficiency that occurs when the user must learn a new tool or new technology.

The figure below illustrates a phenomenon known as the "j-curve." Dotted line "x" represents the user's current state of proficiency using the current tool or technology. Dotted line "y" represents the user's potential new level of proficiency with a tool or technology innovation. Hooray, look at how much better the innovation will make us!!!



Uh, what's that nasty little dip at the beginning all about? What's up with that? Well, that's the reality of the j-curve; it reminds us that we go from one moment being very proficient with our current tool or technology to being pretty stupid with the new one. This is why I hate doing upgrades, I go from smart to stupid in the time it takes to click "Install Now." They might as well relabel the button:


How bad the dip gets is indicated by the distance labeled "A." I am working on a current project where one of the managers named that area "the valley of suck." How much better the new proficiency (or user experience will be) is indicated by the distance labeled "B."

So the basic question every user ends up answering is Was the improvement labeled "B" worth the pain and humiliation labeled "A?"

Example

I recently sat through a presentation where Tom Gorski, STC Director of Communication, demonstrated what the new electronic version of our magazine Intercom would be like.

My first reaction was "bright and shiny, cool" but then very quickly as I watched Tom click this, mouse over that, and a variety of other user interactions, I felt a dip in my enthusiasm--along the lines of "Gee, ten seconds ago I knew how to read a magazine, seems I don't any more."

Then I began to realize that with this new kind of magazine came a new level of power, due to new ways to navigate, search, drill down, and email snippets to friends that did not come with Intercom as I know it and love it today. I also saw how advertisers could provide links in their ads. Hmm, double thrill here. As a board member my first reaction was, great! added value to advertisers (more STC revenue), and as a reader I was equally pleased. As with most professionals, I find vendors to be a major channel of professional education. That's why the Expo hall has become such a mainstay of professional conferences. Being able to click over to their web sites would be a positive for me.

In short, as I better understood my potential new value distance of "B," I became more willing to tolerate "A."

Take-aways

A couple of lessons come out of all of this:

• As technical communicators, we need to help users understand the improvement represented by distance "B." This means overviews of upgrades and new technologies must be benefit-oriented and situated in user contexts. Help make that formula B/A more acceptable by making B bigger.
  
• As technical communicators, we need to minimize the pain represented by distance "A" through good user assistance. Once again, make B/A more tolerable but this time by making A smaller.
  

And as users ourselves, we should try to understand better what the new proficiency level "y" is and accept that some effort is required to get there. As I think back on all of the innovations I have opposed, most of them I would now fight for to the death if you tried to take them away from me.

OK, Twitter I would only fight for to near-exhaustion, but you get the point.

Edit my Wiki, please!

Click cartoon to enlarge.

Click cartoon to enlarge.

Comic Relief

As part of a project I'm working on, we are going to develop a comic-style collection of user scenarios to help communicate best practices around a security service we are offering. This is just experimental at this stage, mainly doing a concept piece to see 1) will it work and 2) will stakeholders buy into it. The model I am using is Google's Chrome's Googlebook for web app developers.

There can be a number of advantages to using a comic-style treatment:

• Overcome traditional disinterest in "User Guides"
• Allow a friendlier, instructive tone
• Use line illustrations of screen areas to focus user attention on critical details
• Use "illogical" shifts, such as going from a "white board" type overview to the narrator standing in front of a large UI pointing to an area of interest
• More easily translated than screen cam tutorials
• Can be randomly accessed for review purposes (something hard to do with video-based training)

The coolest part, though, is this gives me a legitimate reason to be playing with comic styles while at work and on the clock. How cool is that? Actually, I have a real by-gawd graphic designer assigned to the team, but I need to get more familiar with the genre...yeah, that's the ticket; I'm doing comics at work to get more familiar with the genre. Actually, my next column in UXmatters does deal with how I use comics in an internal Wiki-based status report.

So for a while, Fridays will be "Comic Day" in this blog. Just trying to get immersed in the genre--all work and profession related. I'll try hard not to enjoy myself :-)

Veterans Day

I am sitting in my cube in my "Army Strong" baseball cap and my khaki green fatigue-style jacket with my sergeant pins on my lapels. I was a patriotic draft-dodger of the late sixties: Low draft number so I enlisted and became an Arabic linguist for the Army Security Agency. It got me to Ethiopia and out of Viet Nam.

Actually, my tour was fun--more like a PG-13 Hunter Thompson episode--so I take the opportunity today to thank those who have truly served and who are serving by going into harm's way.

Thanks

\:-| (lame emoticon of a salute)