Andrew Colclough – UX & UI Designer

HR App: Time Off Feature

Problem

At Arcoro, I built software used in the HR industry. Our core time-tracking product was called ExakTime, and it was lacking a time off management feature. This feature needed to serve three core users:

Administrators needed to be able to create and assign time off plans
Supervisors needed to manage and approve requests for their teams
Crew Members needed to easily see their time off balances and make requests

I was a lead designer on all aspects of the time off feature, including the mobile application. I first focused on the needs of our admin users for time off plan creation and administration.

My Role

Feature Designer

Contributions

User Research

Visual Design

Interaction Design

Prototyping/Coding

User Testing

Plan Management

Our research indicated that our admin users already had an idea of how time off should work. Our product needed to build on our admins' expectations, while not overloading them with information or complexity.

Tools

Figma

Telerik

Internal Design System

The example below is of a time off plan which included different tiers based on years with the company.

Highlighted Challenge

Time off plan tiers were interconnected. Put simply, changing one tier affected all the others.

Hypothesis: What if we carefully walked admins through each tier, clearly indicating how each change would alter related tiers?

Solution

Through an iterative process, I designed tiers to follow a step by step model, progressively updating and adding interface elements as needed. The interface made calculations automatically as admins walked through each tier. This had an additional benefit of reducing errors, as data could be validated as tiers were created.

Our test admin users provided many scenarios that I had them walk through once I completed a prototype. This helped inform and validate my design.

User Testing Results

Initially, my design allowed users to add and remove any tier in the series. However, this greatly increased the complexity for our admins (and developers). Through their feedback, we settled on a simpler linear process, only allowing addition and removal to the last tier.

Problem

There was no way for supervisors and crew members to view available time off or make requests.

Though we also designed and built a responsive web solution for our supervisor and crew members, here I will focus on the mobile application.

Requests and Approvals

Highlighted Challenge

For most employees using our app, time off was divided into different types (e.g. PTO, Sick). Therefore, types of time off had different balances.

Hypothesis: What if I modified an existing card UI to separate types of time off and highlight accrued balances?

Solution

User research indicated that our existing app structure was understood by our target users. For this reason I chose not to radically change the look and feel of the app for the time off feature. Instead, I adapted and expanded existing UI patterns and components to differentiate time off types and balances.

I designed every request with a high level summary, informing users which type of time they were pulling from, how many hours they had accrued, and how many hours each request used.

Supervisors required an additional flow that allowed them to see pending requests, approve or deny them, and attach comments. Once again, I extended an existing scheduling UI to accommodate requests, adding additional indicators for time off type and approval status.

User Testing Results

Initially, in my early designs, I tried to add all actions at the top level of a request card. I reasoned that supervisors could take actions without drilling into a request.

However, working through feedback from our UX team and target users, it was clear that only the most typical action, "Approve," was needed at this level. Secondary actions were far less common, so I moved request denials and modifications to a request "View" screen. This resulted in a less complicated main view that still provided functionality for important secondary actions.