Pivoted from the pilot approach to improve usability and system performance, creating a stronger foundation for enterprise rollout and user adoption.
PIVOT
REDESIGN
RISK PRIORITIZATION
PRODUCT OVERVIEW
What is ScheduLinKR?
ScheduLinKR is Kroger's enterprise solution for managing store order schedules. These schedules determine when stores must place orders to ensure products arrive on time for customers, accounting for warehouse operations and transit time.
While schedules are mostly static, ScheduLinKR enables changes for exceptions like warehouse outages, promotional events, and peak holiday seasons.
THE OPPORTUNITY
THE OUTCOME
A streamlined data transition that enabled schedulers to upload large volumes of data more efficiently and with greater confidence in accuracy and system performance.
CONTEXT
A Rushed Pilot and Fractured User Trust
ScheduLinKR emerged from a rushed and turbulent pilot. Divisions were required to transition from ColdFusion, a legacy system with critical security risks within the year. Accelerated timelines forced tradeoffs in key features and workflows, leaving users frustrated and requiring them to manually recreate scheduling data for hundreds of stores.
STORE ORDER scheduler - POST PILOT USABILITY TEST
That's another big issue. It's stuff like this. This is why we cannot go live this holiday. I know, I know the other database is slower but it's usable.
Image of MVP UI for Poll, Process & Delivery Pairing
Prioritizing Pain Point Severity
To better understand early user challenges and increase our team's confidence in in our product's trajectory, I conducted usability testing focused on system performance, data setup, and schedule management (3 areas where we knew our product needed significant improvement).
I then mapped pain points by severity, documenting their current and long-term impact on both users and the business.
Manual Data Transfer
Manually setting up schedules for hundreds of stores was time-consuming and inefficient
Unclear Workflow
Disconnected workflows made schedule creation steps unclear and cumbersome
Slow Performance
Slow load times discouraged adoption and pushed users back to legacy systems
Collaborative Solutioning to Solve a Critical Performance Issue
To address our most critical pain points, I led a workshop using LUMA methodologies to leverage knowledge and ideas across our cross-functional team members to create an opportunity solution tree (a prioritization tool popularized by Theresa Torres). Our problems were severe, and we wanted to ensure we were considering every viable possibility by leveraging our team members' knowledge and expertise.
Participants: Product Manager, Back End Developers, Front End Developers, Product Design
How might we help schedulers seamlessly transfer and confidently trust their data in ScheduLinKR?
Standardized Excel Uploads
Create a structured Excel template that allowed schedulers to reformat existing spreadsheets into a format compatible with ScheduLinKR schedule creation.
Scheduler Familiarity with Excel, Consistency Across Divisions
Time Consuming for users, Schema Shift
Reverse Engineering SKOPE Files
Developed a script to reverse engineer SKOPE files, enabling ScheduLinKR to generate schedules from downstream order data already used by stores.
Automates time consuming initial build
Requires Proof of Concept, Complex and Time Consuming for Developers
Grouping Schedules by Shared Patterns
Introduced a backend “pattern” model that grouped shared weekly schedules across stores and commodities instead of processing schedules day by day.
Quicker Load Time, True Permanent Schedules
Initial Schedule build can take an equal amount of time depending on # of variations, Schema Shift
Derisking Solutions through Assumption Testing
Our team ultimately determined that "Patterns" was the most feasible short term solution, but simultaneous recognized that it was also a high-risk, high-impact solution.
Organizing schedules by stores with shared weekly schedules, rather than shared delivery days, did not align with how schedulers mentally organized their work. However, this backend structure would significantly improve system performance and scalability.
Our team needed to determine whether users could adapt to this new model and how it would impact their workflows.
To evaluate understanding of the concept, I conducted concept testing with three schedulers of varying experience levels from our existing research pool. Using a mock Excel schedule, early pattern concepts, and a simple prototype, I tested the following assumptions:
Concept Comprehension
Users will can shift their mental model of schedules to organize them by week and day.
✓ Validated
User capability
Users can effectively update existing store schedules from previous to new patterns.
⚠ Partially Validated
Scalability
"Patterns" is sustainable for managing numerous permanent schedule changes at once.
⚠ Partially Validated
User efficiency
Providing users with pre-organized patterns shared by stores will make creating schedules significantly easier.
✓ Validated
Strategic Solutioning and Prioritization Trade Offs
After communicating risks to product management, I proposed a 2nd phase for Patterns that would significantly reduce the pain points associated with introducing a schema that doesn’t align with how users currently think about scheduling.
I presented concepts and story maps for two design options:
A weekly data view aligned with the “Patterns” model
A more familiar day-by-day editing workflow already used elsewhere in the application
The product team chose the weekly "Patterns" view because
it was easier to build
fit our timeline
supported the idea that permanent data would only require updates a few times a year during rightsizing, when divisions request schedule changes based on consistent patterns and new needs.
Our product manager agreed to consider adding the day-based workflow as a future enhancement depending on adoption and user feedback. But, by working with our developers, we also determined that our other solution ideated during our initial workshop, Reverse Engineering Skope Files, could be viable for some sites later in the roll out plan.
Stage 1
Update backend data structure from individual schedules by day to shared weekly schedule "patterns".
Stage 2
Create backend structure to automate transfer of previous SKOPE data to ScheduLinKR's new "pattern" backend.
Stage 3 (possibility)
Update pattern UI to align with day to day schedule management on the frontend
Screenshot of Proposed Stage 3 Storymapping Workshop
Strategic Feature Enhancements
Outcome
57%
decrease in time to complete an initial schedule build for "simple schedules" with few variances across stores within a division's catalog.
