The Side Panel That Became a System

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

It started as one component for one feature. It ended as a pattern three teams reached for by default.

That arc—from component to system—is the whole story here. Not because we set out to build a system, but because we kept asking the same question every time complexity showed up: "Where does this go?" And the honest answer, every time, was the same panel.

By the end, we'd combined progressive disclosure, deep product knowledge, and a shared design system into one interaction model that scaled across products and teams—without anyone having to redesign it. Different content, same system.

Context: Time & Attendance Looks Simple. It Isn't.

On the surface, T&A is three verbs: clock in, clock out, track hours.

Underneath, it's a swamp. For a single day, for a single employee, you might be juggling:

• Shifts that change per employee
• Holidays that vary by location
• Attendance anomalies and flags
• Leaves, undertime, overtime, and corrections
• Supporting documents—certificates, approvals, proof

And all of it has to coexist in one experience, often on one screen, without making the user feel like they've opened a filing cabinet. We needed an approach that could absorb more complexity without producing more confusion.

The Problem: Too Much, Competing for Attention

Our problem was never a lack of features. It was the opposite—too much information shouting at once. Three issues kept surfacing:

We needed a way to reveal complexity progressively—on intent, not all at once.

What We Were Trying to Achieve

The goal was easy to say and hard to execute:

Show everything, without showing everything all at once.

Concretely, that meant:

• Keep users grounded in their current context
• Reveal information progressively, based on what they're trying to do
• Support the simple case and the complex case in the same flow
• Make the whole thing extensible—so new features plug in instead of redesigning

That north star had a name: progressive disclosure. And the side panel became the canvas for it.

How the Dynamic Side Panel Works

Visual note: The clips below aren't decoration. Each one anchors an abstract idea—"progressive disclosure"—in a real interaction, and shows the same panel adapting without breaking context.

Level 1: Core Context

Try it yourself. Open the live panel, step through the days, then click the shift card to drill into its details—all without leaving the page.

We start on the attendance dashboard widget, where the user sees their scheduled shift and actual time logs. The key moment: they select the shift block, and instead of navigating away, the panel slides in. The page doesn't change—the depth of information does.

At its most basic, the panel answers one question: "What happened on this day?"

• Actual time in and time out
• Assigned shift, with its schedule and rules
• Breaks and expected durations
• Attendance status, plus any notes tied to that shift

All of this while the dashboard stays visible behind it. That alone kills the need to navigate elsewhere and gives the user a strong sense of place.

Level 2: Supporting Information

As the user scrolls or digs in, more layers surface:

• Shift rules that apply to this specific day
• Holiday overlaps
• Exceptions or flags

The discipline here: these are contextual, not decorative. They appear only because they matter to the day being viewed. Nothing loads "just in case."

Level 3: Actions and Requests

This is where the panel proves its worth—and where complexity usually explodes.

The same panel hosts a whole family of actions: apply for leave, request corrections, submit certificates of attendance. Each one follows the same layout and interaction model. Different content, same system.

Take the hardest of them—applying for leave. Policies, dates, balances, validations. Instead of one massive form (or worse, a new page), the panel breaks it into four focused steps, each a single decision:

1. Select leave type and dates
2. Review leave balances
3. Provide supporting details or documents
4. Final review and submission

One step at a time. The user is never staring down the whole form, so cognitive load stays flat even as the task gets heavy.

Reusability Across the System

📌 Design once, scale everywhere

We designed this as a reusable interaction pattern, not a feature-specific UI. The same behavior shows up across:

• Attendance dashboards
• Requests and approvals
• Other HR workflows

Users learn the pattern once and apply it everywhere—only the content changes. For teams, that meant faster delivery and fewer design debates. For users, it meant predictability: they always knew what opening that panel would do.

Why the Design System Made This Possible

This whole experience would have collapsed without a strong design system underneath it. The panel wasn't a one-off component—it was a pattern, and patterns need shared foundations:

• Standardized spacing and hierarchy
• Reusable form patterns
• Clear rules for headers, sections, and actions

So when a new use case arrived, we plugged it in instead of reinventing the UI. The tell that it was actually working: when new teams needed a side panel, they stopped asking how to design one. They asked what content belongs at which level. That's the moment a component becomes a system.

The Role of Product Knowledge

Here's the part that doesn't get talked about enough: this wasn't just a design exercise.

Understanding Time & Attendance deeply is what made the levels right. Knowing which data mattered first. Understanding the real approval flows. Anticipating edge cases before they showed up in production. Product knowledge is what told us a graveyard shift's break rules belong in Level 1, not buried three taps deep.

Design systems scale UI. Product knowledge scales decisions.

What Success Looked Like

We didn't ship this with a dashboard of conversion metrics—it was an interaction model, not a funnel. So before touching pixels, I defined what a win actually meant, and every decision got measured against it:

• One stop for "what happened today." A user should answer that question without leaving the page or opening a second tab.
• Complexity reveals, never dumps. The hardest task in the product (a multi-step leave application) should feel like four small decisions, not one overwhelming form.
• Learn once, use everywhere. A user who's opened the panel in attendance should feel instantly at home opening it in requests.
• New features plug in. A new use case should be a content question, not a redesign.

Most importantly, the system had to feel calm even when the data wasn't. That was the real bar.

What I'd Do Differently

I'd pressure-test the level model earlier, with messier data. Our levels held up beautifully for a clean day—but the truly gnarly days (overlapping holidays and a correction and a pending leave on the same date) are where the hierarchy gets argued over. Next time I'd start with the worst day on the calendar, not the average one, and let the panel earn its structure against the chaos from day one.

Key Takeaways

1. Complexity is inevitable. Confusion is optional.
2. Progressive disclosure is a strategy, not a gimmick—it only works when every layer is contextual.
3. Design systems are force multipliers, but only when paired with real product understanding.
4. You know a component has become a system when teams stop asking how to build it and start asking what goes in it.

This panel lasted not because it was clever, but because it understood the product deeply—and because the system let everyone else reuse that understanding without rebuilding it. That's what makes systems last.