B2B OPERATIONS & DATA MANAGEMENT PLATFORM
An internal platform for the Port of Singapore Authority. Two user roles, one shared spine. The redesign cut operational errors by 35% and reached 85% team adoption within six months of rollout. Metrics from PSA’s own QA review.
Timeline
2023–2024
Role
UX Research, Interaction Design, UI System, Developer Handoff
Platform
Web (B2B)
Client
The Port of Singapore Authority (PSA)
Team
Worked as sole designer embedded in a cross-functional team (PM, developers, QA)
TL;DR
• Problem
The old platform worked. It just didn’t feel safe to use. Dense tables, no visual hierarchy, and confirmation feedback that either arrived too late or not at all. In port operations, “not sure if that saved” isn’t a UX quirk. It’s a delayed shipment.
• Users
Buyer and seller operations teams at PSA. High-volume, time-sensitive transactions where a wrong click can compound into six-figure consequences.
• Key Challenge
Improve accuracy without breaking workflows users already knew.
• My Role
Sole Product Designer. Research through developer handoff.
• Outcome
35% fewer operational errors. 85% team adoption within six months. Both measured by PSA's internal QA team over a six-month post-launch review.
Context & Constraints
SlotXpert is the internal platform PSA’s operations and management teams use to manage container slot bookings and listings. Huge volumes, moving in and out of one of the world’s busiest ports every day.
I had to redesign it without breaking anything users already knew how to do.
Constraints that shaped the work:
Users had years of muscle memory in the legacy tool. Any change had to feel like a better version of what they already knew.
The tables were massive. Cognitive load was already a limiting factor before I added anything.
Limited tolerance for drastic UI change. Adoption asked for familiarity, not novelty.
Delivery timelines ran alongside live port operations. There was no quiet moment to roll things out.
The backend logic and data structures weren't up for discussion. My designs had to route around them, not through them.
User Research & Baseline Survey Insights
PSA had run internal surveys with both teams before I arrived. I got the raw data and reworked it into something usable. Patterns instead of a wall of freeform answers.
Three questions the survey actually answered:
Task completion confidence
Could users complete key actions without hesitation?
Error frequency
Where in the flow were errors clustering?
System trust
Did users trust that the system had recorded what they just did?
The answers were consistent across both teams. Dense tables with no visual hierarchy. Confirmation states people couldn't read. Buyer and seller flows that looked and behaved differently for no good reason.
Source: PSA-provided survey summaries. ~148 users on the booking flow, ~147 on the listing flow. I synthesized and visualized the findings; I did not administer the survey.
The interesting part: most users could technically complete tasks. Completion rate wasn't the problem. Confidence was. People were finishing tasks and then going back to check them a second and third time.
That pattern framed the whole redesign. Reduce errors, close the trust gap, don't retrain anyone.
The Core Problem
Users were making errors, but not because they didn’t know how to use the platform. They were making errors because the platform never told them, clearly, what had just happened. Missed confirmations. Misread rows. Ambiguous states.
Careful users compensated by slowing down. Fast users compensated by getting things wrong.
The brief wasn't visual. It was operational. Make the system trustworthy enough that people can act with confidence the first time.
My Role & Responsibilities
Sole Product Designer, embedded in PSA's cross-functional team through the Metafic design studio. I owned the process end-to-end: research and diagnosis, IA and flows, interaction design, UI system, developer handoff.
• Worked through the internal survey data to map error-prone workflows
• Audited both buyer and seller paths and located the friction points before touching a screen
• Restructured information hierarchy across the dense data tables and multi-step dashboards
• Defined role-specific IA with a shared pattern language, so a buyer switching to a seller view wasn't learning a new tool
• Built error-prevention into the interaction layer: confirmation states, inline validation, progressive disclosure, clearer action labels
• Built a UI component system that matched the constraints of the backend and the shipping calendar
• Ran developer handoff and stayed close to engineering through implementation
Information Architecture & User Flows
Two roles, two workflows that had to work in parallel without diverging visually. The redesign needed a shared spine underneath both.
Structural decisions below. Interaction-level decisions (confirmations, validation, disclosure) sit in the Key Design Decisions section.
• Role routing at login. Buyers and sellers land in different dashboards. The old shared dashboard mixed content from both roles and quietly created most of the confusion.
• Primary actions surfaced at the top of navigation. Book slot. List container. No hunting.
• Same patterns across both flows. If you learned one, you'd already know most of the other.
Seller User Flow
Buyer User Flow
Wireframes & Layout Exploration
The client had existing wireframes for both journeys. I used them as a map of the existing mental model, not as a UI to copy.
Anywhere the friction data pointed to a broken interaction (slot booking for buyers, container listing for sellers), I rebuilt. One question ran through every wireframe: can a user tell what to do next without being told?
Seller Wireframes
Client-provided seller wireframes used as reference material.
Buyer Wireframes
Client-provided buyer wireframes used as reference material.
Wireframe Exploration
Key Design Decisions & Trade-offs
Error prevention over visual minimalism
The cleaner design would have removed some confirmation feedback. I didn’t. In port operations, a missed confirmation is an operational error. The screens are busier than they’d be in a consumer product. They’re also safer.
Progressive disclosure for dense data
Hundreds of container records don't need to be visible at once. Reveal them in context. Load them where users are actually looking.
Preserved familiar interaction patterns
Retraining hundreds of trained users is expensive and slow. Adoption asks for familiarity, not novelty. I intentionally kept the core workflows close to the existing mental model even when I could see a "better" pattern.
Accepted constraints imposed by backend logic
Some ideal solutions weren't possible inside the existing data structures. I documented the compromises so future iterations can revisit them when those constraints move.
Final UI Screens
Selected screens covering the seller and buyer flows, both analytics dashboards, and the two supporting states (empty account, listing detail) that came out of research as the highest-risk moments. Data is anonymized for NDA compliance. One decision runs through every screen: status color and organization identity stay visually separate, so a row’s color always means the same thing. If you see amber, it’s amber for a reason, never because that’s a client’s brand color.
Outcomes
From PSA's six-month post-launch QA review:
• 35% reduction in user errors
• 85% adoption across buyer and seller teams within six months
• 80% retention versus the previous workflow
• Reduced time-on-task on both core flows (slot booking, container listing)
• Stakeholder feedback confirmed the trust gap closed. Users stopped repeating actions out of uncertainty.
Metrics sourced from PSA's internal QA and stakeholder review.
Limitations & Reflections
The proprietary nature of SlotXpert limits what I can show publicly.
Screens are presented with anonymized data and product-identifying details removed.
Impact metrics come from PSA's internal QA logs and stakeholder review over the six-month post-launch period.
I'd push harder for moderated user sessions at the wireframe stage. Stakeholder review worked and the post-launch numbers say the direction was right.
Watching real buyer and seller users move through the flows before we committed to hi-fi would have de-risked more of the interaction decisions earlier.
For B2B systems that people use every day for high-stakes work, predictability beats novelty. Users don't need a system that looks clean. They need one that acts predictably enough that they can trust their own actions on it.
The 35% error reduction didn't come from any single decision. It came from the same set of error-prevention principles applied consistently across dozens of small interactions.
Confirmation states, hierarchy, disclosure, clearer labels. The compound effect is where the number lived.
