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!