All work Case study · 02

Setting up compliant leave policies.

Deeply localising Keka's leave setup experience to align with US workforce norms, regulations, and expectations — from geography-aware configurations and compliant templates to native terminology and formats.

RoleProduct Designer · Keka
Year2025
Duration6 weeks
MarketUS enterprise
Leave policies hero — Keka time off setup
01 — The problem

A legal exam no HR manager signed up for.

US HR and payroll teams must manually build location-specific leave plans that satisfy a complex web of federal and state-level labour laws. Most HR managers don't have in-depth legal knowledge of these statutes — so the effort invested in figuring out compliant leave plans typically stalls HRMS rollouts for weeks.

This results in repeated implementation calls, delayed go-lives, and a growing perception that Keka isn't truly "US-ready." Beyond the friction, misconfigurations carry real financial risk — exposing employers to fines and payroll corrections.

This pain has been surfaced repeatedly by existing clients — Xoxoday, Syren Cloud, skit.ai — and US prospects in discovery conversations. — Sales & implementation call analysis
02 — Business rationale

A retention and acquisition play.

Pre-built, editable, jurisdiction-aware templates simplify one of the most time-consuming tasks in US onboarding. By cutting go-live timelines, the feature directly contributes to earlier revenue recognition and a stronger competitive position in a market Keka is actively expanding into.

Competitors like Rippling, ADP, and UKG already lead with "compliant templates" as a sales lever. The feature has been explicitly requested by multiple existing clients and prospects — making it both a retention and an acquisition play.

03 — Current product

Multi-tab, multi-step, and easy to get lost in.

In Keka today, creating a leave plan is a multi-tab affair. HRs first create leave types in one tab, then create leave plans in a separate tab. While creating a plan they pick types, configure each one, and assign the plan to teams or employees.

  • Problem 01Plan duplication. If a single config differs between two teams, HRs must spin up an entirely new leave plan.
  • Problem 02Disconnected tabs. Leave types live in one tab, leave plans in another — the relationship isn't visible.
  • Problem 03Overwhelming config. New users struggle to understand and navigate the available settings.
  • Problem 04Fragmented flow. Leave types, plans, and assignment rules are all separate. The disjointed experience leaves room for errors.
  • Problem 05Year-end processing is hidden. Users can't associate year-end processing with plan setup and struggle to locate it later.
Current leave types tab
Current experience — Leave types tab
Current leave plan configuration
Current experience — Leave plan configuration
04 — User insights

Three themes from US prospects.

We spoke with several US prospects. Three themes came through clearly:

  • Theme 01No system guidance. There's no help from the product to set up compliant leave policies.
  • Theme 02Calendar year doesn't fit. US employees can cash in leaves whenever they want — a fixed calendar year feels foreign.
  • Theme 03Doesn't feel native to the US. Terminology, structure, and defaults all read as built for another market.
05 — Competitive analysis

How leading US HR tools handle leave.

We studied how Rippling, BambooHR, and Deel approach the same problem to understand what "table stakes" looks like in the US market.

Rippling leave policies
Rippling
Powerful configuration with country selection, priority order, and overlap resolution. Assignment handled outside policy creation. Configuration is long but comprehensive.
BambooHR FMLA leave
BambooHR
Directly assigns US-compliant FMLA policies to employees. Configuration is intentionally basic — easy for any HR user to grasp.
Deel country templates
Deel
Different policy templates per country. Multiple leave policies per employee. Templates do the heavy lifting on compliance.
06 — Objective

Compliance without the legal research burden.

As an HR admin, I want to create leave policies that comply with local labour laws, so that employees receive the correct leave entitlements while ensuring the organisation remains legally compliant. — User goal statement
07 — User journey

Mapping the end-to-end before drawing screens.

We began solutioning by mapping the ideal end-to-end journey for setting up leave policies — from country selection through template adoption to assignment and review.

User journey map for leave policy setup
User journey — country selection → template adoption → assignment → review
08 — Early iteration

Why the first approach didn't hold.

We reused a prior time-off setup revamp that had already solved the overwhelming configuration problem — narrowing the experience to 4 essential inputs and surfacing advanced config on demand.

Initially we proposed two templates: one US-compliant and one default for other markets. After internal reviews and prospect conversations, several flaws surfaced:

  • Flaw 01A "US vs. non-US" split alienates our core customers in India and the Gulf — framing one template as "non-US" implicitly demotes them.
  • Flaw 02One non-US template can't cover every non-US country. Users outside India would need to edit it every time.
  • Flaw 03US prospects don't think in "leave plans." They expect leaves to be configured and assigned directly — the "plan" abstraction confused them.
  • Flaw 04Plan proliferation. Changing one configuration for a team meant creating a whole new plan, ballooning the number of plans.

This made it clear: the architecture itself needed to change.

Earlier time-off setup revamp design
Earlier revamp — simplified 4-input config, carried forward as a principle
Early iteration with US vs non-US split
Early iteration — US vs. non-US split that didn't hold
The architecture had to match how US HR teams already think — not how Keka's data model was built.
09 — Architecture shift

From leave-plan bundles to time-off-type-led policies.

We flipped the model. Time off types become the top-level entity, and policies sit underneath them — each with its own configuration and assignment rules. This mirrors how US HR teams already think about leave, and removes the rigid bundling that forced plan duplication.

Current architecture — leave plan as top-level entity
Current — leave plan as top-level entity
New architecture — time off type as top-level entity
New — time off type at the top, policies beneath
10 — Final design

Ten screens, one coherent setup flow.

Screen 01

Country-scoped policy listing.

Companies with employees across countries usually have regional HRs. An HR managing the US workforce doesn't need to see policies for India or the Gulf. We list policies by country, reducing cognitive load and the surface area to manage.

Country-scoped policy listing
Screen 02

Template-led setup, jurisdiction-aware.

Step 1 starts with templates compliant with local labour laws. Companies can opt out of any time off type they don't operate under. For markets like the US where different jurisdictions mandate different policies, we offer a choice: one policy compliant across all jurisdictions, or multiple policies grouped by similar jurisdiction rules.

Template-led setup with jurisdiction split
Screen 03

Review and extend — with a Compliant badge.

Step 2 lets companies review added policies and add policies for specific teams. A Compliant badge marks time off types mandated by local law. If a change makes a policy non-compliant, the badge flips to Non-compliant. Custom types carry no badge, since compliance doesn't apply.

Review step with compliant/non-compliant badges
Screen 04

Custom policies with rule-based assignment.

HRs can add custom sick time off policies with basic configuration. Since employees may not yet be in the system at setup time, rule-based assignment (team, department, location) is the default mechanism. A note acknowledges complex policies and reassures users that advanced config is available post-setup.

Custom policy creation with rule-based assignment
Screen 05

Progressive disclosure and live compliance feedback.

Once the first custom policy is added, the "Add custom time off policy" CTA moves from a banner to the header. If a configuration falls outside what's compliant for the assigned jurisdiction, a Non-compliant badge appears. We notify but don't block — companies sometimes need flexibility, and this respects their judgment.

CTA migration and non-compliant inline warning
Screen 06

Adding extra time off types.

Companies often offer more time off than the government mandates. Research found that metadata like paid/unpaid, accrual vs. incident-based, and calendar year is largely consistent across policies of the same type within a company — so we promoted these to the time off type level to eliminate redundant configuration.

Adding extra time off types
Screen 07

Final review before going live.

Once setup is complete, policies go live for employees. This step lets users review everything and step back in to reconfigure before committing.

Final review and confirmation step
Screen 08

The post-setup listing page.

Once setup is complete for a country, HRs return here to add departments or teams to existing policies, create new policies for specific teams, or reconfigure an in-use policy. The country-scoped view keeps the surface focused.

Post-setup listing page with country scope
Screen 09

Priority order to resolve overlaps.

Because policies are assigned through include-exclude rules, overlaps are inevitable — an employee can end up with multiple policies for the same time off type. Priority order resolves this, mirroring the pattern that worked well in Rippling.

Priority order modal for policy overlap resolution
Screen 10

Advanced configuration, on demand.

This is the full configuration surface for any time off type. Deliberately surfaced only after initial setup so first-time users aren't overwhelmed by the system's full power upfront.

Advanced configuration surface
11 — Design principles

Six principles behind almost every decision.

P01

Localise, don't bifurcate.

Make the system feel native to each market without making any market feel secondary.

P02

Compliance as a guide, not a gate.

Notify when users drift out of compliance; don't block them. HR teams know their context better than the system does.

P03

Progressive disclosure.

Start with what's mandatory and minimal. Reveal advanced config only on demand.

P04

Templates over blank canvases.

Mandated, compliant templates eliminate the legal-research burden HRs were never trained for.

P05

Architecture = mental model.

Time off types as the top-level entity — not "plans" — because that's how US HR teams already think.

P06

Prominence follows need.

CTAs earn their visual weight only when the user needs them. Once a behaviour is learned, the UI quiets down.

12 — Early metrics

From user testing — limited but directionally strong.

The project is in active development. These numbers come from moderated user testing sessions with US prospects and existing clients, on a clickable prototype with limited configuration scope.

~60%
Reduction in setup time vs. current product (22 min → 9 min median)
8/10
Testers completed setup without implementation-team support (vs. 2/10 today)
4.3
Compliance confidence (5-point scale), up from 2.4 in the current product

Zero testers missed the assignment step in the new flow, compared to 60% who missed it in the early "leave plan" iterations. Qualitative feedback from US prospects consistently described the new experience as "finally feels built for us."

13 — What's next

Leave policy versioning.

Compliance is not static — statutes change, jurisdictions update mandated minimums, and companies revise policies year over year. The next phase will introduce:

  • V01A version history for every policy, with effective-date scoping.
  • V02Clear visibility into which version applied to which employee at any point in time.
  • V03The ability to schedule a future-dated policy change without disturbing the live version.
  • V04Audit trails that satisfy US compliance documentation expectations.
14 — Conclusion

A feature request that became an architecture rethink.

What started as a request to add "US compliance templates" turned into a much deeper rethink of how leave is modelled in Keka. The biggest shift wasn't visual — it was architectural: moving from leave-plan bundles to time-off-type-led policies, mirroring how US HR teams already think.

The work also reinforced a tension worth designing for explicitly: localising for a new market without making existing markets feel like an afterthought. Country-scoped listings, jurisdiction-aware templates, and a single coherent architecture across geographies were how we resolved it.

Next case Case study · 01
Scheduling shifts for large and dynamic teams