Enter Password

Hint: NDA-protected work. Password is on my resume. Questions? hello@serenakim.ca

Back

Flashfood Partner App

Rebuilding the tool grocery partners actually use to post inventory

Role
Lead Product Designer (managing a contractor UI Designer)
Timeline
  • 2-day design sprint,
  • 10-week design delivery
  • 9+ months total project delivery including engineering and QA
Platform
Android

Rebuilt a retail-facing app that had gone years without strategic updates. Urgent partner requests had driven feature accumulation without validation, creating an experience that slowed the exact posting and pickup behaviors the business needed to scale.

Leadership: Directed product strategy through user research and cross-functional collaboration. Hired and managed a contractor UI designer for execution while maintaining design oversight. Made key architectural decisions including scanning technology selection. Translated usability findings into product direction across the dual-sided marketplace.

Impact

Initial rollout results (Dec 2025)

Both inventory value and item count increased — partners posted more items AND higher-value items. This suggests weight-based posting unlocked meat/seafood categories that partners had previously avoided.

The project established evidence-based design strategy over reactive feature requests. The app became a credible Partner Management conversation asset, and design demonstrated the ability to surface business-critical issues invisible in aggregate metrics.

How We Got There

Strategic context, design decisions, and leadership approach.

Strategic Context

The partner app had gone years without strategic investment. Features accumulated through urgent partner requests — many went unused — while the core posting and pickup workflows created friction for the exact behaviors the business needed to scale. Years of reactive development had built up technical and operational debt that needed resolution before building anything retail-relevant.

What we walked into: The app's simple frontend masked real backend complexity — SOC2 compliance requirements and UPC scanning across diverse product types. Posting competed with internal markdowns for priority while pickup required immediate attention, and workflows varied by brand, district, and store. Store staff needed speed, managers decided adoption but rarely used the app, and district managers drove compliance without direct usage. Meanwhile, Partner Management spent significant time calling and visiting stores to cover gaps the product should have handled.

The sprint: 2-day design sprint with Partner Management, CS, Product, and Engineering. 10-week design delivery, 9+ months total project delivery. Platform: Android (iOS currently in development). I hired and managed a contractor UI designer for execution.

Problem Definition

Flashfood's marketplace depends on grocery partners posting surplus inventory — a small part of their daily operations that competes with internal markdown programs and other recovery tools. Labor cost is the binding constraint. Posting to Flashfood ranks as one of the lowest priorities unless C-suite executives actively champion it, and even then, ROI isn't always clear to the store-level staff making posting decisions.

Our posting workflow didn't align with how partners actually operated, which varied significantly by store and brand. The question was straightforward: how do we make the app clear and require minimal labor to achieve maximum posting outcomes across diverse partner workflows?

Person with tattoos on arms wearing a watch

Strategic Design Decision 1

Multiple Posting Workflows

Grocers operate on razor-thin margins. Shrink recovery requires labor, yet Flashfood posting ranked lowest priority in-store. The team relied on store visits and manager calls to drive posting behaviour. The system wasn’t scalable.

The legacy app required single-item scanning with manual entry. Posting 10 items took ~2.5 minutes. In busy stores, that friction meant less inventory posted.

We redesigned the workflow around operational reality.

Instead of one rigid flow, we introduced tiered posting paths, including batch posting powered by multi-scan and auto-populated fields to reduce manual input.

Posting up to 10 items now takes ~32 seconds versus 2.5 minutes previously — a 79% reduction in time to post.

By translating speed into labor savings and posting velocity, design shifted from reactive feature delivery to a supply growth lever.

City skyline silhouette at sunset with warm orange sky.

Strategic Design Decision 2

Weight-Based Posting

Meat and seafood drive high shopper demand with sell-through rates above 90%, but we didn't offer variable-weight posting capability. Partners faced an impossible choice: post each item individually with accurate weight (heavy labor) or use Partner Management's workaround — post with lowest price and weight, losing money on every transaction. Partners protected themselves by posting minimal meat/seafood, only discount rack items, waiting until 2 days before expiration. This suppressed supply in a high-demand category.

We designed weight-based posting with individual item capture via scanning technology, removing the labor vs. revenue loss tradeoff. The design sprint surfaced this revenue leakage pattern through Partner Management field intelligence. Usability testing validated partner enthusiasm but revealed the initial flow required too many actions — we redesigned to streamline steps while maintaining accuracy.

Strategic Design Decision 3

In-Store Refund with Partial Quantity

Posting and pickup were treated as separate features, but inventory milestones at pickup exposed a capability gap. While posting was low-priority work, pickup created urgent interruptions — staff dropped everything to retrieve orders. When items were missing, staff couldn't resolve it properly. Some stores had refund capability but could only refund entire orders (order 2 yogurts, 1 missing, must refund both). Other stores had no refund capability at all and redirected shoppers to customer support. Staff faced impossible choices: over-refund and lose money, give away regular-price items, or escalate and frustrate shoppers.

We designed in-app refund with partial quantity capability. Staff at point of pickup — all stores — could process partial refunds without over-refunding or escalation. We mapped the failure loop in the design sprint and designed a lightweight refund flow with partial quantity adjustment that balanced staff empowerment with fraud prevention.

Snow-covered mountain peaks under a pastel sky
Cross-Functional Leadership

I partnered with Product and an external facilitator to design and run a 2-day workshop that brought together Partner Management, CS, Product, and Engineering. Each group brought a different lens — field intelligence, support patterns, business priorities, technical feasibility. The sprint surfaced the meat/seafood revenue leakage pattern that was business-critical but invisible in aggregate data.

I hired and managed a contractor UI designer, set the strategic direction and vision, and led stakeholder presentations and design reviews. The designer executed screens, handled iteration, and ensured cross-platform consistency. Throughout the 10-week delivery, we ran cross-functional reviews to validate decisions and surface constraints early. I stayed embedded with engineering — answering questions, refining designs around technical realities, and protecting coherence rather than moving immediately to the next initiative.

Measurement Constraints & Strategic Response

The cross-functional workshop and broad usability testing gave us stronger research foundations than the Shopper project — we tested across different store types, not just engaged partners. But post-launch measurement faces a structural challenge specific to the partner side. Each retail partner operates on their own IT roadmap with different rollout processes and timelines for adopting updates. The metrics we have reflect business outcomes but can't isolate which design changes drove which improvements.

I would have pushed to launch with 3–5 beta stores before full rollout. Real performance data — which workflows partners chose, where they dropped off, how refund usage affected pickup satisfaction — would have caught things testing alone can't surface. The rollout timeline didn't leave room for it. We mitigated through the workshop, broad testing, and staying embedded through delivery. But the better move is building beta programs into the project plan from the start — identify representative partners early, scope a 2–4 week beta window before the timeline is set, and define what "good enough to scale" looks like before launch, not after.

This project turned a neglected internal tool into a credible partner-facing product. The design decisions were grounded in field intelligence that aggregate data couldn't surface — and the workflows we built directly expanded marketplace supply in categories that drive shopper retention. The evidence-based approach established during this project replaced years of reactive feature development with validated design strategy.

Strategic Context

The partner app had gone years without strategic investment. Features accumulated through urgent partner requests — many went unused — while the core posting and pickup workflows created friction for the exact behaviors the business needed to scale. Years of reactive development had built up technical and operational debt that needed resolution before building anything retail-relevant.

What we walked into: The app's simple frontend masked real backend complexity — SOC2 compliance requirements and UPC scanning across diverse product types. Posting competed with internal markdowns for priority while pickup required immediate attention, and workflows varied by brand, district, and store. Store staff needed speed, managers decided adoption but rarely used the app, and district managers drove compliance without direct usage. Meanwhile, Partner Management spent significant time calling and visiting stores to cover gaps the product should have handled.

The sprint: 2-day design sprint with Partner Management, CS, Product, and Engineering. 10-week design delivery, 9+ months total project delivery. Platform: Android (iOS currently in development). I hired and managed a contractor UI designer for execution.

Problem Definition

Flashfood's marketplace depends on grocery partners posting surplus inventory — a small part of their daily operations that competes with internal markdown programs and other recovery tools. Labor cost is the binding constraint. Posting to Flashfood ranks as one of the lowest priorities unless C-suite executives actively champion it, and even then, ROI isn't always clear to the store-level staff making posting decisions.

Our posting workflow didn't align with how partners actually operated, which varied significantly by store and brand. The question was straightforward: how do we make the app clear and require minimal labor to achieve maximum posting outcomes across diverse partner workflows?

Person with tattoos on arms wearing a watch

Strategic Design Decision 1

Multiple Posting Workflows

Grocers operate on razor-thin margins. Shrink recovery requires labor, yet Flashfood posting ranked lowest priority in-store. The team relied on store visits and manager calls to drive posting behaviour. The system wasn’t scalable.

The legacy app required single-item scanning with manual entry. Posting 10 items took ~2.5 minutes. In busy stores, that friction meant less inventory posted.

We redesigned the workflow around operational reality.

Instead of one rigid flow, we introduced tiered posting paths, including batch posting powered by multi-scan and auto-populated fields to reduce manual input.

Posting up to 10 items now takes ~32 seconds versus 2.5 minutes previously — a 79% reduction in time to post.

By translating speed into labor savings and posting velocity, design shifted from reactive feature delivery to a supply growth lever.

City skyline silhouette at sunset with warm orange sky.

Strategic Design Decision 2

Weight-Based Posting

Meat and seafood drive high shopper demand with sell-through rates above 90%, but we didn't offer variable-weight posting capability. Partners faced an impossible choice: post each item individually with accurate weight (heavy labor) or use Partner Management's workaround — post with lowest price and weight, losing money on every transaction. Partners protected themselves by posting minimal meat/seafood, only discount rack items, waiting until 2 days before expiration. This suppressed supply in a high-demand category.

We designed weight-based posting with individual item capture via scanning technology, removing the labor vs. revenue loss tradeoff. The design sprint surfaced this revenue leakage pattern through Partner Management field intelligence. Usability testing validated partner enthusiasm but revealed the initial flow required too many actions — we redesigned to streamline steps while maintaining accuracy.

Strategic Design Decision 3

In-Store Refund with Partial Quantity

Posting and pickup were treated as separate features, but inventory milestones at pickup exposed a capability gap. While posting was low-priority work, pickup created urgent interruptions — staff dropped everything to retrieve orders. When items were missing, staff couldn't resolve it properly. Some stores had refund capability but could only refund entire orders (order 2 yogurts, 1 missing, must refund both). Other stores had no refund capability at all and redirected shoppers to customer support. Staff faced impossible choices: over-refund and lose money, give away regular-price items, or escalate and frustrate shoppers.

We designed in-app refund with partial quantity capability. Staff at point of pickup — all stores — could process partial refunds without over-refunding or escalation. We mapped the failure loop in the design sprint and designed a lightweight refund flow with partial quantity adjustment that balanced staff empowerment with fraud prevention.

Snow-covered mountain peaks under a pastel sky
Cross-Functional Leadership

I partnered with Product and an external facilitator to design and run a 2-day workshop that brought together Partner Management, CS, Product, and Engineering. Each group brought a different lens — field intelligence, support patterns, business priorities, technical feasibility. The sprint surfaced the meat/seafood revenue leakage pattern that was business-critical but invisible in aggregate data.

I hired and managed a contractor UI designer, set the strategic direction and vision, and led stakeholder presentations and design reviews. The designer executed screens, handled iteration, and ensured cross-platform consistency. Throughout the 10-week delivery, we ran cross-functional reviews to validate decisions and surface constraints early. I stayed embedded with engineering — answering questions, refining designs around technical realities, and protecting coherence rather than moving immediately to the next initiative.

Measurement Constraints & Strategic Response

The cross-functional workshop and broad usability testing gave us stronger research foundations than the Shopper project — we tested across different store types, not just engaged partners. But post-launch measurement faces a structural challenge specific to the partner side. Each retail partner operates on their own IT roadmap with different rollout processes and timelines for adopting updates. The metrics we have reflect business outcomes but can't isolate which design changes drove which improvements.

I would have pushed to launch with 3–5 beta stores before full rollout. Real performance data — which workflows partners chose, where they dropped off, how refund usage affected pickup satisfaction — would have caught things testing alone can't surface. The rollout timeline didn't leave room for it. We mitigated through the workshop, broad testing, and staying embedded through delivery. But the better move is building beta programs into the project plan from the start — identify representative partners early, scope a 2–4 week beta window before the timeline is set, and define what "good enough to scale" looks like before launch, not after.

This project turned a neglected internal tool into a credible partner-facing product. The design decisions were grounded in field intelligence that aggregate data couldn't surface — and the workflows we built directly expanded marketplace supply in categories that drive shopper retention. The evidence-based approach established during this project replaced years of reactive feature development with validated design strategy.

Strategic Context

The partner app had gone years without strategic investment. Features accumulated through urgent partner requests — many went unused — while the core posting and pickup workflows created friction for the exact behaviors the business needed to scale. Years of reactive development had built up technical and operational debt that needed resolution before building anything retail-relevant.

What we walked into: The app's simple frontend masked real backend complexity — SOC2 compliance requirements and UPC scanning across diverse product types. Posting competed with internal markdowns for priority while pickup required immediate attention, and workflows varied by brand, district, and store. Store staff needed speed, managers decided adoption but rarely used the app, and district managers drove compliance without direct usage. Meanwhile, Partner Management spent significant time calling and visiting stores to cover gaps the product should have handled.

The sprint: 2-day design sprint with Partner Management, CS, Product, and Engineering. 10-week design delivery, 9+ months total project delivery. Platform: Android (iOS currently in development). I hired and managed a contractor UI designer for execution.

Problem Definition

Flashfood's marketplace depends on grocery partners posting surplus inventory — a small part of their daily operations that competes with internal markdown programs and other recovery tools. Labor cost is the binding constraint. Posting to Flashfood ranks as one of the lowest priorities unless C-suite executives actively champion it, and even then, ROI isn't always clear to the store-level staff making posting decisions.

Our posting workflow didn't align with how partners actually operated, which varied significantly by store and brand. The question was straightforward: how do we make the app clear and require minimal labor to achieve maximum posting outcomes across diverse partner workflows?

Person with tattoos on arms wearing a watch

Strategic Design Decision 1

Multiple Posting Workflows

Grocers operate on razor-thin margins. Shrink recovery requires labor, yet Flashfood posting ranked lowest priority in-store. The team relied on store visits and manager calls to drive posting behaviour. The system wasn’t scalable.

The legacy app required single-item scanning with manual entry. Posting 10 items took ~2.5 minutes. In busy stores, that friction meant less inventory posted.

We redesigned the workflow around operational reality.

Instead of one rigid flow, we introduced tiered posting paths, including batch posting powered by multi-scan and auto-populated fields to reduce manual input.

Posting up to 10 items now takes ~32 seconds versus 2.5 minutes previously — a 79% reduction in time to post.

By translating speed into labor savings and posting velocity, design shifted from reactive feature delivery to a supply growth lever.

City skyline silhouette at sunset with warm orange sky.

Strategic Design Decision 2

Weight-Based Posting

Meat and seafood drive high shopper demand with sell-through rates above 90%, but we didn't offer variable-weight posting capability. Partners faced an impossible choice: post each item individually with accurate weight (heavy labor) or use Partner Management's workaround — post with lowest price and weight, losing money on every transaction. Partners protected themselves by posting minimal meat/seafood, only discount rack items, waiting until 2 days before expiration. This suppressed supply in a high-demand category.

We designed weight-based posting with individual item capture via scanning technology, removing the labor vs. revenue loss tradeoff. The design sprint surfaced this revenue leakage pattern through Partner Management field intelligence. Usability testing validated partner enthusiasm but revealed the initial flow required too many actions — we redesigned to streamline steps while maintaining accuracy.

Strategic Design Decision 3

In-Store Refund with Partial Quantity

Posting and pickup were treated as separate features, but inventory milestones at pickup exposed a capability gap. While posting was low-priority work, pickup created urgent interruptions — staff dropped everything to retrieve orders. When items were missing, staff couldn't resolve it properly. Some stores had refund capability but could only refund entire orders (order 2 yogurts, 1 missing, must refund both). Other stores had no refund capability at all and redirected shoppers to customer support. Staff faced impossible choices: over-refund and lose money, give away regular-price items, or escalate and frustrate shoppers.

We designed in-app refund with partial quantity capability. Staff at point of pickup — all stores — could process partial refunds without over-refunding or escalation. We mapped the failure loop in the design sprint and designed a lightweight refund flow with partial quantity adjustment that balanced staff empowerment with fraud prevention.

Snow-covered mountain peaks under a pastel sky
Cross-Functional Leadership

I partnered with Product and an external facilitator to design and run a 2-day workshop that brought together Partner Management, CS, Product, and Engineering. Each group brought a different lens — field intelligence, support patterns, business priorities, technical feasibility. The sprint surfaced the meat/seafood revenue leakage pattern that was business-critical but invisible in aggregate data.

I hired and managed a contractor UI designer, set the strategic direction and vision, and led stakeholder presentations and design reviews. The designer executed screens, handled iteration, and ensured cross-platform consistency. Throughout the 10-week delivery, we ran cross-functional reviews to validate decisions and surface constraints early. I stayed embedded with engineering — answering questions, refining designs around technical realities, and protecting coherence rather than moving immediately to the next initiative.

Measurement Constraints & Strategic Response

The cross-functional workshop and broad usability testing gave us stronger research foundations than the Shopper project — we tested across different store types, not just engaged partners. But post-launch measurement faces a structural challenge specific to the partner side. Each retail partner operates on their own IT roadmap with different rollout processes and timelines for adopting updates. The metrics we have reflect business outcomes but can't isolate which design changes drove which improvements.

I would have pushed to launch with 3–5 beta stores before full rollout. Real performance data — which workflows partners chose, where they dropped off, how refund usage affected pickup satisfaction — would have caught things testing alone can't surface. The rollout timeline didn't leave room for it. We mitigated through the workshop, broad testing, and staying embedded through delivery. But the better move is building beta programs into the project plan from the start — identify representative partners early, scope a 2–4 week beta window before the timeline is set, and define what "good enough to scale" looks like before launch, not after.

This project turned a neglected internal tool into a credible partner-facing product. The design decisions were grounded in field intelligence that aggregate data couldn't surface — and the workflows we built directly expanded marketplace supply in categories that drive shopper retention. The evidence-based approach established during this project replaced years of reactive feature development with validated design strategy.