Discovery and design for a feature ready to test, paused at the acquisition of Harvest.

Role

Design strategy, UX, UI, research.

Team
Me
PM
EM
FE
BE
What this case study covers

Tracking time is core to Harvest, but the experience hadn't been iterated on in years. Users were telling us so. We ran the discovery, formed a hypothesis, designed a solution, and built a prototype. This is the work up to that point.

Status

Designed and prototyped. Ready to enter user testing when Harvest was acquired.

The problem

Tracking time is core to the Harvest product and the value it provides customers. Yet - outside of mobile and some project management integrations - we haven't iterated on Harvest’s time tracking experience in years.

Our users were indicating frustration around the lift to track time in our NPS, and telling us that this is an area that we can improve in our cancellation reasons survey. On top of that, we’re seeing competitors getting ahead of us in this space.

There's an opportunity to reduce the effort it takes for users to track time with both incremental usability improvements as well as larger explorations into new time tracking experiences that serve to significantly reduce the effort required to track time.

Research

How we approached discovery.

Methods:

Analysis of feature-request submissions for auto-tracking, broken down by seat size and industry

Analysis of feature-request submissions for auto-tracking, broken down by seat size and industry

Analysis of NPS verbatims and cancellation-reasons survey for time-tracking pain

Analysis of NPS verbatims and cancellation-reasons survey for time-tracking pain

Tracker pain-point survey: ranked frequency of specific time-tracking frustrations

Tracker pain-point survey: ranked frequency of specific time-tracking frustrations

User interviews with 5 former customers who left for autotracking-capable tools

User interviews with 5 former customers who left for autotracking-capable tools

Competitor catfooding: how Toggl, Clockify, RescueTime handle activity capture

Competitor catfooding: how Toggl, Clockify, RescueTime handle activity capture

I led design research with the PM and a data partner.

What we heard

“It’s not just my words to clients.. I can show them exactly where I was. No better evidence”

“(before autotracking)... It'd be, like, the end of the week, sometimes more than that.. And then I would be forensically trying to, like, recreate my days, like, look at my emails…”

“I’m on so many itty bitty things… on so many projects… way too much going on… and I need something following me around… Need it proactively doing this stuff for me, not reactively”

“I don’t have the mental acuity to remember what I was doing, need that backup to remember where I was, and be able to ballpark where I was as an extra kind of reminder…”

The insight

The pain points auto-tracking would address

A survey of trackers ranked the most frequent time-tracking frustrations.
Auto-tracking aligned with 4 out of the top 5:

✅ I forget to track time (71 selections)

✅ I can't remember how long I worked on something when I track time after-the-fact (71 selections)

✅ I frequently switch between types of work and it's too hard to change my timer (53 selections)

⚠️ I think it's too much manual effort to create a time entry (43 selections — partial alignment)

✅ I can't remember what I worked on when I track time after-the-fact (41 selections)

The bet

Take meaningful steps toward a near-effortless tracking experience

Hypothesis

An auto-tracking feature would be closely aligned to that objective, because it directly supports trackers who struggle to build a tracking habit and/or work across high project/client volume — the exact profile we saw in both the survey data and the feature-request data.

An auto-tracking feature would be closely aligned to that objective, because it directly supports trackers who struggle to build a tracking habit and/or work across high project/client volume — the exact profile we saw in both the survey data and the feature-request data.

The bet wasn't "build auto-tracking and they'll come." It was: if we surface the activity users already produce, in a way that helps them recall it, the effort to track time drops sharply for the users who feel that pain most.

The bet wasn't "build auto-tracking and they'll come." It was: if we surface the activity users already produce, in a way that helps them recall it, the effort to track time drops sharply for the users who feel that pain most.

How we'd validate this

The testing plan we had ready

The design was prepared for two phases of validation:

Phase 1: Usability testing

8–10 active trackers, focused on the Activity → Time entry conversion flow. The questions: do users understand what activity is being captured? Is the relationship between Activity and Time entries clear? Does the detail view (window titles, URLs) help recall, or feel surveillance-y?

Phase 1: Usability testing

8–10 active trackers, focused on the Activity → Time entry conversion flow. The questions: do users understand what activity is being captured? Is the relationship between Activity and Time entries clear? Does the detail view (window titles, URLs) help recall, or feel surveillance-y?

Phase 2: Beta

Self-selected cohort of high-volume trackers — the segment that surfaced strongest in the feature-request data.

Phase 2: Beta

Self-selected cohort of high-volume trackers — the segment that surfaced strongest in the feature-request data.

The acquisition paused the work before phase 1 began.

KPIs

↗️ % of desktop users that had already installed the desktop app prior to auto-tracking launch that are tracking time via auto-tracking at least once per week

↗️ % of users that installed the desktop app after the auto-tracking launch that are tracking time via auto-tracking at least once per week

↗️ % of users on target accounts tracking time via auto-tracking at least once per week

Guardrails: Opt-out rate, Support ticket volume mentioning auto-tracking, Privacy-related feedback in any channel

Reflection

Three lessons from the design phase:

1. The privacy flow was the highest-stakes design decision in the feature.
How users feel about an app capturing their activity is set in the first 30 seconds, and the design has to earn the trust before asking for the permission.

1. The privacy flow was the highest-stakes design decision in the feature.
How users feel about an app capturing their activity is set in the first 30 seconds, and the design has to earn the trust before asking for the permission.

2. Detail isn't decoration.
Window titles, file names, URLs were the difference between "useful aid" and "another thing to manage." This came directly from the interviews and reshaped the design.

2. Detail isn't decoration.
Window titles, file names, URLs were the difference between "useful aid" and "another thing to manage." This came directly from the interviews and reshaped the design.

3. Listening to converted customers, not just churned ones, changed the design.
Churned users said they wanted autotracking. Converted users said they wanted autotracking that didn't make decisions for them. The Activity-vs-Time-entries split came from that second group.

3. Listening to converted customers, not just churned ones, changed the design.
Churned users said they wanted autotracking. Converted users said they wanted autotracking that didn't make decisions for them. The Activity-vs-Time-entries split came from that second group.

Appendix

Workshop artifact

Mid-discovery cross-functional workshop. Sticky-note synthesis of pain points, hypotheses, and rough wireframe direction.

📺 Video

You can watch a short video of me walking you through the UX here

🕹️ Prototype

You can play around with a prototype here

Next up

2024

A recent-timers widget for iOS, designed end-to-end and shipped to 60% adoption.

You can find me here

© 2026 Nikolay Lechev

much love

much love

much love

Nikolay Lechev