Structuring a security service using biometrics
Figma
Service Architecture
UX/UI Design
I led the end-to-end design of a biometric verification service for the Trizy app, owning the service architecture, the user flow, and the UI of every screen involved. The project tackled a recurring fraud problem at loading docks, where unauthorized drivers used forged IDs to steal cargo worth thousands of dollars.
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 Development team on security and performance analysis of facial validation and on service integration. The product design team used the Double Diamond model, splitting the process into discovery and delivery.
My role
I led product design across three layers:
Service architecture: mapped the end-to-end flow, evaluated biometric vendors, and designed the integration with the government identity API.
UX: drafted and validated user flows, defined edge cases and error states, and tested the journey internally before rollout.
UI: designed every screen of the verification journey, including the verified badge surface on the profile page and the recovery flow that emerged from this work.
The Development team handled implementation and security testing. The Product Head co-led vendor selection with me.
About the user persona
Our user base is truck drivers averaging 42 years of age. Most operate in environments hostile to digital interfaces: loading docks with poor lighting, intermittent connectivity, gloves, dust, sun glare, and tight time windows. Many have limited familiarity with modern app patterns like face ID or multi-step verification.
These constraints shaped specific design decisions: large touch targets, high-contrast typography, single-action screens, explicit instructions with visual reinforcement before the camera opens, and recovery paths that assume the user may fail the first attempt without understanding why.
Discovery
The problem
Due to the value of transported cargo, cargo owners face constant risk of scams at loading facilities.
The main purpose of this feature was to enhance security and improve the reliability cargo owners could expect when assigning cargo to drivers. The scams happened at smaller facilities when an unauthorized driver uploaded a forged ID on the Trizy app, combining the name and ID number of the assigned driver with his own edited photo. The app would show the assigned driver's name with the scammer's photo, and the operator would direct him to the loading dock. By the time operators realized what happened, the scammer could be miles away with the stolen cargo.
Research showed this problem occurred frequently, even with forged physical driver IDs. That alone was already a crime, but for someone stealing thousands of dollars in cargo, it was only the start.
The solution
This feature became a security project that would benefit both the facility operator and the truck driver.
We determined that facial comparison and information consistency, validated through an API that could verify government-issued IDs, would solve the problem.
In conversations with the lead developer, we agreed that building a face biometric service from the ground up would take significant development and testing time. The right path was to look for a provider that could deliver all this processing.
Delivery
I researched solutions for face validation, face comparison, and liveness detection. I found multiple providers and narrowed the list to four, each with a distinct strength.
The Product Head and I scheduled meetings throughout the week with the consultants and Latam representatives for the four companies. We selected the most cost-effective option that met our requirements, integrated with our Flutter app, and had a strong market presence with banking and e-commerce clients.
With the provider API selected, I studied its documentation to design an efficient flow for development and identify additional capabilities we could surface. The concept we built around was the Verified Profile.
I drafted user flows to express the ideas and discussed them with the Product and Development teams. After a few iterations, we had a solid use case.
We presented the flowchart with a slideshow explaining the concept to the rest of the company and to the Risk Management partners. The proposal was approved with notes that we incorporated into delivery.
The flow worked as follows: existing users received a notification informing them they could verify their profile for free by scanning their face. New users could verify during sign-up.
The interface explained how to verify the profile and the benefits: more security and reliability in the app, plus increased visibility for compliant users in cargo assignment.
Users were instructed to take a photo without caps, hats, or glasses obstructing the face, with no option to upload from the camera roll. A face validation algorithm checked for a clear face. If validation failed, an error screen guided recovery. If it passed, the image was saved to the database.
This step required a liveness check to prevent scams using camera manipulation software or "photo of a photo" attacks.
The next step verified whether the user had already uploaded a driver's ID. If not, the upload became mandatory.
From the uploaded driver's ID, we captured the photo and stored it. We then ran OCR on the document to extract its fields and sent the data along with the base64-encoded photo to the government's official identity API. The API returned an accuracy percentage based on the official records in the DMV database.
In short, the government API verified:
The uploaded driver's ID contained matching information.
The photo in the uploaded ID matched the official government photo with 90%+ accuracy.
Once those checks passed, we compared the liveness photo against the verified government photo.
When all conditions matched, the user received the Verified status. The verification appeared as a badge next to the user's name on the Profile page. Verified users had a higher probability of being assigned cargo, and cargo owners gained reliability in their assignments.
Interface decisions
A few choices shaped the UI of the verification flow:
Instruction screens before the camera. I added a dedicated step explaining what would happen, what to remove (cap, glasses, mask), and why. This reduced first-attempt failures caused by users not knowing what to do.
Single primary action per screen. Given the environment of use (outdoors, time pressure, low digital familiarity), every screen surfaces exactly one action.
Error states framed as guidance, not rejection. A failed liveness or OCR returns a screen explaining what went wrong and how to fix it, not just a "try again" button. This was critical for the 40+ audience, where a generic error often translates into "the app is broken, I give up".
Verified badge with restraint. The badge appears next to the user's name on the profile page and in the cargo assignment screen for operators. I avoided gamification language like "level up" or "unlock". The goal was to communicate trust, not progression.
Results
We tested the flow with 3,500 users over one week.
72% were verified on the first attempt. Of the remaining 28%:
60% failed due to invalid IDs, mostly expired documents blocked by an existing rule.
40% failed due to a mismatch between the liveness photo and the ID photo. This was the fraud pattern we built the feature to catch, with some cases showing less than 20% match between faces, clearly different people.
We tracked two failure-side metrics closely:
False negatives (legitimate drivers blocked): we identified a small set in early testing, adjusted thresholds, and added a manual review path so honest users would not be locked out of the app.
Abandonment after first failure: we monitored drop-off after the first failed attempt to make sure the feature was not pushing legitimate users away.
We presented results to clients and Risk Management partners, who pushed for production rollout. The feature shipped two sprints later. Once clients started filtering cargo assignments to verified drivers only, fraud attempts dropped sharply and verified attempts surged.
Opportunities
Working with biometrics opened a new opportunity.
We built a new feature for verified users that used a liveness check as multi-factor authentication and as an account recovery method.
The design took one sprint and the development another. This further improved the app and account security, and reinforced the trust verified users felt in the platform.
Conclusion
The feature solved the fraud problem we set out to solve, and eventually was used to develop other security features: with biometric verification in place, we could use liveness checks as MFA and as account recovery.
What I took from this project:
Buying beats building when the core competency lives elsewhere. The conversation that mattered most was the one with the lead developer about scope, not the ones with the vendors.
Security UX lives or dies on the error states. A 28% failure rate is acceptable if those users know what to do next. It is a disaster if they do not.
A feature built for one problem (fraud) generated value in two adjacent ones (MFA, recovery). Worth designing with secondary use cases in mind from the start.
If I were to do this again, I would invest earlier in the manual review path for false negatives
Matheus Gomes / 2025