Time Tracking for Designers: A Workflow That Survives Real Project Loops

A designer's typical billable hour looks like this on the timeline:

• 12 minutes in Figma, three files open, working on the actual layout
• 4 minutes in Chrome, scrolling Dribbble for a treatment idea
• 7 minutes back in Figma
• 3 minutes in Slack responding to the client's feedback
• 1 minute in the file manager grabbing a reference asset
• 6 minutes back in Figma
• 4 minutes reading a CSS Tricks article that was actually for a different project
• 7 minutes in Figma applying what you just read
• 6 minutes in a notebook sketching

That is one billable hour. A traditional timer captures none of the multi-app rhythm. A more careful approach captures all of it.

This post is for freelance designers who want their time records to match what they actually did — across Figma, Sketch, Illustrator, Photoshop, browsers full of references, and the inevitable Slack feedback loop.

Why design work resists linear time tracking

The work has a few specific properties that break timers:

• Multi-app sessions are the norm, not the exception. You will touch 4-8 distinct apps per billable hour.
• Iteration cycles cross days. The client's feedback arrives Tuesday on Monday's work. The revision happens Wednesday. The follow-up arrives Friday.
• Reference and inspiration time is real work. Scrolling Dribbble or Pinterest is billable when it is informing the project — and a distraction when it is not. The two look identical to a naive tracker.
• File-version sprawl means you cannot identify "the project" by file name. You will have client-name-v3-final-FINAL-actually-final.fig in your Recent Files list.
• Handoff and asset preparation is undercounted. Exporting assets, building dev specs, packaging deliverables — all billable, all forgotten.

A timer-based system asks you to start and stop in a workflow shape that does not exist. You either gave up on the timer or you are lying to it.

The phases of a design project

The cleanest mental categories for design work, from the standpoint of time accounting:

| Phase | What it looks like | Typical share | |---|---|---| | Discovery / research | Reading the brief, talking to stakeholders, exploring references | 10-20% | | Ideation / concept | Sketching, wireframing, exploring directions | 15-25% | | Execution | Building the actual designs in Figma/Sketch/etc. | 30-50% | | Iteration | Client review rounds, revisions, polish | 15-25% | | Handoff | Exporting assets, dev specs, file delivery | 5-15% | | Communication | Slack, email, calls about the project | 5-15% |

Notice that execution — the part everyone associates with "designing" — is rarely more than half the actual billable time. The rest is undercounted by traditional tracking.

Capture everything; categorize by project, not by app

The right granularity for design work:

• Capture every app and browser tab automatically — Figma, Sketch, Photoshop, Illustrator, Chrome, Safari, Slack, Notion, file manager
• Group sessions by project — "Acme Brand Redesign" should aggregate ALL apps when you were working on it, not just Figma
• Treat the multi-app session as one block — if you swap between Figma and Chrome (for references) and Slack (for client questions) within the same context, that is one session for billing purposes
• Tag references and exploration to the project that benefited — that 8-minute Dribbble session that produced an idea is part of the Acme project, not "Browsing Time"

This means you need a tool that can tag sessions per project rather than treat each app independently. Most consumer time trackers do not do this well.

How to bill from the log

Most designers use one of three models:

Hourly billing — straightforward export. Filter the log to a project, sum the time, send the invoice.

Project-flat billing — bill a fixed amount for the project regardless of hours. Use the log internally to track effective hourly rate. The first time you charge $5,000 for a brand identity and the log says you spent 80 hours on it, you have a $62/hour problem.

Retainer billing — a fixed monthly fee for ongoing work. Use the log to confirm you are delivering enough hours to justify the retainer, and to push back when scope creeps past it.

The single most undervalued thing a designer can do with passive time tracking is track flat-rate projects to learn your effective hourly rate. Without the data, you cannot tell a $4,000 brand project that paid $200/hour from a $4,000 brand project that paid $50/hour. With it, you can stop accepting the second kind.

The "is this billable?" reference question

A real edge case: you spent 20 minutes scrolling Dribbble. Is it billable?

The honest test: was the scrolling oriented to a specific project, or was it generic exploration?

• Scrolling Dribbble immediately after reading the Acme brief, looking for treatment directions for Acme: billable to Acme. Tag the session that way.
• Scrolling Dribbble between projects for general inspiration: professional development, not client work. Tag it as overhead or skip logging.
• Scrolling Dribbble for 90 minutes after lunch when you should be designing: not billable, and probably a signal to take a break.

The same activity (browsing Dribbble) can be all three in the same day. The tool cannot tell which is which. You decide at end of day during review.

The 5-minute end-of-day review

Passive capture makes the daily review fast:

1. Open the day's timeline.
2. For each multi-app session block, tag it to the matching project (Acme Brand, Beta Website, Internal Marketing).
3. For ambiguous browser sessions (Dribbble, Pinterest, Behance), decide: which project did this serve? Tag accordingly.
4. Split any session that spanned two projects into two entries.
5. Save. Done.

Friday is then a 5-10 minute export per client, not a reconstruction.

Handling the "8 versions of the same file" problem

Most file-based trackers cannot tell acme-redesign-v3-final.fig from acme-redesign-v3-final-FINAL.fig from acme-redesign-v3-final-FINAL-actually.fig. They show three different file entries that are obviously the same project.

The fix: track by window title (which contains the file name pattern) AND tag at the project level (which abstracts over the version mess). A category called "Acme Brand Redesign" with a rule "Figma window title contains 'acme' → Acme Brand Redesign" handles all version variations without manual cleanup.

Communication time is design work

A designer's typical week has 3-5 hours of project-related communication: Slack threads about the design direction, email rounds with client revisions, video calls walking through mockups. All billable. Most undercounted.

If your tracker captures Slack and email as separate apps from Figma, this time often gets dropped because it does not feel like "design work." It is. The work is not just the pixels — it is also the conversation that ensures the pixels are the right pixels.

Tag Slack/email sessions to the project they served. At end of week, you will see that 15-20% of your billable time is communication. That is the number you should be billing for.

What "fixed" looks like for a designer

A working time-tracking system means:

• Multi-app sessions across Figma + Chrome + Slack are captured as one project block, not three apps
• File-version sprawl does not produce three duplicate rows per project
• Reference scrolling oriented to a project is captured as billable
• Communication time is in the log, tagged to the project
• Flat-rate projects have an effective hourly rate you can actually see

If your current system does not produce all five, it is not solving the design-work shape. The problem is not your tracking discipline. The problem is that you are trying to fit a multi-app iterative workflow into a single-app linear timer.

DayReplay for designers specifically

For full disclosure: I built DayReplay because every time tracker I tried treated app-switching as the enemy. Real design work is app-switching. DayReplay runs in the background on Mac or Windows, captures app + window-title + browser-tab activity locally, and lets you group sessions by project regardless of which apps were involved.

A few specific things that help for design work:

• Window title capture means file-name variations all roll up under one project rule
• Browser tab capture means Dribbble/Behance/Pinterest sessions are tagged with the URL, so you can decide "this was Acme research" at review time
• Custom categories (Customize Categories walks through this) let you build per-project rules instead of per-app
• Local storage — your client list and project names never leave your machine
• CSV export per category produces a clean per-client total

The macOS guide and Windows guide cover setup.

If DayReplay is not the right fit, that is fine — the workflow (capture everything, categorize at project level, review daily, export weekly) works with any passive tracker. The point is to stop pretending design work happens in one app at a time. It doesn't. Track accordingly.