Policy Based Travel and Daily Allowance

Lumber is a construction management platform managing complex workflows. This project tackled the Travel and Daily Allowance core within the Payroll vertical.

It calculates how much employees should be paid for travel-related work. A simple concept on paper, but incredibly complex in practice.

The goal here was to transition the system from scattered configurations to a structured, policy-based architecture that scales, adapts to business needs, and re-establishes trust.

Client

Lumber

Timeline

03 Weeks

Role

Product Designer (Solo)

THE PROBLEM

A system buckling under its own flexibility

The legacy system allowed companies to configure rules anywhere, multiple times. This total lack of central structure created 6 massive friction points for the business.

Hard-coded structure

Categories were fixed. Companies couldn’t rename to fit their terminology or add new categories dynamically.

No central control

Rules were defined repeatedly at the Employee, Union, Wage, and Project level with no link.

Complex Setup

Onboarding became error-prone and time-consuming because setups had to be duplicated manually.

5,000+ Configs

This fragmentation resulted in an explosion of combinations. The system became unmanageable.

No bulk operations

Updates had to be applied individually per employee. No way to apply changes across broad groups.

Invisible Fallback Logic

Fallback priorities (Project → Union → Employee) were totally hidden. Users couldn't trust final outputs.

THE APPROACH

Measure twice, cut once

The legacy system allowed companies to configure rules anywhere, multiple times. This total lack of central structure created 6 massive friction points for the business.

01

Understand

Reviewed configs, Jira issues, and mapped current state. Proved it was not a UI problem, but structural.

02

Alignment

Aligned with PM on shifting from "Configure everywhere" to "Define once, reuse everywhere".

03

AI + Iteration

Used AI to untangle logic. Cycled rapidly through rough concepts → dev validation → refinement.

04

Design & Build

Finalized UI flows in Figma, actively defined strict edge cases, and supported devs through tickets.

Finalized UI flows in Figma, actively defined strict edge cases, and supported devs through tickets.

THE SOLUTION

A two-layer policy architecture

We replaced scattered inputs with a linear, centralized system. We incorporated all 7 functional pillars into a clean 4-step workflow that scales predictably.

01

Foundation

Configuration Types

Before making rules, we define the variables. We established a central hub for all allowance categories (Driver, Meals, Lodging).

Before making rules, we define the variables. We established a central hub for all allowance categories (Driver, Meals, Lodging).

Outcome: No more hard-coded structure. Admins have power to add, rename, or adapt these based directly on their own business terminology.

Outcome: No more hard-coded structure. Admins have power to add, rename, or adapt these based directly on their own business terminology.

✨

Connect to Content

Add layers or components to infinitely loop on your page.

02

Logic

The Policy Engine

Instead of configuring loosely everywhere, configurations are packed into a "Policy". Each policy strictly dictates logic: Rates, calculation methodology, start/end conditions, and active types.

Instead of configuring loosely everywhere, configurations are packed into a "Policy". Each policy strictly dictates logic: Rates, calculation methodology, start/end conditions, and active types.

One policy = One complete setup

Example: "Site Workers Policy"

↳ Driver: $5/km

↳ Meals: $30/day

Outcome: Structured instead of scattered. Reduced 5,000+ combos into easily navigable policy lists grouped precisely by function.

Outcome: Structured instead of scattered. Reduced 5,000+ combos into easily navigable policy lists grouped precisely by function.

✨

Connect to Content

Add layers or components to infinitely loop on your page.

03

Scale

Mass Assignment & Centralization

Policies act as master templates that are applied across standard operations. Assign Policy A to "Project X", or to "Union Y".

Policies act as master templates that are applied across standard operations. Assign Policy A to "Project X", or to "Union Y".

Outcome: Update once. If meal pay hikes structurally from ₹300 to ₹350, admins edit that policy once. It automatically updates everywhere.

Outcome: Update once. If meal pay hikes structurally from ₹300 to ₹350, admins edit that policy once. It automatically updates everywhere.

✨

Connect to Content

Add layers or components to infinitely loop on your page.

04

Foundation

Configuration Types

Before making rules, we define the variables. We established a central hub for all allowance categories (Driver, Meals, Lodging).

Before making rules, we define the variables. We established a central hub for all allowance categories (Driver, Meals, Lodging).

Outcome: No more hard-coded structure. Admins have power to add, rename, or adapt these based directly on their own business terminology.

Outcome: No more hard-coded structure. Admins have power to add, rename, or adapt these based directly on their own business terminology.

✨

Connect to Content

Add layers or components to infinitely loop on your page.

Create a free website with Framer, the website builder loved by startups, designers and agencies.