Three phones showing the redesigned SAP Fieldglass time entry app: today's tasks with timers, the weekly timesheet, and the timesheets list
← All projects
B2B SaaS Mobile Design

Redesigning the SAP Time Entry App: From Tedious Tapping to Seamless Tracking

I redesigned the SAP Fieldglass Mobile Time Entry from 0 to 1, replacing about 90 percent of the old experience with a new information architecture, a timer-based interaction, and new screens for workers and managers. The result is one connected workflow from recording work on mobile to reviewing and approving it on desktop.

Role

Product Designer, Scrum UX lead

Team

2 designers, 1 PM, 6 developers, 1 QA, 1 tech writer

Timeline

Jan 2024 – Aug 2026

Problem

Workers were struggling to get paid on time because submitting a timesheet on mobile was unnecessarily painful. The old app carried 1.4 stars on the App Store and 2.4 on Google Play.

Outcome

A 0 to 1 rebuild: new information architecture, a timer-based core interaction, and new screens for workers and managers, from recording work on mobile to approving it on desktop.

01 / THE PROBLEM

What workers were dealing with

SAP Fieldglass is an enterprise SaaS platform that helps large organizations manage their external workforce and vendor relationships at scale. As a global B2B product, it supports complex workflows and compliance needs across different industries and markets.

However, workers using the Fieldglass mobile app were struggling to get paid on time because submitting a timesheet on mobile was unnecessarily painful. The existing app carried ratings of 1.4 stars on the Apple App Store and 2.4 stars on Google Play, which is a clear signal that something needed to change!

Screens from the previous SAP Fieldglass time entry app
This is what the current time entry app looks like.

If we categorize the problems into core pain points:

Time consuming & tedious

No ability to copy time from previous days, manual entry required for every individual day.

Complex interface

Too much information displayed at once, workers needed training just to submit their hours.

Outdated & slow

Frequent crashes, long load times, unreliable saves, and a UI that didn't feel native to mobile.

02 / RESEARCH

How our users actually submit time

To ground our decisions in real behavior, I worked with our UX researcher to combine app store sentiment analysis, user research interviews, and data mining across the global worker base.

Who are our users?

Workers ranged across a wide variety of roles, including Business Analysts, IT professionals, Machine Operators, Project Managers, Contract Specialists, and more. Despite their different contexts, their time entry needs shared common patterns.

How often do workers submit time?

  • 80% submit weekly, 20% submit daily
  • US workers are predominantly on weekly timesheets (91.8%)
  • EU workers have a higher share of monthly timesheets (32.1%)

How many tasks per day?

  • Median: 1 task (US and EU alike)
  • Max observed: 22 tasks

That meant the common one-task day needed to be fast, while the product still had to support workers moving between many tasks.

03 / THE TURNING POINT

I challenged the workflow we were asked to build

Leadership initially asked us to improve the workflow already used by the old app. A worker would open a day, enter how long they spent on each task, separately enter when they started and finished work, then save everything. At the end of the week, they would submit the timesheet for manager approval.

Diagram of the assumed workflow: a worker remembers time in, time out and hours per task, ticks off Monday to Friday, and a manager approves at a desk
So ideally something like this.

However, based on my observation, this still solved the wrong problem. It made the worker responsible for acting as the recording device.

Based on the interviews we've conducted, many workers had to keep notes on paper or in other note apps throughout the day, then transcribe those notes into Fieldglass later. That is only slightly annoying for someone working at a desk, but much harder for a frontline worker moving through a job site such as an oil and gas worker.

Two illustrations: a worker at home at night reconstructing the day from paper notes on his phone, and a manager at a desk surrounded by rejected timesheets
But in reality we've seen more of this from both the workers and their managers.

I had also seen what happened downstream when those records did not agree. The hours entered for individual tasks often failed to match the separate clock-in and clock-out times. The manager could not resolve that discrepancy alone, so they had to contact the worker offline and ask them to correct it.

That's why instead of making that form easier to complete, I pushed for the product to capture the workday itself.

04 / THE NEW PRODUCT

And I designed a new product from the ground up

About 90 percent of the old mobile experience changed. I created a new information architecture, a new core interaction, and new screens rather than carrying the old workflow forward.

Simpler time tracking: the home screen lists today's tasks, each with a timer and Start and Finish buttons, shown across three states
No manual calculations: the Today so far summary, the Review Day screen with time in, breaks and time out, and the weekly timesheet with Submit Weekly Timesheet
From the managers' side: the desktop timesheets list with approval statuses, and a single timesheet detail with Approve and Reject

05 / WHAT'S NEXT

The app is built. Next comes measurement.

At the time documented here, the first version of the app is to be released soon!

Detailed usage data and performance benchmarks are confidential at this stage, however the team will be measuring success against the following key indicators post-launch:

App Store & Google Play rating

Use the current score as baseline, increase post-launch.

Mobile time submission rate

Increase the percentage of workers submitting time via mobile.

Worker satisfaction

Improve survey score through reduced friction and faster time entry.

Full performance results and usage data will be shared following the public launch post Sept 2026.

Due to confidentiality agreements, specific usage metrics and internal performance data cannot be disclosed at this time. Check back after launch for updated results! 🚀