Bertilla

Fighting Hunger Through

Smarter

Logistics

Designing a decision-support tool for Nine13 Logistics — a nonprofit delivering food to thousands of Indianapolis families who can't reach a pantry on their own.

ROLE: Led UX thinking from research to mid-fidelity, translating complex findings into clear product direction. Defined system structure, key interaction flows, and decision-support concepts based on real-world logistics needs.

TIMELINE: September 2025 - Present

TEAM: Capstone project completed as part of a four-member product design team - Shruti R., Agastya D., Shraddha K.

Quick TL;DR of the case study

The Problem

Nine13 Logistics delivers food to 1,000+ Indianapolis families weekly but every growth decision (add a truck? hire a driver? take on a new pantry?) was made on gut instinct. No data. No way to model what it would actually cost or deliver.

What I did

Led UX from research to final design on a decision-support tool that translates a complex engineering model into something a nonprofit coordinator can actually use. That meant field research, ride-alongs, two rounds of user testing, and a lot of deliberate descoping.

Key idea

Every scaling decision lives in the tension between three things: effectiveness (OMOE), cost (OMOC), and risk (OMOR). The tool makes that tradeoff visible in plain language, before Nine13 commits to anything.

✨

What changed is that teams no longer chase emails, requests now move in real time, and nothing gets lost between handoffs.

3.2 ➡️ 4.2

User satisfaction after first redesign

10 minutes ⏱️

for two non-technical executives to navigate a complex engineering model

View Final Screens

Brings essential food support closer to people

Supports local community networks

Handles the complexity behind every delivery

Access, made easier

What looks like a simple delivery is often the difference between access and absence. Nine13 Logistics helps make that access possible.

Brings essential food support closer to people

Supports local community networks

Handles the complexity behind every delivery

Overview

The Last Mile is the Hardest Mile

Nine13 Logistics started as a youth cycling nonprofit. During COVID-19, it pivoted into something more urgent — a community logistics operator delivering food directly to seniors, people with disabilities, and families across Central Indiana. At peak pandemic response, Nine13 was reaching up to 1,000 Marion County residents per week.

Operates with a small fleet and a “white glove” approach, delivering every order with care and dignity.

As they scaled, planning became complex, raising questions about when to add trucks, drivers, or routes.

Existing tools handled routing but couldn’t support these decisions, creating a gap our team addressed.

Households served weekly at peak operations

Vehicles in fleet — 3 vans, 2 box trucks

Distinct delivery models: agency + home

The Problem

Growing on Instinct Isn't a Strategy

Nine13's COO, Ashley, has an extraordinary ability to look at a 7-hour route plan and immediately know it will actually take 8 hours and 15 minutes. That institutional knowledge is invaluable and completely unscalable. When routes go wrong, when a pantry volunteer doesn't show, when a call box is broken and a recipient can't be reached the system bends on the strength of one person's experience.

"What if we add another truck, van, or pantry — how does that actually change our cost and capacity?"

-Tom Hanley, CEO & Founder, Nine13 Logistics

Purdue University's engineering team had already built a powerful mathematical model capable of running thousands of "what-if" simulations. But it was deeply technical — dense with outputs, built for engineers, not for a nonprofit operations coordinator juggling drivers and email chains at 8 AM.

Our task was to bridge that gap: translate a rigorous backend model into a human-centered decision tool that Tom and Ashley could actually use.

What Nine13 Needed

A visual, easy-to-use interface to explore scaling decisions like adding vehicles, staff, or routes.

Shows impact on cost, capacity, and community reach without requiring technical expertise.

View case

What Was Already There

Used OptimoRoute to optimize delivery sequences and routing efficiency.

Could not forecast capacity, model growth, or reflect real-world delivery complexity.

View case

User Research

Getting Off the Laptop and Into the Truck

We didn't start with wireframes. We started with field visits, ride-alongs, and long conversations with the people who actually run these routes. Two studies shaped the entire project.

Study 1 — Stakeholder Interviews

We conducted semi-structured interviews with Tom Hanley (CEO) and Ashley Acuff (COO). These weren't brief check-ins Tom's site tour ran nearly 90 minutes. We used qualitative coding to pull themes from the transcripts, clustering statements around recurring patterns: delivery delays, scaling anxiety, the gap between digital routes and real-world conditions.

Study 2 — Ride-Along Field Observations

One team member joined the box truck route on a Wednesday morning — observing the full arc from loading pallets at Gleaners Food Bank to delivering to four pantry sites. Another shadowed Ashley on a Monday van route delivering produce boxes door-to-door across Marion County. What we saw confirmed everything we'd been told, and surfaced things no interview could have revealed.

Key Findings

Five Truths About Last-Mile Food Delivery

Scaling Decisions Are Made on Gut Feeling
Tom couldn’t predict the impact of adding trucks, drivers, or contracts—data existed across tools and memory but wasn’t synthesized into a usable view.
Two Delivery Types, Two Different Problems
Pantry routes focus on pallet coordination and fixed schedules, while home deliveries require door-to-door interaction, timing flexibility, and handling rejections—operationally very different despite appearing similar.
The "Last 100 Feet" Problem
Routing software assumes uniform stop times, but real-world factors like access issues and client needs can turn a 4-minute stop into 15 minutes, compounding delays across an entire route.
The "White Glove" Standard Resists Automation
Nine13 isn’t Amazon—every delivery involves a human handoff, so efficiency cannot come at the cost of care; the system must improve without removing the human element.
Midwest Food Bank Adds Structural Uncertainty
Unlike Gleaners’ pre-packed orders, Midwest Food Bank relies on selection-day pickups, so pallet counts are unknown until loading—making capacity planning difficult without better upstream data.
Scaling Decisions Are Made on Gut Feeling
Tom couldn’t predict the impact of adding trucks, drivers, or contracts—data existed across tools and memory but wasn’t synthesized into a usable view.
Two Delivery Types, Two Different Problems
Pantry routes focus on pallet coordination and fixed schedules, while home deliveries require door-to-door interaction, timing flexibility, and handling rejections—operationally very different despite appearing similar.
The "Last 100 Feet" Problem
Routing software assumes uniform stop times, but real-world factors like access issues and client needs can turn a 4-minute stop into 15 minutes, compounding delays across an entire route.
The "White Glove" Standard Resists Automation
Nine13 isn’t Amazon—every delivery involves a human handoff, so efficiency cannot come at the cost of care; the system must improve without removing the human element.
Midwest Food Bank Adds Structural Uncertainty
Unlike Gleaners’ pre-packed orders, Midwest Food Bank relies on selection-day pickups, so pallet counts are unknown until loading—making capacity planning difficult without better upstream data.
Scaling Decisions Are Made on Gut Feeling
Tom couldn’t predict the impact of adding trucks, drivers, or contracts—data existed across tools and memory but wasn’t synthesized into a usable view.
Two Delivery Types, Two Different Problems
Pantry routes focus on pallet coordination and fixed schedules, while home deliveries require door-to-door interaction, timing flexibility, and handling rejections—operationally very different despite appearing similar.
The "Last 100 Feet" Problem
Routing software assumes uniform stop times, but real-world factors like access issues and client needs can turn a 4-minute stop into 15 minutes, compounding delays across an entire route.
The "White Glove" Standard Resists Automation
Nine13 isn’t Amazon—every delivery involves a human handoff, so efficiency cannot come at the cost of care; the system must improve without removing the human element.
Midwest Food Bank Adds Structural Uncertainty
Unlike Gleaners’ pre-packed orders, Midwest Food Bank relies on selection-day pickups, so pallet counts are unknown until loading—making capacity planning difficult without better upstream data.
Scaling Decisions Are Made on Gut Feeling
Tom couldn’t predict the impact of adding trucks, drivers, or contracts—data existed across tools and memory but wasn’t synthesized into a usable view.
Two Delivery Types, Two Different Problems
Pantry routes focus on pallet coordination and fixed schedules, while home deliveries require door-to-door interaction, timing flexibility, and handling rejections—operationally very different despite appearing similar.
The "Last 100 Feet" Problem
Routing software assumes uniform stop times, but real-world factors like access issues and client needs can turn a 4-minute stop into 15 minutes, compounding delays across an entire route.
The "White Glove" Standard Resists Automation
Nine13 isn’t Amazon—every delivery involves a human handoff, so efficiency cannot come at the cost of care; the system must improve without removing the human element.
Midwest Food Bank Adds Structural Uncertainty
Unlike Gleaners’ pre-packed orders, Midwest Food Bank relies on selection-day pickups, so pallet counts are unknown until loading—making capacity planning difficult without better upstream data.

Defining Scope

Two Layers of Problems, One Deliberate Choice

Operational Challenges

At the operational layer — broken call boxes, failed deliveries logged only in Ashley's memory, scheduling done over email, Midwest Food Bank capacity unknown until the truck is already loading.

Strategic Challenges

At the strategic layer — no way to model what adding a truck, a driver, or ten new pantry contracts would actually cost or deliver.

We made a deliberate call: scope this phase to the strategic decision-support layer giving Tom and Ashley a way to explore growth decisions with real data behind them.

The operational gaps address logging, real-time tracking, scheduling coordination are real, documented, and the right problem for a future phase. This case study covers the strategic layer.

Competitive Analysis

Learning From What Already Exists

We evaluated three platforms that touch on logistics planning and simulation — not to copy them, but to identify what a nonprofit like Nine13 actually needs from software like this, and where the market has left a gap.

AIMMS SC Navigator

Strength:

Strategic scenario modeling, clean dashboards, scenario navigator

Weakness:

Enterprise pricing, requires structured data inputs

Relevance to Nine13:

Strong conceptual fit

Accessibility:

$$$ — not nonprofit-friendly

AnyLogic

Strength:

Multi-method simulation, closest in spirit to what Nine13 needs

Weakness:

Steep learning curve, cluttered UI, technical jargon

Relevance to Nine13:

Strong simulation logic

Accessibility:

Complex, enterprise-grade

EasyCargo

Strength:

Intuitive 3D visualization, drag-and-drop, immediate feedback

Weakness:

Narrow focus — load optimization only, not capacity forecasting

Relevance to Nine13:

UX inspiration only

Accessibility:

Affordable, browser-based

The Gap We Found

No tool in the market combines strategic what-if modeling with an interface simple enough for a nonprofit coordinator. AIMMS has the logic but not the accessibility. EasyCargo has the usability but not the scope. Our opportunity was to bring these together in plain language, for non-technical users, at zero enterprise cost.

From Research to Design

What Is This Tool Actually Measuring?

Before designing screens, we defined what “better” means for Nine13—captured by two key outputs from the Purdue model for every scenario.

OMOE

Operational Measure of Effectiveness

How well the operation delivers — community reach, delivery volume, service reliability.

OMOC

Operational Measure of Cost

What it costs to run — fuel, driver hours, vehicle utilization, overhead.

OMOR

Operational Measure of Risk

What could go wrong, missed deliveries, over-capacity routes, driver fatigue, single points of failure like Ashley's institutional knowledge.

The Tradeoff

Add a truck: OMOE goes up, OMOC goes up too.

The tool makes all three visible before Nine13 commits.

The problem was that this model lived in an engineering environment — dense outputs, no plain language, built for analysts. Tom and Ashley couldn't use it. Our job was to design an interface that surfaces this tradeoff clearly, for non-technical users, in the middle of a busy workday.

Turning Findings Into Direction

📊

Speak the operator's language

OMOE and OMOC never appear raw in the UI. They translate to "deliveries per week" and "cost per delivery" — terms Ashley would use on a phone call.

📆

Always show the baseline

Every scenario is meaningless without a reference point. The current operation stays visible and locked — so every what-if is instantly comparable to today's reality.

👩🏻‍💻

Validate before running

Impossible configurations like over-capacity routes, driver fatigue, and single points of failure must be flagged before running. The model should not output broken plans.

💻

Surface what changed, not just outputs

Side-by-side comparison needs clear deltas. Key differences between baseline and scenario must be obvious so Tom sees impact quickly.

Other Core Experiences

Ask planning questions naturally, conversational guidance walks users through planning decisions with clarifying questions instead of overwhelming input forms, helping them explore scenarios faster.

Update metrics in real time ,as Tom adjusts inputs (trucks, drivers, operating hours), outcome metrics (deliveries per week, cost per delivery, capacity) recalculate instantly so he sees impact immediately, not after clicking "Calculate."

Make scenarios exportable, for funder presentations, board reviews, and planning conversations so Tom can share findings without returning to the tool.

Information Architecture

Structuring a Tool That Thinks Like a Planner

The IA needed to support two modes: Tom's strategic exploration and Ashley's operational planning. We organized the product around five top-level areas, each mapped to a distinct user need.

Wireframes

Setting the Base Flow

Before committing to visual design, we built low-fidelity wireframes to establish the core interaction flows. The goal wasn't polish, it was clarity. Could a user create a scenario, adjust inputs, and compare results without getting lost? Wireframes let us stress-test the IA against real tasks cheaply and quickly.

User Testing — Round 1

Semi-Structured Interviews

❌

The planning model was wrong

The prototype only worked forward — enter inputs, get outputs. But Amy immediately identified that real planners often work in reverse: given a fixed budget or fleet, what's possible? Without reverse calculation, the tool couldn't support authentic executive decision-making.

📊

The dashboard didn't communicate priority

Professor Tovar compared it to a bad banking app, data everywhere, but no clear signal about what matters. Metrics were displayed without hierarchy or decision context. Users couldn't tell what to act on.

We expected feedback about features. Instead we discovered the system's core logic didn't align with how experienced planners actually work.

User Testing — Round 2

Think-Aloud Study

After incorporating interview insights into a revised prototype, we ran a think-aloud study with Ashley and Peter Lacey (CSO). Both completed five tasks while verbalizing their thoughts giving us a window into not just whether they succeeded, but why they struggled.

Ashley — COO

Satisfaction score: 3.2 / 5

Completed most tasks but struggled with the reverse calculate feature (4/5 difficulty) and faced too many competing CTAs. Labels were the main blocker, she knew her goal but couldn’t match it to the interface language.

Peter — CSO

Satisfaction score: 4.2 / 5

Faster with navigation but still struggled with reverse calculate. Key feedback: the “both” delivery option is unrealistic, pantry and home delivery have different cost structures and shouldn’t be modeled together.

Design Response

What We Changed and Why

Redesigned reverse calculate

Made it prominent and clearly labeled, aligned its interaction pattern with forward calculation so users don't need to re-learn the UI.

Separated delivery method scenarios

Removed the "both" option entirely. Pantry and home delivery now have distinct scenario paths with separate cost logic.

Rebuilt the dashboard hierarchy

Primary KPIs elevated to the top, supporting detail accessible but not competing. Benchmarked against banking-style clarity: what's my situation, what changed, what do I do next.

Added chart interactivity

Hover states, tooltips, and inline annotations on all charts so data is interpretable, not just visible.

Final Designs

From Structure to Screen

Explore, adjust, and own your baseline

Set your current operation as the reference point, explore how inputs change your effectiveness, cost and Risk in real time, and lock it in as the baseline everything else is measured against.

Professional, conversion-optimized websites tailored for business clients and lead generation.

Compare scenarios, make confident calls

Run two scenarios side by side against the baseline or each other to see exactly which configuration delivers more for less before committing to it.

Professional, conversion-optimized websites tailored for business clients and lead generation.

Start from the answer, work backward

Know your budget or capacity limit first? Reverse calculate lets you set the outcome you need and surfaces what resources it would actually take to get there.

Professional, conversion-optimized websites tailored for business clients and lead generation.

Reflections

A tool is only as good as the decisions it changes.

Nine13 now has something they didn't have at the start of this project, a tool that models growth decisions the way they actually make them, in language they can act on, built from the ground up around how their operation really works.

For me, the sharpest lesson was about scope. The research surfaced more problems than one tool could solve. Choosing which layer to address and being honest about what we weren't solving was as important as any screen we designed.

Next: Currently being validated by Nine13's team to see how it holds up against real decisions.

Fighting Hunger Through

Smarter

Logistics

Quick TL;DR of the case study

View Final Screens

The Last Mile is the Hardest Mile

shwebertilla@gmail.com