Thursday, February 24, 2011

If I only had an *

My favorite quote from the Wizard of Oz:

Why, anybody can have a brain. That's a very mediocre commodity. Every pusillanimous creature that crawls on the Earth or slinks through slimy seas has a brain. Back where I come from, we have universities, seats of great learning, where men go to become great thinkers. And when they come out, they think deep thoughts and with no more brains than you have. But they have one thing you haven't got: a diploma.

I'm designing a new user experience for submitting technical support requests. The support folks said customers aren't giving them enough information and they specified what fields they wanted to be required. So I mocked up a form and put "*" in front of the required fields. Then I cross referenced it against the existing form and found mine was pretty much the same--except for the asterisks.

Pretty powerful thing, an asterisk, apparently it can make our users smarter.

Wednesday, February 23, 2011

When did I become "that guy?"

Five months ago I was in the camp of "All I need my cell phone to do is make and take calls." Then I realized that sooner or later I was going to need to design user experiences for smart phones and that I had no direct experience as a user. So I cowboyed up and bought an iPhone.

Fast forward to yesterday. I got a call from our customer loyalty manager late in the afternoon (on my iPhone). We are doing a big customer hoo-hah thing today and we were out of Post-it flip charts. (Who you gonna call? Apparently the UX guy!)

So I go down to the conference room to see what they need. They showed me what they had and suggested I write down the part number and description. "Not necessary," I said. I took out my iPhone and opened my RedLaser app. I scanned the bar code and got a description and the pricing for all the local office supply stores. I put the address of the closest Office Depot in my Google Map app and used my iPhone's GPS to get there.

When did I become "that guy?" Five months ago I'm all about "I don't need no stinkin' camera in my cell phone," and yesterday I'm laser scanning bar codes with it.

Lesson for UX: Discount NO technology. The adoption rate happens in dog years, if not faster.

Wednesday, February 09, 2011

Hughes' Law of Non-linear UX Time

I've always wanted my own law. Here it is:

t=log(UX) 

User experience time is logarithmic. The user's first 30 seconds on an application or web page is as important as the next 30 minutes. And that 30 minutes is as important as the next 3 hours.

Loren Burke, my usability mentor, created an entire business fixing the first 30 minutes of products that were about to be launched or which were already in trouble.

I am reminded of this as I am working on dashboards right now. Manage the first 30 seconds, then the first 30 minutes.

The next question then is whether to move on to the next 3 hours or to find another 30 second/30 minute problem to solve.

Wednesday, February 02, 2011

The Spherical User

Just read a great joke--OK, a joke I liked at any rate.

"A dairy farmer, in a fit of desperation because his cows aren't giving enough milk, consults a theoretical physicist about the problem. The physicist listens to him, asks a few questions, and then says he'll take the assignment. A few weeks later, he calls up the farmer, and says 'I've got the answer.'

'Tell me,' pleads the excited farmer.

The physicist starts his answer by saying, 'First, we assume a spherical cow...'"

Physicists often have to construct clean, clear-cut laws to describe messy realities. They do this by cleaning up their concepts about reality, assuming frictionless surfaces, loss-less mirrors, and yes, lots of spherical objects.

UX and UI designers sometimes do the same thing, assuming a spherical user who knows what he wants to do, will not make errors in doing so, and will do it in an environment that supports his objective, his timing, and everything else idiosyncratic about him.

Anything outside of those design boundaries we term "edge cases." The result is often a design that works great when it works and that really sucks when it doesn't.

I admit that I laughed at the cow joke, but it was a nervous, could-this-be-me laugh. Maybe because in my Agile zeal, I try to avoid over-thinking the solution at the front end. My scenarios are happy paths that lead to success.

But I'm going to stop and pause more and ask myself, "How can someone do this wrong?" Anyone have any experience or ideas on how to implement that step systematically in an Agile model?

Tuesday, February 01, 2011

The Degentrification of User Assistance

A theme I have watched for awhile has finally caught up to me. There has been a steady movement away from using professional technical writers to produce user assistance and, instead, let subject matter experts do it directly.

Some examples:
  • Wikipedia (I use it all the time to understand security concepts my products naturally assume I already know.)
  • Product-sponsored social networks that let users pose questions to product experts or other users
  • Open social networks where users pose questions for other users in the audience, e.g., Twitter and Linkedin
I am working on a project now to revamp an Internet portal for managed security services. There is a  requirement in the project to provide contextual help at the page level. But there are no technical writers. To date, there has been no formal approach to user assistance, and this particular portal offers a varied set of documents available to users. There are PDF mini-papers, PDF user guides, HTML help for some pages, Knowledge Base Articles that are available to the public, and video tutorials and best practices documents provided by a training group.

And there was a strong sentiment among the project stakeholders to have SMEs write the content directly without having to require engineering intervention to post new topics or edits to existing topics.

As someone who still feels he is a technical writer at heart, my initial reaction was mixed. On one page our current online explanation reads, "This report is ran every hour." Ouch. Also, last year I pulled in user guides from a third party vendor where none of the procedures had numbered steps. Yes, this is what happens when you let untrained writers generate unedited content.

But let's remember Sturgeon's law: "Ninety per cent of everything is crud."

The truth is that in those examples above, there was also some very useful information--just badly written. On the other hand, take a look at professionally written Help and you will find your share of well-stated, correctly punctuated crud. "Type your user ID in the field labeled UserID." Well said but still crud!

My job right now as the UX architect on the project is to translate these high level requirements into scenarios and the starts of stories so that my Engineering cohorts can estimate the various features. So with apologies to my technical writer friends, I have embarked on creating a design that will make it easy for SMEs, who have insight about how to get value out of our portal and services, to pass that insight along. I want it to be easy for the SME to post, and easy for the user to get to it.




So I'm looking at a split pane, embedded assistance panel. The top pane will be for tips and definitions and the bottom pane will be for links to larger files, such as video tutorials and PDF documents that offer more extensive information. It can also contain links to KBAs as well. The split pane approach keeps the external links above the fold.

I'm asking the Engineers to code it to look for HTML files in a database, and to make that database available to the SMEs who are responsible for the content.

So not only I am developing user stories such as:
  • As a portal user, I want to see contextual Help so that I understand how to use specific aspects of a screen I am on.
  • As a portal user, I want to hide the embedded Help pane so that I have more real estate on my screen.
I am also developing stories such as:
  • As an SME, I want to upload content to the embedded Help for a specific screen so that I do not have to be limited by engineering availability to add or edit content.
  • As an SME, I want to provide links to documentation and media that could help a user on a specific screen so that I do not have to be limited by engineering availability to add or edit content.
In addition, I will develop the templates and CSS files for the embedded panes along with guidelines that help SMEs focus on writing effective user assistance.

Not sure what the outcome will be, but I suspect it will be Help that is more helpful but less elegant than if we went with a traditional HAT and technical writing staff. I'm sure there will be examples aplenty that support Sturgeons law, but that is always the case.