UI/UX for the software layer of an automated factory
A global manufacturer had grown by acquisition, and every region had built its own software for running production and logistics. Their robotics worked. The human side, less so. There were six operational roles, three countries, and a different tool with a different mental model at every station. We led the UX strategy that unified it: research on the floor, a service blueprint of the entire dispatch lifecycle, one information architecture, and a design system that became the platform's scalable foundation. It is in daily use across three countries, on floors where automated equipment and people work the same process.
At a glance
Core problem
Six operational roles across multiple factories, split across incompatible regional tools with no shared design language
Andes Path's role
UX strategy, service design, information architecture, design system definition
Key methods
Persona research, service blueprinting, role-based IA, low-fidelity workflow validation
Delivery timeline
Foundation phase of a multi-country platform build — discovery through validated wireframes
Client type
Global manufacturer growing through acquisition, multiple factories, mixed equipment and device fleets
Domain
Industrial manufacturing, factory operations, dispatch and logistics
3
Countries running the unified platform
2
Operational platforms on one design system — Factory Operations, Dispatch, and Logistics
1,000s
Production, logistics, and dispatch tasks moving through the platform daily
What we walked into
The factories ran the same process. The software didn't.
Growth by acquisition had left the company with a fragmented ecosystem of operational tools. Each region had developed its own internal software, its own processes, and its own ways of working. Functionality was duplicated across products, user experiences were inconsistent, and every new capability had to be built several times over. A production operator moving between facilities faced a different interface for the same task.
The people affected were not one audience. Production operators work gloved, standing, at shared kiosks. Supervisors and process users monitor stations and coordinate the day. Logistics coordinators plan multi-stop routes for oversize loads. Drivers work from a phone in a truck, often outside cellular coverage. IT administrators manage permissions across companies, countries, factories, and branches. Six roles, different devices, different permissions, different goals. One platform had to serve all of them without becoming six products.
This is where our work in robotics and physical AI mattered. We build software for operations where the outcome is physical, not a record in a database: fleet telemetry, escalation engines, dispatch infrastructure. These are the last meters of a physical system. When a screen is unclear, a line might stall, a truck waits at a gate, or a module misses its delivery window. We approached the interface problem as a systems problem, because we'd already worked the other side of it.
Frontier design in action
This is way more than pixels
Understanding who runs the floor
We started with the people, not the screens. Working across manufacturing, logistics, and administration, we documented each role's goals, responsibilities, pain points, technical fluency, and daily workflow — including the physical context that enterprise software usually ignores. Those personas became the arbiters for every decision that followed.
Four user groups anchored the research: production floor operators, who need real-time status, error prevention, and minimal interaction; station and process users, who track operational status and manage workflows and priorities; IT teams, who need flexible administration, scalable configuration, and clear system dependencies; and drivers, who need simple workflows, real-time updates, and clear task-completion states from outside the factory.
Blueprinting the dispatch service, end to end
Dispatch was the proving ground: it touches factory operators, coordinators, drivers, customers, and half a dozen backend systems. We mapped the full lifecycle — intake and feasibility, planning and staging, manufacturing and QA, dispatch and loading, transit and support — into a service blueprint spanning customer actions, operations, backstage processes, and the APIs underneath, with pain points and design opportunities pinned to the exact stage where they occur.
The blueprint surfaced problems no screen redesign would have found: inaccurate site layouts causing delivery rejections weeks downstream, part-naming conventions that differed by factory and caused picking errors, drivers arriving at sites with no visibility into gate codes or entry requirements, and proof-of-delivery syncs failing in poor cellular coverage. Each became a concrete design requirement — including offline-first capture in the driver app. It also became the primary alignment tool between Product, Engineering, and Operations: one artifact everyone could point at.
One architecture instead of ten applications
With the ecosystem understood, we defined a single information architecture with multiple modules — dispatch, trips, branches, documents, checklists, notifications, reporting, and administration — under one global shell, with a context selector for company, country, factory, and branch. Users can belong to several of each; context is chosen at login and switchable from the top bar.
Every module is filtered by a role-based navigation matrix: administrators see everything, operators see their stations, drivers get a mobile-only surface scoped to assigned trips, documents, and push notifications. The IA also made system dependencies explicit, so engineering could see coupling before writing code, not after.
A design system as the scalable foundation
Rather than designing each product independently, we established shared components, typography, a color system, iconography, interaction patterns, and layout principles once, and then applied them everywhere. This was structural, not merely cosmetic. A design system is what lets new modules and new regions inherit the platform instead of negotiating with it. It is the reason our unified platform could absorb different local workflows without becoming different products — the original failure mode we were hired to end.
The effect showed up on both sides of the work. Every module now reads as part of the same ecosystem, so a supervisor moving between Factory Operations and Dispatch relearns nothing. Design and development effort both dropped, because a pattern solved once for factory operations is not re-solved for logistics, and not re-solved again per region.
Validating in low fidelity
With the foundation set, we worked through every core workflow in grayscale wireframes — dashboards, scheduling, document management, and dispatch requests — iterating in constant collaboration with engineering, product, operations, and business stakeholders. Workflows were validated before a single production screen was designed.
Frontier design in action
Enterprise software for physical AI is different
Most design work on industrial software starts at the screen and works inward. We started at the physical process and worked outward. Our own engineering history is in the layers underneath: fleet telemetry pipelines, escalation engines for factory incidents, remote operation systems for autonomous machines. None of that was in scope here, and no robots appear in this architecture. What our experience gave us was the ability to read a physical operation correctly before designing anything for it.
That changed the design decisions. Knowing that GPS pings arrive on 30-second intervals shaped how tracking states are displayed. Knowing that QA failures trigger a non-conformance loop shaped where photo evidence lives in the document model. Knowing that drivers lose coverage at remote sites made offline-first proof of delivery a requirement. Design strategy and systems engineering were combined as teammates.
The result is an interface system that operators trust, because it never contradicts what's actually happening on the floor.
What we shipped
One foundation, every operational surface
Like every engagement, this one left the client in full control: the research, the architecture, and the design system are theirs, documented and adopted by their internal teams.
Unified operational platform
One product foundation spanning factory operations and dispatch & logistics, with different workflows without different products, deployed across three countries.
Role-based information architecture
Eleven modules under a global shell with company, country, factory, and branch context. Every surface is filtered by a role-permission matrix, from full admin to mobile-only driver.
Shared design system
One design language across Factory Operations and Dispatch & Logistics — components, type, color, and interaction patterns defined once and adopted across products, cutting duplicated design and engineering effort between regional teams.
Service blueprint and workflow library
The end-to-end dispatch blueprint and validated wireframe set, kept as living alignment artifacts between product, engineering, and operations.
