How a UX Researcher Fixed Her Time Distortion Problem (Case Study)

The Problem That Looked Like a Discipline Issue

Priya Kapoor had been a UX researcher for six years. She was good at her job—thorough in her methods, well-regarded by the product teams she supported, consistently delivering insight that influenced decisions. She was also consistently late with deliverables.

Not catastrophically late. Usually a day, sometimes three. Enough to create friction, apologize in Slack, and quietly wonder whether she needed to work more efficiently.

Her estimates looked reasonable. A usability study analysis: four hours. A synthesis report: three hours. A research readout deck: two hours. But when she actually tracked her time—which she did sporadically, usually in retrospect—the tasks took six hours, five hours, three and a half hours. The gap was persistent and it was costing her.

She assumed the problem was focus. She thought she needed to eliminate distractions better, or block deeper sessions, or stop checking Slack during analysis. She tried all of these. The gap persisted.

What she had not tried was examining whether her estimates were accurate in the first place.

Week One and Two: The Diagnosis Phase

Priya started a structured two-week diagnosis log after encountering the DCA Framework. The rules were simple: write the estimate before starting every task, log the actual time when the task ended, note the time of day, and briefly note whether anything unusual happened.

She was skeptical. She had tried time tracking before and it had always felt like overhead without payoff. This time the structure was different: she was not tracking to feel productive or to fill a spreadsheet. She was tracking to build evidence.

By the end of week one, she had data on twenty-three tasks. She pasted the log into Claude and asked:

“Here is one week of my task log with estimates and actuals, task types, and time of day. For each task type, calculate my average estimate-to-actual ratio. What are my three biggest estimation errors by category? Are there any patterns by time of day?”

The response surfaced three findings she did not expect.

Finding 1: Synthesis and report writing was her worst category. Her estimate-to-actual ratio for synthesis and writing tasks was 0.57—she estimated 57% of actual duration on average. She had assumed analysis was her hardest to estimate. It turned out her analysis estimates (exploratory reading, affinity mapping) were actually close to accurate (0.89 ratio). The writing that came after was where she consistently fell short.

Finding 2: Afternoon tasks had a worse ratio than morning tasks. Across all task types, her afternoon estimates were off by about 30% more than her morning estimates. She had not controlled for energy state in her initial estimate—a three-hour afternoon writing block was not the same as a three-hour morning writing block in her actual performance data.

Finding 3: Tasks with external dependencies took twice her estimated time. Any task that required her to gather input from a stakeholder, wait for a recording, or coordinate timing with a PM ran significantly over—not because her core work estimate was wrong, but because she had not built in coordination overhead at all.

These were not the findings she expected. She had been managing the wrong problem.

Week Three: Building the Calibration Table

With two weeks of data and the AI analysis in hand, Priya built her Personal Estimation Profile.

Her multiplier table looked like this:

She added two context modifiers:

• Afternoon tasks: multiply by an additional 1.3x for any task requiring sustained concentration
• Tasks with external dependencies: add 45 minutes per dependency point

She used Beyond Time to log ongoing task time with minimal friction—the mobile entry meant she could capture start and stop times without breaking her workflow.

The first week of applying the multiplier table felt wrong. Her adjusted plan for Wednesday showed eight and a half hours of work for a day that had felt like a six-hour day in her original estimates. She almost dismissed the numbers as obviously inflated.

She worked the day anyway, logged accurately, and found that she had used seven hours and forty-five minutes.

The adjusted estimate had been nearly correct. Her original estimate would have created a gap of nearly two hours—again.

Weeks Four Through Six: The Recalibration Loop

With her multiplier table active, Priya ran the weekly recalibration cycle each Friday for four weeks. The AI prompt she used each week:

“Here is my time log for this week. My current multiplier table is [paste]. Which multipliers should be updated based on this week’s data? What is my four-week rolling average for each task type? Has my accuracy trend improved or degraded?”

Several things shifted over this period.

Her synthesis writing multiplier drifted down slightly, from 1.75 to 1.65. This was not because her estimates had improved—it was because she had started breaking large writing tasks into smaller sub-tasks (outline, first draft, revision), each with its own estimate. The smaller granularity improved her accuracy.

Her stakeholder readout prep multiplier increased from 1.50 to 1.65 after two weeks that included unusually complex readouts. The AI flagged this as a potential signal: “Your readout prep estimates have been below actual for four consecutive weeks. Consider raising the base multiplier or investigating whether complexity has increased in this category.”

She investigated. She had taken on a more senior stakeholder audience in month two, which had increased her preparation requirements. The multiplier adjustment was accurate—but she would not have noticed the cause without the AI surfacing the pattern.

What the Data Showed at Week Eight

By the end of week eight, Priya ran a full eight-week analysis. The same prompt she had used in week one, now on eight weeks of data:

“Here is my complete eight-week time log. Compare my estimate accuracy in weeks one and two to weeks seven and eight, by task type. How much has my accuracy improved? Which categories still have the most room for improvement?”

The results were meaningful.

Synthesis and writing accuracy improved from a 0.57 ratio to 0.79—from underestimating by 43% to underestimating by 21%. Not perfect, but a substantial change that translated directly into planning reliability.

Stakeholder readout accuracy improved from 0.68 to 0.74. The improvement was smaller, but the category had also increased in complexity, which meant holding roughly steady represented real recalibration.

Analysis accuracy remained strong (0.86 in weeks seven and eight) and required no significant change.

The more significant change was in how her weeks felt. She described it in a note she wrote during week eight:

“I used to feel behind by Tuesday. Now I feel behind maybe once every two weeks, and when I do I can usually point to a specific thing that changed—a longer readout, an unexpected stakeholder input cycle. I’m not less busy. I’m just wrong about how busy I am less often.”

The Three Lessons This Case Study Surfaces

Lesson 1: You Are Probably Wrong About Where Your Estimation Fails

Priya assumed analysis was her hard category. Her data showed it was writing. This misidentification is common: we tend to attribute estimation failure to our hardest intellectual tasks rather than to the tasks we do most automatically.

The only way to find out where you actually fail is to log and measure. Intuition is nearly always wrong on this specific question.

Lesson 2: Context Modifiers Matter as Much as Task-Type Multipliers

The afternoon penalty in Priya’s data accounted for roughly a third of her total estimation gap. Without a context modifier, she would have improved her multiplier table and still had her afternoons fall apart.

When running your initial diagnosis, do not stop at task type. Always check for time-of-day, energy-state, and collaboration-mode patterns before concluding that task type alone explains the data.

Lesson 3: The AI Does Not Make Decisions—It Surfaces Patterns

Priya did not delegate her planning to an AI. She used AI to do the pattern analysis she would have rationalized or missed manually. Every decision—which multipliers to apply, how to restructure task granularity, when to investigate a trend—was hers.

The value of AI in this workflow is not judgment. It is honest arithmetic and pattern matching at a speed that makes the feedback loop usable rather than theoretical.

Starting Your Own Eight-Week Cycle

If you recognize any part of Priya’s situation—persistent estimation gaps you have attributed to focus or discipline issues—the most useful next step is to begin the two-week diagnostic logging phase described here and in the DCA Framework article.

The data will probably surprise you. That surprise is useful. It means the pattern you have been managing around was not the one causing the problem.

The complete research context behind why estimation fails the way it does is covered in the guide to time perception and productivity.

Tags: time distortion, case study, planning fallacy, time estimation, AI productivity