Compensation costs
UX & UI design
Meight is a logistics platform for trucking companies, covering driver management, trip data and driver compensation. I designed this feature as the only designer, working with a project manager and a team of engineers. The feature is large and complex, so I’m only showing its key parts here. It’s aimed mainly at HR and traffic managers.
Context
MY ROLE
Principal UX & UI designer
TIMELINE
TOOLS
SCOPE
DELIVERABLES
8 Weeks
Figma
UX & UI design
Feedback session insights
User flows
Concept development
Hi-fi wireframes
Prototypes
The challenge
Customers calculate driver allowances by hand, using spreadsheets and their own reading of labor law. The goal was to replace this with a rules engine that calculates pay automatically from trip data, which HR configures and managers review before payroll.
The design challenge was to make a rigid, law-based system feel simple and trustworthy for non-technical users. It had to be flexible within legal limits, automated but still editable, and able to fit how each company approves pay, without needing a developer.
Understanding the problem
On top of base pay, truck drivers receive daily allowances, meal and night supplements, set by collective labor agreements such as ANTRAM's in Portugal.
Context
Every company is different
Some pay by clause, others per kilometre plus their own extra costs.
Trip type matters
National, Iberian or international trips pay different daily rates.
Rests and holidays count
24h and 45h rests, worked Sundays and public holidays change what a driver is owed.
Automate most daily allowance decisions
Respect collective agreements and the law
Give payroll audit-ready, traceable values
How might I automate driver variable pay so it's compliant, explainable and still flexible enough for how each company really pays?
These problems surfaced through interviews and feedback sessions with several customers as we scoped how the driver compensation system should work in practice
How every company is different
No audit trail
Nothing links what happened on a trip to what the driver was paid.
Manual data entry from telematics
Routes, hours and km are typed into spreadsheets by hand before anything can be calculated.
Fragile, personalized Excel formulas:
Each customer maintains their own complex spreadsheet logic to encode the rules, which is hard to maintain, easy to break, and impossible to hand off.
Today's pain points
The result: hours lost by finance and ops teams every month, plus payroll errors and compliance risk.
Rules applied unevenly
National or international? Full or half allowance? Minimums and weekend rules are read differently each time.
Key problems uncovered
Beyond the pain points every customer shares, each company works differently, so a single fixed rule would never fit. I found five differences:
Every company pays its own way. Some pay by clause, some per kilometre plus their own extras, and some compare both.
Approval happens at different levels. Some approve per driver per month, others per trip.
Pay periods aren’t calendar months. Some run from the 26th to the 25th, others close on the last business day of the month.
The data needs context. The driver’s base location, rest days and holidays decide whether an allowance applies.
People need the final say. Being able to edit, add or remove items was called critical.
So the system had to be flexible enough to fit each company, not one rule for everyone.
Who is this for?
There moments, there personas.
Finance or payroll admin
HR
Review & approve
Goal
Approve each driver's month quickly and correctly.
Pain
Checking trips one by one across spreadsheets and notes.
Freight manager
Goal
Keep each driver's contract accurate and private.
Pain
Contract dates and renewals are tracked outside the platform.
Assign
Set up
Goal
Keep each driver's contract accurate and private.
Pain
Contract dates and renewals are tracked outside the platform.
What users need
Set our own pay rules once, within what the law allows.
Trust the result, and see where every value comes from.
Override anything when reality differs from the data.
Review a whole month fast, and see what’s still pending.
Close on our own pay cycle, and send clean values to payroll.
User flows
System overview: how the feature works
Before moving to prototypes, the key flows were mapped against the user needs. First, I worked with the PM and engineering to define how the price calculation would work. Once that was validated, I mapped the full system in two layers: setup, where the rules are defined, and operational, where they’re applied to real drivers. I then broke it down into specific user flows. Two key ones are shown here; the others follow the same logic and aren’t represented.
Key user flows
Ideation & Design
Using prototypes to drive user research
Testing early assumptions
With the flows mapped, I used Figma Make to quickly build clickable prototypes and put them in front of customers. The goal at this stage wasn’t to polish the design but to test my assumptions early. Interviews told me what users said they needed, but reacting to something concrete revealed needs they hadn’t mentioned. It was also a cheap way to find out what didn’t work before committing to the final design.
Compensation calendar: a monthly view of every driver, with status colours and a period summary.
Approve one day: contract, trip details and clauses side by side in a single modal.
Ruleset settings: one company-wide ruleset applied to every driver contract.
Ruleset on the driver: the ruleset and its allowances shown in each driver’s profile.
What the prototype changed
Final design
With the structure validated and the prototype learnings in place, I designed the final experience around the user journey. It starts with the setup in Settings, where payslip items, driver contracts and the pay period are defined once. Then each driver is assigned a contract type. Finally, the daily calendar is where costs are reviewed and approved every month. The screens below follow that same order.
What used to depend on manual data entry and fragile spreadsheets is now a single flow: rules are defined once, applied automatically to every trip, and reviewed by a person before reaching payroll. The biggest lesson was that automation alone isn’t enough. Every company pays differently, so the system had to be flexible enough to adapt, and transparent enough to be trusted.
Next steps after launch
Measure real use:
Track how many allowances are calculated automatically (target: 95%).
Track how often users override values. A high override rate shows where the rules need work.
Measure time saved: compare how long the monthly review takes now with the old spreadsheet process.
Gather feedback: follow up with customers after their first pay periods and track satisfaction (target NPS: 70).
Iterate on the formula builder: use real formulas created by customers to add ready-made examples and simplify common cases.
Grow the feature: add bulk approval, notifications for pending days and expiring contracts and more EU countries.
Conclusion
© 2025. All rights reserved.