Skip to content

🎨 Time tracking design

Problem

Current time tracking functionality is available only via quick actions which can be unfamiliar. As entering and managing time is essential to the time tracking widget it should have capabilities from the UI, with the quick actions remaining as a secondary input option.

Current inputs for time tracking include:

  • Estimate: A single time represented in months, weeks, days, hours, and minutes
  • Spent: One or many time entries which must include a time (using the same format as estimate) and date and optionally include a note

Proposal

Introduce controls in two locations to support adding and managing entries.

Sidebar: Extend the existing Time Tracking widget to include a "+" that triggers a dropdown with the time entry fields. This uses a similar UI overlay as Confidential and Lock widgets and keeps the actions close to the widget while maintaining the context of the page. A "Set estimate" (or, after entry, "Edit estimate") action utilizes a similar dropdown to provide the estimate input.

Time Tracking Report: Extend the existing Time Tracking Report modal to include Edit functionality, utilizing a directly editable table. An empty new line provides the ability to additionally add time from this context, and users can edit the estimate from here as well, providing a complete and self-contained management experience. Filters (user/date range) and bulk actions from the table further provide capabilities for understanding or managing time.

📼 Video walkthrough (audio is not great, let me know if you'd like a cleaner version)

👉 Figma prototype

Static designs will be attached

Redundancy

Redundancy

Redundant controls are provided between the Report and Sidebar contexts for adding time entries and editing the estimate as these each serve a different use case — sidebar primarily for quickly entering time or initiating the issue/MR, and the report for managing time tracking on that item. It would be inconvenient to force a user to switch contexts

👣 As these are redundant controls, they could be built iteratively as either one existing would enable this functionality.

Time Format

Suggest making hh:mm the default for time entry to reduce errors — #h #m has greater ambiguity and potential for error, e.g. is there a space, is it “h” or “hr”, etc. — and standardization with time conventions in many other tools. However ideally the existing format could also be recognized and converted to hours:minutes.

Optimal Time Entry accepted formats image

Feedback Questions

  • Does this design provide a quick and simple way for a user to estimate and enter time?
  • Are the separate input and management contexts clear, and feel valuable to separate?
  • Is it clear how you’d interact with the report table? Is it clear when things get saved?
  • What’s missing that would improve the time tracking experience?
Edited by Nick Leonard