# WiseTech Connect Portal

By Munawar Khel / WiseTech Global / Lead Product UI/UX Designer, CargoWise Landside / 2026 / 7 min read

Published at https://munawarkhel.com/work/wisetech-global/wisetech-connect-portal/

Transformed a fragmented, single-purpose legacy admin tool into a scalable, role-aware, enterprise-grade platform capable of supporting multi-TMS and multi-organization operations

- Company: WiseTech Global
- My role: Lead Product UI/UX Designer, CargoWise Landside
- Timeline: January 2026 – May 2026
- Platform: Web (Desktop)
- Category: Enterprise SaaS / Role-Based Admin Platform
- Status: Redesign, delivered
- Tools: Figma, FigJam, CargoWise Supply Design System
- Team: Solo designer with iterative stakeholder reviews (product support, specialist teams)

## Context

WiseTech Connect Portal is a centralized web-based administration platform inside the CargoWise logistics ecosystem. It acts as the bridge between an organization's Transportation Management System (TMS) and the CargoWise Driver Mobile App (DMA), the control center where logistics companies and WiseTech's internal teams manage the people, services, and permissions that keep freight operations running. In practical terms it answers a foundational question in multi-system logistics: how do you give the right people access to the right services, across the right organizations, with minimal friction?

The portal connects TMS services (organizations link platforms such as Tailwind, CarrierGo, and Profittools, which then sync driver data automatically), manages organizations, members, and drivers, controls what drivers can see and do inside the CargoWise Driver Mobile App (DMA) on a per-service basis, and provides a built-in chat module so admins, members, and drivers can coordinate without leaving the platform. It serves three distinct roles, each with a tailored experience: System Admin (WiseTech's internal product support and specialist teams), Organization Admin (customer-level administrators managing their own organization), and Member (operational users, primarily drivers, with scoped access).

The original portal had been built years earlier as a single-purpose administrative tool. Over time the platform's ambitions grew: it needed to support multiple TMS integrations, multiple organizations, and a multi-service architecture. The legacy system was never designed for that scale, and it lacked clear structure, modern usability standards, and the flexibility to support the platform's transformation.

## The problem

The WiseTech Connect Portal was transitioning from a single-purpose admin tool into a multi-TMS, multi-service platform, but its UX had not evolved to match. Several connected problems defined the work:

Together these gaps created unnecessary friction for both WiseTech's internal teams, who onboard and support customers, and the customer-level administrators who manage their own organizations day to day. The core tension was scale versus clarity: the product had to absorb far more operational complexity (multiple TMS systems, thousands of records, three role types) without pushing that complexity onto the people using it.

- Unclear role boundaries: the system did not consistently define what System Admins, Organization Admins, and Members could see or do, which created confusion and permission-related friction.
- Unintuitive workflows: core processes like onboarding organizations, connecting services, and managing drivers required more steps and cognitive effort than necessary.
- Poor scalability: the information architecture was built for a simpler use case and could not gracefully handle thousands of services, members, and cross-organization operations.
- Lack of visibility: there was no centralized dashboard or activity feed to give administrators a quick read on system health, alerts, or recent changes.

## What I did

The solution was a ground-up redesign of the WiseTech Connect Portal into a unified, role-based administration experience built on the CargoWise Supply Design System. Rather than bolt new capabilities onto the legacy structure, the redesign reorganized the product around three distinct user roles, each with tailored views, permissions, and workflows, and a scalable information architecture that could hold multi-TMS and multi-organization operations.

The redesign was structured around a role-based architecture. System Admins (WiseTech internal) get full platform visibility: a dashboard with KPIs (total organizations, services, members), system alerts, member distribution analytics, a recent activity feed, and a recent organizations table, plus access to the Organization module for customer onboarding. Organization Admins are scoped to their own organization, with a dashboard of relevant metrics and management of their services, members, and drivers. Members are operational users, primarily drivers, with appropriate access levels.

Eight-plus modules were designed to carry this: an Onboarding flow with a simplified welcome and account setup; a data-rich Home Dashboard with KPI cards, system alerts, member distribution by role, a recent activity timeline, and a recent organizations table; the Organization module (System Admin only) for creating, editing, and governing organizations and invitations; the Services module for connecting TMS services, auto-pulling drivers, and managing service detail and mobile app configuration at scale; the Members module for inviting and managing members either system-wide or scoped to an organization; the Drivers module for inviting and associating drivers synced from connected TMS systems; a Chat module for internal coordination; and Profile and Settings for personal account management. A consistent interaction language ties the product together: data tables with inline actions and row selection, side-drawer panels for detail and editing, modal dialogs for creation and confirmation, alert modals for destructive actions, toast notifications, global search with categorized results, breadcrumb navigation, and friendly empty states with clear calls to action.

## Outcomes

- Transformed a fragmented, single-purpose legacy admin tool into a scalable, role-aware, enterprise-grade platform capable of supporting multi-TMS and multi-organization operations
- Established clear role separation across System Admin, Organization Admin, and Member, resolving the legacy portal's unclear role boundaries and permission friction
- Delivered a centralized Home Dashboard giving administrators at-a-glance visibility into system health, KPIs, alerts, member distribution, and recent activity where the legacy tool had none
- Designed scalable data-table patterns that keep high-volume surfaces (Services and Members) usable at real scale with filtering, sorting, column customization, bulk actions, and export
- Simplified core workflows (organization onboarding, service connection, member and driver management) and brought operational coordination inside the product through an integrated Chat module
- Grounded the redesign in structured research (legacy audit, terminology chart, role-based personas, QAD framework, functional requirements) and built it all on the CargoWise Supply Design System for long-term consistency and maintainability

## Decisions

### Role-based architecture over a single shared interface

What: Structured the entire product around three distinct roles (System Admin, Organization Admin, Member), each with tailored views, permissions, and workflows.

Alternatives: A single shared interface with features conditionally shown or hidden per user.

Why: The legacy portal's biggest failure was unclear role boundaries and permission friction. Designing role-first made access explicit and legible, let each role's dashboard and modules be tuned to its actual responsibilities, and gave the platform a clean way to scale across multiple organizations without leaking capability across role lines.

### A data-rich home dashboard as the visibility layer

What: Introduced a centralized Home Dashboard with KPI cards, system alerts, member distribution analytics, a recent activity timeline, and a recent organizations table.

Alternatives: Keeping the legacy model with no central overview, sending admins straight into module lists.

Why: The legacy tool gave administrators no quick read on system health, alerts, or recent changes. A dashboard turned scattered state into an at-a-glance operational picture, which matters most for System Admins governing many organizations and services at once.

### Scalable data-table patterns for high-volume operational surfaces

What: Standardized data tables with filtering, sorting, column customization, row selection, bulk actions, and CSV export across the Services and Members modules.

Alternatives: Simpler list views carried over from the single-purpose legacy tool.

Why: The information architecture had to gracefully handle thousands of services and members across organizations. A consistent, powerful table pattern kept these dense surfaces usable at real scale and reduced the cognitive cost of moving between modules.

### Bringing communication inside the platform with a Chat module

What: Designed a built-in chat module enabling admins, members, and drivers to coordinate directly in the portal.

Alternatives: Continuing to rely on external messaging tools for operational coordination.

Why: Disconnected communication forced users out of the product to coordinate, adding friction and context-switching. Embedding messaging kept operational coordination attached to the people, services, and drivers it referred to, inside the same role-aware environment.

## What I learned

Role clarity is the product, not a setting. The legacy portal treated permissions as an afterthought, and almost every downstream problem (confusing workflows, friction, poor scalability) traced back to unclear role boundaries. Designing role-first, with distinct personas and tailored views for System Admin, Organization Admin, and Member, was what made the rest of the system legible. The lesson was that in a multi-tenant admin platform, deciding what each role can see and do is not a configuration detail bolted on at the end, it is the architecture the whole experience hangs from.

Research pays for itself when the domain is unfamiliar and shared language is missing. Creating detailed role-based personas for System Admin, Organization Admin, and Member during UX research, each with goals, user stories, responsibilities, access permissions, and user flows, alongside the terminology chart and QAD framework, was not busywork: with multiple TMS systems, three role types, and cross-functional stakeholders, misaligned vocabulary, unclear role needs, and untracked assumptions would have quietly produced the wrong product. Grounding the work in personas, writing terms down, and tracking questions, assumptions, and decisions kept a complex, multi-party redesign coherent and gave stakeholder reviews something concrete to pressure-test against.

Designing for scale changes the patterns, not just the data. Surfaces that hold thousands of services and members cannot use the same list views a single-purpose tool got away with. Committing early to a consistent, powerful data-table pattern (filter, sort, customize columns, select, bulk-act, export) and reusing it across modules was what let dense operational screens stay usable, and it made the whole product feel like one system rather than a set of stitched-together tools.

Tags: UX Research, Information Architecture, Design Systems, Enterprise SaaS, Dashboard, Logistics, Supply Chain, Legacy Modernization, Data Visualisation