Redesigning Timesheets Around How People Actually Work

Timesheet is where Proteus's project economics begin.

Every minute logged feeds project profitability and utilisation reporting, making Timesheet the highest-frequency workflow in the platform. We use Proteus internally too, so recurring problems were already visible inside the business. The redesign began as an internal product initiative rather than a client request, with the wider goal of making the platform viable for larger organisations.

During the redesign, one client wanted to adopt the new experience early. We prioritised a usable first release for them, then continued iterating from live feedback before progressively rolling the system out to the rest of the client base.

The old system's failures were structural, not cosmetic.

"Just adding my projects takes ages. Internal calls happen every single day, but every week I have to scroll all the way to the bottom to add them. And the rows all look the same, I have to read the names carefully, and when there are a lot of them I still end up double-checking everything after I've filled it in."

Engineer, internal interview

One person, describing several failures in the system at once.

• Users couldn't shape their own working set. Visible rows depended on a PM removing or locking a project. Work packages, the thing people actually logged against, were buried under projects, while recurring non-billable work sat at the bottom of the list.
• The interface surfaced the wrong information for the decision. Budget context required expanding projects one at a time, while approvers were given day-by-day detail that rarely helped them decide. Reporting often ended with raw exports being rebuilt manually in spreadsheets.
• Approval responsibility didn't match decision ownership. Line managers and project managers were making different decisions, but the old flow treated approval as one generic action and separated budget ownership from the person approving the time.

I mapped the information architecture before designing screens, then pressure-tested it with users and the wider team.

We run Proteus ourselves, so the first round of interviews was internal: 5 people across 3 roles. That was the fastest way in, and also the obvious limitation: our consultancy is one company, not fourteen. Where a decision depended on how client organisations were structured, the BA and CTO took those questions directly to clients before we committed.

I also benchmarked interaction patterns in ClickUp, Hubstaff and Clockify. Their grids, bulk actions and list-based approvals were useful references, but their product models were simpler than ours. None had to reconcile work-package budgets with multiple approval roles, so the interaction patterns transferred more readily than the information architecture.

I organised the redesign around three product decisions rather than a list of features.

Decision 1/3

Design around the work users actually log against

The work package is the real unit.

Users don't think, "Which projects am I on?" They think, "Which work package do I log against?" The old system buried that unit under projects and made the PM, rather than the user, responsible for what appeared on a timesheet.

I restructured My Time around three top-level categories: Projects, Proposals and Non-Billable, with work packages as the primary interactive unit. A two-tier status model at week and row level makes approval progress visible without forcing users into each row individually.

Let users curate their own working set

A dedicated Manage Rows modal lets users add exactly what they need, whether a whole project or only specific work packages. New assignments are flagged, and copy-from-week removes repetitive setup. What used to depend entirely on a PM's actions became something users could manage themselves.

Keep repetitive entry familiar

Our users already live in spreadsheets, so I borrowed the interaction behaviours that reduced repetitive work without trying to recreate Excel. Users can drag to fill repeated hours, attach notes at cell level, and clear a row in one action.

Decision 2/3

Separate approvals by the decision being made

Two approvers, two different decisions.

Line managers watch workload distribution: utilisation and billable split. Project and proposal managers make commercial decisions about budget. The old system treated both as the same approval problem, which meant the action and the information needed to make that decision often sat with different people.

I split the workflows but kept the interaction pattern consistent. Line Manager Approvals surfaces utilisation and billable split. Project and Proposal Approvals surfaces Budget, Booked, Remaining and Impact inline, so an over-budget submission can be caught before opening the detail view.

Decision 3/3

Fix the dependency upstream

Who can log time is decided before the timesheet opens.

Once the time-entry experience was restructured, another dependency became clearer: users can only log against work they have already been assigned to in the Project module. That meant the timesheet redesign could not stop at the timesheet itself.

I improved Project Resources with clearer hierarchy across WBS levels, bulk assign and lock/unlock actions, richer resource information, and inline Budget vs. Booked figures. A PM can now understand the resourcing load while making the assignment rather than after the fact.

The first release iterated on the existing Project Resources structure rather than replacing it outright. That reduced rollout risk for a central module while still removing the biggest sources of repetition. The fuller redesign remains future work, now informed by live usage rather than assumptions.

From early adoption to platform-wide rollout.

Timesheet 2.0 first went live with a client that wanted to adopt the redesign before the wider rollout was ready. That gave the team real usage to learn from while the product was still evolving. From 2025 onwards, the system rolled out progressively across the client base and is now used by 4,000+ users across all 14 client companies.

Post-launch feedback gathered through Customer Success has consistently highlighted time savings and improved usability, including the clearer grouping of timesheet categories and easier resource assignment. Continued use has also generated multiple rounds of follow-up requirements rather than the module becoming a one-off redesign.

"A massive amount of great work done, all the way from design, documentation, development, delivery and finally launch planning… our timesheet system will be (if not already is) the best in the industry."

CTO, on launch day

From weekly to daily: live usage is now driving the next structural evolution.

One capability deliberately left out of the first release was configurable approval periods. After launch, clients asked for more flexibility: some organisations work in weekly cycles, others day by day. Supporting both moves the source of truth from the row to each individual entry and opens up a more flexible model across the system.

Designs for the daily model are complete and in development: entry-level status, so a single row can hold submitted, approved and draft days at once; date-range approvals, so approvers work in whatever period suits them; and confirmation scaled to impact, a popup for single rows and a modal for bulk actions.