Wanna see a great counter-example of protecting your product’s First Use Case?

This is a digital thermometer for kids. You turn it on, press it against your kid’s forehead, click on the big button, wait for a second, and get his body temperature. That’s the First Use Case — the primary use case this object is supposed to solve: I want to take my kid’s temperature.

Yet, every time I try to use it, I think the device is broken. I click on the button, and nothing happens.

Why is that?

Because the product is also trying to address a secondary use case — I want to know whether my kid’s temperature is worrisome. In order to address this secondary use case, the background changes color when the number is displayed. If your kid has 36.9°, the background goes green. If your kids has 40.5°, it goes red. Makes sense, right? Complementary information, particular useful for young parents who don’t know yet what to make of a 38.3° result.

The only problem is that the scale of temperature is actually dependent on the kid’s age. A 39.1° temperature may not be interpreted the same for a 2-month old baby vs a 4-year old kid. The green-yellow-red scales have to be adjusted, so that the color code makes sense.

How was this age-entry problem solved? By having the user indicate beforehand whether the kid is 1-3, 3-36 or 36+ months old. Every time I need to use this thermometer, I first need to click another button multiple times until the kid’s age range is correct. Only then can I actually click on the big button and get the temperature.

The secondary use case has become an additional step to the primary use case. Every single time I want to take the temperature, I need to go through this step, that turns out to be useless to me.

Of course, it may look a minor friction. It takes a just a couple of seconds to go through this step. But when you are in the middle of the night, half-awake by your crying child, having forgotten about this useless (to me) step, it turns into a « why the fuc* is this thing not working! » what could have been a seamless experience. 

Being customer-centric is not enough. 

I’m sure there’s a customer-centric person behind this feature. Someone who observed parents who were clueless about what to do after reading a particular temperature level. Someone who developed empathy for such profiles and looked for a solution to that problem. Someone who, in the process, forgot about the wider group of parents who just needed to get their kid’s temperature.

Get to know your users.

Understand their needs.

And prioritize them based on a simple heuristic: what do most people do, most of the time?