Enterprise Web App: Driver Registration & Terminal Loading
Operational workflow for chemical terminals (details anonymized)
Note: Screens/names were removed or reconstructed with generic visuals due to confidentiality!
Role:
UI/UX Designer, Frontend bridge and development, QA support
Timeline:
24 months in total (12 months when I joined the team)
Who worked on the project:
Scrum method with team + stakeholders
Platform:
Web (currently expanding to mobile)
Tools:
Figma for prototypes, Vscode for Frontend (React), Backend (C#)
Context
In this workflow, each truck driver follows a specific delivery route and stops at a terminal to load chemical products. Drivers complete an on-site registration step at the terminal to be allowed to load and proceed. To reduce operational friction, a web/mobile portal allowed drivers to plan ahead by checking which terminals were available, whether any disruptions were happening (maintenance, cleaning, restrictions), opening hours, and which products were currently available, out of stock, or in progress. Terminal managers could update status and send urgent alerts to specific drivers through a role-based system, so drivers wouldn’t arrive at a closed terminal or one that couldn’t support their required pickup.
Users & Scenarios
.png)
Truck Driver
Primary Users
-
Check terminal status (open/closed/disruptions) before leaving
-
Confirm product availability to avoid wasted trips
-
Use mobile/PWA on the road for quick, readable updates
Terminal Managers
Secondary Users
-
Publish urgent disruption notices like maintenance/cleaning, etc.
-
Send targeted alerts to impacted drivers on specific routes
-
Keep terminal info updated to reduce delays and confusion
Terminal Staff
Secondary Users
-
Validate and update product/status information during the day
-
Support drivers by ensuring data is accurate and consistent
-
Flag issues that require manager action or escalation
Admin
Access and maintenance
-
Manage permissions across roles (driver, staff, manager)
-
Ensure the right users see the right actions and data
-
Prevent errors with clear access boundaries and UI states
My Role
-
Improving usability and accessibility (contrast, layout, navigation hierarchy, and element sizing).
-
Designing low-fidelity mobile prototypes to support the transition toward a PWA experience.
-
Defining interaction patterns and edge cases for status communication and alerts.
-
Supporting frontend implementation through bug fixes and UX-driven improvements.
-
Conducting manual QA testing and documenting test plans and validation scenarios.
-
Automating critical checks using Playwright to ensure reliability across core flows
I worked across UX, frontend implementation, and quality assurance. These are some of the responsibilities included:
Key Design Decisions
Terminal Status at a Glance
Problem:
Drivers needed to quickly assess whether a terminal could support their route, often under time pressure.
Designed a card-based terminal overview using clear color status indicators (green, red, yellow), enabling rapid scanning without opening each terminal.
Change:
Why:
In time-critical scenarios, users should understand system status in seconds, not minutes.
Outcome:
Drivers could identify viable terminals faster and avoid unnecessary route deviations.
Terminal Details Disclosure
Problem:
Exposing all terminal information at once increased cognitive load and made critical data harder to find.
Structured terminal details into a layered view, revealing product availability, operating hours, and disruption notices only when a terminal card was selected.
Change:
Why:
Progressive disclosure improves clarity by showing only what is relevant at each decision stage.
Outcome:
Information became easier to consume, reducing confusion and misinterpretation.
Role-Based Permissions
Problem:
Multiple user roles (drivers, terminal staff, managers, admins) increased the risk of incorrect actions and confusion.
Defined role-based permissions and UI cues to ensure users only accessed actions and information relevant to their responsibilities.
Change:
Why:
In operational systems, preventing errors is as critical as enabling efficiency.
Outcome:
Improved trust in the system and reduced the likelihood of operational mistakes.
For example...
Manager view
Publishing a disruption alert. This action is exclusive to the Terminal Manager role.
1
2
Add Alert action available to Terminal Managers only. Role-based UI prevents unauthorized publishing.
Targeted alerts. Manager selects who receives the notification, reducing noise for unaffected drivers.
The Process
This simplified flow illustrates how drivers plan routes, assess terminal availability, and receive critical updates before arrival.
Driver receives instructions on transportation
Terminal is disrupted, unavailable or doesn't contain the desired product
Driver contacts their superiors to receive new instructions
Searches on the website for the destined terminal
Terminal is available and contains the desired product for loading
Checks terminal status (available / disrupted / unavailable)
Reviews terminal details (available products, notifications, hours, disruptions)
Driver can proceed to terminal
Arrives prepared at terminal
Workflow
Before vs After
BEFORE
VS
AFTER
Drivers had limited confidence in terminal availability before arrival
Terminal availability and status are visible at a glance
Critical status information was scattered across multiple views
Centralized and structured access to critical terminal information
Disruptions were often discovered too late to adjust routes safely
Disruptions surfaced early enough to support route replanning
Urgent updates depended on fragmented and misleading communication
Targeted, in-system alerts replaced limited communication
High cognitive load during time-sensitive decision-making
More confident decisions under time pressure, making the loading process faster
Design Process
The final card-based layout came from evaluating three approaches:
-
Simple list: made status scanning slow under time pressure
-
Interactive map: added implementation complexity without a real UX benefit
-
Card grid: color-coded status indicators are fast to scan, feasible to build, and extensible for future states and roles
The Before wireframe above reflects the starting point and the final decisions show how we got from there to the solution.
The before...
.png)
No role-based access. All users see identical interface regardless of their responsibilities.
1
2
3
4
Status shown as plain text only, no visual difference between Interrupted, Unavailable, and Available states.
All terminal data exposed at once, no progressive disclosure, high cognitive load for time-pressured users.
Critical alerts buried below the fold and mixed with routine updates. No urgency hierarchy.
...and the after
*the following wireframes are reconstructed examples created to illustrate key UX decisions while respecting confidentiality.
Terminal overview with clear status indicators (reconstructed).
Expanded terminal details with operational information and disruptions + targeted alert message
Mobile version of the pages, created to be reproduced using PWA
Terminal overview with clear status indicators (reconstructed).
Constraints & Challenges
Different Timezones
Most design decisions required validation and approval from international stakeholders. Time zone differences slowed feedback cycles and increased dependency on asynchronous communication.
Team Expectations
Reaching consensus within a cross-functional team required balancing UX improvements with frontend feasibility.
Real-time Operations
Design solutions needed to remain strictly aligned with real-time terminal operations. Any mismatch between UI states and backend data could result in operational disruptions or communication errors.
Outcomes
-
Reduced uncertainty for drivers during route planning and terminal selection.
-
Improved clarity and reliability of terminal status and operational information.
-
Faster dissemination of critical updates through centralized, role-based communication.
-
Better alignment between design decisions and technical implementation.
-
Increased trust in the system under time-sensitive operational conditions.
-
Improved confidence in decision-making across different user roles.
What I learned...
Learnings
Clear communication and documentation are critical in all teams, not only cross-timezone ones.
Designing within constraints is often more impactful than designing without them (and more complex).
UX decisions in operational systems must prioritize reliability and data consistency over visual refinement.
Resume
Laura Hundzinski da Rocha
Download PDF file
Want to know more ?
This case study highlights selected decisions and reconstructed examples.
I’d be happy to walk through the full context, trade-offs, and iterations in an interview.
