The Blinking 12:00 Problem
Anyone old enough to remember the VCR, will have experienced a blinking 12:00.It was the same in nearly every house you visited, but oh the respect you had for those whose clock had the right time set. It was even more frustrating for my 10 year old self, given Dad’s obsession with unplugging everything before bed. All that hard work following the complex sequence of buttons outlined in the manual lost every night.
The blinking 12:00 problem must be one of the best known examples of bad user inteface design. The payoff of having the right time did not out weight the pain of the complex set of intructions, so the user gave up.The issue was so well known and wide spread that a feature on a device that is too complicated for a user to use became known as a Blinking Twelve Problem.
It is most often linked to changing a default state and we see examples of it all time today, such as default passwords left on routers admin panels.
You can see the Blinking Twelve Problem in effect on Twitter. Search for a random name and you will see a screen with three examples of the Blinking Twelve Problem. (For some reason ex-Newcastle United manager John Carver popped in my head when I searched)
1. The twitter Egg – Users have not uploaded a picture of themselves. These are mainly new, unused or spam account.
2. Empty cover photo placeholders – A large number of people don’t add a cover photo. This is not just limited to the same users as the Twitter Egg but some long term and active Twitter users too. *A much higher percentage of Twitter accounts have no cover photo compared to Facebook users. Facebook makes it super easy to do, with it being a single click away on your profile page, vs having to specifically go to edit on Twitter.*
3. The vast majority of people leave the default color scheme. I believe the purpose of this feature is for brands to change the page and not aimed at non commercial users. If it was, it maybe more prominent and easier to find and the features use might be higher. It would be interesting to see.
What is it telling us?
When we have a feature which allows the user to change something but is always left in it’s default state by the vast majority. When this happens we are being told one of four things:
1. The feature is too complex to use.
2. The benefits of the feature are not clear.
3. The feature is hard to find, or not noticed by the user.
4. The feature is not needed, it doesn’t solve a problem your userbase cares about and could be pulled to simplify the product.
When ever I am faced with a Blinking 12:00 I tend to investigation each of the four reason above in that order. It can be a long process with many different ways to test each but if you get to point 4 and have not solved the issue it may be time to pull the feature. This can be a hard thing to do but unless it is core to your product, it should be.
Why bloat your application with something users don’t want, you have to support it further in the development, during updates and upgrades, the time can effort can be best spent elsewhere. If it isn’t being used it won’t be missed. It if it core to your site, application or product and it can’t be rectified by the fixing the first 3 items on the list, as tough as it sounds, the idea may not have an audience and it could be time to start to rethink the purpose of your application all together.
Get the defaults right?
Another thing that the Blinking Twelve problem shows is that users don’t always search ways to change the defaults, so as developers we need to meet the expected behaviour for the vast majority of our target users by default.
In fact research by the Microsoft Office team found that 95% of users don’t change a thing and that behaviour had a big impact on users.
Of course, this mean that 95% of the users were running with autosave turned off. When we interviewed a sample of them, they all told us the same thing: They assumed Microsoft had delivered it turned off for a reason, therefore who were they to set it otherwise. “Microsoft must know what they are doing,”several of the participants told us.
People were losing work, Microsoft had a solution but users either didn’t find it or didn’t want to mess with the defaults. We can’t expect our users to behave any different.
Combating the blinking twelve problem by getting the defaults right, minimising choice for the user and making it easy for the user to do things adds additional benefits for us too. One great example of this in action was back in 2007 when New York City made cab drivers take credit cards payments. The touchscreens to take payment allowed you to add a tip. You could input by touching the onscreen buttons or pick one of three options. 20%, 25% or 30%. Most people didn’t bother to type in a tip; they just hit the 20% or 25% button, and the average tip leapt from 10% to 22%. You can read more about it in a post called The $144,146,165 button by Joshua Gross.