Project

Service Customer

In Campbell’s STAR, Independent Distributors can service stores along their route that sell Campbell’s Snacks.

🚨 Problem

Distributors lack a consolidated digital experience when servicing Campbell’s Snacks stores along their independently owned routes. They also lack real-time insight into their sales metrics and inventory throughout the ticketing process.

🔍 Discovery

Problem definition and goals

Data and user interviews with active distributors revealed a few important pain points:

Distribution routes are independently owned, so they don’t HAVE TO use any tools from Campbell’s Snacks.
Campbell’s Snacks is missing key metrics and insights into their distributors, and there is no way to surface those insights back to the distributors.
Distributors have little to no incentive (besides profit) to coordinate business efforts with Campbell’s Snacks.

Primary goals:

Create a streamlined and consolidated route-servicing experience that connects two separate databases.
Surface sales metrics from the separate Campbell’s STAR work stream, offering insights and promotional information.
Increase the amount of service-ticket finalization invoices.
Decrease amount of “voided” service-tickets.
Decrease paper usage and address recurring technical support topics experienced by Campbell’s Snacks.

Collaborative documentation tools, along with AI expedites research and synthesis.
- Notion
- FigJam
- Miro
- Claude.ai
- ChatGPT

User personas

In collaboration with Campbell’s Snacks' business development and database teams during discovery and scoping, we identified two core user cases we needed to cover:

Single-route distributors
Multi-route distributors, either a business owner with multiple subordinates or a single distributor owning multiple routes.

Background artifacts

With the problem, goals, and user personas identified, user research includes:

Gathering of existing feature validation, user personas, and user feedback artifacts from the strategy and research phase.
References to any proof-of-concept materials or artifacts, if available.
References to PI planning deliverables — timeline, roadmap, scope.
User interviews and gathering of customer feedback.

POC Wireframes

Acceptance Criteria

Pre-Discovery

User Interview

POC Prototype

Workshop and team alignment

In collaboration with Campbell’s Snacks stakeholders, product owners and managers, business analysts, design, development, and API teams, we all align on the following:

Problem needing to be solved
Goals and business values
User personas, permissions, user mindset, and setting
Design and technical assumptions
Feature and technical requirements (AC)
Site structure and navigation
MVP outline
Stakeholder ideas and input
High-level flow, functionality, expected outcomes
Areas for product growth, beyond initial release

👨‍💻 Design

Audit, distill, validate

Using discovery phase deliverables and artifacts, UX/UI work begins by referencing existing experiences within the application, and based on the goals of the new feature, identify:

Required technical iteration
Required UX iteration
Opportunities for improvements (backlog)
PI plan dependencies
User input

Mind on the macro while working in the micro:

Requirements

Workshop Board

POC Prototype

User Sessions

User Personas

Design tools used during the UX/UI design process include:
- FigJam
- Figma
- Prototype (Figma)

Iteration

Following the discovery sessions for Item-level Promotions, design meets with development to get early feedback, thoughts, red flags, and validation. A previously built feature needed iteration due to complexities between data-driven pricing edits and user-driven pricing edits.

Challenge: Compounding pricing edits from two separate databases

Challenge: User-driven pricing edits and templates

In hindsight, we should have designed and built a couple of feature functionalities in reverse order — promotion templates, then apply promotions and discounts. That being said, stakeholders needed to discuss and discover them in a different order, not conducive to design and development.
Challenge:
Dynamic data and technical challenges started to become real difficulties since we (probably) built a couple features in the wrong order. Pricing and promotions come into the application from different data sets and impact a product in a specific order of operations, and developers built things with this knowledge. Giving users the ability to edit and manipulate that pricing (future feature) required some iteration on a previous feature.
Solution:
Isolate those two areas of data input and manipulation into different work areas, and avoid the need for data to be so dynamic.

User flows and functionality

After feature discovery, exploration begins — MVP and beyond MVP.

Requirement:
Item-level Promotional details have multiple touch points — sometimes it’s a page (a part of the navigational structure), and sometimes it’s a flyout (appears on top of any page and not a part of the navigational structure).
Solution:
The Item-level Promotion list needs to also be in a flyout.
- Promotional data exposed to user across all servicing workflows
- Reduce clicks
- Avoid navigation
- Future-proof
- Better flow — less screen transitions

UX refinement and UI

Interactive prototyping to communicate functionality, flow, and generate stakeholder and technical feedback and buy-in.
Existing design system components and patterns validate and/or identify areas of iteration.
User testing of interactivity, hierarchy, and flow.
Validation: API and development teams (scope).
Design system audit to identify solutions and/or areas of growth.
Identification of the path to MVP.
Exploration beyond MVP to identify areas of iteration and improvements.

Iteration

Navigation took a bit of iteration as we negotiated existing technical limitations against requirements added to the scope from Campbell’s Snacks stakeholders.

Challenge:
To view store and promotional details when servicing a customer, the user must save their work, exit, and then navigate back to resume their work. An important goal for these Service Customer features was a seamless transition between in-progress service tickets and ALL store details, without work being lost.
Solution:
Hide the main navigation bar on any store details page IF the user navigates there from a service ticket that is in progress, and replace it with a component with a single call-to-action allowing them to bypass the navigation back stack that comes with the main navigation bar — working as an isolated “back button” specific to this workflow that allows the user to resume without an lost work.

The ability to create “service-only visit transactions” needed to be added to the first iteration of store invoicing. During the early UX phase of Service-only Visit Transactions, a design solution surfaced that would improve the existing ticketing user flow and experience, in addition to solving the problem at hand.

A relabeled button (“Create Ticket” to “Service Store”) and a new button group component were added to the Store Details page, allowing for a seamless feature iteration — Service-Only Visit Transactions.
This iteration also resulted in a more intuitive experience and a leaner UI.

Final UI

Final mockups were approved for handoff to development — agile iteration continued over the following months.

Challenge:
Product names can be very long, coming from a database where our team has no influence. The amount of required data input, tools, and additional access to more information for each product while servicing a store. Additionally, users are often on the move — working in their truck or walking around the store.
Solution:
Separate the types of service between two tabs, rather than choosing to deliver as well as receive a return of the same product
- Allows for maximum screen space (user setting)
- Reduce complexity (non-technical users)
- Clear separation and labeling between two very different types of transactions (reduce tech support)

Challenge:
Servicing a store takes time — walking around the store, communicating with multiple store employees, manual labor, trips out to the trucks, etc. Distributors also lacked real-time insight into their inventory and sales metrics.
Solution:
A drawer that can open and close over the top of any page gives the user access to the entire application and allows them to move their work out of the way, if needed, and pick up at any moment. Additionally, data in the summary drawer is dynamic, so the user can be confident that their bottom-line profits are accurate at that moment, regardless of selling more, returning more, adjusting their virtual inventory quantities, and applying promotions.
- Real-time insight into sales metrics, inventory, and store performance (profitability)
- Open-ended workflow and research (user setting)
- Minimized navigation (non-technical users)
- Real-time data summary (user adoption)

During the first pilot phase, early user feedback surfaced a less-than-desirable experience on phones (10% of the user base). The interface was becoming more and more busy, as features were added.
After receiving user feedback during the pilot phase, design spent a full sprint on “mobile optimization” — drastically improving the experience on smaller devices, as well as adding some improvements across all device experiences.
- Hide main navigation on scroll, show on immediate reverse scroll (user feedback)
- Responsive table body cells (user feedback)
- Refactored summary drawer (user feedback)
- Button Group component (user feedback)

View Prototype ↗️

Challenge:
There is a separate part of the application (outside of Retail Management) that displays promotions on the user’s weekly distribution calendar, where color is used in very specific ways, revolving around schedule and time.
Solution:
When the user is servicing a store using the STAR Route Management feature set, those same colors are used to connect those work streams — Route Execution and Route Management.

Challenge:
Dynamic data and technical challenges became a problem when initially attempting to allow for manual price editing alongside promotion management.
Solution:
Iteration was required — isolating those two areas of data input and manipulation to different work areas to avoid data needing to be so dynamic.