Network Labor Forecasting

Context

Three people were working on the same forecasting model. Every handoff introduced delay, error, and lost context.

Lowe's labor forecasting ran in sequence: a DC Flow Analyst built a volume forecast in Excel, handed it to a Finance Manager who manually translated it into a labor plan, and Industrial Engineers ran efficiency scenarios against the same underlying data with no formal connection to either workflow. When something changed — a store opening, a volume shift — the correction traveled through all three people again, by hand.

The design goal: replace that chain of handoffs with a unified platform that serves three distinct user types, accommodates model runs exceeding an hour, and feeds outputs directly into financial planning systems and operational scorecards.

System Failure

The problem wasn't that the process was slow. It was that there was no shared system at all.

The stated problem: "It takes too long to create facility goals and labor requirements." True. Not the whole story.

Volume forecasts lived in files. Finance plans lived in separate files. Industrial Engineers ran simulations no one else could see. Every week, someone reformatted something another person had built. When a forecast changed between Week 1 and Week 4, there was no way to explain why — the model ran in a black box and results were passed person to person without a shared space to interrogate them. A tool built for one persona would have left the other two in Excel.

The Reframe

The ask was "build a forecasting tool." The actual problem was that three people needed to enter the same project at different points, not use three separate tools.

One tool per persona would have shipped three disconnected experiences that need to stay in sync forever. The reframe: one unified project model that each persona enters at the right point in the lifecycle. That's the distinction that made the IA solvable.

The comparison problem sharpened it further. Users needed two structurally different types of comparison: temporal (how did this forecast change since I last ran it?) and scenario (how does this IE projection compare to that one?). Collapsing them into a generic "compare" view would have broken both. Naming the distinction early kept the IA from making that mistake.

Process & Key Decisions

The project started in FigJam, not Figma. The first artifacts were analytical — and they shaped everything downstream.

Problem Definition — Before wireframes, I built a Problem Definition canvas: problem statement, target users, outcomes, scope, measurement targets, and key challenges. Three personas is a challenge that surfaces immediately in any conversation about what "done" looks like. Making it explicit before design began created a shared definition before anyone could disagree about it later.

Service Blueprint — Three persona lanes, model run dependencies, decision points, and backend system layers. Two things became visible that weren't visible before: a linear dependency (Finance can't submit until Volume does — that's not a permission setting, it's an architecture requirement) and an async problem (52-week model runs exceed one hour — users submit, leave, and come back). Both had to be designed for explicitly. Neither was in the original brief.

User Tasking — A task matrix across all three personas and eight task categories (create, load, configure, run, review, save, compare, submit) grounded every IA decision in what users actually needed to do, not what the system needed to display.

Information Architecture — Five screen categories: Home, Configuration, Read Only, Review & Submit, and Compare & Submit. The key structural decision: comparison mode as a parallel track, not a detour. A user comparing forecasts doesn't lose their place in the primary review flow — they enter a mirrored version of it.

Async UX — For model runs exceeding an hour, the solution was intentionally simple: a status flag on the project card plus email notification when results were ready. Users don't need a progress bar for a process they're not watching. They need a trust signal that the system hasn't lost their submission.

Outcomes & Impact

Engineering is still in progress. What shipped first was organizational clarity.

The design produced a service blueprint, user tasking model, complete IA, and low-fidelity wireframes used directly in stakeholder presentations. They became the shared language for how product and engineering approached the build. The artifacts shaped how the organization thought about the problem before a line of code was written.

The tool is designed for 200 users across 15 distribution centers. Target outcomes are operationally specific: 5% reduction in temp labor, 12% reduction in RDC overtime, 3% reduction in key job function hours.

Reflection

The service blueprint was the most valuable artifact. The wireframes came later. The clarity came first.

The blueprint is where the structural problem became legible — where the linear persona dependency, the async model timing, and the locked/configurable permission logic all became visible at once. Everything downstream was easier because of it.

If I revisited anything: I'd define what "model explainability" means as a measurable outcome before design began. We named it as a user need. We didn't define what success looked like. What does a user need to be able to say after reviewing a changed forecast? That question, answered early, would have sharpened several IA decisions.