Homebase

Rebuilding employee availability for 3.5M+ hourly workers

Role

Product Designer

Context

Internship

Timeline

Jun - Dec 2026

Tools

Problem

Employees couldn't enter their true availability using just the app.

Due to limitations in our current availability model, employee availability requests repeated weekly, and with no end date.

“Once my track season starts in January, I won’t be able to work on Fridays or Saturday until March or April.”

Example of an employee using the “Availability Notes” field to describe inputs that our current system lacked.

“Once my track season starts in January, I won’t be able to work on Fridays or Saturday until March or April.”

Example of an employee using the “Availability Notes” field to describe inputs that our current system lacked.

“Once my track season starts in January, I won’t be able to work on Fridays or Saturday until March or April.”

Example of an employee using the “Availability Notes” field to describe inputs that our current system lacked.

Class schedules, other jobs, and one-off changes were more easily communicated outside of Homebase.

The majority of availability updates typically happened over text, email, or in-person conversations, meaning what information the app did have was often out of date.

Most employees set their availability once during onboarding and never update it. 11 of 15 employees would rather text their manager when something changed.

Image: Purgatory Pizza, Los Angeles

Most employees set their availability once during onboarding and never update it. 11 of 15 employees would rather text their manager when something changed.

Image: Purgatory Pizza, Los Angeles

Most employees set their availability once during onboarding and never update it. 11 of 15 employees would rather text their manager when something changed.

Image: Purgatory Pizza, Los Angeles

My Role

I led the redesign of how employees set their availability.

I worked alongside a PM, design manager, and the 3 engineers. Every iteration followed the same loop of research, prototype and test.

Research

Prototype

Test

4 iterations

Background Research

Before designing, I studied the way common hourly scheduling apps handle availability.

While functional, we found through testing that this way of entering availability didn’t match how employees generally thought about when they could and couldn't work.

7shifts

Deputy

When I Work

Gusto

Initial Insight

The availability request was actually hiding several reasons why an employee couldn't work.

Employees had to put everything into one availability request, but each reason they couldn’t work had its own end date or recurrence which couldn't be captured by our existing system.

A single weekly schedule could hide several commitments (old UI).

Iterations

The design went through four major revisions, each shaped by the previous iteration.

Every version was tested before moving on, with teammates, customers or employees depending on the round.

To start, I rebuilt the current availability request setup mirror our current model: one weekly schedule, Monday to Sunday, with new inputs for custom start and end dates.

One weekly schedule could mix a few things, such as practice on Sunday and class on Monday. Each reason gets its own "time block" that can change or end independently.

On calls with small business owners, they talked in dates, such as “I’m not available Mondays, starting on the 12th.” In V1, the days and the start date were two separate questions. Here, I used a calendar as the primary input of the form, combining the inputs for the day it repeats on, and the date it starts on.

V3 cleans up the V2 form into the final version. Validated through usability testing and multiple rounds of design crit.

Before acting on the initial insight, I rebuilt the current availability request setup as closely as I could: one weekly schedule, Monday to Sunday, with added inputs for custom start and end dates. It was a test of what a new version of availability could look like if it mirrored our current system.

One weekly schedule could mix a few things, like practice on Sunday and class on Monday. So each reason got its own entry that can change or end on its own.

On calls with business owners, they talked in dates, like “I’m not available Monday the 12th.” In V1, the days and the start date were two separate questions. So I put a calendar at the top of the form, where tapping a date picks the day it repeats on and the day it starts at the same time.

V3 cleans up the V2 form into the final version. It’s also the version we validated the most, through usability testing and rounds of design crit.

One weekly schedule could mix a few things, like practice on Sunday and class on Monday. So each reason got its own entry that can change or end on its own.

V3 cleans up the V2 form into the final version. It’s also the version we validated the most, through usability testing and rounds of design crit.

Final Design

Teaching employees to split up their availability requests by reason.

Since splitting the requests into separate entries is a new way of thinking about availability in Homebase, the design needs to accomodate for active employees who are accustomed to submitting one availability request that holds all the reasons they can’t work. To introduce the new desired behavior, the form opens on a single question, “Why can’t you work?”, and builds one request around the answer.

Why can’t you work?

Select a reason

Autofill the form

Send for approval

Validation

A usability test answered the final open questions.

In addition to presenting prototypes at design crits, I ran a usability test with several members of Homebase’s internal CX and Growth teams (who were great proxies for customers), and built the final form around those findings.

I tested two versions of the form for adding a time you can't work. One put the reason, days, times and repeats on a single screen you scroll. The other moved days and times to a second screen you tap into, which looked cleaner but add a step.

5 of 7 participants preferred the single screen. Navigating between two sheets bothered participants, whereas nobody had an issue with having all content presented in a single sheet.

The first field is where an employee says what the time is for, like Classes. One version called it "Label", and the other called it "Reason".

All participants resonated more with "Reason". To them, a label is a note to yourself, whereas a reason feels like something you give your manager.

The form already asks for a reason, days, times and locations, so an optional note to the manager potentially could be just another field that just repeats already specified content.

Many participants found it useful, each for something the reason didn't already cover: how urgent it was (example: a son in the ER), context that changes the call (classes that end this semester), or flagging a mistake. I decided to keep the optional field.

“I like seeing everything on the screen and going down, going section to section and selecting everything.”

P5, CX Team

“I think with showing all the options instead of having to click into a lot of loops, the simplicity of it makes it easier to use for everybody.”

P6, CX Team

5 of 7 participants preferred the single screen, including both who saw the two step version first. Going to another screen and back is what bothered them, and nobody said the single screen showed too much.

The first field is where an employee says what the time is for, like Classes. One version called it Label (optional) and put it near the bottom. The other called it Reason and put it first.

All 3 participants I asked picked Reason. To them a label is a note to yourself, and a reason is something you give your manager. In the final design the reason goes to the manager with the request, so the word now matches what happens to it.

The form already asks for a reason, days, times and locations, so an optional note to the manager could be one more field that just repeats the reason.

4 of 7 participants found it useful, each for something the reason didn't cover: how urgent it was (a son in the ER), context that changes the call (classes for this semester), or flagging a mistake. It stayed as an optional last field.

“I like seeing everything on the screen and going down, going section to section and selecting everything.”

P5, CX Team

“I think with showing all the options instead of having to click into a lot of loops, the simplicity of it makes it easier to use for everybody.”

P6, CX Team

Success Metrics

More employees inputting their availability, and actually keeping it up to date within the app.

Of the millions of employees with a shift in the last 90 days, about 1 in 4 had set their availability, and about 1 in 7 edited it in that time. 12 months after launch, we're aiming for:

27% → 35%

of scheduled employees with availability on file

14% → 20%

of scheduled employees with updated or confirmed availability in the last 90 days

Updating the availability feature also serves as a building block for Homebase Assistant!

To support future agentic scheduling tooling, we’ll need reliable employee availability. The new availability design empowers employees to say something like “My class on Tuesday got canceled, let my manager know I can work,” and the assistant could find the Classes entry, mark Tuesday available and tell their manager, all without needing to open the app. This never would have been possible before!

Reflection

Availability is a surprisingly complex surface, it was even difficult deciding what to even call it!

Explorating ideas using Figma + Claude Code made changes cheap to test, and allowed for more time to be spent choosing the "right" option and getting the inputs clear enough that a 16-year-old working at an ice cream shop could understand it.

Next project

HandshakeRedesigning the weekly job digest for 7M+ students, which they rated ~22% higher.Jun - Aug 2025

Problem

Competitive Landscape