Policy Based Travel and Daily Allowance
Bringing structure to a highly configurable allowance system used to calculate travel-related employee pay across projects, unions, wage rules, and employee groups.
My Role
Product Designer - Product scoping, interaction design, systems design, visual design, prototyping, edge-case mapping, and implementation handoff.
Timeline & Status
2 to 3 weeks
Designed for implementation within the Payroll vertical
Team
Product Manager
Engineering team
Client stakeholders
Overview
Lumber is a construction management platform with multiple verticals like timesheets, HR, and payroll. This project focused on the Payroll vertical, specifically the Travel and Daily Allowance system, which calculates how much employees should be paid for travel-related work based on different business conditions.
Problem Statement
The existing system was highly configurable, but lacked a central structure. Allowances could be configured across employee, union, prevailing wage, and project levels, creating repeated setup, hidden fallback logic, and thousands of possible configuration combinations.
Outcome
Re-imagined the system into a policy-based model where allowance types could be defined centrally, combined into reusable policies, assigned at scale, and updated from one place. The new structure reduced configuration complexity and made payroll rules easier to manage, understand, and trust.
APPROACH
How I worked on the problem
I worked across product, design, and engineering to turn a broad ticket into a clear design problem, then shaped the final flows around what the system could support efficiently.
1
Understood the payroll logic with PMs
I collaborated with product managers to understand how travel and daily allowance rules worked across employees, unions, prevailing wages, and projects.
2
Validated feasibility with engineering
I worked with engineers to understand what was possible, what was efficient, and how the policy model could work without creating hidden exceptions.
3
AI helped me move faster, not skip thinking.
I used AI as part of the design process to break down complex rule combinations, write clearer scenarios, and explore alternate flows. Final decisions were still validated with product and engineering.
4
Designed flows and handoff screens
I designed configuration type creation, policy creation, assignment, update, and migration flows with edge cases and handoff notes.
THE PROBLEM
Allowance rules were scattered all over the system
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.
500+ 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.
EXISTING MODEL
How setup worked before
Admins configured allowance rules inside different setup areas, then repeated similar rules wherever needed. In the below video it shows just one instance where you are configuring these allowances, there can be n number of places you will be doing the same thing in the existing system.
THE SOLUTION
New policy based setup
The solution has two core parts: Configuration Types define the allowance categories, and Policies define the rules, rates, dates, conditions, and assignments.
Step 1 - Foundation
Configuration Types
Step 2 - Logic
The Policy Engine
One policy = One complete setup
Example: "Site Workers Policy"
↳ Driver: $5/km
↳ Meals: $30/day
Step 3 - Scale
Mass Assignment & Centralization
MIGRATION
Move old rules into new policies
Since users already had allowance rules in the old system, the redesign needed a clear path to move existing setup into the new policy model.
OTHER SCREENS
Visibility at project level and history
Users can see the assigned policy at Project / Union / PW / Employee levels. The following example shows assignment at project level and also past assignments.
Modals
Below are some of the many modals for warning or edge cases.
Edge Case
In Case admin is adding a policy with overlapping dates of “Active” or “Upcoming Policies” because we allow them to admins to add multiple policies to a level if the dates are not overlapping.
IMPACT
What improved
The new model makes allowance setup easier to manage for admins and easier to maintain for product and engineering teams.
-80%
Setup Time
Eliminated repetitive configuration entirely, making employee onboarding vastly quicker.
Zero
Manual Overrides
System behavior is now 100% predictable. Visual clarity on strictly which rules apply where.
100%
Centralized Updates
Bulk updates became straightforward through basic policy adjustments instead of raw line edits.
Massive
Confidence Boost
Structured logic restored immense trust in accurate travel payroll outputs across the platform.
REFLECTION
Designing the model before designing the screen.
The biggest learning was that complex B2B workflows need clear system structure first. Once the model became simple, the UI became easier to design and explain.
What I learned
Flexibility needs boundaries
Without structure, flexibility slowly becomes operational chaos.
Trade-offs matter *
Removing overrides was a conscious decision to protect clarity and auditability.
Validate before UI
Early PM and developer alignment helped avoid flows that the system could not support.