From Assumption to Data-Driven Execution
Last week, we redesigned a critical feature and, while doing so, we identified significant problems in the production design. After a follow-up meeting with my manager for further evaluation, I started working on the designs. This time, however, I approached it differently: instead of evaluating assumptions, I used user data as evidence to drive progress.
The feature is a timer that users can quickly start anywhere in the app, even without associating it with a specific task. However, there was a constraint: the user could only stop or save the timer after adding the task. Otherwise, they could only pause it - they weren't able to cancel it.
The problem we addressed was: how can we let the user stop the timer if they started it accidentally? The simple solution is to add a cancel button beside the start button, but there are other factors to consider:
What if the timer runs beyond 15 to 30 minutes?
If a user accidentally cancels a timer, how can they recover that tracked time?
The simple answer for accidental cancellation is that one confirmation message works well. But what if they cancel the timer within 5–10 seconds of starting it? Does asking for confirmation work then? Probably not. By addressing this, we proposed "threshold management" for cancelling active timers. Now, we have two thresholds: one for within 15 minutes and another for over 15 minutes.
The question then became: how do we set the threshold at 15 minutes without knowing the user requirements or having data about their activities? Without data, it’s just assumptions, right?
This is where I approached things differently. Since our product's target audience for this timer feature is primarily marketing and sales agencies, I researched their workflows and found their minimum billable increment is 15 minutes. I set this as our standard threshold for the cancel interval.
If my manager asks, "How do you know 15 minutes is enough for the user?"
OLD ME: I would have simply starred at them or stretched my mind for random thoughts to fill the gap.
NEW ME: I can now confidently show the research insights and explain that these are the actual user requirements we are proposing.
The Old Way: Moving forward with assumptions and "gut feelings." By the end, it’s purely luck whether the feature is helpful or not.
The New Way (or rather, the right way): Moving forward with confidence and evidence. No more relying on luck.
I’m aiming to be a problem solver, not just a pixel pusher.