Operations Intelligence
Platform
A B2B operations intelligence platform for mid-market logistics and distribution teams. Workflow automation, AI-driven recommendations, real-time KPI monitoring, and integration across fragmented systems. Built as a high-fidelity prototype for active client sales and investor demos.
Role
Lead Product Designer
Collaborator
Founding team (4 members)
Timeline
Apr 2026 — May 2026
Status
Live Prototype
Cross-functional Team
Solo designer · 3 collaborators
Tools
0 weeks
build time
0 pages
screens built
0 pivot
mid-build vertical pivot
Product Walkthrough
A guided walkthrough of the platform: dashboard, analytics, workflow builder, and integrations.
The platform was built as a fully functional React prototype demonstrating operations intelligence capabilities across logistics and distribution workflows. Every screen shown here was built in code and used in live client discovery calls and sales demos.
Want a live walkthrough of the full product? Get in touch and I will walk you through every module in a 30-minute session.
Building the product while discovering the market.
The engagement started with a founding team that had already done the hard work. They had sat with 40 to 60 staff members per client audit, mapping existing processes from scratch, and identifying that mid-market logistics operations were running fragmented systems with no connective layer between them.
The initial brief was not a feature list. It was a problem space: operations teams at companies doing $1M to $25M in revenue could not afford enterprise ERPs but had outgrown spreadsheets and basic integrations.
I was the sole designer on this project, embedded directly with the founding team. All UX decisions, design system creation, and front-end prototype implementation were mine from day one.
The first design conversations were working sessions, not briefs. The founding team brought qualitative research from manufacturer and distributor site visits. A 26-page discovery workbook captured pain points, ideal states, system utilisation gaps, and competitive pricing benchmarks from ERP vendors.
My job was to translate that research into a product that could run in a demo before any backend existed.
The most important early constraint: the prototype had to be fully functional in code, not a Figma clickthrough. It was going to be shown to real clients who had already received quotes from enterprise vendors. The visual fidelity and interaction quality had to match that context.
Discovery phase
Founder conducted site visits with 40-60 staff per audit
Scope defined
26-page discovery workbook capturing pain points and ideal states
Prototype brief
High-fidelity prototype required for live client demos
Four weeks. One pivot. One modular architecture.
The project ran across four build phases, from design system foundation to a structured client feedback cycle. The four phases below trace what happened inside each.
01
Design System
Component library before any screens
Established color palette, typography system, spacing scale, component patterns, and animation standards. Built the full component library in React before designing any screens.
02
Vertical Pivot
Full content rebuild, zero architecture changes
Mid-build, founder discovery confirmed logistics and distribution as the higher-value market. The entire content layer was rebuilt without touching the component architecture.
03
Feature Build
6 analytics tabs, workflow canvas, integrations
Dashboard KPI system, six analytics tabs, drag-and-drop workflow builder canvas, integrations panel, and AI assistant layer. Every data layer typed with TypeScript interfaces.
04
Client Feedback
Two feedback rounds, structured UX audit
Two formal feedback rounds. Hub filter reactivity, modular KPI system, workflow clone and edit, and step locking all added. Structured audit pass normalised interaction signifiers.
The gap between tools that no integration could fill.
Five systems. No connective layer. One team holding it together manually.
Mid-market logistics companies were running four to six operational systems daily: warehouse management, transport management, ERP, carrier portals, email, and spreadsheets. None of them talked to each other in any meaningful way. The moment a shipment or process crossed from one tool to another, visibility was lost.
The cost of this was not abstract. One missing component in a production line creates a bottleneck. Carrier overbilling goes uncaught because reconciliation is manual. Claims processing has no structured workflow. Dispatch decisions get made on the basis of data that is hours old. The people carrying this cost were operations managers and dispatch leads who could not articulate the root cause because the pain was systemic, not localised to any one tool.
Existing solutions fell into two categories. Enterprise ERPs were expensive, slow to implement, and required teams of consultants to run. Simpler integration tools handled basic connections but had no intelligence layer and no workflow visibility. There was nothing between them that could be deployed in weeks, cost a fraction of enterprise pricing, and still give operations teams real-time intelligence with AI recommendations attached.
Core insight cards
Operations managers could not see inside their own operations
Neither the founding team's client participants had a live view of what was happening in their operations. They found out about problems after they had already caused downstream damage. The platform's core value proposition was making the invisible visible in under 30 seconds.
The problem was ERP plus processes, not just ERP
Every company had the same fragmentation but prioritised differently based on the current quarter's problems. The real insight was that the platform's value was not in replacing any single tool but in being the connective intelligence layer between all of them.
Implementation speed was the real differentiator
The comparison was not feature-for-feature against enterprise software. It was weeks-to-value against months-to-value. The prototype had to demonstrate that the platform could be running in a client environment within weeks, not after a six-month implementation project.
The right users. The wrong assumptions about what they needed.
Research was conducted through founder-led site visits: qualitative, ethnographic-style observation sessions with staff at manufacturing, distribution, and logistics companies. The founding team sat with teams of 40 to 60 staff per engagement, mapping processes from the ground up rather than asking structured questions. This produced insights that surveys would never have surfaced.
The expectation that clients know their own problems was wrong. Most could not articulate root cause because the pain was systemic.
Three findings
The persona was right. The problem framing was wrong.
Operations managers and dispatch leads were the right primary users. But the initial assumption was that they understood their own pain points. They did not. The pain was systemic across tools, so no individual could see the full shape of the problem from inside it. The product had to teach users to see their own operations differently, not just give them a better interface.
Investment-backed companies had a stakeholder problem the product needed to account for
Several target companies had multiple stakeholders with equal authority. Design decisions that were purely about the operations user missed the reality that the platform would also be evaluated by finance, IT, and investors simultaneously. The dashboard ROI tab and the CSV export capabilities were direct responses to this finding.
Competitive pricing data changed the positioning entirely
Real pricing data gathered from ERP consultants at major firms showed enterprise implementations ranging into seven figures with multi-year timelines. This was not just a competitive differentiator. It was the entire reason the market existed. The prototype had to look and feel at enterprise quality to make the pricing gap meaningful.
The decisions that were actually hard.
The technically complex parts of this build were expected. The genuinely hard design decisions were the ones where two valid approaches existed and the choice had real consequences for how the product would be used.
Bento grid dashboard over standard card layout
The options
Three layouts were evaluated: a standard card grid, a table-based view, and the bento grid.
The choice
The bento grid. Operations dashboards need to show data at different levels of detail simultaneously. A KPI tile, a trend chart, and a workflow status panel all needed to coexist at different visual weights without the user navigating between tabs.
Why it matters
The bento grid makes every piece of information a first-class element with its own visual real estate. Nothing important gets buried under a uniform card height.
Modular KPI system over hardcoded logistics KPIs
The options
Hardcode logistics KPIs directly into the dashboard and analytics components, or build a swappable KPI layer driven by an industry selector.
The choice
The modular approach. Feedback from the technical team raised the question of whether the platform could support other verticals with different KPI sets, so an industry selector drives a swappable KPI layer.
Why it matters
It was more complex to build but turned out to be a fundamental product insight. The platform is not a logistics tool. It is an operations intelligence layer that happens to be going to market through logistics first.
Feature flags over deletion during the vertical pivot
The options
Delete the components made obsolete by the pivot from the earlier real estate scope, or gate them behind feature flags and keep them in the codebase.
The choice
Feature flags. Hidden components stayed in the codebase, gated off but fully functional.
Why it matters
This preserved architectural optionality, prevented irreversible loss of built UI, and meant the platform could re-enter other verticals without a rebuild.
Step locking on active workflow runs
The options
Hard-lock the entire canvas while a pipeline runs, or design a visual state system that distinguishes viewing an active run from editing a draft workflow.
The choice
Edit mode signifiers. Three canvas states, draft, running, and locked, share the same visual language but communicate different affordances clearly.
Why it matters
Users are prevented from editing steps mid-run without the canvas ever feeling locked or broken. The current state is legible at a glance, and clone and edit gives a safe path to iterate on a running workflow.
One platform. Six surfaces. Zero manual reconciliation.
The platform deployed as a fully functional prototype across six primary surfaces, all sharing a single typed data layer and design system.
Dashboard
Six logistics KPI tiles with hub and time range filter reactivity. Every KPI updates simultaneously on filter change.
Analytics
Six filter-reactive tabs covering KPI overview, automation trends, hub performance, workflow metrics, ROI tracking, and predictive forecasting.
Workflow Builder
Drag-and-drop canvas with typed nodes, SVG connectors, step locking for active runs, clone and edit with edit mode signifiers.
Integrations
12 connected logistics integrations with health status indicators, usage metrics, and reauthentication flow.
Insights
Modular KPI system with industry selector. Designed to transfer across verticals without rebuilding the component layer.
AI Assistant
Embedded assistant with three display states. Surfaces logistics-specific recommendations contextually across all pages.
A prototype that runs in live sales calls.
0
formal feedback rounds
Live
prototype status
Sales-ready
demo quality
The prototype is live and being used as the primary sales tool in client discovery calls and investor demos.
It has been through two formal feedback rounds with the founding team, producing measurable iteration on filter reactivity, KPI architecture, and workflow interaction patterns.
The business context gives this project a different weight than most prototype work. The platform is being shown to operations teams that have already received quotes from enterprise vendors. The quality of the design directly influences whether deals close. That stakes level shaped every decision from typography scale to data interaction speed.
After the final review, the prototype was recognised as a living foundation rather than a final deliverable. The modular architecture means every iteration from this point is an extension, not a rebuild.
What this project reinforced.
Building a full-fidelity prototype under real sales pressure compressed the feedback loop in a way that typical design projects do not. Client reactions during calls became immediate design inputs. The gap between designing something and seeing how it performs in front of a real stakeholder collapsed to hours, not weeks.
01
Modular architecture is a design decision
The vertical pivot was only possible because every component was designed to be content-agnostic from the start. The design system carried the product through a fundamental scope change without breaking.
02
Typed data layers should come first
The filter reactivity work in the final phase would have been faster if the data separation had been established in Phase 1. Architecture decisions made under time pressure carry forward cost.
03
Watch someone use it to close a deal
Usability testing in a controlled setting tells you one thing. Watching a prototype perform in a live sales call tells you something entirely different about what matters and what does not.
Phase 2 roadmap