How Shift Management Almost Broke Our Admins (and What We Did About It)

Role: Lead Designer & Interaction Designer · Company: Sprout Solutions (HRIS) · Timeline: 1 month · Team: 1 PM, 1 Designer, 1 Engineer

You know it’s bad when your users start secretly building their own tools to avoid using yours. That was the vibe we were getting from HR admins using our scheduling feature—if they were using it at all.

Some would stay hours past their shift, wrestling with our clunky UI just to plan the next week. Others gave up entirely and built Frankenstein Excel sheets that made more sense to them than our actual tool. Ouch. It was like buying a fancy treadmill and using it as a clothes rack.

So, what was going on?

The Problem: Workforce Planning, But Make It a Nightmare

Imagine having to schedule 100+ employees across:

• Multiple companies
• Multiple work locations
• Multiple shift types (broken shifts, graveyard, “why-are-we-open-at-this-hour?” shifts)

Now imagine doing that every. single. week.

Admins were drowning. The tool wasn’t helping—it was dragging them down. Instead of simplifying their lives, it was making them say things like, “Let’s just use Google Sheets again.”

As a team that proudly says we “make work life easier,” this was a hard pill to swallow.

My Role: Lead Designer / Shift Therapist

I led design and interaction for the feature overhaul. But honestly? I felt more like a shift therapist.

I kicked off with deep-dive interviews and ideation sessions with our clients—HR admins living this workflow every week. That’s where we started to hear things like:

“I’m doing OT just to fix the schedule every week.”
“It’s easier if I don’t use your product.”

(If that doesn’t make your inner designer soul shrivel up, I don’t know what will.)

The Process: From Chaos to Enterprise-Ready Calm

We didn’t want to just patch things up—we wanted to future-proof it. Make it enterprise-proof, even.

So we asked ourselves:
What if we stopped designing for one admin’s messy Tuesday—and started designing for an entire org’s scheduling philosophy?

That led us to three big design moves:

1. Think Reusable, Not Repetitive

Admins were creating the same shifts again and again. Midnight-8 AM here, 2 PM-11 PM there—it was like déjà vu with extra clicks.

So we thought:
Why not let them build shifts once and reuse them everywhere?
Not only that, but what if other admins could tap into those same pre-defined shifts too?

Boom: shared shift libraries.
Create once, use forever. Or at least until someone retires.

2. Design for Modularity and Scale

We wanted to make scheduling feel like building with LEGO, not assembling IKEA furniture. So we focused on modularity: reusable components, scalable logic, and drag-and-drop ease that could adapt to everything from startups to 5,000-headcount enterprises.

That’s where the idea of the Shift Builder came in—a centralized, intuitive way to build, name, and manage shifts like a pro.

🧱 ASCII Shift Workflow: From Builder to Everyone

+---------------+
| SHIFT BUILDER | <-- Step 1: Create your custom shift types here.
+---------------+
         |
         v
+----------------------------+
| ASSIGN SHIFTS TO EMPLOYEES | <-- Step 2: Use your saved shifts and apply in bulk.
+----------------------------+
         |
         v
+-----------------------------------------+
|   SHIFTS SYNCED ACROSS ECOSYSTEM       |
|   - Web App                            |
|   - Mobile App                         |
|   - User Profiles                      |
|   - Team Calendars                     |
+-----------------------------------------+

The result?
Admins spend less time copy-pasting and more time actually managing. Plus, everyone—from managers to rank-and-file—gets shift visibility across all touchpoints.

It’s one of those solutions that looks simple on the surface, but under the hood? It’s a beast built for scale.

Key Moment: Designing for Scale, Not Just Screens

Once we truly understood how overwhelming workforce planning was, we pivoted our design. We made bulk actions smarter. We made setup management way easier. And most importantly, we created an experience that could scale across a range of complex scenarios.

Suddenly, the feature didn’t feel like a time sink. It felt like a time saver.

Admins started to breathe again. (Some even smiled, I swear.)

What Success Looked Like

Before touching pixels, I defined what a win actually meant—the bar every design decision got measured against:

• Minutes, not hours. Building a full week of shifts should take a coffee break, not an evening of overtime.
• Create once, reuse everywhere. A shift defined by one admin becomes a building block any admin can drop in—no rebuilding the same graveyard shift for the hundredth time.
• Retire the shadow spreadsheets. The real win was making the product the easier path, so the Frankenstein Excel sheets quietly went away on their own.
• Scale without breaking. The same flow had to feel light for a 20-person shop and hold up for a 5,000-headcount enterprise across multiple companies and locations.
• One source of truth. A shift created in the builder shows up correctly everywhere it matters—web app, mobile, employee profiles, and team calendars.

These weren’t vanity targets—each one mapped directly to a pain we heard in the interviews. Get them right, and the numbers take care of themselves.

The “Oh Crap” Moment: We Designed It Backwards

Here’s the twist: in our first version, we made it easy to assign shifts to employees—but not the other way around.

Turns out, admins don’t think that way. They start with a shift (like a 9 PM–6 AM graveyard), and then figure out who fits. Not the other way around.

That was a big “oh crap” moment. But it was also a great opportunity to iterate.

What I’d Do Differently

Next time? I’d zoom out even more. We missed out on interviewing industries like manufacturing and healthcare, where shift planning gets even wilder.

The lesson: Don’t assume one industry’s chaos is another’s norm. Design might be universal—but workflows sure as hell aren’t.