Wurkit

Cognitive dissonance: Traffic cop edition

2013-02-07T08:07:00-08:00

For the last few months there’s been construction on the same intersection as I’m coming into work. When there’s enough activity to close a lane, a traffic cop comes to the rescue. I’ve had the pleasure of observing this person for a few moments each day and I keep noticing the same problem.

Nobody pays attention to him.

I had been at that intersection dozens of times. I had watched that traffic cop struggle to get people to do what he was signaling. From several cars back I could see the big picture and I still couldn’t figure out why it was so problematic.

Why don’t people just do what he signals?

Eventually I ended up at the front of the line waiting for my turn to go. This was taking way too long. I shoudn’t still be here. What the *$%& is going on?

Then I noticed cars behind me honking and the traffic cop yelling and walking out into the street. He was just on the edge of my peripheral vision. Even after seeing him signaling me, I returned my gaze forward to the traffic light. That glowing red circle was just so comfortable and familiar that it overpowered my senses. The man to my side, even though he was a cop, wasn’t a dominant part of the picture and the traffic light still had authority in my mind.

A moment later I realized what was going on. I was that guy. Staring at a traffic light that had no purpose. I felt like such an idiot.

This was an interesting reminder to me how powerful our assumptions, beliefs, and routines can be. Our “automatic pilot” takes over and handles what we think we already understand. Even when there are obvious signals, it can still be terribly difficult to cope with new approaches to a common problem.

The embarrassment from this situation is a good reason for me to be afraid of change. I can’t rely on my autopilot anymore. I’m not just learning something new, I’m also abandoning comfortable and familiar things from my past. Thanks to that raging traffic cop I can empathize with people resistant to change just a little bit more.

Now, if I could only get that cop to stand in front of the traffic light.

Clarity or Efficiency?

2013-01-21T17:51:00-08:00

Over the years I’ve noticed a very common source of friction between designers and engineers. It seems as though designers value clarity over efficiency and engineers value efficiency over clarity. When left to their own devices, designers tend to add more screens, more design elements, and more words in an effort to make things easier to understand, while engineers tend to combine and consolidate these elements to gain the advantage of speed. Even though these dual goals might seem to be in opposition, it’s a good tension and striking just the right balance makes the software much more satisfying to use.

Designers love clarity. Maybe too much.

To a designer, “clarity” seems to be code for “it doesn’t take a lot of heavy mental lifting for the customer to understand how this thing works.” It’s a noble goal, and one that’s totally worth pursuing. Making a customer’s life less complicated will make them happier and more productive.

From a resource perspective, the less need the software has to explain itself, the less support, training, and documentation it will need. This will help the business scale, serve more customers, and incur less overhead and expense. Clarity is a hugely valuable asset and is all too often underestimated.

Unfortunately, in many cases the drive for clarity can come at the cost of creating more work for the customer. Slowing people down with “procedure” is a great way to turn an effective tool into a nuisance. Also, making people feel as though their hands are being held as they work through your software can come across as patronizing and rude.

Engineers love efficiency. Maybe too much.

To an engineer, efficiency is about helping customers do two things in the time it typically takes them to do one. When you give people more time, you give them more opportunity to do the things that matter in their lives or in their business. More opportunity equals a greater chance of success. Efficiency rules.

I think the logic of efficiency is a little easier for people to grasp. When you can help someone do something faster, it’s easy to connect the product to value in their lives. This perception of value is what makes something worth buying. The more efficiency you can offer, the more money you’ll make.

Unfortunately, an unintended consequence of efficiency is that when you combine complex tasks or rely on customer’s domain knowledge, you’re shifting the responsibility of knowledge from the software to the customer. This introduces all sorts of expectations around training and support, which then puts a burden onto other areas of the company. It can also frustrate the customer when they can’t extract the value out of a system without admitting, even if only to themselves, they don’t really know how it works.

Imbalance gets noticed

When your customer is dealing with a complex problem, a complex solution isn’t going to be a surprise. It’s when they’re on the tenth step of something that shouldn’t require ten steps or looking at one epic interface that takes several minutes to decipher. This imbalance gets noticed and will be interpreted as unnecessary work.

So when your customer feels like he’s jumping through hoops to the point where it becomes repetitive and boring, you’ve introduced too much procedure to compensate for clarity.

And when your customer feels like she’s unsure of what she’s doing or is intimidated, you’ve probably introduced too many tasks into the same flow to compensate for efficiency.

Learn to love the tension

The right mix of clarity and efficiency is where the magic happens, and that can’t be done without a little bit of healthy tension. So designers and engineers each have something to learn from each other. This isn’t a zero sum game, and both camps can learn something valuable from each other.

Thanks to Joshua Porter and Beth Dunn for help with this article.

Are you an expert or a professional?

2013-01-21T17:47:00-08:00

A while ago, I was planning to head out to brunch with a few friends. The restaurant we had in mind looked more like a bar, and several windows were boarded up (due to a lack of window glass). We were skeptical of how great a brunch we would get served at such a place, so we called ahead to ask them a few questions. Well, this just opened up a Pandora’s Box of sassy.

We started out by asking some broad questions. Like, “How does your brunch work?” You know, some places have buffets, some have a special menu, some have a prix fixe…

We got the sarcastic response that their brunch was “breakfast- and lunch-type food served for some part of the day.” You could practically see the sneer come through the phone.

Now, I realize that we were fishing for specific details with an ambiguously phrased question. The hope was that the hostess would be able to read into our questions and elaborate on our needs without requiring us to precisely define the exact purpose of our call.

Being approachable and taking responsibility for finding a way to please the customer is something I’ve always associated with a professional.

Throughout the rest of the conversation, she was perfectly able to answer every single one of our questions. She was obviously an expert, if loosely defined as someone who knows the details of her job. Unfortunately, we still couldn’t extract any answers from her unless we first formulated the perfectly matched question.

What we needed was a professional, not an expert. We didn’t really know what to ask, so what we got was a lot of unhelpful snark in return. When we lucked into a question that produced a straightforward answer, our expert was able to give the appropriate answer. But a professional would have found a way to answer both the questions we knew to ask, and the questions we didn’t know to ask.

Assumed knowledge, attention, and perspective

Our hostess assumed that what was common knowledge to her is common knowledge to others. She was an expert on this topic and it never occurred to her that we were not. Or at least, she felt that our ignorance implied either idiocy or laziness on our part. When all it really meant was that we didn’t know.

Our hostess assumed that she had our complete and undivided attention. Her apparent willingness to prolong the conversation so that she could dispense her daily dosage of snark gives away the fact that she didn’t think we had anything better to do than to play Twenty Questions on the phone. In fact, we were simultaneously trying to deal with the different desires and expectations of several different hungry people.

Our hostess assumed that the conversation had a similar value for each of us. We had differing perspectives on how important the call was to achieving our goals. Her priority was to manage the day’s business for the restaurant, whether or not that included our table. Our priority was to eat a delicious brunch, which meant that we needed to gather enough information that would allow us to commit to a plan.

Reflecting on the experience

This subtle difference between expertise and professionalism has been heavy on my mind since that day. As a designer of web-based software, there are so many assumptions that I can make about someone else’s level of knowledge, attention, and perspective. When I take the time to shine a light on any of my own assumptions and compare them with those of my customers, I can see where I’m being more of an “expert” and less of a “professional.”

For example, I might be assuming our customers have a certain level of:

Industry knowledge (What do they already know about how software works?)
General internet skills (What’s their level of familiarity with common design patterns?)
Desire to learn new methods of interacting with a computer (Shouldn’t it just work?)
Level of focus and attention while using your software (How many other things are they doing?)
Desire to grasp your software’s particular approach (Are there any unique interfaces?)
Amount of pressure they are under to finish quickly (What are their commitments to their peers?)

Added up, these assumptions can create large gaps in my knowledge – and my preparedness to respond to a customer’s needs. Any of these gaps played out in real life can come off as rude and turn off the customer. Notice how none of them have anything to do with the skills of writing software or implementing interfaces, which is typically where I spend most of my time. What’s called for instead is a certain level of patience, empathy, and humility.

In short, professionalism.

Don’t be the expert, be the professional

Software can fumble and fail just as much as any human being can. Just like that hostess on the phone, software design can make assumptions about the user that are simply not based in fact. For my part, I’m going to look more closely at the things I design to make sure that I’m not being too much of an “expert” and not enough of a “professional.” Examining my own assumptions will hopefully point me toward better ways of get the information we need to do our jobs well. Professionally.

Thanks to Joshua Porter and Beth Dunn for help with this article.