UX RESEARCH | ILLUSTRATIVE ENGAGEMENT
Can both sides of a chemical delivery see the same exception before confirming receipt?
Testing a delivery confirmation terminal across driver, receiving operator and control roles in Rotterdam, Netherlands.
CLIENT SITUATION
A bulk chemical supplier was preparing a terminal workflow for compartment checks, receiving bay confirmation and delivery acceptance.
DECISION REQUIRED
Determine whether exception handling was clear enough for a controlled pilot across supplier and customer organisations.
Why the interaction mattered
The driver and receiving operator could each complete their part of the workflow while holding different assumptions about the product, compartment, bay or acceptance status. The client needed to know whether the terminal created one shared delivery state or merely produced two separate records.
Research decision
DETECT
Which mismatch cues are noticed before transfer or acceptance?
RECONCILE
Can both roles recover when their records disagree?
CONFIRM
Does the final state mean the same thing on both sides?
Hypothetical engagement frame
20 PARTICIPANTS
Eight driver and receiver pairs plus four control roles
ROTTERDAM
Botlek industrial area and approved training facilities
4 EXCEPTIONS
Product, bay, scan and confirmation mismatch
6 WEEKS
Setup, paired sessions, synthesis and retest
Note: The organisation, study location, participant counts, findings and recommendations are hypothetical and do not represent a completed client project.
PARTICIPANT AND OUTREACH DESIGN
Recruit both sides of the delivery
Paired sessions preserve the cross company handoff. Individual interviews alone would not show when one role believes the other has already verified an exception.
Participant structure
8 tanker drivers
Recent experience with compartment checks, site entry and digital proof of delivery
8 receiving operators
Direct responsibility for bay readiness, product acceptance and discrepancy handling
2 transport coordinators
Monitor route, load record and driver exception escalation
2 site control roles
Review access, receiving status and final exception ownership
Selection parameters
Recent responsibility for delivery presentation, receiving verification or exception escalation
Single compartment and multi compartment delivery experience
Regular visitors and drivers entering an unfamiliar receiving site
Dutch and English interface use, with terminology checked during screening
Approved terminal, scanner, gloves and protective equipment conditions
Recent experience of a mismatch, scanner failure, queue change or record correction
Outreach route
SOURCE
Approved carriers and receiving sites
PAIR
Match one driver with one receiver
VERIFY
Confirm recent task and working language
SCHEDULE
Work around route and shift windows
CONSENT
Cross company recording permissions
Why independent research adds value
A supplier or customer led session can encourage each side to defend its own procedure. A neutral moderator can hold both views together and distinguish interface ambiguity from process disagreement.
RESEARCH METHOD
Dual Control Exception Test
Driver and receiver complete linked tasks with separate screens. The test introduces one controlled mismatch and observes whether the two records converge without an unsafe live transfer.
Controlled environment
Sessions would use an approved training bay, inactive terminal or digital simulation in the Rotterdam area. Product names, vehicle data and customer records would be fictitious. No chemical transfer would occur during research.
Paired test sequence
ROLE | 1. PREPARE | 2. VERIFY | 3. EXCEPTION | 4. RECONCILE |
|---|---|---|---|---|
DRIVER | Reviews load and compartment | Presents delivery and selects bay | Receives conflicting or missing cue | Corrects, escalates or waits |
RECEIVER | Reviews order and site readiness | Checks identity and receiving condition | Sees a different state or mismatch | Accepts, rejects or requests evidence |
Exception scenarios
EXCEPTION | BACKGROUND | OBSERVED RECOVERY |
|---|---|---|
COMPARTMENT | Selected compartment does not match the digital order | Whether the discrepancy is visible to both roles |
RECEIVING BAY | Driver is redirected after initial check in | Whether the correct destination follows the record |
SCANNER | Scan fails after identity has been reviewed | Whether fallback preserves evidence and accountability |
Evidence captured
Screen state at each role, sequence of checks, verbal clarification, exception ownership, fallback path, repeated entry and the point at which the paired records become consistent.
QUESTION DESIGN
Questions follow the mismatch
The moderator first records what each person did, then asks each role to reconstruct what they believed the other person had already verified.
Example paired task background
TASK PROMPT
A delivery has arrived at the assigned site. The order, compartment and receiving bay appear correct at first. During confirmation, the terminal shows a discrepancy that is visible differently to the driver and receiving operator. Continue until you can accept, stop or escalate the delivery.
Questions for the driver
Before presenting the delivery, what did you believe the receiving site had already checked?
Reconstructs assumptions about work completed by the other organisation.
Which screen cue first told you that the delivery might not match the receiving record?
Links detection to a specific interface element.
When the scan failed, what did you believe would remain in the record if you used the fallback?
Tests evidence continuity and confidence.
At what point did you believe responsibility had moved to the receiver?
Locates the ownership transition.
Questions for the receiving operator
What did the driver's confirmation tell you, and what did you still need to verify yourself?
Separates shared evidence from repeated checking.
When the bay changed, what did you expect to update automatically?
Tests destination continuity across systems.
What would make you stop and call control rather than continue in the terminal?
Identifies the escalation threshold.
Looking at the final record, what does 'accepted' mean to you?
Checks whether acceptance has one shared meaning.
ILLUSTRATIVE FINDINGS
Where paired records diverged
Hypothetical patterns from eight driver and receiver pairs show whether the terminal created one delivery state across two organisations.
Pair reconciliation pattern
TEST CONDITION | SAME STATE | NEEDED CALL | DECISION CONSEQUENCE |
|---|---|---|---|
Compartment mismatch | 5/8 pairs | 3/8 pairs | Mismatch not visible at the same point |
Receiving bay change | 4/8 pairs | 4/8 pairs | Route changed before the record did |
Scanner fallback | 4/8 pairs | 4/8 pairs | Evidence ownership became unclear |
Final acceptance | 3/8 pairs | 5/8 pairs | Accepted meant different things to each role |
Note: All counts are hypothetical and illustrate the analysis format. The same pair could experience more than one point of divergence.
Exception recovery path
MISMATCH
One record differs
PAUSE
Transfer remains blocked
COMPARE
Roles see shared exception code
OWN
One role accepts next action
RESOLVE
Both screens show final state
Illustrative decision
REVISE BEFORE PILOT
Add a shared exception identifier, keep the transfer blocked until one role owns the next action and show the same acceptance definition on both screens.
DECISION AND DELIVERY
What the client receives
The evidence package connects interface states to cross company responsibility and the conditions for a safe controlled pilot.
Paired State Trace
Driver and receiver screens aligned at each exception point
Exception Ownership Register
Who detects, pauses, corrects, accepts and closes each mismatch
Fallback Evidence Standard
Minimum record required when scanning or connectivity fails
Pilot Acceptance Checks
Observable conditions for shared meaning before field release
Delivery sequence
WEEK 1
Scope and permissions
WEEK 2
Pair recruitment and scenario build
WEEKS 3-4
Controlled paired sessions
WEEK 5
Reconciliation analysis
WEEK 6
Design review and retest
Timing is indicative and depends on carrier and site response, cross company permissions, route schedules, working language, travel within Rotterdam and access to an approved inactive environment.
FAQ
Does this research validate chemical handling or terminal safety?
No. It evaluates the delivery confirmation interaction. It does not replace process safety, dangerous goods, engineering, regulatory, cyber or operating procedure assessment.
Contact Us
Discuss your UX research question
Tell us the roles, critical task, terminal or application, operating conditions, markets and decision you need to make. August Research will design the outreach, paired test environment and decision outputs around the interaction that matters.
