project Highlights
Reduced review effort
Eliminated paper-based comparison workflow
Improved trust in system-generated data
Accessibility improvements adopted platform-wide
project Deliverables
Interaction & Visual Design, Prototypes, User Tests, Information Architecture, Stakeholder Interviews.
Context
LeasePlan is one of the world’s largest vehicle leasing and fleet management companies, managing millions of vehicles across multiple countries. Functionally, the application resembled a highly complex spreadsheet, containing thousands of interdependent attributes, calculations, and business rules. Changes to configurations required a multi-step peer-review and approval process before they could be published.
Note: due to the NDA, I use sketches to illustratie the case study rather then using actual designs. I am however permitted to showcase this design fully in an interview. Don't hesitate to ask.
Understanding the problem
Users were reviewing changes blind. During observation sessions, I discovered that reviewers had no way of seeing what had changed between configurations. To compensate, teams printed previous versions, compared them manually, and archived the printouts after each review cycle. A process that felt normal to users was, in reality, slow, error-prone, and a compliance risk.
Observations
Users could not distinguish system-prefilled fields from manually edited fields.
Users did not know where prefilled values originated.
Reviewers could not see what had changed between versions.
Foundation first
Before introducing new functionality, I focused on the foundation: the field states. During research, I observed that users struggled to distinguish between default values, global prefilled values, and fields they had edited themselves.
I redesigned the field states to improve clarity, accessibility, and visibility of unsaved changes.
These improvements made the interface easier to understand at a glance while also improving WCAG compliance.
Results
Users immediately understood the difference during testing without onboarding or training.
The improvements also resolved a latent accessibility issue.
Making a case for a Comparison Tool
Iteration 1: Stacked Comparison
“I used to keep a printout of the previous configuration next to me while reviewing changes.”
To maintain momentum, I chose a lower-risk approach and repurposed the existing list view. Instead of displaying configurations side by side, I stacked the old and new versions vertically. This approach offered several advantages:
Reused existing UI patterns.
Reduced development effort.
Preserved a familiar interaction model.
Allowed us to validate the concept quickly with users.
Designing the layout was challenging. Related information needed to remain visually connected without creating excessive nesting or cognitive overload.
What worked?
Faster reviews
Positive user feedback
Reduced effort during peer review
What didn't work?
New users struggled to orient themselves during a 5-second test,Long select-list values frequently overflowed the viewport, making it impossible to compare,
Dense layouts made scanning difficult.
Iteration 2: Side-by-Side Comparison
While the stacked view solved the original problem, it also exposed its limitations. The dense layout and viewport issues led me to revisit an idea I had previously rejected: a side-by-side comparison view.
I had dismissed the concept because I assumed it would be expensive to build, wouldn’t fit on standard company laptops, and would break the users’ mental model. Instead of relying on those assumptions, I decided to test them.
After simplifying the layout and removing non-essential elements, two assumptions quickly disappeared. The side-by-side view fit comfortably within the available screen space and proved no more complex to build than the stacked version. The remaining challenge was helping users transition into the comparison experience.
While mapping the interaction flow, I noticed that selecting versions and reviewing them were fundamentally different tasks. Users first needed to decide what to compare before they could begin their review. To support this transition, I introduced a lightweight wizard that guided users through version selection before entering the comparison view.
The concept was validated with users before implementation and received the fastest stakeholder sign-off of any project I worked on at LeasePlan. After testing the Figma prototype, their response was simply:
Results
Made peer reviews faster and easier
Reduced reliance on paper-based workarounds
Created a transparent digital audit trail
Increased confidence in the application
Accessibility improvements adopted platform-wide
What I learned
Fix Foundations Before Features
Improving field states solved part of the problem before introducing new functionality.
Assumptions Are Hypotheses
Three assumptions blocked a potentially better solution. Testing revealed that two were incorrect.
Workflow Design Matters
The biggest improvement came from redesigning the review process itself, not from visual design changes.
Revisiting a previously rejected idea: could a side-by-side comparison simplify reviews without overwhelming users?
Early sketch exploring a wizard to separate version selection from the comparison task.
Final side-by-side comparison flow, designed to make changes visible at a glance.