Avlino.com

Timeline: June 2023 – October 2025
Phase: 0 → MVP · Full Suite
Team: 1 designer, 6 engineers, 2 PMs
Key Methods: Field study, stakeholder interviews, Agile/Double Diamond
Domain: AI-powered logistics analytics / container terminal operations
Toals: Figma, Adobe CC, Miro, Jira

Leding the design of AICON, an AI platform serving the world's most complex logistics operations

Building the design system, cross-functional process, and product foundation for a suite of AI tools that help container terminals predict, plan, and act, before problems happen.

Overview

AICON Suite is a modular enterprise platform for container terminal intelligence. It gives port operators, planners, and managers the tools to coordinate berth scheduling, yard visibility, dispatch logistics, vessel tracking, and operational analytics — across a single, unified design system.

My role went beyond interface execution. I was responsible for the product design strategy across the entire ecosystem: establishing the platform architecture, building the design system from scratch, aligning engineering and product stakeholders, and creating the scalable foundations that allowed six distinct operational products to function as one coherent system.

The challenge was not designing six screens. It was designing one platform that six different operational contexts could inhabit without losing coherence.

Role

As the only product designer on the team for the duration of the engagement, I owned the full design scope across AICON Suite:

• Defined UX strategy and interaction principles across all products
• Built the design system and token architecture from the ground up
• Led product discovery, stakeholder workshops, and operational field research
• Structured information architecture for high-density, real-time operational workflows
• Created the shared navigation model, filtering logic, and component ecosystem
• Collaborated directly with engineering on implementation quality and design QA
• Supported roadmap definition and feature prioritisation alongside the PM and CPO
• Reviewed engineering implementation against design intent across all product releases
• Created and validated prototypes with operational stakeholders at live terminal sites
  

The scope required balancing real-time data complexity, multi-role usability, cross-terminal adaptability, and long-term scalability — simultaneously. In practice, this meant thinking like a platform architect as much as a product designer.

Context & Scope

Container terminal operations are among the most complex coordination environments in global logistics. At a major terminal, thousands of containers move daily across berths, cranes, yard blocks, and gate lanes — each decision affecting the next, and mistakes measured in commercial penalties, vessel delays, and cascading congestion.

Most existing platforms failed operators not because the data was wrong, but because the interfaces were built for the technology, not for the people making decisions under pressure. The common failure modes were consistent across the industry:

• Fragmented tools for related workflows, forcing constant context-switching
• Legacy interfaces with no shared interaction logic or consistent behaviour
• High-density data environments with no hierarchy, no progressive disclosure, and no cognitive relief
• Low adaptability to different terminal configurations and operator roles
• No design consistency between products from the same vendor — let alone across vendors
  

The opportunity behind AICON Suite was not to build better versions of these tools. It was to rethink terminal operations as a connected platform problem, where planning, monitoring, dispatching, and analytics shared the same design language, the same interaction patterns, and the same operational logic.

Strategic Challenge

The central design challenge was not usability in isolation. It was designing a scalable operational framework capable of supporting multiple products, multiple roles, high-density real-time data, and a terminal environment that varies significantly between deployments — without fragmenting into inconsistency.
This required a shift in design posture. Rather than treating each product as an independent deliverable, I approached the suite as a platform architecture problem: what are the shared foundations that allow every module to feel native to the same system?

The answer had four layers:

• Shared interaction models. Every product would use the same table patterns, the same filtering logic, the same modal behaviour, and the same status vocabulary. Users moving from Berth to Dispatch should not need to relearn anything structural.
• Semantic design tokens. Colour, spacing, typography, and state would be governed by a token architecture that communicated operational meaning — not just visual style. A critical alert looks the same whether it appears in Yard, Berth, or Dispatch.
• Role-based information architecture. Operator, planner, coordinator, and manager roles have fundamentally different information needs and decision loops. The platform needed to surface the right density and context for each role without building four separate products.
• Design governance. Maintaining platform coherence across six products, two product managers, and multiple engineering tracks required a formal governance process — not verbal agreement. Component reviews, design QA, and shared documentation were operational necessities, not optional process overhead.
  

Designing a Platform, Not Individual Screens

The most consequential strategic decision on this project was made before any interface was designed: the decision to treat AICON Suite as a platform rather than a product collection.
In practice, this meant every design decision was evaluated against a platform standard, not just a product requirement. A new component introduced in Berth would be reviewed for reusability in Dispatch. A status pattern introduced in Yard would be standardised for use across all monitoring contexts. A navigation model introduced in one product would become the navigation standard across the suite.
This approach had direct operational and commercial consequences. Operators who learned AICON Berth could navigate AICON Dispatch with minimal friction. Engineering teams could implement shared components without rebuilding them. New product modules could be added to the platform without requiring the interaction vocabulary to be re-established.

Platform thinking created compounding returns on every design decision.

Design Principles 

Operational Clarity Above All

Terminal operations are already cognitively demanding. The interface carries a responsibility not to add to that load. Every design decision was evaluated against whether it reduced friction or introduced it — not whether it looked sophisticated.
This influenced information hierarchy at every level: which data appeared by default, which required a click, which was summarised and which was granular. Progressive disclosure was not a pattern — it was a survival mechanism for operators managing hundreds of concurrent data points under time pressure.

Semantic Consistency

In operational environments, colour is not decorative. It is communicative. A mismatch between what red means in Berth and what red means in Dispatch is not an inconsistency — it is a safety issue.
Every colour, every status indicator, every alert classification in AICON was defined semantically first. The token architecture enforced that semantic meaning across all products. This reduced cognitive load, improved error recognition, and built the kind of ambient operational fluency that only comes from consistent environmental cues.

Flexibility Without Fragmentation

No two terminals operate identically. The platform had to adapt to different quay configurations, different equipment fleets, different operational priorities, and different user permission structures — without forking into custom experiences that diverged from the platform baseline.
The answer was modularity at the component level and configuration at the product level. The design system defined the fixed interaction vocabulary. Product configuration defined the variable operational context. These were kept deliberately separate.

Design and Engineering as Co-owners of Quality

Implementation fragmentation is the primary cause of platform inconsistency in enterprise products. A design system is only as good as its adoption rate in engineering. I introduced structured design QA processes, component review workflows, and cross-team documentation specifically to close the gap between design intent and delivered product.
This was not a process tax. It was an investment in the platform's long-term coherence — and it paid off in consistently faster implementation cycles on every product added after the system was established.

Research and Discovery

Understanding how operational decisions are actually made in terminal environments required going to where those decisions happen. Research was not a phase, it was a continuous input throughout the project.

Activities included on-site visits to live terminal operations, workflow mapping with planners and operators, heuristic reviews of legacy interfaces, structured stakeholder interviews across operational and management roles, and competitive analysis of existing port technology platforms.

The most valuable findings came not from asking what users wanted, but from observing where the existing tools created operational gaps:

• Dispatching decisions were being made with incomplete visibility. Coordinators were cross-referencing three separate screens to assemble the information needed to make a single assignment, a clear structural failure that informed the Dispatch product architecture.
• Berth planning conflicts were discovered too late. The existing planning tools surfaced conflicts after commitments had been made, not before. Every design decision in AICON Berth was shaped by this single finding.
• Yard monitoring required physical presence. Operators were walking the yard to verify information the system should have been providing in real time. AICON Yard was designed around the principle that the system should be the ground truth, not a supplement to it.
• Management decisions were being made on lagging data. The reporting infrastructure was disconnected from the operational layer, meaning executives were acting on information that was already hours old. AICON 360 was designed to close this temporal gap.

"The operators we spoke to weren't lacking data. They were drowning in it. Our job was to make the right decision obvious."

Building the AICON Design System
 

The design system was the most structurally important output of this project. Without it, six products built by multiple engineering tracks over two years would have fragmented into six inconsistent experiences. With it, the platform could scale, evolve, and onboard new team members without re-establishing its foundations.

The system was not built as a visual style guide. It was built as operational infrastructure.

Token Architecture

The foundation of the system was a token architecture that governed every decision layer (colour, typography, spacing, elevation, motion, and state) through semantic variables rather than hardcoded values.
This decision had two major consequences. First, it gave engineering a single source of truth for implementation values, eliminating the drift that occurs when design files and codebases diverge. Second, it allowed the system to scale to new terminal configurations and potential theme variations without redesigning the underlying structure.

Token categories:

• Colour tokens: Semantic operational palette — critical, warning, active, success, neutral, equipment-status, exception
• Typography tokens: Scale, weight, and line-height variables for operational density contexts
• Spacing tokens: 4pt grid-aligned spatial system for consistent layout rhythm
• Radius tokens: Component corner radius scale from flat to rounded
• Elevation tokens: Shadow and depth system for modal, popover, and card hierarchy
• State tokens: Interactive states — default, hover, active, disabled, loading, error — standardised across all components
• Motion tokens: Duration and easing variables for operational feedback animations
• Semantic operational tokens: Custom token layer mapping operational meaning (vessel condition, equipment status, alert severity) to visual representation
  

The semantic operational token layer was the most critical innovation. In a terminal environment, colour communicates operational state before the user reads a label. Standardising this vocabulary across the suite meant that an operator moving between Berth and Yard experienced the same ambient operational language — building the kind of intuitive pattern recognition that reduces decision time under pressure.

Component Ecosystem

The component library was built specifically for high-density operational environments — not adapted from a generic design system. Standard component libraries optimise for content readability and form interactions. AICON needed components that could carry operational data at density levels that would break a standard component.

Core operational components:

• Data tables: Multi-sort, filterable, row-selectable, with inline status indicators and configurable column density
• Timeline systems: Drag-and-drop scheduling interfaces with conflict detection, resource overlay, and time-scale controls
• Operational cards: Compact data containers for equipment, vessel, and task status — designed for scanning, not reading
• Status pills and alert chips: Semantic colour-coded, icon-supported state indicators standardised across the suite
• Filtering systems: Persistent, combinable filter panels with state preservation across sessions
• Notification and alert systems: Priority-tiered, contextually anchored alert architecture
• Heatmaps and spatial overlays: Data density visualisation components for yard and terminal map contexts
• Dashboard modules: Composable KPI and analytics tiles for the 360 and management contexts
• Configuration panels: Role-based settings interfaces with clear scope separation

Each component was documented with operational usage guidance — not just visual specifications. Engineers implementing a component received its behavioural contract, not just its pixel dimensions.

Governance and Implementation Quality

The design system was only valuable if it was adopted consistently. Governance was the mechanism that made adoption happen.
I introduced a component review process that required any new component or pattern introduced by an engineering track to be validated against the existing system before implementation. This caught duplications, inconsistencies, and scope creep before they entered the production codebase.
Design QA reviews were structured around implementation parity, comparing delivered builds against design specifications at the component and interaction level, not just the visual level. This shifted the quality conversation from "does it look right" to "does it behave correctly."
Shared documentation in Confluence and Figma gave engineering teams direct access to component specifications, interaction standards, and usage guidelines without requiring designer involvement for every implementation decision. This was essential for maintaining quality at the pace the product roadmap demanded.

The Product Ecosystem

AICON Yard

Operational purpose: Real-time yard visibility, container positioning, and equipment monitoring.

Yard operators manage a spatial environment at a scale and density that no table or list interface can adequately represent. AICON Yard addressed this by making spatial awareness the primary design paradigm — a georeferenced yard view where container blocks, equipment positions, and operational exceptions are visible at the level of detail the decision requires.

The interface operates across three zoom levels: yard overview (zone-level congestion and exception visibility), block level (container occupancy and equipment distribution), and individual stack (container identity, status, and movement history). Each level surfaces only the information relevant to decisions at that scale.

Key design contributions:

Spatial operational visualisation with multi-level zoom and exception-first rendering
Real-time equipment position overlay with status-coded availability indicators
Layered information hierarchy that surfaces anomalies without obscuring normal operations
Container filtering system with persistent multi-attribute filter state
Operational alerting anchored to spatial context rather than separate notification feeds
Strategic value: AICON Yard transformed yard management from a physical-presence task into a system-supported one. Operators no longer needed to walk the yard to verify what the system should already know.

AICON Berth

Operational purpose: Berth planning, vessel scheduling, and pre-arrival coordination.

Berth planning is the most consequential scheduling decision in terminal operations. A poorly planned berth window cascades through crane allocation, yard preparation, gate activity, and SLA performance. AICON Berth was designed around the principle that every conflict should be surfaced before a commitment is made — not after.

The central interaction surface is a drag-and-drop Gantt timeline representing berth occupancy across a rolling time window. The design challenge was not building a Gantt — it was building one capable of carrying the operational complexity of multi-vessel, multi-berth scheduling without becoming illegible under realistic data loads.

Key design contributions:

Timeline-based berth planning interface with vessel-level data density at readable scale
Pre-commit conflict detection surfaced as ambient inline indicators — not modal interruptions
AI recommendation overlay showing proposed berth windows with confidence rationale
Scenario fork capability allowing side-by-side comparison of planning alternatives
AIS-fed ETA propagation with downstream impact recalculation on schedule change
Multi-stakeholder read access for vessel agents and shipping lines
Strategic value: Moving conflict detection from post-commit to pre-commit was the single most impactful UX decision in the product. It changed the emotional register of the tool from accusatory to supportive — and it changed the commercial calculus for terminal operators whose SLA penalties made every avoided conflict financially material.

AICON Dispatch

Operational purpose: Horizontal transport orchestration, equipment assignment, and exception management.

Dispatch coordinators operate in the highest-pressure, shortest-decision-loop context in the terminal. The interface needs to be readable in under three seconds per task, actionable without navigating away from the primary view, and capable of surfacing exceptions before they become failures.

The design challenge in Dispatch was not adding capability — the operational logic already existed. It was reducing the interface to the minimum viable interaction surface for each decision type, and ensuring that exceptions rose above the noise of normal operations without creating false urgency.

Key design contributions:

Task-status table optimised for rapid scanning with semantic colour hierarchy
Exception management system with priority tiers and escalation paths
Equipment swap workflow with conflict validation and confirmation model
Solver recommendation panel with rationale visibility and override capability
Configuration system for dispatch rules and assignment preferences
Shift handover state preservation — operational context survives the handover
Strategic value: Dispatch coordinators described the pre-AICON workflow as "flying blind with both hands full." The design reduced the number of screens required to make a dispatch decision from three to one — and moved exception detection from reactive to predictive.

 AICON 360

Operational purpose: Cross-product operational visibility, KPI monitoring, and executive-level reporting.

AICON 360 was the strategic layer of the suite — the product that made the platform visible to the stakeholders responsible for terminal performance rather than terminal execution. It connected operational data from Yard, Berth, and Dispatch into a unified KPI environment designed for management decisions, not operational ones.

The design challenge was information architecture at the executive level: what does a terminal manager need to see at 8am to understand whether the terminal is performing well, and where do they need to drill to understand why it isn't?

Key design contributions:

Modular dashboard architecture with role-configurable KPI tile sets
Cross-product operational overview with temporal trend visualisation
Drill-down architecture from summary KPI to underlying operational event
Heatmap visualisation for yard performance, overhead rates, and equipment utilisation
Custom reporting configuration for different terminal deployment contexts
Data freshness indicators ensuring executives act on current, not cached, information
Strategic value: Management decisions were previously made on data that was hours old. AICON 360 closed the temporal gap between operational reality and executive visibility — and made it possible for terminal managers to diagnose performance issues without requiring a shift supervisor to compile a manual report.

AICON Vessel

Operational purpose: Vessel operational visibility, status tracking, and coordination workflows.

Vessel management sits at the intersection of pre-arrival planning and live operational execution. AICON Vessel gave teams a single view of vessel status, schedule, cargo profile, and operational activity — replacing a workflow that had previously required cross-referencing four separate systems.

Key design contributions:

Vessel status lifecycle model from pre-arrival through departure
Cargo and operations summary with drill-down to line-level detail
Coordination workflow linking vessel status to berth, crane, and yard allocations
Real-time operational event feed anchored to vessel context
Notification architecture for schedule deviations and operational exceptions
Strategic value: Vessel coordination previously required a phone call for information that should have been a screen view. AICON Vessel made vessel status a self-service lookup for any stakeholder who needed it.

AICON VMT

Operational purpose: Vehicle and transport management inside terminal operations.

VMT addressed the last-mile coordination problem inside the terminal boundary — the orchestration of internal transport vehicles (ITVs, prime movers, terminal tractors) between crane positions, yard blocks, and gate lanes.

The product originated from a field observation, not a product brief. During on-site research, it became clear that ITV allocation decisions were being made based on radio communication and institutional knowledge rather than system data — creating a coordination bottleneck that no existing product addressed. I developed the concept, validated it through stakeholder research, and presented it as a formal product proposal to engineering, product, and C-suite. It was approved for the roadmap.

Key design contributions:

Real-time ITV position overlay on terminal spatial map
Task assignment interface with load balancing visualisation
Equipment utilisation monitoring and idle-time detection
Operational exception flagging for vehicles not executing assigned tasks
Three-layer spatial hierarchy: terminal zone → block → individual vehicle
Strategic value: VMT was the only AICON product that did not begin with a stakeholder brief. It began with a field observation about an unmet operational need. Originating a product feature from research — and securing its roadmap approval — is the clearest demonstration of design leadership contributing to product strategy rather than executing it.

Cross-Product UX Challenges

Data Density vs Operational Readability
The persistent tension across every AICON product was the same: terminal operations generate enormous volumes of data, and operators need to act on the right subset of that data within very short time windows. Showing everything creates paralysis. Showing too little creates blind spots.
The design resolution was consistent across the suite: exception-first rendering as the default state, with progressive disclosure as the mechanism for accessing depth. Normal operations should recede into the background. Anomalies should surface without requiring the operator to search for them.
This principle influenced every information hierarchy decision across all six products.

Cognitive Load Management in Real-Time Environments
High-density operational interfaces are uniquely vulnerable to cognitive overload because the data is live — it changes while the operator is looking at it. A static dashboard can be learned over time. A real-time dashboard requires instant orientation on every view.
The semantic token system was the primary mechanism for managing this. When colour consistently communicates operational meaning, operators can assess the status of a view before reading a single label. The design investment in semantic consistency paid compound interest in operational speed.

Multi-Role Information Architecture
Six products, four primary personas, multiple deployment contexts. The same underlying data needs to be structured differently for an operator making a 10-second decision and a manager doing a weekly performance review.
The role-based information architecture approach — which surfaced different default views, different data densities, and different action sets for each role — was designed into the platform architecture from the beginning. Retrofitting role-based IA onto an existing product is expensive and disruptive. Building it in from the platform foundation made it invisible to users and maintainable by engineering.

Design Leadership

Stakeholder Alignment
On a project with two product managers, six engineers, and operational stakeholders at multiple terminal sites, design alignment required more than good communication. It required structured processes.
I introduced weekly cross-functional design reviews that gave engineering visibility into upcoming design decisions before they became implementation surprises. I ran quarterly roadmap workshops with the PM and CPO to ensure design investment was aligned with product priorities. I maintained a living design decisions log that gave any team member access to the rationale behind every significant design choice — eliminating the tribal knowledge problem that causes consistency to erode as teams scale.

Roadmap Influence
Design input into roadmap decisions was not advisory — it was structural. Research findings from on-site terminal visits directly influenced product sequencing decisions. The VMT concept, originated from field observation, was added to the roadmap based on a design-led proposal. Feature prioritisation workshops gave the design perspective explicit weight alongside commercial and engineering inputs.

Engineering Collaboration
Maintaining implementation quality across multiple engineering tracks was the most operationally demanding part of the role. The design QA process, component review workflows, and shared documentation infrastructure were not process overhead — they were the mechanism that kept the platform coherent as it scaled.
hen engineering capacity constrained the delivery scope of a product feature, I participated in scoping decisions to ensure the minimum deliverable preserved the core interaction value of the design intent. This is the work that rarely appears in portfolios — the negotiation between what was designed and what was shipped, and the judgement required to make that negotiation produce a result worth shipping.

Impact & Results

The AICON Suite moved from concept to actively deployed MVP across multiple terminal sites, with Yard and Dispatch modules in live testing and Berth entering pilot.

7

Product modules scoped and designed within the suite
 

19

UX personas built to validate design decisions
 

0→1

Design function built from scratch - system, process, and team

~40%

Estimated reduction in design-to-engineering rework cycles

Suite coherence

Consistent AI transparency pattern, role-based IA model, and alerting taxonomy across all seven modules, enabling enterprise buyers to evaluate AICON as a unified platform, not a collection of features

Lessons as a design leader

• Platform thinking creates compounding design returns. Every shared component, every standardised interaction pattern, every semantic token pays forward into every product that comes after it.

  Design systems are governance infrastructure, not aesthetic tools. Without adoption processes, component reviews, and implementation QA, a design system is a Figma file that diverges from the product within weeks of shipping.

  Operational interfaces must prioritise cognitive relief over visual sophistication. The measure of success in a high-density, real-time environment is not how much the interface shows — it is how quickly the operator finds what they need.

  Stakeholder alignment is a design deliverable. Workshops, decision logs, and roadmap input are as much design output as screens and prototypes. They are what makes the screens coherent.

  Field research produces product strategy. The VMT concept did not come from a brief. It came from watching people make decisions that the system should have been making easier. Observational research is product strategy research.