Case study
Edward Martin Storefront
Replatforming a 6,000-SKU store — and building a design function while doing it.
- Client
- Edward Martin
- Role
- Head of Product Design Product strategy, UX architecture, IA, design system, design leadership
- Timeframe
- Nov 2025 – Jun 2026
- Outcome
- Launched August 2026 on a headless stack, with merchandising building pages without design or engineering
Edward Martin was moving its ecommerce storefront from a modified Shopify theme to a headless platform: Salesforce Commerce Cloud for commerce and Storyblok for content and merchandising.
I led the design work through that replatform. The mandate was not to reproduce the old store on a new stack, but to use the moment to improve how customers discover products, buy with confidence, and manage trade accounts—while creating the design systems and team practices the company needed to keep improving after launch.
The problem
The replatform required detailed design for every page and customer flow. That created an opening to address a bigger experience problem: research I commissioned through Edward Martin’s UX Research team showed that customers struggled to find what they were looking for.
The problem did not end in navigation. It extended through the full browse-to-buy journey—homepage, search, navigation, product listing and category pages, product pages, cart, checkout, payment, and account management.
Underneath the interface, the catalogue added another constraint. Around 6,000 SKUs had been migrated from Shopify one-to-one, along with attributes that were too rigid to support either the new discovery model or Salesforce Commerce Cloud effectively.
We needed to make a large catalogue easier to explore, create a credible experience for both retail and trade customers, and give merchandising the freedom to run the storefront without turning every layout change into a design or engineering request.
My role
As Head of Product Design, I owned the UX and design direction for the project.
I directed and commissioned the research, set the experience strategy, made the UX and design decisions, and designed crucial parts of the work myself. Alongside the storefront, I built the design function that had to deliver it—covered at the end of this case study.
Key decisions
Fix the data model before adding more interface
The most consequential design decision was not a screen. It was the product-attribute model behind the screen.
The catalogue had been migrated one-to-one, and its attributes described the old store rather than the products. Fields conflated separate concepts, duplicated one another, or meant different things in different categories—so there was nothing dependable to filter or navigate on. One inherited Use attribute is typical of the problem: it held compound values such as “Bathroom floor” and “Kitchen wall,” two ideas in a single field, requiring a new value for every combination the catalogue might grow into.
Working with the product team, who own the catalogue, I led a pass through the attributes category by category—splitting what had been conflated, consolidating what had been duplicated, and defining what each field was actually for. Use became Space and Type; other fields needed the same treatment for their own reasons.
The point was not tidier data. It made the model extensible, and it let product-listing filters be generated automatically per category or collection rather than maintained by hand. I used user-testing outcomes, past-customer feedback, and sales-team needs to decide what the model had to support, then wrote the documentation that made clear what the change would unlock in UX terms.
Separate discovery from browsing
Every category page on the old store was a product listing page with editorial and inspiration content stacked above the listing. Our research showed it served neither intent: people with a buying task scrolled past inspiration they hadn’t asked for, and people looking for ideas got a grid.
Drawing on NN/g’s work and other published research, I split the two. Every category now has an Explore page for discovery—inspiration, editorial, propositions—and a product listing page for browsing. Both sit in that category’s main navigation, and the two cross-link freely, but neither tries to do the other’s job.
The split lets the page match the intent. Someone who does not yet know what they want goes to Explore. Someone who wants white tiles goes to the listing page, where the first thing on screen is the filters.
- Filters and sort
- Dense product grid
- Sample CTAs
- Fast path to PDP
- Shop This Look scenes
- Buying guides
- Curated edits
- Editorial stories
Design navigation around real demand
The new navigation had to make the catalogue’s depth useful rather than overwhelming.
Primary navigation is category-led. Categories with subcategories open into a megamenu, with a left-hand subcategory selector and filter-led routes such as “Shop by space” and “Shop by colour.” The links promoted within each menu were chosen from click-rate analytics and Google search analysis, category by category.
One signal was unambiguous: Shop by space → Bathroom was the most-clicked link across the old navigation. That supported a dedicated Shop by entry for space and style, reinforcing both practical product discovery and the company’s investment in guide and editorial content.
Make one product page work for every kind of product
Edward Martin’s categories are not comparable to one another. A tile collection can run to 34 colours and 9 sizes with several finishes; a vanity comes in two colours. Tiles sell by the square metre, most other products sell as units. Rather than design a page per category, we built one modular product page that could carry all of them.
Clarity came first. The old page used thumbnails for colour, finish and size alike, so at a glance you could not tell the three apart. Each now has its own visual treatment.
The more consequential decision was to always show the whole collection. Every colour, size and finish is displayed, including combinations that do not exist. An unavailable colour appears disabled but stays clickable: choosing it switches to that colour and automatically selects the first available size or finish, and the same works in reverse. The customer sees at a glance what the collection can do, rather than discovering its range by trial and error.
The gallery was rebuilt around a large main image above the rest. Hovering a variant previews it in that main image, whatever is currently shown there; the images below act as slideshow thumbnails, but at a size that lets them be read on their own.
Finally, technical specifications, delivery details and other product information moved into drawers opened from a link—clearing enough room on the page for cross-sell and up-sell carousels and UGC content.
Make trade signup useful before approval
Trade was a distinct customer journey, not an edge case.
Previously, applicants submitted business information and ownership documents before an account was manually created after approval. I flipped that sequence: applicants create and verify a standard account first, then complete their trade application.
The change made the experience more useful immediately. Applicants could shop as normal customers while their trade application was pending, and approval became a confirmation rather than a manual account-creation step.
We rebuilt the account experience from the ground up too: a custom dashboard, order history with product thumbnails, live per-package status synchronised with Zenkraft, editable profile information, address management, and default billing and shipping preferences. Its structure also created headroom for future trade features, including multi-user organisations, invitations, and permissions.
Build checkout for the real purchase decision
We designed checkout around both the strengths and constraints of Salesforce Commerce Cloud, rather than inheriting a default flow.
One non-standard cart behaviour addressed a specific challenge in tile retail. When a recognised customer had never previously bought samples, the cart could offer to replace newly added tile products with their matching sample SKUs. For a customer considering a floor, sampling is a more confident next step than buying unseen.
The flow was also designed around CRM and ERP integrations for tax, stock, and shipping costs.
Design the motion, not the transitions
The site relies on photographs of rooms, so I treated their movement as part of the design. I set one rule: motion must never animate the interface. Each image is a window into a room; movement should let you look into that room, not decorate the page. If you can describe a transition afterwards, it has failed.
I built the motion with my team as a running prototype rather than a specification. It uses five planes: the photograph, a light that follows the pointer, the frame, the copy and the button. Each moves by a slightly different, very small amount. The photograph drifts away from the pointer, while the button moves furthest towards it, by no more than about eighteen pixels. Those differences are what the eye reads as depth.
Try it yourselfThe prototype opens in a new tab. Best with a mouse or trackpad — the depth answers the pointer.
Seven behaviours came out of it:
- Aperture reveal
- The wall parts and the room is already there. Interior cards never fade in.
- Establishing shot
- The hero room settles as the page loads, with the heading, copy and button landing on top of it in turn.
- Looking around
- Move the pointer and each layer answers at its own rate. Nothing chases the cursor; the room simply has depth.
- Travelling light
- A soft light crosses the interior with the pointer. On tile samples it reads as a sheen off the glaze.
- Daylight
- A warm pass drifts across the hero every few seconds, as though the sun had moved.
- Depth of field
- Hover one room and its neighbours soften, the way a lens racks focus.
- Stepping away
- The hero loses focus and dims as it scrolls out of view, while the page stays sharp.
Prototyping also exposed browser constraints: Safari does not interpolate custom properties for descendants, so the smoothing had to move into JavaScript. Blur could not be animated cleanly, so each photograph uses a pre-blurred twin that cross-fades.
None of this shipped in the MVP. Motion like this is expensive to get right across every browser and every image, so I put it into the same queue as visual navigation and sampling: designed, understood, and waiting for a release that could support it properly.
Design system and modular content architecture
I started Edward Martin’s first design system and secured leadership investment in it.
The system was the foundation for the whole interface: every UI element came from it; gaps, padding, and corner radii were managed as variables; and colour was managed as tokens. Design-system specialists worked alongside UX/UI designers to turn the work into well-formed components.
That system enabled a second, distinct piece of work: a modular pattern library for the storefront.
We built 22 flexible sections as Storyblok blocks, most with variants and configurable options. An image carousel could use portrait, square, or landscape images with copy either on the image or beneath it. Sections could show or hide supporting content; their internal components could configure further.
The decision was not to design each page upfront. Instead, I led the team through an analysis of the existing site and the needs of merchandising, synthesised the requirements into a section list, and designed each section from the design system across breakpoints and variants.
This shifted control to the people who operate the site. Merchandising can assemble a new page, reorder sections, or adapt a carousel in Storyblok without a design or engineering ticket. Design is no longer the bottleneck for routine layout changes.
Introducing AI as a team practice
Partway through the project, I introduced AI into the design process as both a tool and a deliberate operating practice.
For the team, it supported three areas:
- Concepting: rapidly exploring low-fidelity ideas before investing in detailed design.
- Prototyping: testing interactions that static screens could not explain, and making stakeholder decisions more tangible.
- Design QA: validating finished work against a definition of done and the requirements established in each Shape Up pitch.
For me, it became a daily operations hub across connected company systems—supporting planning, communication, high-level diagrams, and access to UX research.
The important shift was not asking individuals to experiment in isolation. It was designing a practical process around where the technology could make the team more deliberate.
What we cut — and why
Not every explored idea deserved a place in the MVP.
We explored visual navigation using thumbnail tiles for filters and their values. It looked promising, but the real cost was not the interface: every attribute and value would require an image, permanent maintenance, and a visual treatment even where no meaningful photograph could exist. We deliberately deferred the work for post-launch iteration rather than ship a partial version.
I also ran a cross-functional affinity session on sampling. It revealed that improving sampling was a broader project spanning product data, bundling, order management, packaging, discovery, customer expectations, and trade-account needs. These dependencies needed to land together, so we scoped it as a follow-on project rather than force an incomplete slice into the launch.
Both decisions were documented. They represent product judgement under a deadline: protecting the quality and coherence of what ships, while making the next opportunities visible.
How we validated the work
Validation was designed into the process at several levels.
The work started with research directed through the internal UX Research team, including persona development and prototype validation. The revised attribute model reflected evidence from user testing, past customers, and sales.
We then tested the modular architecture before implementation: could strong pages actually be assembled in Figma from the proposed sections alone? The answer shaped a second pass of improvements and additional variants.
Finally, we validated the system in the hands of its intended operators. Merchandising built and populated launch pages in Storyblok, selecting copy, imagery, product placement, and layout. Their feedback drove a final refinement pass.
For delivery QA, I introduced a definition of done that let the team check finished design work against the requirements established in each Shape Up pitch.
Building the team while shipping the product
Alongside the storefront, I built the foundations of the design function itself.
The team grew from two to seven people, including a freelancer I brought in for the final stretch. I established the operating model that had been missing: team rituals, reporting requirements, a design definition of done, and a single workflow that every piece of work followed — from pitch to implementation, with the tool, the steps and the hand-off defined at each stage.
With the CTO and Product Manager, I adopted Shape Up for this project to improve cross-functional alignment. We turned iterative pitches into decided solutions before detailed delivery began. My breadboards provided the high-level UX architecture that gave the teams a shared view of each solution before it moved into design and implementation.
Outcome
The new Edward Martin storefront launched in August 2026.
The project delivered more than a redesigned ecommerce site. It established a scalable way to structure and discover a complex catalogue, a stronger retail and trade experience, Edward Martin’s first design system, and a modular content architecture that allows merchandising to move independently.
It also left behind a stronger design function: a larger team, shared delivery practices, and a clearer way for product, design, and engineering to turn complex problems into buildable decisions.
For me, this was design leadership at both the product and organisational level—using a replatform to improve the customer experience now, while building the capability to improve it long after launch.