It was a big fat usability issue. I haven’t seen one like it for years: a broad, bamboozling beauty that ate 3 hours of my time.
I thought I’d capture it here for you as a special treat. Donald Norman fans will love the mental models aspect. And for product teams everywhere it’s a grim reminder that you need a robust product delivery process, rather than just assuming “it’ll obviously work for customer.”
Let’s set up parental controls, kids!
The kids were turning into housebound zombies so I bought a new router with parental controls. An TP-Link Archer D7. It had an app so you could control and configure it from your iPhone.
I sat down at my computer to configure parental controls on a Saturday. The kids devices would only be able to access the internet in the evening and the morning. During the day and after bedtime they’d need to do something else. Like play or sleep.
So here we go… I enter the MAC address of my daughter’s device and click the little icon to set “Internet Access Time.”
Next, up pops a grid. Days and times. And that key at the bottom: green means “System time”. A little experimentation shows that you click on a box to make it turn green. Super.
So my daughter can access the internet from 6:00am – 8:00am and then again from 4:00pm to 9:00 pm. I save the grid. Activate the master switch and… Nothing happens. My daughter carries on consuming junk Youtube, unfettered by paternal do-gooding.
I go back and fiddle. Check again. Nope… nothing happening. It the time set right on the router? Yes. Is the MAC address for my daughters iPad entered correctly? Yes. Hmm.
I try the mobile app. It’s a little wacky… two nested clocks that I need to use to “set the effective time for this device.” But the clock reflects what I entered into the grid, and when I save my choices, nothing new happens.
I google the problem, and get a shock.
Parental controls are not working?!
I search again and again, and find frustrated forum participants moaning about how parental controls don’t work. Nor does timed wi-fi on-off. In fact, people are saying, things like “a word to the prospective buyer: better steer clear of TP Link. They really don’t work so well.”
Dismay. I just paid good money for this. I check firmware versions etc. All up to date. It’s just a bad product. And TP-Link are conspicuously silent.
I google once more in disgust and find this.
So green means “off” and white means “on?”
I go back to the grid and swap all the colours around. And lo! The internet stops and my daughter starts complaining. Well I’ll be!
Mental model
My mental model was: make the square is green when you want your child to have access to the internet. Green means go. Then my child can go go go onto the internet. The link said “set internet access time”. The key said “System time”. All pointing pretty clearly in the same direction, I think.
But the developer’s mental model was: “Colour a cell green when you want to activate the software switch that filters out internet access.” The developer was writing a feature – a filter that would be activated at selected times. When a user colours a cell green, he assumes that means they want to activate that filter. Green means activate, right? So green means activate the parental control filter. Of course.
Brain flipped? Quite.
It’s like a Necker cube. You can see it one way, or see it the other.
Except it’s fairly clear to me from the forums that normal, human consumers are thinking about it my way, not the developer’s way. Because the humans don’t give a monkeys about the fact that the developer wrote some code and that code will be activated according to a timer. They care about when the access is available (green = on) and when it’s not (white = off).
I’m pretty sure that the designer was thinking like a consumer. And the copy writer. And the product manager. And the technical author who wrote the manual.
But the developer and the tester were thinking the other way round. And once the feature had been thrown over the wall to them, no-one ever tested it with users. So no-one ever found out that there was a problem.
The moral: Quality process, always
People on product teams will see things from different perspectives, of course. But a good product process, and a good product team, will make sure that:
– Ambiguities are flagged and discussed by real human beings who aren’t afraid to have a conversation
– UX is tested with users
– User feedback from the wild is gathered and acted upon, so that your product can continually improved
Hard work. That’s digital product design.