Friday, September 28, 2012

Is it time to update the 10 commandments?

Some things have converged for me recently as I listen to the campaign rhetoric and the political pundits, and I need to write them down.

There's a lot about the 1% vs the 99% and then that whole other 47% thing.

I saw two news items this morning: One about obesity in America and one about hunger in America.

And religion-based law keeps popping up. What constitutes a marriage, what kind of sexual behavior will we ban? We distrust Muslim states that want to enforce Sharia law, yet we seem to get into a snit when someone challenges having the ten commandments in our own court houses. I mean, what is there to argue with around the ten commandments?

I'll go with the Catholic version here, since we were always good about keeping things brief (my Protestant friends were always envious that we could get Sunday services done in under an hour).

1. I am the LORD your God:
you shall not have
strange Gods before me.

2. You shall not take
the name of the LORD your God in vain.

3. Remember to keep holy the LORD'S Day.

4. Honor your father and your mother.

5. You shall not kill.

6. You shall not commit adultery.

7. You shall not steal.

8. You shall not bear false witness
against your neighbor.

9. You shall not covet
your neighbor's wife.

10. You shall not covet
your neighbor's goods.

I look at numbers 4, 6, 7, 9, and 10 and come up with a startling revelation:

The ten commandments seem to have been written by rich old men (not unlike the dominant demographic of our secular law makers).

  • We see the stipulation that we must honor our fathers and mothers--not a word against abusing children. Given the recent scandals within the church, that is certainly worth a raised eyebrow.
  • You shall not commit adultery. Hey, if you're a young attractive guy, are you really all that worried that someone is going to steal your gal?
  •  And don't take any of my stuff. You gotta have stuff before this commandment means anything.
  • Whoa, not only can't you sleep with my wife, good-looking pool boy, don't even THINK about it!
  • Lastly, don't be eying my stuff either!
So, you're a poor woman coming to court to get legal action against a husband who is abusing you and your children and failing to support you, and this is what you read on the wall. See the problem? There is nothing in the ten commandments that protects you or your kids.

What if the ten commandments had been written by a working mom with a sense of social responsibility?

1. Thou shall protect and provide for the children.

2. Thou shall not get fat when your neighbor is hungry.

3. Thou shall not own two coats when your neighbor is cold.

4. Thou shall not bully.

5. Thou shall not kill.

6. Thou shall not steal.

7. Thou shall not lie or cheat.

8. And it wouldn't kill you to visit me once a week.

Really, have I missed anything?

Tuesday, August 07, 2012

Monday, May 14, 2012

The Troughs of Disillusionment

Once again, my experience with music delivers an epiphany that sheds light on other aspects of my personal and professional life. Bear with me on this somewhat wandering blog as I tie several seemingly disparate threads together into a tapestry of personal meaning. (I also apologize for that last sentence, but as burdensome as it might be to read, it was a lot of fun to write.)

Thread One

I was collaborating with some IBM colleagues on an article, and one of the collaborators introduced me to the term hype cycle. It was coined by the Gartner Group to describe a predictable pattern associated with technology breakthroughs.

Initially everyone gets all excited and expectations soar to unwarranted heights. Then comes the trough of disillusionment as reality sets in. Eventually, the audience resets its expectations, and acting on those new expectations, the technology is put to productive use.

Thread Two

I've been really digging in on my Dobro and have made a lot of headway in the last six months. I have a goal to reach a certain level of competence within a selected repertoire of songs by the time I go to the Steve Kaufman Acoustic Kamp in June, and I'm just about where I wanted to be. I had one of my monthly lessons with David Ellis this weekend and reviewed the fiddle tunes (popular in the nightly jam sessions at camp). While doing so, I realized that I don't have great breaks, what I have are good fakes. At one point as I'm about to do Blackberry Blossom for David, I say, "The only thing this will have in common with Blackberry Blossom is the chord progression." In other words, I play simplified versions that capture the spirit of the melody, while allowing me to play at jam speed.

Thread Three

I'm almost 63 and it seems anytime I get an ache or I feel a bit puny, I immediately imagine it to be some fatal illness. During one of those funks and on my way to a recent checkup, I asked myself what I would do if the doctor said I had six months to live. I was surprised by the spontaneity and the clarity of my response: "I'd quit trying to play Saint Ann's Reel so damn fast and just enjoy playing all the notes."

Thread Four

OK, this is the last thread and the one that really triggered this blog. I was driving to the monthly SEBA jam on Sunday, feeling tired and even a tad bit depressed. Something in me didn't want to go--I just wanted to turn around and go home, crawl into bed, and pull the covers over my head. I did an uncharacteristically mature thing: I turned around and went home.

The Epiphany

I think that with anything (and possibly anyone) we love, we go through similar patterns to the hype cycle. But instead of being a one time thing resulting in a static plateau--it has the potential to keep repeating itself at increasingly higher levels of satisfaction (or competence, depending on what you're measuring). But each of those cycles is separated by a trough of disillusionment.

For example, I had great expectations that I would become good with all of my practice and dedication. But at my new level of good, I could see a level of better that was still ahead. So instead of feeling good, I felt not-so-good.

At this point, I think there are two mistakes one can make:
  • Mistake One: Quit trying to get faster at Saint Ann's Reel and just enjoy playing all the notes. What's so wrong with that? Well, if I KNOW I only have six months, then nothing is wrong with that. But what if I could know with that same certainty that I had another 20 years? In that case, I'd like to get better at it during that time.
  • Mistake Two: Do the cowboy thing and "get right back on the horse that threw you." That can lead to an even deeper trough of disillusionment as you learn to not enjoy the thing (or person) you are passionate about.
What we need to do when we hit the trough is to stop for awhile and enjoy what we have. Sure, slow down on Saint Ann's Reel for a while and enjoy it. There needs to be a period where we cash in some of our satisfaction equity and just appreciate what we have accomplished. So what if my breaks aren't great, that's OK. I'm going to go to camp with some good fakes that will let me jump into the jams and pull my own weight. It's going to be a lot of fun.

And I've already talked with David, and after June, he and I will sit down and set some new goals. So until then, I'm going to have some fun and not worry about how good I need/should/could be.

In the meantime, I know I would like to get better, and I know I will get better. But for now I'm giving myself permission to enjoy where I am today.

Thursday, May 10, 2012

Is 'Useful' the New 'Usable?'

I have recently written two separate pieces that are starting to converge for me. One was a guest blog at Useful, Saleable, Buildable: The Role of UX in Defining Requirements.  The other was a column in UX Dimensions of Conflict

In the first, I mention that I have been shifting my design focus from being usable to being useful. In the second, I discuss the risk of innovative design versus conventional solutions. I wonder if I am becoming the IKEA of user experience, looking for products that are functional, reasonably attractive, but most important, easy to ship and warehouse.

And I'm wondering how I feel about that.

Useful and/or Useable

Let me start by differentiating these two terms.
  • Usable has to do with attributes like user-friendly, intuitive, learnable, error-tolerant, etc. Essentially, how easily does the design help the user meet the goal of the design?  For example, a print dialog can be very usable if it enables a user to make all the right decisions and efficiently provide the required inputs to print a document.
  • Useful has to do with does the feature serve a goal of the user? Let's go back to the print dialog example. If the user doesn't want to print documents, if instead the user wants to export them as .XML files, then the print dialog is not very useful.
I think we would all agree that useful and usable are not mutually exclusive, but I definitely see where I spend most of my effort on useful, whereas not that long ago it seemed most of my effort was on usable. And I think it has been an appropriate shift.

I know that sounds heretical, but hear me out. There are some dynamics in my world that have made this a logical transition:
  • I work for a company that has a well-defined style guide and philosophy for its UIs.
  • I work in an engineering group that has a designated library of UI widgets.
  • My engineering group uses Agile as its development methodology.
  • I work with UI developers who are well-grounded in principles of HCI.
My interaction design is pretty well bounded by compliance and the widget library at our disposal. So there is not a lot of wiggle room for interaction design decisions--and interaction is at the core of usability.

Being Agile means that to a large degree the building of it is the designing of it. Couple this with the fact that I work with talented UI developers who have a finite bag of widgets, and I really should not waste a lot of time defining interactions they can build faster and better than I can design.

So most of my energy is spent at the front end defining scenarios and sketching wireframes that help encapsulate what the user wants to do. So when I put a calendar widget on a wireframe it tells users and stakeholders "Yes, we will accommodate the fact that you want to set date parameters around this feature." It tells the developer, "Use your stock date selector here."

In an ideal world I would circle around and do usability testing to see if all of this was usable, but I rely on our staying compliant with corporate guidelines and industry practices and the skill of the developers to reduce our usability risk. Usability is becoming a triage victim of the new economy--but largely because its risk is getting low for all of the reasons I've stated. It is a better business decision for me to worry about are we building a product the user will value, i.e., find useful, rather than are we building interactions that will be usable.

Innovative versus Conventional

OK, notice there is no and/or on this one--I went all the way to 'versus.' Yes you can have both, but it is like the treble/bass knob on your radio. The more you have one, the less you get of the other. Here, the trick is balance. I am particularly sensitive about this because I think the kind of environment I have been describing does not naturally stimulate innovation. Technology constraints, widget library limitations, and the tight time-boxing that comes with Agile means I probably will not do a lot of revolutionary interaction design. In fact, I argue in my UXmatters column that innovation can often work against usability. Users know and understand conventional interactions such as radio buttons, text fields, calendar widgets. Change those rules and you introduce usability issues.

So when should you bother with innovation?

When usefulness demands it! I just had my socks blown off this week by something that came out of the Watson Center for Research. Let's just say it was a very innovative way to have users interact with the UI. It so happened that it can be applied to a problem I'm trying to solve around helping users navigate through complex risk components that have a lot of interaction with each other. So why am I now (uncharacteristically) willing to go to bat for a UI that can't be built out of our standard widgets and which will initially befuddle the user due to its novelty? Because it will be so damn useful!

I really do believe the landscape has shifted and UX professionals should be focusing on usefulness. We can't ignore usability, but we do need to be sensitive to where usability risk is getting mitigated by well-thought out style guides, practices, pre-developed widgets, and skilled developers--and make good business decisions about putting our efforts further upstream in designing products that are useful

Wednesday, January 25, 2012

Not right does not mean wrong

I'm reading a really good document about risk analysis, and the author makes the point that when using probabilities to make predictions, at some point the future will unfold in a way that will make others perceive you were wrong. He emphasized "perceive" and that got me thinking.

We do that a lot. Someone does their analysis, makes a decision, and then acts on it. Like a football coach that decides to go for it on fourth down in overtime rather than punt and put the ball in the hands of the opponents' red hot quarterback. The play doesn't work and everyone says he was wrong. Oh yeah, based on what?

"Well, the play didn't work, that proves he was wrong." No it doesn't. It could merely be an instance where the future took the less probable path. It's gonna happen! Chances are good that his decision was right.

Someone's analysis and decisions should be judged only over time and against a pattern of how often the predictions come true. Additionally, we should judge them by whether their analysis has a feedback loop that learns from failure and how quickly they respond to the unexpected outcome.

Anything else is just Monday morning quarterbacking.

Monday, January 16, 2012

Think Aloud Is More than Talk Aloud

Nielsen's current Alert Box reinforces that think-aloud is a great usability test tool. I couldn't agree more, but I'd like to add some in-the-trenches wisdom I learned from my first usability mentor, Loren Burke. There is a big difference between someone thinking out loud about the task they are doing and someone voicing their opinion about the design. The first is very valuable; the second, meh at best and dangerous at worst.

Here is the kind of data you WANT to get from a user who is thinking out loud:
  • "I'm looking at the UI and I think it does..."
  • "I want to do..."
  • "Hmmm, that's not what I expected, I thought it was going to..."
  • "That took longer than I expected/wanted."
In short, you want to learn about how the user sees her task and how she is making sense out of the UI in terms of that task.

What you don't need to hear is stuff like:
  • "I think the background should be blue."
  • "I don't think other users are going to understand..."
For one, this kind of information does not enlighten the problem space, it just adds one more opinion into a mix that probably has no shortage of opinions already. At best, it's a distraction; at worst it leads developers to make bad design decisions based on what the "users told us they wanted." First of all, the user who specified blue as the background, did he have any background in visual design? I'm amazed how quickly we are willing to overturn the opinion of our in-house visual design expert with the degree from SCAD just because an accountant tells us he likes blue.

Ok, but how do you get users to give you the kind of feedback you need? I use two techniques to improve the think-aloud I get:
  • Instructive practice
  • Reinforcement and extinction (a la B. F. Skinner)
Instructive Practice
I picked this exercise up from Mike Hannafin at the University of Georgia. Before I start my first task with a user I explain the think-aloud protocol and then ask the participant to count the windows in his house while practicing thinking out loud. I tell them, "I'm not interested in how many windows you have, but I am interested in how you go about doing this." Some will sit quietly and then say, "12." I then point out that I have learned nothing about how they solved the problem. I ask them to try again but to work real hard at thinking out loud. They try again, "OK, in my kitchen I have one over the sink, in the living room there are three, the den has one behind the couch..." At that point I stop them. "OK, now I have some insight into how you solve the problem, you imagine yourself inside your house and you kind of go from room to room counting the windows--starting with the kitchen." Usually their light bulb goes on and they say something like, "Oh, I see, you want me to think out loud." I suppress my instinctive response of "Duh!" and say, "Exactly, I'm going to want to know how you are making sense of the product while you do what you do."

Another useful tip is to have a safe and short first task, so if the person is having trouble thinking out loud you have a chance to work with them some more before getting into longer, meatier tasks.

Reinforcement and Extinction
Reinforcement and extinction are two principles from B.F. Skinner's Operant Conditioning. Most of us are pretty familiar with reinforcement, but extinction might be a new concept.

Reinforce user behavior only when they give you data, and praise them for exactly that: giving you data. Do NOT reinforce them for giving design suggestions.

For example, if a user tells me "This instruction here is really confusing," I first try to clarify where the confusion is, e.g. a word they don't understand, an ambiguity or whatever. Then I usually say "Thanks, that's useful to know." Same thing if they're trying to get the product to do something it doesn't. "So you expect it to automatically correct the word 'manger' to 'manager' because manger wouldn't make sense here. Thank's that's useful to know." Notice, I did NOT say, "That's a good suggestion." Why not? For one, I've got a room full of developers watching this test that know it's an unreasonable expectation for a spell checker. Also, when I praise a user for making a good design suggestion, what behavior am I reinforcing? Making design suggestions. But I didn't bring this user in to make design suggestions, I wanted to see how real people made sense of the UI in the context of doing authentic tasks.

The next technique, extinction, is how I deal with unwanted feedback such as style preferences, design suggestions, etc. I do nothing. That is what extinction is, the removal of feedback that would reinforce the behavior. Essentially, reinforced behavior continues, behavior that is not reinforced eventually goes away (becomes extinct). So a typical exchange would go something like this.

User: I didn't see the Submit button.
Me: So you didn't know what to do when you finsished the form because you didn't see the Submit button. Thanks, that's useful information.
User: Yeah, I think you should make it red.
Me: In this next task we are going to ask you to...

My first response: positive reinforcement for the insight--didn't notice the button.
My second response: moved right along without acknowledging the design suggestion. Thanks to the first response, we know we have a problem with Submit not being noticed. I'll let that visual designer with the degree from SCAD run with that.

I know there are some who would want the user's design ideas. But once you start down that path, the user quits sharing their insight into the problem space and starts giving you their solutions. It's like the user who says "12 windows." OK, I know your answer but I have no insight into how you got there. And again, usually I have no shortage of experts in the subject of the solution; what I lack is understanding the problem from the user's perspective.

So by all means, get your users thinking out loud, but encourage talk that illuminates the problem space--that's what a usability test is all about.

Tuesday, December 20, 2011

It ain't the walk, it's the talk.

I have a new column out today in UXmatters. It has to do with managing design tensions, but I talk a little in it about Action Science.

During my doctoral research, in which I studied how development teams learn collectively during usability tests, I came across a field called Action Science, which analyzes dysfunctional communication with a focus on resolving contradictions between stated beliefs and theories in use. In cliched terms: A lot goes wrong when there is a disconnect between our talk and our walk. When confronted with such disconnects, most of us tend to blame our walk for failing to meet the standards of our talk—and we vow to do better. But Action Science also challenges the validity of the talk. Many times, it provides a surprisingly simple answer: Stop saying what you obviously do not believe. You’re just confusing people.
It seems we carry a lot of scripts with us that are so ingrained we never question them. Yet, they don't seem to really work for us, so we behave to a different set of norms. What I personally found so liberating about Action Science was the throwing out of these scripts that just confused me and those around me.

As I say in my column, however, we have a natural response to beat ourselves up when our walk doesn't match our talk, as if we are failing to meet our standards. As we get ready to go into the new year, I invite us all to review some of our talk that doesn't match our walk and ask ourselves if we are reading from irrelevant scripts.

Some examples:
  • When I hear writers discuss the writing process (including many a writing professor) they invariably say "Start with an outline." I said that for years. But I never actually started with an outline, and most writers I have observed don't either. Most of us jump in and do some stream of consciousness writing or we jot down disconnected snippets of ideas that we don't want to lose. Later, we start to see a pattern or structure emerge and then we start rearranging the pieces. So why do we say we start with an outline? There's a script I plan to throw away.
  • Companies love to talk about teams and how they evaluate employees based on the success of the team. Yet, I've never been called in for my annual review as a team. It always feels like it is about me. Why can't companies say, "We will certainly consider how well you support teams we put you on, but essentially you will be evaluated and your raise based on your individual performance."
  • For many years I worked in management because my script said "I want to coach others." I was unhappy and the people I managed weren't all that thrilled. Finally I threw away the script that said "I want to be the coach," and replaced it with what I really wanted:" I want to be the quarterback." Nothing wrong with that. I'm happier and all the folks who do not work for me should be delighted as well.
So think about this. At this stage in your life, there is a good chance that you do a lot of what you do because IT WORKS FOR YOU! If you find a big disconnect between what you say and what you do, don't forget to challenge what you say with the same rigor that you challenge what you do. It might not be your walk, it could be your talk.