Detailed
TL;DR
A terminal journey connects people, operations, and decisions. I made that complexity easier to navigate.
A terminal journey connects people, operations, and decisions. I made that complexity easier to navigate.
A terminal journey connects people, operations, and decisions. I made that complexity easier to navigate.
A terminal journey connects people, operations, and decisions. I made that complexity easier to navigate.
Role
Product Design, UX Strategy
Project
Passify
Product
Digital Logistics Platform
Year
2025 - Ongoing
Region
Europe
Overview
Passify is a digital logistics platform connecting drivers, trucking companies, and terminals in one ecosystem. Each role has distinct responsibilities, but their actions influence the same terminal visit.
So, I designed workflows across mobile and desktop that make the next step clear for each user while keeping the entire operation connected.
Problem statement
One action could change what happened somewhere else.
One action could change what happened somewhere else.
Passify connects digital decisions with live terminal operations. A change in one product could affect another user's next steps, while terminal rules shape what happens on the ground.
Passify connects digital decisions with live terminal operations. A change in one product could affect another user's next steps, while terminal rules shape what happens on the ground.
Passify connects digital decisions with live terminal operations A change in one product could affect another user's status, actions, or next step.
Passify connects digital decisions with live terminal operations A change in one product could affect another user's status, actions, or next step.
Rules, permissions, and real-time conditions added complexity. Even a small change could affect whether a truck entered, moved forward, or exited.
Rules, permissions, and real-time conditions added complexity. Even a small change could affect whether a truck entered, moved forward, or exited.
A change in one workflow could alter another user’s status, information, or actions.
A change in one workflow could alter another user’s status, information, or actions.
Roles, permissions, and terminal rules could change what happened next.
Roles, permissions, and terminal rules could change what happened next.
Digital decisions could determine whether a truck entered, moved forward, or exited.
Digital decisions could determine whether a truck entered, moved forward, or exited.
A decision made on screen could shape what happened on the ground.
Diagnosis
The same journey requires
different information and actions.
The same journey requires
different information and actions.
A driver focuses on the next step, a trucking company on coordinating the visit, and a terminal operator on keeping things moving. Understanding each role's needs and timing was key.
A driver focuses on the next step, a trucking company on coordinating the visit, and a terminal operator on keeping things moving. Understanding each role's needs and timing was key.
What matters most depends on the user's role and where they are in the visit.
What matters most depends on the user's role and where they are in the visit.
Even visible actions can be easy to miss.
Even visible actions can be easy to miss.
Rules and permissions determine which information and actions are relevant.
Rules and permissions determine which information and actions are relevant.
Exceptions need the right context, not just more information.
Exceptions need the right context, not just more information.
Clarity depended on showing the right context at the right moment, not simply showing less.
What I tried first
Started with requirements, then I looked beyond.
Started with requirements, then I looked beyond.
Some requirements began as rough ideas, while others came with defined flows. I examined the users, rules, and dependencies before shaping the experience.
Some requirements began as rough ideas, while others came with defined flows. I examined the users, rules, and dependencies before shaping the experience.
Understand the requirement
I first looked at what the user needed to accomplish, what triggered the task, and what had to happen next.
I first looked at what the user needed to accomplish, what triggered the task, and what had to happen next.
For rough ideas, I worked out the flow. For defined requirements, I looked for gaps and ways to improve clarity without changing the operational rules.
For rough ideas, I worked out the flow. For defined requirements, I looked for gaps and ways to improve clarity without changing the operational rules.
Understand the requirement
Trace what it affects
Once the immediate flow made sense, I looked at what the change could affect elsewhere: another role, status, permission, screen, or stage of the visit.
Once the immediate flow made sense, I looked at what the change could affect elsewhere: another role, status, permission, screen, or stage of the visit.
This helped me catch dependencies before treating a requirement as an isolated screen or interaction.
This helped me catch dependencies before treating a requirement as an isolated screen or interaction.
Trace what it affects
Challenge the proposed interaction
Some requirements described the problem, while others came with a suggested interface or flow. I treated these suggestions as a starting point rather than the final design.
Some requirements described the problem, while others came with a suggested interface or flow. I treated these suggestions as a starting point rather than the final design.
When another interaction solved the same operational need more clearly, I proposed the alternative and worked within the product and technical constraints.
When another interaction solved the same operational need more clearly, I proposed the alternative and worked within the product and technical constraints.
The requirement defined what to build. I decided how it should work.
The decision
One connected operation, designed around the using.
One connected operation, designed around the using.
I considered each user's role, stage of the visit, and terminal rules to decide what mattered most. The next step had to be clear without losing essential context.
I considered each user's role, stage of the visit, and terminal rules to decide what mattered most. The next step had to be clear without losing essential context.
Make progress visible
A user should be able to understand where they are without reconstructing the workflow from separate screens or messages.
A user should be able to understand where they are without reconstructing the workflow from separate screens or messages.
Make the present status immediately recognizable.
Make the present status immediately recognizable.
Give the upcoming action a clear place in the hierarchy.
Give the upcoming action a clear place in the hierarchy.
Show when an action is accepted, processing, or completed.
Show when an action is accepted, processing, or completed.
Make progress visible
Give problems a way forward
A blocked state should explain the issue and what comes next, with clear actions to resolve it or a way to contact terminal staff when help is needed.
A blocked state should explain the issue and what comes next, with clear actions to resolve it or a way to contact terminal staff when help is needed.
A blocked state was not useful if it only told someone that something went wrong. The interface also needed to communicate enough of the reason for the situation to make sense.
A blocked state was not useful if it only told someone that something went wrong. The interface also needed to communicate enough of the reason for the situation to make sense.
Where the user could resolve it themselves, I surfaced the relevant action. Where they could not, I provided an appropriate route forward, such as contacting terminal staff instead of leaving them at a dead end.
Where the user could resolve it themselves, I surfaced the relevant action. Where they could not, I provided an appropriate route forward, such as contacting terminal staff instead of leaving them at a dead end.
Let the interface change with the situation
Not every action should remain available throughout a workflow. What users could see or do had to respond to permissions, status, terminal rules, and changing conditions, so I designed states deliberately rather than relying on one interface to cover every situation.
Not every action should remain available throughout a workflow. What users could see or do had to respond to permissions, status, terminal rules, and changing conditions, so I designed states deliberately rather than relying on one interface to cover every situation.
The right experience depended on what the moment required.
The solution
The terminal visit became the thread connecting the experience.
The terminal visit became the thread connecting the experience.
I used the terminal visit to shape workflows across all three products. From booking to exit, each experience supports a different stage of the same connected journey.
I used the terminal visit to shape workflows across all three products. From booking to exit, each experience supports a different stage of the same connected journey.
The trucking company books a slot, provides the visit details, and prepares the information the driver and terminal need for the upcoming visit.
The trucking company books a slot, provides the visit details, and prepares the information the driver and terminal need for the upcoming visit.
The trucking company assigns a driver, linking the booking to the person responsible for carrying out the visit.
The trucking company assigns a driver, linking the booking to the person responsible for carrying out the visit.
The driver checks in, the system validates the required information, and terminal access depends on the result.
The driver checks in, the system validates the required information, and terminal access depends on the result.
The driver follows the assigned route, completes each stop, and receives guidance on where to go next.
The driver follows the assigned route, completes each stop, and receives guidance on where to go next.
Terminal staff identify issues that need attention, review the affected visit, and take action according to terminal rules.
Terminal staff identify issues that need attention, review the affected visit, and take action according to terminal rules.
The driver completes the terminal visit, while the trucking company can review the resulting records and receipts.
The driver completes the terminal visit, while the trucking company can review the resulting records and receipts.
Each experience had its own role, but they all had to move the same operation forward.
System
The product keeps growing. The design system grows with it.
The product keeps growing. The design system grows with it.
I built design systems for Passify’s web and mobile products, extending them with new components and patterns as workflows evolve.
I built design systems for Passify’s web and mobile products, extending them with new components and patterns as workflows evolve.
I built dedicated design systems for Passify’s web and mobile products, covering the components, interactions, and states needed across its workflows.
I built dedicated design systems for Passify’s web and mobile products, covering the components, interactions, and states needed across its workflows.
As the product evolves, I extend these systems with new components and patterns rather than designing each feature from scratch.
As the product evolves, I extend these systems with new components and patterns rather than designing each feature from scratch.
Variables organize colors, typography, spacing, and other properties, making the system easier to maintain and scale.
Variables organize colors, typography, spacing, and other properties, making the system easier to maintain and scale.
Variables organize colors, typography, spacing, and other design properties, creating a foundation that makes the system easier to maintain, update, and scale as the product evolves.
Variables organize colors, typography, spacing, and other design properties, creating a foundation that makes the system easier to maintain, update, and scale as the product evolves.
Reusable components keep interactions consistent, with specialized variants for slot booking and terminal workflows.
Reusable components keep interactions consistent, with specialized variants for slot booking and terminal workflows.
Reusable components support common interactions, with specialized variants for workflows such as slot booking and terminal operations.
Reusable components support common interactions, with specialized variants for workflows such as slot booking and terminal operations.
The system grows with the product, not separately from it.
Validation
Real use revealed what the screens alone could not.
Real use revealed what the screens alone could not.
Passify tested selected designs with users, including A/B tests of design variants. Their feedback helped me refine interactions, hierarchy, and guidance based on real use.
Passify tested selected designs with users, including A/B tests of design variants. Their feedback helped me refine interactions, hierarchy, and guidance based on real use.
What the feedback tested
Driver experience: Could drivers recognize the situation, find the action, and continue?
Driver experience: Could drivers recognize the situation, find the action, and continue?
Trucking Company experience: Was there enough visibility and control to coordinate the visit?
Trucking Company experience: Was there enough visibility and control to coordinate the visit?
Terminal experience: Could teams manage rules, decisions, and exceptions with the context they needed?
Terminal experience: Could teams manage rules, decisions, and exceptions with the context they needed?
Across products: Did changes still make sense wherever the resulting status or information appeared?
Across products: Did changes still make sense wherever the resulting status or information appeared?
What the feedback tested
Where reality challenged the design
Feedback showed that visible actions could still be missed, rules could change the expected path, and the same state could need different context across the ecosystem.
Feedback showed that visible actions could still be missed, rules could change the expected path, and the same state could need different context across the ecosystem.
I used those findings to refine the affected workflow, not only the screen where the issue appeared.
I used those findings to refine the affected workflow, not only the screen where the issue appeared.
Where reality challenged the design
Validation continues with the product
Passify continues to evolve, and new requirements, user feedback, operational constraints, and technical limitations continue to test earlier decisions and shape what comes next.
Passify continues to evolve, and new requirements, user feedback, operational constraints, and technical limitations continue to test earlier decisions and shape what comes next.
Real use keeps challenging assumptions that screens alone cannot.
Reflection
Designing Passify keeps challenging what “simple” really means.
Designing Passify keeps challenging what “simple” really means.
I learned that visible actions could be missed easily, while simplicity requires context, and exceptions reveal gaps that ideal flows overlook.
I learned that visible actions could be missed easily, while simplicity requires context, and exceptions reveal gaps that ideal flows overlook.
Visibility is not the same as discoverability
An action can be present on the screen and still be missed. I learned to pay closer attention to hierarchy, timing, and how clearly the interface guides attention.
An action can be present on the screen and still be missed. I learned to pay closer attention to hierarchy, timing, and how clearly the interface guides attention.
Simplifying does not always mean removing
Operational products sometimes need context to make an action or status understandable. The better question is what deserves attention now and what can stay secondary.
Operational products sometimes need context to make an action or status understandable. The better question is what deserves attention now and what can stay secondary.
The details reveal what simplicity misses.
Exceptions reveal the strength of a flow
The expected path is only part of the experience. Designing blocked, pending, restricted, and changing states often exposes gaps that the ideal path does not.
The expected path is only part of the experience. Designing blocked, pending, restricted, and changing states often exposes gaps that the ideal path does not.
Good design makes complexity easier to navigate, not invisible.
Showcase
More of Passify,
beyond the journey.
More of Passify,
beyond the journey.
Contact
Have a role in mind?
imran.uxi@gmail.com
Copied
© 2026 Imran. All Rights Reserved.
Contact
Have a role in mind?
imran.uxi@gmail.com
Copied
© 2026 Imran. All Rights Reserved.
Contact
Have a role in mind?
imran.uxi@gmail.com
Copied
© 2026 Imran. All Rights Reserved.
Contact
Have a role in mind?
imran.uxi@gmail.com
Copied
© 2026 Imran. All Rights Reserved.
Contact
Have a role in mind?
imran.uxi@gmail.com
Copied
© 2026 Imran. All Rights Reserved.