Cube

Global trade looks structured from a distance.

In reality, it is messy, fragmented, and heavily dependent on people who each understand one part of the chain extremely well — and only enough of the adjacent parts to keep work moving. Exporters, importers, customs brokers, compliance teams, logistics providers, finance, and operations all contribute to the same overall flow, but none of them holds the whole picture alone.

That was the real challenge behind Cube.

TradeWindow was building a digital platform intended to simplify and unify cross-border trade workflows. On paper, that sounds like a standard SaaS problem: bring documents, compliance, and process tracking into one place. In practice, it meant designing for a complex ecosystem of roles, responsibilities, handoffs, and edge cases where the cost of confusion could be delay, non-compliance, or commercial risk.

My role was to help shape Cube’s user experience from the ground up — from early research and workflow framing through to wireframes, prototypes, user stories, personas, and usability testing.

Role Lead UX Designer

Capability Complex workflows, Service design, Information architecture, Design systems

System Enterprise SaaS, Operational tooling

Cube was intended to give users a more unified way to manage trade operations: shipments, documents, compliance, approvals, onboarding, and organisational setup. The ambition was strong, but the domain made the product difficult in very particular ways.

Trade is not a single workflow owned by one role. It is a chain of intersecting responsibilities, each with its own language, constraints, dependencies, and risks. That meant Cube could not be designed as though there were one primary user and a few secondary edge cases around them. The product had to work at the intersections between multiple specialist roles.

That insight shaped the whole programme.

1. Discovery & Framing

The early research made something clear very quickly: in international logistics, no one knows it all.

Every participant in the process had deep expertise in their own slice of the work — customs, shipping, documentation, finance, approvals, compliance — and just enough understanding of adjacent steps to keep things moving. That meant the product challenge was not just to simplify a task. It was to help different people move through a shared system without losing sight of where they were, what they were responsible for, and what needed to happen next.

That is a much harder design problem than it first sounds.

The product could not be designed around a single ideal user

This was one of the most important framing decisions in the work.

Many products are built around a dominant user type and then adjusted for everyone else. That model would have been too weak for Cube. The product needed to support a chain of specialist roles whose work intersected in practical ways. A customs agent, a finance team member, an exporter, and an operations user might all touch the same broader process, but with different goals, different pressures, and different levels of context.

That led to a more useful design principle:

In other words, the system needed to make the handoffs, dependencies, and flow between roles clearer, not simply make each local interface cleaner in isolation.

Research grounded the product in real trade behaviour

To get there, I worked closely with stakeholders to research how trade processes actually operated. This included interviews, observation, and synthesis across the different people involved in cross-border trade, from exporters to customs and compliance stakeholders.

The research pointed to several recurring issues:

users struggled to access a single source of truth
document handling created friction and duplication
information was often spread across systems, inboxes, and people
collaboration across roles was difficult to track
compliance-sensitive flows needed more structure and confidence

The product goal, therefore, was not just digitisation. It was coordination.

User stories helped make the complexity buildable

As the interviews were synthesised, I translated the research into detailed user stories and role-based scenarios. This helped the team reason about what each user group actually needed from Cube, what problems they were trying to solve, and where workflows overlapped or diverged.

That work became especially important because it gave product and development teams something more concrete than general “trade complexity” to design against. It turned a messy domain into a more structured product problem.

2. Designing For Intersecting Roles

Once the product was framed properly, the interface work became much clearer.

The aim was not to give every role a completely separate experience. That would only have recreated the fragmentation the platform was trying to reduce. Instead, the design had to create a shared environment that felt coherent while still allowing different users to work through relevant flows, views, and data in ways that matched their responsibilities.

A unified platform without pretending everyone does the same job

This is where Cube became interesting as a UX problem.

The product needed a unifying structure: common navigation, a recognisable model of records and workflows, and a dashboard that gave users a clear overview of what mattered. But it also needed to reflect the fact that people approached the system with different questions.

Some users needed operational visibility. Some needed document certainty. Some needed compliance confidence. Some needed approvals to move. Some just needed to complete the next step without getting blocked.

That meant the UX work had to balance shared structure with role-appropriate relevance.

The dashboard as orientation, not just reporting

One of the key pieces was the dashboard. This was not just a summary screen. It was a way to orient users inside a complex, multi-party process.

The dashboard aimed to make trade activity more visible and legible: contracts, schedules, bookings, templates, notifications, shipments in transit, and organisation-level setup all needed to work together as part of a clearer operating picture.

That clarity mattered because users were often dealing with partial information and shared responsibility. The dashboard helped reduce the need to reconstruct system state from scattered pieces.

3. Workflow, Onboarding & Iteration

A large part of the real design challenge sat inside onboarding and conditional workflow logic.

This is where many trade products become painful. It is not usually the existence of fields or forms that makes them difficult. It is the number of exceptions, dependencies, missing documents, permission questions, and edge cases that appear once a real business starts trying to set itself up properly.

Onboarding was more than data entry

We began by reviewing known requirements with the product team, aligning on business and user goals, and working through common onboarding issues. That created a foundation for sketching flows, surfacing exceptions, and defining conditional logic before the product became too rigid.

From there, I carried out task analysis and mapped the flow in more detail. The goal was not merely to move users from start to finish, but to make the setup process understandable when things did not proceed cleanly.

For example:

what happens if the user belongs to another organisation?
what if they do not have access to key documents?
what if authorisation sits with a different person?
how should customs bond and POA logic affect the journey?
when should the system branch, pause, or support recovery?

These were not minor details. They were core to whether onboarding felt usable or bureaucratic.

Sketching and low-fidelity thinking first

I started with sketches and low-fidelity exploration to work through structure and flow before locking into polished UI. That made it easier to reason about exceptions, sequence, and navigation without getting distracted by surface detail too early.

This stage was especially valuable because it allowed the team to keep adjusting the underlying logic as requirements and edge cases became clearer.

Prototypes and usability testing

From there, I created low-fidelity prototypes and tested them with target users. The focus was on whether the product made workflows more understandable and whether users could move through key tasks without the usual document and process friction.

After iterating on the low-fi direction, I developed higher-fidelity prototypes and ran additional usability testing. This allowed the team to refine both the general interaction model and the more specific compliance/onboarding flows.

The testing surfaced more edge cases and led to further refinement, particularly around exceptional conditions and the many ways real-world organisational setup could diverge from the ideal path.

Workshops helped align the product around the process

The workshops were also important because they brought the team together around a shared understanding of workflow structure and business/user goals. In a domain like this, where exceptions and dependencies can multiply quickly, shared alignment matters. Without it, the product risks becoming a collection of isolated features rather than a usable operational system.

4. Outcomes & Reflection

Cube created a stronger foundation for managing trade processes in one place.

The design work helped shape a platform that could bring together documentation, compliance, logistics, and organisation setup in a more coherent way. Rather than forcing users to stitch the process together across fragmented systems and role silos, Cube moved toward a more unified operating model.

What this enabled

a clearer shared structure for complex trade workflows
better visibility across documents, compliance, and logistics activity
more usable onboarding for organisations entering the platform
stronger support for multi-role collaboration and handoff
a product architecture built around the intersections between users rather than around one narrow primary persona

Reflection

What I like about this project is that it captures a truth I still come back to often: in complex systems, the UX challenge is rarely just about making one screen simpler.

It is about understanding how people depend on each other.

Cube was valuable because it treated trade as a connected chain of specialist work rather than a flat list of tasks. That changed the product architecture, the workflow design, and the way the system needed to support onboarding and everyday use. The goal was not to make global trade look simple. It was to make it more navigable, more coherent, and less dependent on users carrying the full burden of process complexity in their heads.

That is the kind of work I find most meaningful.

Not flattening complexity.

Structuring it well enough that people can actually work through it.