Albertsons
Sr. Product Designer
Standardizing labor planning to improve forecasting accuracy
Project Overview
Our goal is to design an app that helps users move from manual labor planning to a more accurate automated process, which will result in increased labor savings. Since they trust their own process and are cautious about new tools (10% adoption), the challenge is figuring out how to increase adoption of a tool they might initially distrust.
If we understand the user’s manual workflow, the data they rely on to make decisions, and important data that they don’t currently have, we can design an experience users can be confident in, which will lead to higher adoption rates. As more users adopt the tool, they will plan labor more efficiently, resulting in significant savings due to more effective labor planning.
$2,000,000
Measured by comparing the labor savings from the before and after the redesign.
+ 700 bps
Measured by comparing the user’s task completion rate before and after the redesign.
+ 4.15
Measured by our user researcher’s survey sent out before and after the redesign.
Challenges
I was the first designe on the Customer Promise Pillar -- a team that didn't have a lot of experience working with a UX designer. Working with a team with lower design maturity required a lot of patience, and communication throughout the duration of the project. Some of the challenges I faced included:
0 to 1
starting from scratch means investing a lot of time into understanding the current state by interviewing users
No Established Design System
had to work in parallel work streams with our design system manager to design components, while designing this interface
Managing Stakeholder Expectations
there were multiple stakeholders at a variety of the levels all of them had different interpretations on how labor should be calculated this affected the iterative process, as we had to go back and forth on the design depending on what the right way of calculating the forecast was thought at the time
Engineering Constraints
the dev team was still determining their tech stack this changed what designs were possible at certain parts of the process we had limited bandwidth allowed per the project that affected what was possible in the early stages of the project
Understanding User Needs
I led user interviews to understand how they plan labor day-to-day. By uncovering their manual process, their key pain points, and their reasons for not using the auto-scheduler feature, I shaped the Information Architecture around their real workflow, creating a strong foundation for the application.
Findings
Through user interviews, I identified two distinct user groups: those focused on division-level performance and those responsible for editing demand forecasts. I recommended separating these workflows to create a more focused experience, but due to resource constraints, leadership opted for a single end-to-end solution instead. I pushed back, as designing for four users with different motivations conflicted with our goal of mirroring their manual process for easier adoption. Ultimately, the business prioritized short-term adoption to hit KPIs, with the plan to refine the interface to better align with user needs once more resources became available.
I mapped out the necessary components based on user workflows, quickly iterating from wireframes to high-fidelity designs. This was a true zero-to-one project, made even more interesting by the fact that I was working alongside our design system lead on an early-stage design system. Since many components didn’t yet exist, I sourced potential solutions, which had to be reviewed, approved, and then stress-tested in my designs. It was a unique challenge—building both the experience and the design system simultaneously.
Design Process
Iterative Design
Working on this project, I quickly learned the importance of documenting design decisions. When debates over operational logic put the project on hold, having clear records made it easier to pick up where we left off. In some cases, we even revisited scrapped designs, reinforcing the need for strong version control. This experience highlighted how essential it is to track decisions to maintain momentum and ensure a smooth design process.
Iteration #1
An early design allowed bulk editing of any value in the demand forecast, but users found it overwhelming. It also wasn’t ideal from a design and development standpoint—making all fields editable added unnecessary complexity to the logic and overall experience.
Iteration #2
Another iteration limited edits to total fields instead of day-by-day adjustments. This approach was considered because operations hadn’t finalized how the backend calculations would work.
Iteration #3
After months of iteration and stakeholder discussions, we aligned on the ideal user and editing process. We revisited the row edit best practice I had proposed earlier, which users responded well to due to its clear, focused approach.
