Custom Fields for Flexible Time Tracking
Client
7pace | Appfire
Role
Lead Product Designer
Year
2024
Context
Time tracking captures hours. But most organizations need more than hours. They need context: what type of work, which cost center, is this billable, what is the project code.
I designed Custom Fields for 7pace across Azure DevOps, Jira, and monday.com. A system that lets teams define and capture structured operational data at the point of time entry, without adding friction to daily logging.
Problem
The product had a fixed logging model. Organizations with more complex data needs were working around it through spreadsheet exports, naming convention hacks, and post-processing scripts to tag entries correctly after the fact.
Every workaround is a signal that the product is not solving the real problem. The time was being logged, but it was not meaningful.
Concept
Two distinct user modes with very different needs.
Admins need power and flexibility. They are configuring fields for their entire organization, and the setup has to be comprehensive enough to handle edge cases without becoming a configuration nightmare.
Contributors need simplicity. They are logging time, not managing a data model. Fields need to appear when relevant and stay invisible when not.
The hardest part was not the flexibility itself. It was the constraint. Every field type and configuration option had to be evaluated against one question: will this slow down someone logging fifteen minutes of work? Platform consistency across ADO, Jira, and monday.com added another layer. Same field logic, three different interaction environments.
Outcome
Custom Fields turned time logs into structured operational data. Teams could capture billing codes, work categories, and cost allocation at source, which meant reports that did not require cleanup and data that was actually usable downstream.
More importantly, it removed the workarounds. When people stop building their own systems around a product, that is a real signal.
