Can this employee
take leave?
One question. Several systems. Different states.
What coverage applies?
- Benefit A
- Approved
- Benefit B
- Pending
What requirements are met?
- Required document
- Missing
- Medical certification
- Awaiting review
Which dates are covered?
- Time-off request
- Approved
- Changed dates
- Check alignment
An approved request is only one piece of the answer.
Illustrative states from the problem framing—not a final interface or an eligibility determination.
The challenge
A simple question.
A complicated answer.
At Tilt, “Can this employee take leave?” isn’t answered by one status. A leave may involve multiple benefits, each with its own eligibility and approval state. Those benefits can depend on documents that are missing, under review, approved, rejected, or fulfilled through another path.
Meanwhile, time-off requests have their own dates and approval states. Changes to those dates can affect the benefits attached to the leave.
Each system made sense on its own. Together, they left an HR admin with a puzzle: what’s approved, what’s unresolved, and what needs attention?
My role
Make the relationships understandable.
My goal was to make the relationship between benefits, documentation, and requested time visible enough that an admin didn’t have to reconstruct the state of a leave every time they opened it.
This meant looking beyond individual status labels to the mental model of the whole leave: how its parts depend on one another, where their states diverge, and what an admin needs to understand before acting.
Detailed ownership, partnerships, and project timeline will be added here.
Our job wasn’t to remove the complexity. It was to make the complexity understandable.
The approach
Connect the pieces without hiding the nuance.
A single “Approved,” “Pending,” or “Denied” label could conceal an unresolved requirement or imply that all requested dates were covered. The design problem was to preserve the detail needed to administer leave while making its relationships easier to understand.
Trace the paths behind an approval.
Mapping the benefit paths made the distinction between job protection and paid benefits visible, alongside the eligibility checks and documentation each path depends on.
Make document dependencies explicit.
A second map connects leave types with document requirements across state benefits, insurance, FMLA, and company policy.
The edge cases are the work.
The problem becomes clearest where individual states don’t tell the whole story:
A requirement fulfilled another way
A document can appear overdue even though another document has satisfied the same requirement. Document status and requirement status need to be understood together.
Dates that change after benefits are applied
A time-off change raises a new question: does the existing benefit still align with the requested dates?
Multiple benefits, different coverage
Benefits may cover different portions of one leave. Understanding one benefit’s status doesn’t explain the entire leave.
Attention needed isn’t the same as denied
An admin needs to distinguish an outstanding task from a decision about whether the leave is approved.
The evolving models, explored concepts, and user or stakeholder feedback will be added with the design artifacts.
The outcome
No black-and-white answer.
A clearer picture.
Leave doesn’t always have a single, clear-cut answer. Someone may have coverage for one block of time but still be waiting on approval for another. A benefit might require documentation—or a document already on file might fulfill that requirement.
The goal is to make those pieces easy to find and understand together: when someone can take leave, which benefits apply to each block of time, and what is still needed to approve them. HR, managers, and employees need enough context to understand what applies to them and what needs attention.
We can’t reduce every situation to a simple yes or no. But we can make the relationships between dates, benefits, approvals, and documents visible—helping people see the whole picture and understand their next step.
