Case study — product ecosystem strategy
Common Associate Store Experience
A vision to remove the organizational friction & disconnect of technology org verticals & Associates’ real-world experiences.
- The problem
- A 100+ application Store ecosystem, locally optimized and horizontally fragmented — inconsistent UI, duplicated components, incompatible front-end choices, and too much knowledge pushed onto the associate.
- What I did
- Defined the Common Associate Store Experience (CASE) Northstar, drove Product and Engineering to a formal front-end standard — React or Angular on shared Google Material components — hired the design-system capability, and turned the strategy into common navigation, deep linking, contextual guidance and role-aware patterns.
- What shipped
- A formal Store front-end and design-system guardrail with a working design-system practice behind it; common navigation and deep-linking patterns prototyped; priority products moving to shared patterns and services; and the Northstar carried into a 2030 vision, where 89% of associates who tested it said it actually would significantly make their jobs a lot easier!
Listen & read this case study
Opening
- 1×
- 1.25×
- 1.5×
- 2×
- 2.5×
- 3×
Loading audio
Individual Store applications could get better and the associate experience could still get worse. Every balanced team had a reasonable local backlog; the associate had to stitch all of those decisions together while standing in an aisle, helping a customer, receiving a task, or learning the job.
I defined a different unit of strategy: the Store associate’s work environment, not the application boundary. This Northstar was a common experience that could remain technically distributed underneath while becoming increasingly coherent, role-aware and connected on the surface.
That required more than vision work. Over roughly three years I worked across Product, Engineering and executive leadership to formalize a narrower Store front-end direction — React or Angular, supported by shared Google Material design-system/components — and to build the design-system capability, governance and team behavior needed to make that standard useful.
The strategy later expanded through to Team Tangerine’s 2030 vision into a rich role-aware experience across Home, search, tasking, communications, Know How, account/device and selling. The through-line stayed the same: hide the application chaos and let the experience follow the work.
Improving every app was not enough
The visible symptom was inconsistent UI. The actual problem was fragmentation as an operating model.
Associates did not come to work thinking in portfolios or product boundaries. They came in thinking: what do I need to do, who needs help, where is the product, and what matters next?
By 2024, roughly 80 applications were loaded on the associate handheld alone; the Store ecosystem as a whole ran past 100. Some of those products were individually successful. Together, they still asked the associate to know which tool, device and interaction model belonged to which part of the job.
How do many Product teams and technical systems remain underneath while the associate increasingly experiences one coherent workplace?
That became the Northstar question. The answer was never “replace every application with one giant app.” It was to define what should become common — navigation, interaction patterns, components, tasking, notifications, search, guidance, identity and context — and make application boundaries progressively less important to the person doing the work.
Turn the Northstar into executable layers
By 2022, the strategy was no longer only a future-state picture.
The Common Associate Store Experience (CASE) work translated the Northstar into three connected mechanisms: a front-end UI framework, a Store Design System, and an end-to-end experience proposal. The first created reusable implementation leverage. The second made the experience standard visible and usable. The third kept every vertical team connected to the horizontal associate journey.
The first stage — Crawl — was done by 2022: Google Material design-framework alignment, a dedicated hire whose sole focus was on design-system capability, and cross-team UX + Product collaboration.
I hired specifically for this capability because the Store portfolio did not have an enterprise design-system operating model we could simply adopt. We had to create one, rally teams around it, and make it usable enough that teams could stop recreating the same interaction patterns product by product.
The harder dependency was underneath the pixels
A reusable experience is only as reusable as the technical environment underneath it.
Balanced teams had historically been given broad latitude to choose their front-end implementation. Locally, that autonomy could feel fast and attractive. At portfolio scale, it produced a tax: duplicated engineering, hard-coded components, inconsistent behavior, design-system drift, technical debt and much harder cross-product integration.
Across those years I drove alignment with Product, Engineering and executive leadership toward a formal Store guardrail: React or Angular, with shared Google Material components and design-system guidance. Store intentionally did not standardize around Ant, even though it was used elsewhere in the enterprise.
Developer autonomy is valuable; however, continued unrestricted front-end autonomy created an enterprise integration tax.
So the work became governance as much as architecture: reusable assets, review, enablement, clearer exception handling and repeated course-correction across UX, Product and Engineering. Teams with dedicated UX coverage eventually became much more consistent; teams without strong UX/Product attachment remained the hardest edge case.
By 2023, I purposely connected the same constraints of this to the Unified Tasking strategy as well: the applications were not on the same design system, so even small UI changes were hard to coordinate — and unifying the application ecosystem was sized as work worth dedicated balanced-team capacity.
Give the ecosystem one interaction layer
Of course, this common experience needed a way to operate across products without asking the associate to understand the products underneath it.
The 2023 Tasking work made the Common Associate Store Experience (CASE) interaction model concrete: a Seamless Associate Experience built from ubiquitous navigation, common components and interaction patterns, and illustrated contextual guidance. The task repository, rules engine and prioritization system are their own story (Unified Tasking); what mattered for Common Associate Store Experience (CASE) was what those systems made possible on the surface.
The planning then separated what was required for a seamless experience from what the shared platform could enable. Required capabilities included a centralized task list, deep linking, global navigation / IA and native notifications. The same foundation could enable more granular metrics, systemically prioritized field-task creation and store-level reprioritization.
That distinction matters: Common Associate Store Experience (CASE) was not a visual skin. It was a product/platform contract between the visible experience and the shared services underneath it.
Global navigation was the clearest expression of the strategy: navigate by the work, not by the app name.
The concept replaced application brands, acronyms and internal jargon with natural-language & job-function labels. It was intended to remain available as associates moved between experiences, with deep links taking them directly to the specific place needed to complete work rather than forcing another login, launcher decision or navigation tree. The destination was to be a common interaction layer over a technically distributed ecosystem.
The role-aware version is especially important because a Store Leader, Aisle Associate and POS Associate should not receive the same undifferentiated menu. The system should know enough about role and context to expose the right capabilities while keeping the underlying application ownership invisible.
This is also where the front-end standard and deep-linking work connect directly: a common shell is only useful if teams can reuse components consistently and if the experience can move an associate into the right destination without making them mentally reconstruct the technical architecture.
Make the experience teach the work
A common experience had to reduce more than just visual UI inconsistency. I specifically codified how we had to reduce how much institutional knowledge the associate had to memorize.
By 2022, Sidekick and BOLT (teams I supported & managed) executed parts of this strategy directly into specific associate tasks: what to do, how to do it safely, and which related system action may be required. This was the start of the snowball which showed how this guidance model could travel across products.
This work connected to the CEO’s “Day 2” ambition, which was: for selected core tasks, how could the application experience make a new associate roughly 60–80% as effective as a more tenured associate by Day 2? That range was the target we set.
Design for the horizontal associate journey
Day 2 was the sharpest version of the problem. It was not the whole problem.
Vertical application teams could see what happened inside their product. What they could not see was what piled up between products over one associate’s shift — so in 2022 my team put three associates on one timeline: an in-aisle veteran, an in-aisle “Day-1,” and a freight veteran, and mapped a single day as the questions each of them had to answer to get through it. More than fifty questions, and each one tagged with the application that held the answer — ten different apps across the day, and three or four of them behind a single question like “what’s the most important thing I could be doing right now?”
The emotional curves did the rest. The Day-1 associate’s day dropped at “looks like I’ll need to learn all these apps ASAP” and never fully came back. The veteran’s day dipped every time he had to stop and find something for a customer. And when the trucks ran behind and that same veteran went to help on freight, his curve fell with hers — “I’m not as familiar with the Freight apps.” Tenure didn’t protect either of them. It only changed which app was the unfamiliar one.
Unless a new associate has been extensively trained and afforded time to learn all the idiosyncratic needs to complete specific tasks — it’s impossible to expect an associate to swarm across the store and help in areas where it’s deemed a priority and high value. This is also a problem for experienced associates… their task completion speed is slowed after engaging an unfamiliar app experience.Common Associate Store Experience strategy, 2022
Every one of those questions had a labor cost the store was already paying: a second associate shadowing the first, a supervisor fielding the escalation, a veteran working slower in a tool that wasn’t his. That is the horizontal journey, and it is why the strategy carried three goals in this order — cut onboarding time; let any associate help with any task they’re qualified for, the “Any Associate, Anywhere” standard Store was already asking of its people; and reduce the friction of moving between apps to finish a piece of work.
This continued to cement what “common” meant. The strategy was not one generic UI for every role. It was a shared experience architecture capable of adapting to the associate’s role, context and work while maintaining recognizable patterns underneath.
Carry the strategy forward: from apps to experiences
This was a multi-year effort, deep and wide, and by the time the 2030 work began a lot of the foundation was in — and a lot of the hardest part was still ahead.
What was done. The front-end guardrail and the design-system practice behind it. “Know How” living inside the task in a number of apps. Common navigation and deep linking, prototyped at high fidelity and moving into priority products. The work inventory and prioritization engine underneath it all — Unified Tasking. An ease-of-use score on every Store application, so the friction finally had a number (Experience Measurement). And a journey model that tied associate friction to the customer outcomes business leaders were already accountable for (Journey Management). Each of those is its own case; together they are the foundation this one set out to build.
What was left was the big, slow part — the pieces that only move when every vertical team moves together: one home surface, one search, one notification layer, the role-aware shell over the whole ecosystem, and a portfolio of 100+ applications still migrating toward the standard, team by team. At the core, the current state was still asking the associate to know which app and device to use to finish their task.
The Product argument also became more explicit: Associate-Back → Customer-Back → Business Bottom Line. Simplification was tied to training and retention, associate satisfaction, sales/productivity, services attachment, margin and customer confidence.
Nobody asked me for this vision. I initiated the Common Associate Store Experience as a strategy, got it bought into, and pushed it forward for years. By 2025 the role had changed around me: the Experience Measurement and Journey Management practices I had built were now explicit responsibilities of mine across the Store portfolio, and Team Tangerine — an all-volunteer squad drawn from across the Store experience teams — took up the torch on the 2030 vision: “From Apps... to Experiences.” I still carried the end-to-end Store portfolio experience, the continuation of the Northstar I’d been driving. That is what a strategy is supposed to do: keep moving when the person who started it gets pulled onto the next thing.
Four role-based journeys from the 2030 vision show how the same common experience architecture adapts across onboarding, selling, leadership and front-end operations while reusing the same underlying capabilities.
What changed — and what was still moving
Put the ledger in one place. This was not a one-interface launch. It was a multi-year change to the default architecture and decision behavior of a very large ecosystem.
- ✓Google Material alignment and dedicated Store design-system capabilityimplemented
- ✓A formal Store front-end/design-system guardrail across Product, UX and Engineeringformalized
- ✓Stronger reusable-component, review and compliance mechanismsoperationalized
- ✓Priority experiences including MyView, BOLT and Sidekick moving toward shared patterns/servicesimplemented in parts
- ✓Global navigation, natural-language IA and role-aware access defined and prototyped as common cross-product patternsdefined / prototyped
- ✓Deep linking and merged experiences progressing in key areasimplemented in parts
- ✓The Northstar carried forward into Team Tangerine / 2030 and role-based concept validationadvanced
- ·Full convergence across the entire 100+ application Store ecosystemincomplete
- ·Consistent adoption in teams without reliable UX/Product coverageongoing challenge
The result was not a perfectly unified Store — and claiming that would erase the reality of legacy systems, technical debt, vertically owned roadmaps and uneven team capacity.
The result I would defend is different: we changed the expected direction of travel. Shared components, front-end constraints, cross-product patterns, deeper integration and a role-aware Northstar became legitimate portfolio concerns rather than optional UX preferences.
What I’d do differently
Getting the standard agreed turned out to be the easy half.
Establish enforcement and enablement at the same time as the standard
We won the strategic argument before the operating mechanism was fully mature. For too long, compliance depended on whether I or a strong UX/Product partner happened to be close enough to a team to catch drift. If I ran this again, the standard would launch with the governance, component ownership, review mechanisms, training and exception path already in place. A platform standard is not finished when leaders agree with it; it is finished when the organization can operate it without heroic advocacy.
What this work proves
I did not solve this by owning every Product roadmap. I solved it by changing what the portfolio was optimizing for.
I moved a 100+ application Store ecosystem toward a common experience strategy, drove a formal front-end and design-system standard across Product and Engineering, built reusable experience capability, connected technical choices to deep linking and cross-product integration, and kept the Northstar focused on the associate’s role and work rather than the org chart underneath it.
The work demonstrates product vision, platform strategy, technical dependency judgment, governance, organizational change, long-range sequencing and influence without authority — grounded in actual UI, actual implementation constraints and actual product-team behavior.