One of my little Google Homepage widgets is for a blog by one James Bach, who knows more about testing than me. A lot more. He recently blogged about his dislike for the words ‘intuition’ and ‘common sense’ being used as explanations in arguments.
Bach has a very good point when it comes to using those two concepts as ways to explain away a problem.
The article also made me think about how often I run into issues of common sense or intuition while providing tech support. Keep reading for some examples, and a little discussion on how I think the common sense and intuition pitfalls can be avoided.
Common Sense
Dictionary.com says: “Sound judgment not based on specialized knowledge; native good judgment.” [link] This is a good definition, since the idea of common sense is that it’s common, or rather not uncommon. Take crossing the road. You look both ways, right? That’s common sense – if you don’t look, you get hit by a car. This is common because most people are taught it when they’re a child.
The problem is when you, me, or anyone else thinks that something is common sense, but isn’t. “It’s common sense that to make a new file, you go to File -> New File, right?” No. One key part of tech support is instructing users on how to accomplish tasks. If the user doesn’t know how to do something, then thinking, “But that’s common sense!” is pointless. It’s only common to you.
A related problem concept is ‘obviousness’. I think the only way something can be truly obvious is if it is simply in plain sight and clearly delineated. If you say something is obvious and it’s not staring you in the face saying, “I’m obvious!”, it’s not.
My favorite example is the picture below:
This is the Microsoft ActiveSync connection window, with a Pocket PC 2002 PDA connected. I’m not trying to pick on ActiveSync, but this happens to be a very common scenario that I have to deal with, and it’s a subtle one.
If you are familiar with Pocket PCs, forget that you’ve ever used one before. If you aren’t familiar with them, stay that way for the next 30 seconds.
Now, pretend that you’re on the phone with me getting help:
Me: “Okay, now I need to know the partnership name of your Pocket PC.”
You: “How do I find that?”
Me: “Open your ActiveSync window on your PC and you’ll see the name listed.”
You (more often than not): “Uh, where’s the name?”
Where is the name? Something is connected, and probably synchronized. Do you know where the name is?
The name is “Pocket_PC” – that’s the name assigned to your Pocket PC by ActiveSync, for use in identifying it in other software. That’s the piece of information I needed. Do I blame you for not knowing how to get it? Not at all. That piece of information is not obvious.
My solution for this obvious problem would be to place the following in front of the actual name text, so it reads Device Name: Pocket_PC . That way, if I ask you for the name of your Pocket PC, there’s a much higher chance you could look at the ActiveSync window and say, “Oh, it’s Pocket underscore PC.”
Obvious things are a kind of discoverable common sense. To learn not to walk blindly into the street, your parents had to tell you not to do it – you can’t really discover ‘look both ways’ unless you want to get hit by a car. To learn how to save an article as a draft and keep writing it in WordPress, you hopefully just look down below where you’re typing and see the large button labeled “Save and Continue Editing” – in other words, you discover the obvious button.
From a tech support perspective, everything should be obvious – this helps maximize a user’s happiness with software and minimizes tech support for things that aren’t actually broken. Obviousness helps people develop their own common sense and helps them explore the software on their own.
Intuition
If common sense is something everyone is supposed to know, intuition is something no one knows. “The act or faculty of knowing or sensing without the use of rational processes; immediate cognition.” [link] James Bach argues that intuition is really, “I don’t know how I did it,” and I agree with that definition.
Sometimes it’s easiest to throw out a counter example – here’s the file menu I see when I’m right-clicking a file in my FTP client to rename it to a backup copy:
What’s wrong with this picture? Let’s say that wasn’t SurvivorGuide.clf, but instead ThisFileIsSoImportantYouWillDieIfYouDeleteIt.ext . Let’s say you sneeze right before clicking ‘Rename’. What other option might you click? DELETE.
You could argue that this is not an intuitive thing to do – it’s counter-intuitive. But what’s the reason? Well, because. Maybe it’s a bad idea to put delete next to a very innocuous thing such as Rename. It just feels funny, at least to me.
Part of tech support involves fielding feature requests. A user decides that it’d be easier to use OurProduct if the Widgets are configurable by right-clicking on them, and so they send something along which gets to me. But why is it any better to have right-click on Widgets? Sometimes the user gives a really good explanation, but other times, it’s just, “I like it better that way.” It’s like explaining why you like pistachio ice cream – you just do. I could implement my GTD organizational system using Microsoft Outlook, but I don’t like the way Outlook works, and for the most part I don’t know why. Other options just feel better.
When users can’t use our software, I want to know why. It’s in my best interest to figure out what the problem is, since I’ll be helping people with it when it becomes a problem. Are we assuming users know something that they really don’t know (“it’s common sense!”)? Are we ignoring an easy way to make things ‘feel’ right for users (“it’s not intuitive unless the category tree’s on the right!”)?
It’s all very linked together. Users come to technical support with problems, technical support goes to the developers with common problems, developers fix the problems and refine the software, users take the refined software and find more problems.