Daylight Savings Time Stinks

(or, Why Frequency belongs in Problem Stories )

Well, golly, it’s that time of year: Daylight Savings Time. I’m with the many who have proposed getting rid of “spring forward and fall back.”


Changing the clocks twice a year is inconvenient when you have only one clock—as people did when Daylight Savings Time was invented. But when you have one in every room plus every car, it’s agony. [I know, I know: first world problems.]


Why? Because every clock has different interface.


My office clock is supposed to change automatically. Sometimes it does.


My microwave and oven have clocks. Different interfaces. Microwave is press CLOCK, enter the time, press CLOCK. The oven is CLOCK, enter the time, START.


On my Prius, I have to change the clock from the steering wheel AND from the entertainment hub. For that, I need to check the documentation.


You change the Kia from the entertainment hub but must remember to press SETUP and not CLOCK to get started.


All of these suffer from the problem of frequency. That is, infrequency. Your personal “muscle memory” learns to work around poor interfaces that you use daily. But since we only reset the clocks twice a year, we never get good at it. We never develop that learned behavior.


Add Frequency to your Problem Stories

[I prefer to call them Problem Stories rather than “user stories” or “epics.” It’s a reminder that product managers should be focused on problems.]


When designing a solution, take