Designing a trip cost calculator
Figma
Research
UX/UI Design
I led the redesign of an underperforming feature in the Trizy app, the Trip Cost Calculator. What started as a usability fix turned into a business pivot: the technical constraint that almost killed the feature became the seed of the app's subscription model.
Overview
About the product
Trizy is a mobile app that assists truck drivers by providing a simple interface to communicate with employers and clients. The app supports load and unloading scheduling, freight negotiation, yard check-in, and other operational tasks.
About the team
I worked as the product designer, with support from the Data team for analytics, the Development team for service integration, and the Research squad for coordinating test sessions. The product design team used the Double Diamond model, splitting the process into discovery and delivery.
My role
I led product design from research to delivery:
Research: planned and ran the user interviews and usability sessions that surfaced the gap between user expectations and what the feature actually delivered.
Service architecture: scoped the integration with the third-party routing API and defined the request and response contract with the Development team.
UX/UI: designed the new input flow, the results screen, the loading and error states, and the paywall layout for the subscription tier.
The Data team provided the original analytics that flagged the abandonment problem. The Research squad helped coordinate test sessions. The Development team handled implementation and front-end build.
About the user persona
Our user base is truck drivers averaging 42 years of age. For the Trip Cost Calculator specifically, what matters is the decision context:
Drivers calculate operating margin to decide whether a freight is worth accepting. The difference between a profitable run and a money-losing one can be a few percentage points.
Most already have a mental model for trip cost (fuel, tolls, meals, lodging), often done by hand or by gut.
They are skeptical of automated calculations and only trust a number they can break down line by line.
Limited familiarity with form-heavy interfaces means every extra field costs completion rate.
These constraints shaped the form design, the breakdown layout of the results, and the decision to surface line-item costs (fuel, tolls, additional expenses) instead of just a total.
Discovery
The problem
The Trizy app had a Trip Cost Calculator from the start, but the analytics told a strange story: the button was getting clicks, but most users were not completing the flow. The feature was not technically broken. Something else was off.
The research
We approached the abandonment problem with two methods:
Analytics review: confirmed that the calculator was one of the most clicked items on the main menu, but only a small fraction of users completed the existing flow.
User interviews and usability sessions: walked drivers through the existing feature and asked what they expected versus what they got.
The pattern was consistent. Users expected an automated cost estimate based on route information, not a manual expense ledger. One driver put it bluntly:
"I can do that with a calculator. I was expecting something more"
dissatisfied user
This reframed the problem: the feature was not broken, it was the wrong result for the expectation it was setting.
The solution
We expanded the feature to deliver the automated experience users actually expected. The new version connected to a third-party routing API that took origin, destination, vehicle category, axles, fuel economy, and gas price as parameters, and returned route distance, travel time, toll cost, and fuel cost. Users could add custom expenses (meals, lodging, repairs) on top, and the app returned the full trip cost in seconds.
Delivery
I drafted the integration flow with the external API and aligned the request and response contract with the Development team. After alignment meetings to resolve technical questions, the back-end was operational.
For the UI, the priority was clarity. The user persona was not tech-savvy, and the form involved more fields than the original version. The information density needed to feel digestible, not overwhelming.
The screen opens with the starting point, the destination, and optional stopovers. The user then selects the vehicle category, since toll pricing varies by vehicle type, and the number of axles. Two optional fields ask for fuel economy and gas price. The final options are the route preference (most efficient, shortest, avoid tolls) and a checkbox for the return trip.
Tapping the primary button calls the external API and navigates to the Trip Route page within a couple of seconds. The results page shows the map, distance, travel time, and a cost breakdown (tolls, fuel, additional expenses). The user can switch between up to three alternative routes to compare totals.
Interface decisions
A few choices shaped the new UI:
Form ordering by cognitive load. Origin, destination, and stops first (high familiarity), then vehicle and route preferences, with the optional fields (fuel economy, gas price) last so users could submit even without that data.
Smart defaults. The app pre-filled fuel economy based on the user's vehicle profile and gas price based on regional averages, both editable. Reduced friction for drivers who do not carry exact numbers.
Results as a breakdown, not a total. Tolls, fuel, and additional costs each get their own line. Drivers do not trust a single big number, they trust a number they can audit.
Three route options. Most efficient, shortest, and avoid toll stations. The cost of each is shown side by side so the trade-off is visible.
Paywall framed as an upgrade, not a wall. The third free query of the day shows a small banner mentioning the limit. The actual paywall appears only on the fourth attempt, with the previous three results still accessible.
Limiting factors
The routing API was a paid service. The app was free. Without a plan, the cost of each query would scale linearly with usage and erode the unit economics.
Leadership had been pushing the team to find new revenue, and advertising was off the table. The Trip Cost Calculator became the wedge.
We designed a subscription tier that bundled:
Unlimited Trip Cost Calculator queries (free users got three per day)
GPS navigator
Exclusive coupons and partner services
Free users hit the daily limit naturally if they used the calculator more than a few times per week, which is the actual behavior pattern for active drivers comparing freights. The paywall triggered at the moment of highest intent: right after the user filled in the form and tapped to calculate the fourth trip of the day.
Results
Within the first weeks after rollout, we had a couple hundred new uses. We tagged every event and button to monitor adoption and identify drop-off points. The Trip Cost Calculator became one of the highest-converting entry points into the subscription tier. Soon enough, we saw a crescent number on uses and subscriptions. So far, we had a crescent number of users with an active subscription of the trip calculator and other premium features.
Conclusion
This project changed how I think about post-launch design. The data we needed to find the opportunity was already there, sitting in the analytics dashboard nobody was watching closely. The feature was not failing because of bad implementation, it was failing because nobody had questioned whether the original concept matched the user's expectation.
Three things I took from this work:
Click rate without completion rate is a trap. A button being pressed is not validation of the feature behind it.
Constraints can be the design. The API cost almost killed the feature, and ended up shaping the business model.
Paywall design is product design. Where the wall sits, how it is framed, and what the user keeps access to defines whether the upgrade feels fair or punitive.
If I were to do this again, I would invest in a structured post-launch review cadence so that the next underused feature gets caught in weeks, not in a quarterly analytics review.
Matheus Gomes / 2025