Camelo is a B2B workforce management tool for shift-based teams. The features here vary in scale: a dashboard redesign that affects every user, a pay calendar that touches payroll, a document system spanning web and mobile. In a connected product, most decisions require understanding not just the feature itself, but where it touches the rest of the system.

This is a showcase of work that didn’t make it into a full case study. The metrics weren’t always there, but the design problems were real and the decisions are worth seeing.

Redesigning the Dashboard page

The Dashboard was the first screen every user saw, but a single fixed layout was trying to serve managers, admins, and employees: three roles with very different daily priorities.

I redesigned it around a card-based system where each card surfaces a distinct feature: clock-in status, latest schedule, attendance notices, team posts, and tasks. Cards can be shown, hidden, and reordered, so each role gets a starting point that fits their actual day rather than a generic default.

Schedule warnings

Scheduling conflicts (overlapping shifts, time-off clashes, hour limit violations) were often invisible until after a schedule was finalized. I designed an inline warning system that surfaces issues in real time as shifts are added, alongside a conflict drawer that gives managers a full overview before publishing. The goal was to make problems visible without adding friction to the scheduling workflow.

Attendance Notices

Managers needed a quick way to spot attendance issues at the start of their day: who clocked in late, who didn’t show up, who was working an unscheduled shift.

I designed an Attendance Notices section on the Home page that surfaces the ones that need attention. Each notice carries just enough information to act on it: who, when, what the issue is, and the one or two next steps a manager would take.

The tricky part was scope. Attendance connects to scheduling, timesheets, and messaging. A late clock-in might warrant a timesheet correction or a message to the employee. I had to decide how much of that to support within the notice itself versus handing off to those other flows, and design the handoffs so the experience didn’t feel disconnected.

Time Off Policies

Time-off policies are how a workplace defines its rules: how much leave employees get, how it accrues, what types of leave exist, who’s eligible.

Behind the simple-sounding goal sat a lot of complexity. Accrual rates that depended on tenure. Different rules for different employment types. Carry-over caps. Policies that applied to some employees and not others.

I designed a setup flow that guided admins through one decision at a time, with sensible defaults at each step so a small workplace could finish setup in minutes. More complex workplaces could still configure edge cases without leaving the flow.

Documents page

Document management in Camelo needed to handle four jobs in one space: storing and viewing files, requiring employee acknowledgments, tracking expiry dates, and organizing content by folder. The challenge was keeping these functions accessible without overwhelming a screen with controls.

The main design tension was between completeness and clarity: each document row needed to communicate enough state (acknowledged? expired? pending action?) without turning the list into a status board. I worked alongside another designer to cover both web and mobile, making sure the information hierarchy held across screen sizes.

Pay Calendar

Setting up a pay calendar is something admins do once, but a misconfiguration early can have downstream effects on payroll. The choices (pay frequency, period start date, pay date) interact in ways that aren’t always obvious.

I designed a setup flow that stepped admins through each decision with a live preview of pay periods and pay dates, so they could verify the configuration before it went into effect.

Working across the product

Camelo is a connected product: attendance affects scheduling, scheduling affects time off, time off affects payroll. Working across these features reinforced how rarely a design decision is truly isolated.

The breadth of this work also sharpened how I think about scope. Some problems needed careful system design. Others needed a focused, minimal interface that gave users exactly what they needed. Knowing which was which, and resisting the urge to over-engineer the smaller ones, is a skill this kind of work builds.