AI Network Optimizer | Unilever
Designing an AI-powered logistics planning tool to unlock cost efficiency across India’s Unilever supply chain.
Role
UI/UX Designer
Timeline
14 Weeks
1 Designer & Researcher,
5 developers, 1 PO, 1 Architect
Skills
User experience, Research, User interviews, Concepts, Interaction design, UX Strategy
Got just a minute?
Enabled planners to consistently uncover cost-saving opportunities, refine route decisions with confidence, and produce execution-ready shipping plans with significantly less manual effort.
Outcome & Impact
Measured faster task completion
of human effort saved annually
Times Improved Productivity
Problem
PMRS was a decade-old reporting system that teams relied on every day by teams but struggled constantly. Started as a usability problem later revealed a deeper issue: the system no longer matched how people actually worked.
What I did
I led the entire end-to-end design process from research and strategy to execution. As both a designer and researcher, I conducted user research workshops, synthesized insights, and translated them into hands-on deliverables.
Context
What it was about?
What is the project about
This was a complete 0→1 product initiative where the outcome was highly uncertain. My role was to transform a concept on paper into a fully functioning product.
What is Network Optimizer
Network Optimizer is an AI-powered logistics planning tool built for Unilever India's transportation planners. It replaces the manual, spreadsheet-driven process of calculating inbound/outbound shipping routes and costs giving planners an automated baseline, a map of the network, and the ability to compare and edit scenarios before locking in a monthly plan.
Why - The problem
Largely manual and spreadsheet driven
Transportation planners manually routed flows every month and quarter, across processing plants, depots, suppliers, packaging and inbound legs. Even with significant validation, three issues persisted.
Issue 01
High human effort
Every planning cycle required manual data gathering across multiple fragmented sources and stakeholders, plant-to- plant dependencies, packaging flows, lane data.
Issue 02
Process repeats
The same workflow ran every month for execution and before every quarter for forecasting, with no reuse, no
memory, and no compounding efficiency over time.
Issue 03
Output lacked efficiency
Formula-driven spreadsheet costing was error-prone and hard to audit. The process completed, but never revealed whether a more cost-efficient route existed.
What we assumed going in
We thought fixing the UI would fix the problem
The business reported this as a simple UI problem.
We initially believed that modernising the look and feel and reducing visual clutter through a redesigned experience would be enough to make the system work as intended.
What we decided
We chose to validate before we design anything, so we decided to conduct a mixed methods user research study.
The system was 10 years old and heavily adapted. The goal wasn't to audit the interface, it was to understand what was delaying the users and what they actually needed.
Heuristics analysis
Surfaces known usability issues, but not the reasons behind long-term adaptations.
Usability testing
Identifies friction in specific tasks, but not whether the overall flow makes sense.
Mixed methods (Interviews+ Surveys)
Reveal real-world usage under pressure, what success means to users, and where the system breaks trust.
Research - The turning point
Mixed methods approach to find the real problem
Step 1
User Interviews
I interviewed users from the Data Load and Report Generation teams in India. Although the product serves a global audience, India has the largest user base, making it the primary focus for gathering insights.
Goal
To uncover how users built workarounds and what the system failed to support
Step 2
Questionnaire Surveys
The survey was designed using insights from the interviews to validate and measure the most common user problems at scale.
Goal
To Measure Prevalence & to validate patterns
Actual end Users
Data Load Team
Reports Generation Team
Total Users
1400+
Total Users
1600+
Geography
Majorly from India, Few Globally.
Gender Distribution
75%
Male
25%
Female
0%
Others
Interview context
Method
Remote Interviews via video call
Regions Covered
India
Duration
45-60 (Minutes per participants)
User Involved in interviews
14 ( 7 From Data Load, 7 From Report Generation )
Survey context
Completed target response
302 (From both teams)
Margin of error
± 5%
Confidence level maintained across both
95%
Total responses across both segments
612
Insights
What the research revealed
Design goal
Defining the ultimate experience
Based on the decisions made during the ideation workshop, we chose to focus our solutions around these two key areas.
Focus 01
Task driven system
Organize every screen around what users are trying to do, not how the backend is structured. Domains become invisible the user sees their goal, not our architecture.
Focus 02
Unified experience
Make every export or data-load workflow completable in one continuous flow, no jumping between pages, no holding context in your head, no re-entering the same parameters.
Key decisions
Strategic decisions & Trade off's
The above two goals set the direction but the research surfaced more problems than we could solve in one release. Prioritisation wasn't optional it was how we protected delivery speed without abandoning user value.
How we used effort Matrix: Not as a ranking tool, as a shared alignment tool for the whole team.
The PO, developers, and stakeholders all contributed to placing features on the matrix. This meant every trade-off was visible and agreed on, not made silently by the designer or the PO alone.
Trade off's: Delivery speed > Complexity
Delivering value incrementally by deferring high-complexity features to future phases.
Trade-off 1
Deferred
The design intent
We explored integrating direct data pulls from SharePoint in addition manual uploads.
Constraint
The approach required significant security, authentication, and backend dependencies.
The decision
To protect timelines and system stability, we deferred this and prioritized the core Data Extract & manual load capability.
Trade-off 2
Deferred
The design intent
We proposed moving data load and report generation requests from email into PMRS with in-app notifications.
Constraint
Although it improved visibility and speed, it added more development effort and added complexity for the first release.
The decision
To keep the launch focused and reliable, this enhancement was planned for a future phase.
Key Iteration
How should reports and booklets be structured?
Rejected
Option A - Different Pages
Access reports. and booklets from different pages.
Approved
Option B - Single Unified Page
All reports extraction in one view.
Why we chose (option B)
The core problem wasn't that reports and booklets were hard to use separately it was that users were trying to use them together. Every export task required both. Splitting them across pages forced users to hold context in their head, re-enter parameters, and navigate back and forth just to complete one workflow.
Solution
The new experience
01 - Information Architecture
Insight
85% reported they will have to switch to multiple links to complete export/load operations for one domain.
Each domain has its own entry point. Every time I jump between them, I lose context and have to reorient.
Designed around what users do, not how systems are organised
Instead of organizing content by domain or module, I focused on functional intent, grouping screens and actions based on tasks. Followed a noun + verb approach using nouns for navigations to clearly define sections, and verbs for actions to guide users on what they can do
Impact → This shift improved discoverability, efficiency and reduced navigation effort following a logical goal centred flow.
02 - Onboarding
Insight
80% of users found the system difficult to understand during onboarding
New users had to rely completely on their colleague to understand how to use the system. It’s not beginner-friendly at all.
Reduced onboarding friction
A guided product tour was introduced to onboard new users by walking them through key tasks . The tour highlights essential actions and explains system behavior in context, reducing reliance on external documentation or training.
Impact → Shortened onboarding, helped users become productive faster.
03 - Export
Insight
95 % of user are not completing their tasks within this tool.
User usually export multiple reports and merge them outside PMRS. It doesn’t really support pulling everything together in one go.
One space. Multiple export needs satisfied.
A new booklet-based export experience lets users group multiple reports into a single downloadable package, making bulk exports faster and more organized. Both single report exports and booklet exports are handled within the same interface.
Impact → Reduced the need to work outside the system, one interface for all exports
04 - Report Preview
Insight
90% experienced errors discovered only after export
Exporting feels like guessing. Without a preview, I have to double-check everything outside the system.
Seeing before sharing, report preview.
Introduced a Report Preview feature that lets users view content, verify details, and download the previewed report as a single file.
Impact → Improved clarity and accuracy, reduced rework and made exporting the right reports faster.
05 - Data Load
Insight
80% found data loading time-consuming and error-prone
Manual data loading acted as a drag on productivity particularly during peak cycles. The lack of structure and safeguards increased task time and error rates, often resulting in rework and delayed reporting.
Data ingestion simplified and flexible.
Users can now load data directly from available data sources within PMRS, removing the need for manual handoffs and extra steps.
Impact → Reduced manual effort, minimized errors, made the system significantly faster and reliable
06 - Manual Data Load
Insight
75% found manual data loading is not proper and user friendly
Manual data loading was not guiding the new users in loading the data in a seamless way, it was friction heavy and had multiple steps.
Flexibility Without Friction: A Smarter Manual data load Experience
Manual uploads were retained but improved with a predefined template, a quick upload guide, and a history log showing recent uploads for traceability.
Impact → Less manual effort, fewer errors, full traceability
Before
Hard to learn
Onboarding relied heavily on peer support and trial-and-error.
Fragmented navigation
Users had to jump across modules to complete one reporting task.
Low confidence during tasks
limited clarity and feedback increased hesitation and repeated actions.
High manual effort
Users spent time compensating for the system rather than focusing on reporting outcomes.
Workarounds were normalized
Users adapted their behavior to make the system “work”
After
Faster onboarding
Users could understand the workflow and become productive sooner
Task-driven flows
Reporting journeys were more continuous and easier to follow end-to-end
Improved clarity and trust
users received better visibility and feedback while completing tasks
Reduced rework
Fewer repeated actions caused by uncertainty
Less dependency on workarounds
Users could complete workflows with fewer manual compensations
Impact
What actually changed
We started with a system where each domain had its own entry point, where simple tasks took too many steps, and where users built workarounds outside the tool just to finish their work. The task-driven restructure was meant to remove exactly those frictions. Here's what we saw.
45%
Measured across 32 representative export tasks before/after redesign.
8000hrs
Modeled across 1400+ users
2X
Measured in report generation throughput for core workflows.
Behaviour change- the part that proved it worked
New users got productive without a colleague.
The guided tour replaced the "ask the person next to you" onboarding
The workarounds shrank.
Tasks that previously spilled into Excel and email could now be completed inside PMRS
Exports stopped being a guessing game.
With preview before export, users verified inside the system instead of double-checking outside it
Data loading stopped being the bottleneck
What used to be a slow, manual, error-prone drag during peak cycles became a guided, structured step
What it means
The shift from a domain-based structure to task-driven workflows didn't just make the system faster, it made the interface match how people already thought about their work. The friction we opened with wasn't a UI problem. Solving it wasn't a UI fix.
Reflections from the journey
Early Collaboration Reduced Misalignment
Involving stakeholders and developers early helped align expectations, identify dependencies sooner, and reduce rework throughout the project.
Validating cost us two weeks, and saved the release
Pushing back on "just fix the UI" to invest time in research felt risky within a 14-week timeline. But had we designed around the original assumption, we'd likely have shipped a cleaner interface without addressing the underlying workflow problems. The slower start gave us the clarity to build the right solution.
Final Thoughts
This project reminded me that great design is not just about improving usability, but also about collaborating efficiently and making strategic decisions under constraints to deliver impactful results.
Thanks for reading my case study!
If you have any more questions or want to know more details, please don't hesitate to contact me. For now, please consider checking my other work, my experiments, or learn more about me.
Next case study
TechAdvisor
Enterprise
Automobile & heavy machinery
A global application for dealers transforming technical complexity into clear, customer-ready recommendations.
