Blueprinting a Complex Intermodal Platform
Before the Roadmap
When BNSF and J.B. Hunt needed to define the future of a premium, service-sensitive intermodal shipment platform, the challenge was bigger than interface design. The work required a blueprint-first approach that connected customer needs, operations, systems, data, ownership, engineering scope, and executive decision-making before major development investment. The bigger outcome wasn't the MVP. It was a repeatable model for how complex enterprise initiatives should begin.
The whole engagement, in thirty seconds.
Full case study below · about a 14 minute read
- Organization
- BNSF Railway × J.B. Hunt Transport
- Industry
- Transportation & Logistics
- My Role
- UX & Innovation Lead Consultant
- Engagement
- 8 weeks — discovery through executive readout
- Groups Involved
- Product · Engineering · Operations · Business Analysis · Executive
- Outputs
- Holistic Enterprise Blueprint · Control Tower prototype · MVP definition
Screens were being designed before anyone could see how the system actually connected — across two companies, their teams, workflows, systems and data.
Blueprinted the customer journey, operational workflows, supporting systems and ownership into one shared view, before major development investment.
An MVP definition leadership could fund — and a repeatable model for how complex enterprise initiatives should begin.
The Quantum platform and the challenge of designing without a map
BNSF Railway and J.B. Hunt were investing in Quantum — an intermodal shipment management platform designed to improve how freight customers tracked, managed, and coordinated container moves across the rail network. The Experience Design team embedded in BNSF's Fort Worth Innovation Center was responsible for designing the customer-facing experience.
The team was capable and motivated. The problem wasn't execution — it was orientation. Screens were being designed based on partial information about how the system actually worked: which teams owned which data, how operations translated into customer-visible events, where BNSF processes and J.B. Hunt processes intersected, and which pain points were genuinely solvable at the product level versus deeper operational or systems issues.
Without a shared map, decisions about what to build, when, and why were harder to make — and harder to align across two large organizations with different cultures and internal priorities.
Designing a complex enterprise product without a shared foundation.
The design team could see customer needs and could see some system capabilities — but the layers in between (operations, data, ownership) weren't mapped. Every design decision carried hidden assumptions.
BNSF and J.B. Hunt each had their own processes, data definitions, and customer relationships. There was no shared language or shared discovery process for surfacing where those worlds overlapped or conflicted.
The team included Business Analysts responsible for requirements — but without structured UX research methods, discovery was largely informal, and requirements often reflected assumptions rather than validated customer insight.
Leadership had no real-time or structured view of operational state across the Quantum shipment lifecycle. Decision-making operated on lagging indicators and anecdotal reporting rather than a live operational picture.
The engagement had a fixed horizon. Discovery, blueprinting, cross-company alignment, analyst training, prototype development, and executive readout all needed to happen within a compressed but productive timeframe.
Some of what was being designed assumed operational and systems capabilities that didn't fully exist yet — or that were owned by teams not yet part of the conversation. Recognizing and naming these gaps was itself a valuable output.
A better way to start enterprise projects.
The MVP was important. But the breakthrough was the process. The Holistic Enterprise Blueprint gave engineering and product leadership a way to see the project before building it.
Instead of starting with isolated requirements or screens, the team could see the customer journey, operational handoffs, systems, data dependencies, ownership gaps, and decision points in one connected view. Engineering teams are often asked to estimate and build before the organization understands the workflow, dependencies, and ownership. Here, leadership could see it first — and use it as a model for how future initiatives could begin.
- Gave engineering and product leadership clear visibility into scope, complexity, and what actually needed to be built.
- Made operational dependencies, data questions, and ownership gaps visible before development.
- Separated MVP needs from future-state opportunities.
- Made budgeting and planning conversations more informed and realistic.
- Reduced the risk of building from incomplete requirements.
- Created a repeatable, blueprint-first model for starting future initiatives.
"This was amazing! This is a model for how we should kick off every project."
Consulting-led discovery that connected what the team already knew.
The methodology introduced here — mapping customer experience, operations, systems, data, AI opportunities, ownership, and strategy into a unified picture — became the foundation for the Holistic Enterprise Blueprint™ framework applied in subsequent engagements.
Learn about the framework →The engagement was structured around one core idea: before you design solutions, you need to understand the full system you're designing within. Not just the user-facing touchpoints — but the operational processes, systems, data flows, ownership structures, and strategic priorities that together determine what's actually buildable and what will actually matter to customers.
We introduced a consulting-led discovery approach that combined service blueprinting, systems blueprinting, and systems thinking — applied simultaneously to the customer-facing experience and the internal operational landscape across both BNSF and J.B. Hunt.
This wasn't research for its own sake. Every discovery session was designed to produce artifacts — maps, blueprints, gap analyses — that the team could use directly to make better product decisions and that leadership could use to understand where the initiative stood and where to invest next.
Three disciplines working together to build the picture.
Mapped the end-to-end customer journey across the Quantum shipment lifecycle — from booking through delivery — and connected each customer-facing moment to the backstage processes, systems, and people responsible for enabling it. Made invisible dependencies visible.
Mapped the technology landscape: which systems touched which data, how information flowed between BNSF and J.B. Hunt platforms, where data was owned versus shared versus duplicated, and which system boundaries created friction for users and operators alike.
Facilitated structured analysis of how the components of the Quantum ecosystem — customer behaviors, operational processes, systems, data flows, and organizational ownership — created feedback loops, constraints, and leverage points that pure UX methods wouldn't surface.
Facilitated structured discovery sessions that brought BNSF and J.B. Hunt stakeholders into the same room with the same artifacts. Created shared understanding of where processes aligned, where they conflicted, and where assumptions on one side were invisible to the other.
Embedded UX research methods — structured interviewing, synthesis, journey mapping, validation techniques — directly into the Business Analyst workflow. Built internal capability that continued to produce value after the engagement concluded.
Built the Quantum Control Tower — an operational visibility prototype designed to give leadership a structured, real-time view of shipment state and operational health across the lifecycle. Designed to inform strategy, not just report status.
Why Traditional UX Discovery Wasn't Enough
In complex enterprise environments, customer pain points rarely come from a single screen. They often come from handoffs, systems, data gaps, operational constraints, unclear ownership, or disconnected initiatives. For Quantum, the discovery process needed to show the full ecosystem — not just the interface.
Mapped the customer, employee, and operational journey across every stage of the Quantum shipment lifecycle.
Mapped the applications, data, integrations, and reporting dependencies behind the experience across both organizations.
Helped stakeholders see how decisions in one part of the ecosystem affected operations, customers, systems, and business outcomes.
Mapping the Shipment Lifecycle Across Teams
Instead of treating the Quantum experience as a single interface, we mapped the shipment lifecycle across customer actions, J.B. Hunt operations, BNSF rail operations, terminal operations, and the systems/data layer. This helped reveal handoff gaps, risk points, and the operational dependencies behind the customer experience.
Mapping the Ecosystem Behind the Experience
After mapping the service experience, we connected it to the systems, applications, integrations, reporting, ownership, and stakeholder groups that made the experience possible. This helped teams understand where data moved, where accountability changed hands, and where duplicate initiatives or hidden dependencies could emerge.
What the Blueprinting Work Revealed
Where responsibility shifted between customer, logistics, rail, terminal, and support teams — and where those shifts created friction, delay, or invisible risk in the shipment lifecycle.
Which applications, integrations, reports, and data sources supported each stage of the experience — and where ownership, availability, or data quality constraints affected what was actually buildable.
Where teams could avoid rebuilding capabilities that already existed elsewhere — or where parallel efforts were creating conflicting data models and ownership structures without realizing it.
How a shared ecosystem view helped clarify what the MVP needed to support first — grounded in operational reality and organizational readiness, not feature instinct or stakeholder preference.
"The biggest shift was moving from 'What screens should we design?' to 'How does the full service, system, and operating model need to work?'"
That shift helped the Experience Design team operate more like an internal consulting group — using blueprinting, stakeholder facilitation, and systems thinking to clarify product direction before implementation.
Explore the Holistic Enterprise Blueprint Framework →One connected view, from customer to budget.
The Holistic Enterprise Blueprint connects the layers most discovery efforts examine in isolation. Seeing them together is what let leadership understand scope, dependencies, and budget implications before committing to a build.
The layers below are a Quantum-specific application of the Holistic Enterprise Blueprint™, adapted to the needs of that initiative — data and metrics were mapped as separate layers, and the closing layer carried budget alongside the roadmap. The core framework stays fixed; engagement blueprints adapt to the project. See the seven core layers.
Eight weeks, structured to answer what should be built — and why.
This wasn't a sprint to produce screens. It was structured to help the organization understand what should be built, why it mattered, what dependencies existed, and how to plan the work. Every week produced an artifact the team could use immediately — the same repeatable pattern I bring to complex initiatives.
Reviewed the existing shipment tracking portal, established business context, and aligned stakeholders across both organizations on goals and scope.
Conducted and supported customer research and stakeholder interviews across executive, dispatch, crew, drayage, and customer-facing roles.
Mapped the shipment lifecycle across customer actions and backstage operations, connecting each moment to the teams and systems behind it.
Completed the systems landscape — data flows, integration points, and ownership gaps — surfacing dependencies that affected what was actually buildable.
Translated validated discovery into prioritized opportunities, separating MVP needs from future-state ambitions based on impact and organizational readiness.
Facilitated a participatory dashboard visioning exercise — executives, business, operations, and product participants sketched their ideal visibility views — then shaped those inputs into the control-tower-style MVP concept.
Validated the prototype and priorities with stakeholders, refined the direction, and aligned leadership from both organizations around a shared plan.
Presented findings, the MVP definition, and the prioritized roadmap in a structured executive session — and left behind a repeatable model for starting future initiatives.
Turning stakeholder assumptions into visible product inputs
As part of the MVP process, I facilitated a participatory dashboard visioning exercise where executives, business stakeholders, operations teams, and product participants sketched their ideal visibility views. The exercise revealed what each role needed to see, which decisions the dashboard needed to support, and where visibility gaps existed across the shipment lifecycle.
These sketches informed the control-tower-style MVP concept and helped align executive visibility, operational monitoring, exception management, and customer communication needs before prototype development.
- Captured executive mental models early.
- Clarified decision-support needs before design.
- Made hidden assumptions visible.
- Helped align stakeholders around MVP priorities.
- Gave engineering stronger inputs for scope and budget conversations.
What the engagement changed about how the team worked.
| Before the Engagement | After the Engagement |
|---|---|
| Screen-first design without a cross-layer picture of the system | Blueprint-first discovery connecting experience, operations, systems, and data before any screen was committed |
| Discovery conducted informally, based on availability and individual relationships | Structured UX research process embedded into the Business Analyst workflow and repeatable for future cycles |
| BNSF and J.B. Hunt operating with separate assumptions about shared processes | Cross-company discovery workshops established a shared understanding of process handoffs, data ownership, and mutual dependencies |
| Requirements based on stakeholder assumptions rather than validated evidence | Evidence-based requirements grounded in documented user research, process mapping, and cross-functional validation |
| No executive view of operational state across the Quantum lifecycle | Quantum Control Tower prototype providing structured operational visibility for leadership decision-making |
| Product priorities negotiated without a shared strategic foundation | Prioritized MVP definition aligned to validated discovery, organizational readiness, and strategic sequence |
Quantum Control Tower
An operational visibility prototype built to give BNSF and J.B. Hunt leadership a structured, real-time view of shipment state and operational health across the Quantum intermodal lifecycle. Designed to support strategic decision-making — not just status tracking.
Interactive prototype · For demonstration purposes · Built during the BNSF × J.B. Hunt engagement
The blueprint made the initiative clear enough to estimate, budget and staff.
By defining the MVP and making the customer journey, operational dependencies, systems, data and technical requirements visible in one shared view, engineering and development could more confidently assess level of effort. That clarity also gave leadership a stronger basis for understanding budget needs and determining the roles and expertise required to develop the solution further.
The prototype did not produce that on its own. Knowledge had been fragmented across teams and systems; it was discovery, blueprinting, MVP definition and cross-functional participation together that made the ecosystem visible — and the Control Tower that made the result concrete enough for engineering and leadership to act on.
- 01What are we actually building?
- 02What will it take to build it?
- 03Who do we need to build it?
That is the value of blueprinting before a build: reducing delivery risk while the cost of changing direction is still low.
Have a complex initiative that needs a clear starting point?
Discuss an InitiativeThe blueprint informed what came next — including a portal that achieved 94% customer satisfaction.
The work produced in this engagement — the cross-layer blueprint, the validated product priorities, the shared discovery process — contributed to the strategic foundation that BNSF carried forward in developing its broader customer portal strategy.
In public pilot reporting, that portal achieved 94% customer satisfaction. We don't take credit for that outcome — it was built by a large team over a sustained period. But the discovery, alignment, and direction established in this engagement helped shape the foundation it was built on.
Based on publicly reported statistics from BNSF's customer portal pilot program. The Quantum engagement contributed to the strategic and product foundation this initiative was built upon.
What was delivered, and what it made possible.
A structured, evidence-based product definition with prioritized roadmap — completed within the fixed engagement window and ready for executive alignment.
Structured research methods embedded into the BA workflow — creating internal capability the team continued to use independently after the engagement.
A repeatable framework for shared discovery between BNSF and J.B. Hunt — surfacing dependencies, handoffs, and assumptions that had previously been invisible to both teams.
A complete cross-layer map of the Quantum ecosystem — customer experience, operations, systems, data, ownership, and strategic priorities — in a single unified artifact.
An operational visibility prototype giving leadership a structured view of shipment state and operational health — designed to inform strategy and support executive decision-making.
The discovery, blueprint, and product direction from this engagement contributed to the strategic foundation of a BNSF customer portal that achieved 94% satisfaction in public pilot reporting.
The biggest risk isn't poor design. It's building before you understand the system.
For enterprise teams building complex platforms, AI tools, analytics products, modernization efforts, or transformation programs, the bigger risk is building before the organization has a shared understanding of the customer journey, operational dependencies, data ownership, decision rights, engineering scope, budget implications, and adoption model. A blueprint-first start makes that understanding visible before serious money is committed.
Start complex projects with a
blueprint, not assumptions.
If your team is modernizing a platform, launching an AI-enabled workflow, or trying to align product, engineering, operations, data, and customer experience, I can help you map the system before you commit to the roadmap.