SP

Good afternoon.

SP

Enter password to view case study

Back to projects

Back to projects

Modernizing a Legacy Production Planning Platform

Project Overview

Project Overview

Enterprise SaaS

Live in production

Web Application

Internal Platform

Location

Fargo, ND

Role

Sr. UX Designer

Year

2023-24

Duration

~18 months

Users

200+ across US and Mexico

Overview

A legacy production planning platform powered daily manufacturing operations through two interconnected systems managing forecasts and production schedules. Modernizing this workflow meant improving how these systems worked together without disrupting the production decisions teams relied on every day.

A legacy production planning platform powered daily manufacturing operations through two interconnected systems managing forecasts and production schedules. Modernizing this workflow meant improving how these systems worked together without disrupting the production decisions teams relied on every day.

A legacy production planning platform powered daily manufacturing operations through two interconnected systems managing forecasts and production schedules. Modernizing this workflow meant improving how these systems worked together without disrupting the production decisions teams relied on every day.

Problem
A legacy platform that no longer matched how planners worked.

John Deere’s production planning relied on a legacy platform that had evolved over years without being designed around how planners actually worked. Critical functions were buried, forecasting and planning workflows overlapped, and planners relied on spreadsheets and external tools to complete everyday tasks.

Solution
Redesign the workflow. Rebuild the platform. Earn the trust.

The redesign focused on fixing what was breaking the workflow first, then rebuilding the platform around how planners actually make decisions. Because stakeholders managing billion-dollar production decisions couldn’t abandon existing tools overnight, the transition was designed to reduce dependency gradually rather than force an abrupt cutover.

Impact
Transforming a fragmented workflow into a trusted planning platform.

Operational efficiency improved by ~30%, and 200+ planners across the US and Mexico transitioned from the legacy system to the redesigned platform. Most of the planning decisions that once required spreadsheets, external documents, and multiple tools could now be made directly within a single platform.

First
Second
Before
After

Before — Legacy platform | After — Redesigned platform

Research

Research

Problem

How do you redesign a system responsible for billions in production decisions — without breaking the trust of the people using it?

John Deere’s production planning relied on a legacy platform that had accumulated years of complexity without ever being designed around how planners actually worked.

Critical functions were buried deep in the interface. Two fundamentally different workflows — forecasting and production planning — were forced into the same environment. The freeze system governing billion-dollar production decisions was poorly understood even by stakeholders responsible for it.

Planners had learned to cope. Five browser tabs open at all times. External documents constantly referenced. Excel used whenever they needed actual clarity.

The system technically worked — but only because users had learned how to work around it.

How the System actually worked

This wasn't one platform. It was two systems held together by manual effort.

daily

Forecasters update the Excel forecast

The Bottleneck

Manual file upload to legacy tool

Processing

Legacy tool converts forecast into production plan

Daily

Planners adjust and finalize the production plan

Why this mattered: Billions of dollars in production decisions moved through this workflow every day. Any disruption had direct downstream consequences on manufacturing. That's why stakeholders couldn't simply switch systems — and why every design decision had to make the transition feel safe, not just possible.

Research

If the tool had existed for decades — why was it still broken?

Because no one had mapped what the work actually looked like. The inefficiency had become so normalized it was invisible to everyone inside it.

9

In-depth contextual interviews with planners and forecasting leads across US and Mexico

~1K

Data points synthesized into 12 core workflow and usability insights

$B

In daily production value running through this workflow — the constraint shaping every decision

2

Systems — Disconnected tools never designed to work together

The reframe: The problem wasn't just that the platform was hard to use. It was that the platform was never the real system. The real system was Excel + legacy tool + the people manually bridging the gap between them every single day.

The reframe: The problem wasn't just that the platform was hard to use. It was that the platform was never the real system. The real system was Excel + legacy tool + the people manually bridging the gap between them every single day.

The reframe: The problem wasn't just that the platform was hard to use. It was that the platform was never the real system. The real system was Excel + legacy tool + the people manually bridging the gap between them every single day.

Key insights
  • 01 — Two Workflows, One Confusing System
    Planners and forecasters were working in the same environment despite performing entirely different tasks.

    "We never use that function, think it could be used for forecasting, I have no idea why is it here. We are told not to use it"

    What this meant: The first structural decision was separating the two workflows into clearly defined tabs — giving each user group a space built for them, not shared with everyone else.

  • 02 — Normalized Inefficiency
    Planners had built their own system on top of the system.

    “I’ve got 5 tabs open while I’m working all the time.”

    "If you cannot multitask you cannot be an efficient planner"

    What this meant: The tool wasn’t supporting the work — it was forcing planners to compensate for it. Every workaround was a signal of a missing or broken capability.

  • 03 — Context Lost at the Moment It Mattered Most
    Comparing planning periods for. parts across or within sites required leaving the system entirely.

    "It would be easier for me to just see the parts and site together — I've to keep going back and forth"

    What this meant: Decision-making required side-by-side context. Comparison tools, persistent details panels, and in-platform data visibility were essential for supporting real planning workflows.

  • 04 — A Freeze System Nobody Understood
    Two freeze mechanisms existed with different calculations and no shared definition of when to use each.

    "I only use this freeze function, I've no idea what the other one does"

    "No you cannot remove either of the freeze fucntions"

    What this meant: This wasn’t just an interaction problem — it was a product definition problem. Before redesigning the interface, the logic behind the freeze system had to be clarified and aligned with stakeholders.

  • 05 — No Visibility During Upload Processing
    Forecast updates ran through a manual upload at a fixed time each day, with no system visibility.

    " We just stop working at 3. You never know when the process would start"

    What this meant: Planners often stopped updating plans to avoid conflicts. No one was asking to fix the upload process because no one believed it could be fixed. Making that hidden time cost visible became the first design move.

  • 06 — Risk-Driven Resistance
    Stakeholders weren't blocking change. They were protecting operations.

    "If something goes wrong in planning, that's a production line problem. We can't afford experiments."

    What this meant: Resistance wasn’t about rejecting change — it was about protecting operations. Adoption had to be designed as carefully as the interface itself, introducing improvements gradually rather than forcing teams to abandon Excel overnight.

01 — Two Workflows, One Confusing System
Planners and forecasters were working in the same environment despite performing entirely different tasks.

"We never use that function, think it could be used for forecasting, I have no idea why is it here. We are told not to use it"

What this meant: The first structural decision was separating the two workflows into clearly defined tabs — giving each user group a space built for them, not shared with everyone else.

02 — Normalized Inefficiency
Planners had built their own system on top of the system.

“I’ve got 5 tabs open while I’m working all the time.”

"If you cannot multitask you cannot be an efficient planner"

What this meant: The tool wasn’t supporting the work — it was forcing planners to compensate for it. Every workaround was a signal of a missing or broken capability.

03 — Context Lost at the Moment It Mattered Most
Comparing planning periods for. parts across or within sites required leaving the system entirely.

"It would be easier for me to just see the parts and site together — I've to keep going back and forth"

What this meant: Decision-making required side-by-side context. Comparison tools, persistent details panels, and in-platform data visibility were essential for supporting real planning workflows.

04 — A Freeze System Nobody Understood
Two freeze mechanisms existed with different calculations and no shared definition of when to use each.

"I only use this freeze function, I've no idea what the other one does"

"No you cannot remove either of the freeze fucntions"

What this meant: This wasn’t just an interaction problem — it was a product definition problem. Before redesigning the interface, the logic behind the freeze system had to be clarified and aligned with stakeholders.

05 — No Visibility During Upload Processing
Forecast updates ran through a manual upload at a fixed time each day, with no system visibility.

" We just stop working at 3. You never know when the process would start"

What this meant: Planners often stopped updating plans to avoid conflicts. No one was asking to fix the upload process because no one believed it could be fixed. Making that hidden time cost visible became the first design move.

06 — Risk-Driven Resistance
Stakeholders weren't blocking change. They were protecting operations.

"If something goes wrong in planning, that's a production line problem. We can't afford experiments."

What this meant: Resistance wasn’t about rejecting change — it was about protecting operations. Adoption had to be designed as carefully as the interface itself, introducing improvements gradually rather than forcing teams to abandon Excel overnight.

Design Process

Design Process

USER group

Who It Was Designing For

Two groups depended on this system every day — but the platform had never been designed around either of them.

Master Planners

Managing production schedules across a 16-week window — searching for parts, adjusting quantities, and locking decisions that fed directly into manufacturing.

Adjust MPS Qty

Search Parts

Plan production

Freeze Dates

Validate Forecast

USER group

Data needed to make decisions was never in one place. Freeze states were visually ambiguous. Comparing two periods meant exporting to Excel. A routine session meant five tabs open, constantly copying data manually.

Their frustration wasn't the complexity of the work — it was how much effort the system demanded just to do it.

Their frustration wasn't the complexity of the work — it was how much effort the system demanded just to do it.

Daily workflow

  • Search by part number

  • Review forecast quantities

  • Open 5 tabs, copy data manually

  • Attempt to freeze — state unclear

  • Attempt to freeze — state unclear

  • Wait — no visibility into status

Order Fulfillment Specialists

Managing forecast accuracy across the entire product catalog — updating quantities, coordinating uploads, and keeping planners informed of every change.

Manage Daily Forecast entries

Track Changes

Coordinate Upload Process

Loop in Planners

USER group

Their frustration wasn't the forecast work itself — it was the communication overhead every small correction created across three people before it reached the system.

Their frustration wasn't the forecast — it was everything that happened after they updated it.

Their frustration wasn't the forecast — it was everything that happened after they updated it.

Daily workflow

  • Update forecast in Excel

  • Coordinate with Admin for upload

  • Manually notify Planners of changes

  • Cannot function while the upload process is running

  • Repeat entire loop for minor fixes

  • Repeat entire loop for minor fixes

The System Tension: Both groups depended on each other — yet operated with almost no shared visibility. Changes made in Excel only reached planners after manual uploads, creating friction at every point where the workflows intersected.

The System Tension: Both groups depended on each other — yet operated with almost no shared visibility. Changes made in Excel only reached planners after manual uploads, creating friction at every point where the workflows intersected.

Understanding the System

Before redesigning the interface, I needed to understand the workflow behind it.

Early research revealed that many of the challenges weren’t simply UI problems. They were symptoms of a system that had evolved over time without a clear shared understanding of how planning actually worked. Forecast data moved across multiple systems before becoming a finalized production plan, with manual uploads and freeze points shaping when planners could intervene.

To make sense of this ecosystem, I stepped back and created a process map that visualized how forecasts moved through the system, where planners interacted with the data, and where friction occurred. The map surfaced key breakdown points — manual uploads, moments where data froze, and places where planners relied on external tools to complete their work.

More importantly, it became a shared artifact that aligned stakeholders, engineers, and product owners around the same understanding of the system, helping guide the redesign that followed.

USER group

Who It Was Designing For

Two groups depended on this system every day — but the platform had never been designed around either of them.

Master Planners

Managing production schedules across a 16-week window — searching for parts, adjusting quantities, and locking decisions that fed directly into manufacturing.

Adjust MPS Qty

Search Parts

Plan production

Freeze Dates

Validate Forecast

USER group

Data needed to make decisions was never in one place. Freeze states were visually ambiguous. Comparing two periods meant exporting to Excel. A routine session meant five tabs open, constantly copying data manually.

Their frustration wasn't the complexity of the work — it was how much effort the system demanded just to do it.

Daily workflow

  • Search by part number

  • Review forecast quantities

  • Open 5 tabs, copy data manually

  • Attempt to freeze — state unclear

  • Wait — no visibility into status

Order Fulfillment Specialists

Managing forecast accuracy across the entire product catalog — updating quantities, coordinating uploads, and keeping planners informed of every change.

Manage Daily Forecast entries

Track Changes

Coordinate Upload Process

Loop in Planners

USER group

Their frustration wasn't the forecast work itself — it was the communication overhead every small correction created across three people before it reached the system.

Their frustration wasn't the forecast — it was everything that happened after they updated it.

Daily workflow

  • Update forecast in Excel

  • Coordinate with Admin for upload

  • Manually notify Planners of changes

  • Cannot function while the upload process is running

  • Repeat entire loop for minor fixes

The System Tension: Both groups depended on each other — yet operated with almost no shared visibility. Changes made in Excel only reached planners after manual uploads, creating friction at every point where the workflows intersected.

Understanding the System

Before redesigning the interface, I needed to understand the workflow behind it.

Early research revealed that many of the challenges weren’t simply UI problems. They were symptoms of a system that had evolved over time without a clear shared understanding of how planning actually worked. Forecast data moved across multiple systems before becoming a finalized production plan, with manual uploads and freeze points shaping when planners could intervene.

To make sense of this ecosystem, I stepped back and created a process map that visualized how forecasts moved through the system, where planners interacted with the data, and where friction occurred. The map surfaced key breakdown points — manual uploads, moments where data froze, and places where planners relied on external tools to complete their work.

More importantly, it became a shared artifact that aligned stakeholders, engineers, and product owners around the same understanding of the system, helping guide the redesign that followed.

Solution

Solution

Solution

How did the platform evolve once the workflow was understood?

Every change focused on reducing friction in a system that could not afford to fail. Rather than redesigning individual screens, the goal was to align the platform with how planning decisions were actually made.

The Redesigned Production Planning Platform

The redesigned platform simplifies complex planning workflows while maintaining the reliability required for production-critical decisions. Below are the six major shifts that enabled this transformation.

Shift 01 — Separate the Workflows

Planning and forecasting had historically existed in the same interface. The platform was restructured into two dedicated environments — one for Master Planners and one for Order Fulfillment Specialists — giving each group a space designed around their responsibilities.`

Shift 02 — Clarifying the Freeze System

Through stakeholder alignment sessions, two freeze mechanisms were clarified and redesigned as separate interactions. Bulk freezing handled large-scale updates, while single-line freezing allowed planners to lock individual decisions. Persistent visual indicators were introduced so planners could immediately understand the freeze state of any item.

Shift 03 — Rebuilding the Planning Interface

The core planning table was redesigned to surface the information planners needed most. Contextual details that previously required external documents were integrated directly into the interface, supported by search, filtering, and aggregate summaries.

Shift 04 — Comparison Without Leaving the Tool

Planners often exported data to Excel just to compare parts, sites, or planning periods. A comparison view was introduced that allowed side-by-side analysis directly within the platform, preserving context while supporting faster decision-making.

Shift 05 — Streamlined Upload Workflow

The manual forecast upload was automated end to end. Real-time status kept planners informed throughout — so they always knew whether the process was running, complete, or needed attention.

Shift 06 — Component Library

Because the central design system was incompatible with this platform, a localized component library was created. It standardized interaction patterns across the product and was later adopted across several adjacent applications.

Impact

Impact

IMPACT

What does success look like for a production-critical platform?

  • Improved operational efficiency by ~30% through streamlined planning workflows and reduced reliance on external tools.

  • Successfully transitioned 200+ planners and forecasters across the US and Mexico from a legacy platform to the redesigned system.

  • Enabled planners to compare forecasts, adjust plans, and validate production decisions directly within the platform, reducing manual verification effort.

  • Reduced dependency on fragmented tools and manual uploads by introducing a structured planning workflow with clear system visibility.

  • Established a reusable component library later adopted across multiple adjacent applications.

Reflections

Reflections

01 — Map the system before jumping to a solution

The system map I built became the single most influential artifact in the project — where data froze, where manual effort was silently absorbed, where the real workflow diverged from the assumed one. It wasn't just a design tool. It was the shared language that aligned stakeholders, PMs, and engineers around the same understanding of the problem. Without it, everyone would have been solving different versions of it.

01 — Map the system before jumping to a solution

The system map I built became the single most influential artifact in the project — where data froze, where manual effort was silently absorbed, where the real workflow diverged from the assumed one. It wasn't just a design tool. It was the shared language that aligned stakeholders, PMs, and engineers around the same understanding of the problem. Without it, everyone would have been solving different versions of it.

02 — Constraints aren't obstacles, they're the brief

Stakeholders managing billions in production decisions had legitimate reasons not to trust a new system. Designing with those constraints — not around them — is what made the legacy platform's retirement possible. The phased migration wasn't a compromise. It was the only approach that had a real chance of working. This project fundamentally changed how I approach rigid stakeholder environments. When the path forward feels blocked, the constraint itself is usually pointing at the real problem — and the real opportunity.

02 — Constraints aren't obstacles, they're the brief

Stakeholders managing billions in production decisions had legitimate reasons not to trust a new system. Designing with those constraints — not around them — is what made the legacy platform's retirement possible. The phased migration wasn't a compromise. It was the only approach that had a real chance of working. This project fundamentally changed how I approach rigid stakeholder environments. When the path forward feels blocked, the constraint itself is usually pointing at the real problem — and the real opportunity.

03 — The work that outlasts the project never shows up in a mockup

The highest-leverage contributions on this project were not individual flows or polished components. They were the automation architecture, the system map, the component library, and the change strategy. The most important design decisions were made before a single screen was opened — and they are the ones that will outlast the project.

03 — The work that outlasts the project never shows up in a mockup

The highest-leverage contributions on this project were not individual flows or polished components. They were the automation architecture, the system map, the component library, and the change strategy. The most important design decisions were made before a single screen was opened — and they are the ones that will outlast the project.

Let's Collaborate

2026 Shivani Patel

Designing at the intersection of people, systems, and scale.

Let's Collaborate

2026 Shivani Patel

Designing at the intersection of people, systems, and scale.