Merging a store split across two platforms into one, with live POS inventory behind it
Youth Sports Platform
Snapshot
A premium sports retailer was running half a website on PHP and half on Shopify. Content pages — home, services, media, promos, gallery — lived in one system; the shop lived in another. Inventory was managed in a LightSpeed POS that neither reflected in real time. I designed the consolidation onto a single Shopify platform, restructured the catalogue so twenty-plus categories were reachable on arrival, and rebuilt the front end responsive. The client reported a 57% sales increase in the first four weeks after launch.
MY ROLE:
Product Designer + Frontend Developer
TIMELINE:
3 weeks · Q2 2025
TEAM:
PM, BA, me, implementation partner
SCOPE:
Two platforms merged to one · 20+ categories
OWNERSHIP:
Product Designer + Frontend Developer
STATUS:
Product Designer + Frontend Developer
The problem
Three things were wrong at the same time, and they compounded.
The site was two sites. Home, Services, Media, Promos and Gallery were a single-page PHP build. The shop was Shopify. A customer crossing between them crossed platforms, and the business maintained two systems to run one store.
Inventory lived somewhere else again. Stock, pricing and product data were managed in a LightSpeed POS with no real-time link to the storefront, so what the site showed and what the shop actually had could drift apart.
And the catalogue was unreachable. Twenty-plus categories — apparel, hockey equipment, skates, sticks, goalie gear, baseball and softball, roller and street hockey, training, accessories — sat behind a dropdown. Four were visible without opening it.
3 weeks
Timeline
No iteration runway and no second launch.
1 platform
Platform
Shopify backend locked; one domain target.
20+
Categories
Catalogue depth needed to be discoverable on arrival.
3 seconds
Performance
Hard load-time requirement with full plugin stack.
Research
I interviewed eight customers who had abandoned carts. Seven gave a version of the same sentence: "I gave up looking for the product I wanted." Heatmap data confirmed it — the navigation menu was rarely opened.
I also took the brief's design reference apart properly. The client wanted to look like the market leader; I needed to know why the leader worked. What it does is refuse to hide its catalogue — depth is exposed rather than nested. That was the transferable lesson, and it was structural rather than cosmetic, which meant I could adopt it without copying the visual language.
The insight that decided the project: shoppers didn't want more options, they wanted to find the one they arrived for. With three weeks, that reframed the work from "match the reference" to "make the catalogue visible" — narrower, and shippable.
How I worked
Three weeks doesn't survive a normal handoff. A Figma file, a spec, a build sprint and a QA round is four weeks on its own — so I didn't run one. I designed in Figma only as far as the decisions required, then built the rest directly in Liquid, in the browser, against the real catalogue.
I sequenced by what could not be built twice. The platform consolidation went first, because everything else sits on top of it. The catalogue restructure came second, because it set what the homepage and every category page had to hold. The responsive rebuild ran in parallel with the visual refresh, because I was doing both myself and neither blocked the other.
Working in the theme changed what I could decide. The category grid landed on twelve cards because I could see — in the live theme, with the real SKUs loaded — that twelve held at 375px and sixteen collapsed. The actual constraint turned out to be the product photography's aspect ratios, which only surfaced once real images were in the grid rather than placeholders. It also let me find out early what each plugin actually rendered, and design the page around its real output instead of a mockup of what I wanted it to be. Two layout decisions changed once I saw what the search plugin returned.
The honest cost: designing in code biases you toward what's cheap to build. Twice I caught myself choosing the layout the theme already supported rather than the one the shopper needed, and had to step back into Figma to make the decision away from the constraint before returning to implement it.
Decision 1 — Consolidate onto one platform rather than restyle two
Everything moved to Shopify on a single domain — the PHP content pages rebuilt as Shopify pages, the shop absorbed, the POS wired in behind it.
What I rejected: restyling both systems to match, which was the cheaper three-week option and avoided a migration entirely. I passed because it would have locked in the underlying problem. Two systems means two content models, two release paths, and a seam the customer feels every time they cross it. The visual fix would have shipped faster and left the business maintaining the thing that was actually costing it.
What it cost: a migration inside a three-week window, with content moving platforms while the theme was being built on top of it.
Decision 2 — Expose the catalogue on arrival
Twelve category cards in the body of the homepage, replacing four nav items with everything else behind a dropdown.
What I rejected: a mega-menu — the conventional answer for a deep catalogue, and the one that preserved the minimal homepage the client liked. The heatmap had already shown this audience doesn't open menus, so a better menu is still a menu. Putting categories in the page body meant they were found rather than looked for.
What it cost: the homepage lost its minimalist composition, which was a real argument with the client. Discoverability won it.
Outcome: the client reported category page views up 120%.
Decision 3 — Rebuild the theme responsive, against the performance budget
A CSS grid layout rewritten in Liquid, tested on six physical devices, built against a three-second page-load requirement.
What I rejected: patching the existing responsive rules. The breakpoints were layered years deep and every fix risked a regression somewhere I couldn't see. A rebuild was more work up front and far less risk in week three — and it was the only way to hold the performance budget with a predictive-search plugin, an upsell engine and a loyalty app all wanting space on the page.
What it cost: froze all new feature work for two weeks.
Outcome: the client reported mobile traffic up 40% and bounce rate down 22%.
Beyond the three decisions
Three parts of the scope that don't appear in the headline but shaped every page.
Bilingual and dual-currency. English and French, Canadian dollars by default with US conversion — which constrains every string, every price component and every layout that can't reflow when a label doubles in length.
A three-second load requirement with a full commerce stack active. Predictive search, upselling and loyalty all wanted space on the critical path, and the budget was the thing that decided what got to stay.
Plugin-delivered components. Search, POS sync and upselling were explicitly out of scope for custom development, so I was designing around components I couldn't restyle freely.
Validation
With three weeks and no testing infrastructure, I validated by preference rather than by split test. I put both navigation structures in front of 12 people and both visual directions in front of 10, asking which let them find a specific product faster. The new structure was preferred by 78%, the refreshed visual language by 82%.
It isn't an A/B test and I wouldn't claim it as one — no traffic split, no statistical power. It was enough to de-risk two decisions I had to make that week.
Responsive behaviour was verified on six physical devices, and page load was checked against the three-second requirement with the full plugin stack active.
Influence, and what outlived the project
The PM wanted new features shipped alongside the replatform. I pushed back with the heatmap and the interview transcripts — customers were giving up after two clicks, and adding surface area to a store people already couldn't navigate would make the core problem worse. It escalated to the CEO, and the focused scope won. We shipped a tighter product instead of a bloated release, and the features that were cut went into a backlog with evidence attached rather than being dropped.
What came out of it was a sequencing method the team kept: list the constraints, map each one to a design decision, order by what can't be retrofitted later. On a three-week timeline that ordering is the whole game — get it wrong and you discover it in week three, when there is no room left to absorb it.
Outcomes
Consolidated a two-platform store onto one, restructured the catalogue, and shipped a rebuilt responsive theme in three weeks — as the sole designer and the person who wrote the theme code.
As reported by the client after launch: sales up 57% in the first four weeks, category page views up 120%, mobile traffic up 40% and bounce rate down 22%. The replatform shipped as a single change, so these describe what happened after launch rather than what each decision caused independently.
Learnings
Discovery beats features. One structural change to the catalogue outperformed the five features we didn't ship.
A named reference is a brief, not an answer. Being told to look like the market leader is only useful once you work out which part of it is doing the work. The answer was structural, which meant I could take it without copying the surface.
Designing against plugins is designing with a partner who won't negotiate. Half this stack was configuration rather than code. Finding out early what each component actually rendered was worth more than any amount of designing what I wished it rendered.
What I'd do differently
I'd bring the visual direction into research instead of locking structure first and refreshing after. Testing whether premium visual signals moved behaviour — before committing to a full refresh — would have either saved a week of rework or given me a much stronger claim about why it mattered.
I'd also push for a pre-launch baseline beyond the platform's own analytics. The 57% is the client's number and I trust it, but I can't tell you as precisely as I'd like which part of the work produced it.