Why Did They Break My Indicator?

My wife got a new car a few weeks ago. It is a pretty nice thing and even has that Microsoft Sync thing, which I’ll talk about in a future blog(hint: I think it’s awesome). But where it falls down is the indicator.

A steering knob with indicator stick

As you can tell I’m an artist. What you can’t tell from that picture is that I’m also a car expert. So much so that I know that the indicator thingy is known as an “Indicator Stick”. I’m basically the Senna of Calgary.

On every car I’ve ever driven the indicator works the same way. If you’re changing lanes or you don’t want the indicator to stay on you can hold it. If you want the indicator to stay on you push it a bit further and it clicks. When you straighten up the steering knob or “wheel” the indicator self cancels.

Enter the new car: it is all high tech and now the indicator doesn’t stay in position when it clicks. It seems like a really minor thing but it has far reaching implications. When self-cancelation fails there is no clear action to take to cancel manually. Do you push it in the same direction you pushed it in before? Push it the other way? It isn’t clear. Turns out you push it in the opposite direction, that brings a whole new set of problems. When you turn right andimmediatelychange langes you now have to press the indicator up twice, the first time to cancel and then again to actually indicate left. To make matters worse the audio hint that the indicator is on is really quiet. More than once I’ve found myself being the guy who is always indicating.

Scott Hanselman would say that I’m upset because somebody moved my cheese. I am. I would be fine with the change if I felt it provided some advantage over the previous version. For the life of me I can’t think what the advantage is. This brings me to my point: if it ain’t broke don’t fix it.

I see a lot of websites and software tools which are changed driven by not a user need but by a programmer’s desire to improve things. There is nothing wrong with wanting to make things better but there needs to be some evidence that a change will be for the better. Metrics are your friend in these circumstances. If your user base is sufficiently large you can make use of A/B testingto refine your software over time. If your user base is too small for an effective A/B test then you need to revert to a more direct approach: interacting with your users. Take some time to bring the changes to your users and let them lead the evolution of your ideas.

All too frequently do we programmers believe that we’re the domain experts and that we now know better than our users.That is infrequently the case so it is worthwhile to always give users the opportunity to interact with development versions as they’re being created. We make use of hallway testing and frequent demos to avoid creating user interfaces which don’t help the user.

Your users have to know where their cheese is at all times and that if you move it on them it should be somewhere that is easier to find than where it was.

Oh, and if you’re driving behind a guy who is indicating all the time, sorry that could be me. It isn’t my fault, my cheese is missing.