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.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 andÂ immediatelyÂ change 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 testingÂ to 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.