Led the redesign of a complex scheduling application, balancing a more scalable data model with familiar user workflows. We introduced a phased solution that simplified schedule creation and reduced initial build time by up to 57%.
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.
Role
COMPANY
TEAM
LIBRARIES
Tools
Contributions
THE OPPORTUNITY
Schedulers needed to manually recreate hundreds of store schedules while the system struggled to process the resulting volume of data, creating both an adoption problem and a scalability risk ahead of enterprise rollout.
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 our product's trajectory, I conducted usability tests 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 Downstream Files
Develop a script to reverse engineer backend 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
Introduce 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 simultaneously 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.
Su
M
Tu
after | BY WEEK
Su
M
Tu
W
Th
F
Sa
Su
M
Tu
W
Th
F
Sa
Su
M
Tu
W
Th
F
Sa
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 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
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 Downstream 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 downstream 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
UPDATING EXTERNAL CONSULTANT TRAINING MATERIALS
Supporting Adoption Beyond the Product
ScheduLinKR’s original training materials were developed by an external consultancy while the MVP was still taking shape. By launch, the product had already evolved beyond much of the documentation and continued enhancements made those resources increasingly outdated.
As we introduced Patterns and a new scheduling workflow, I helped bridge the gap between product changes and user adoption. I updated training materials to reflect the new experience and partnered with my Product Manager to lead Microsoft Teams training sessions and office hours, giving users multiple ways to learn the workflow, ask questions, and transition with confidence.
Outcome
57%
decrease in time to complete an initial schedule build for "simple schedules" with few variances across stores within a division's catalog. To measure the impact of the redesign, our team recreated the same store schedules in both the previous and redesigned versions of ScheduLinKR.
