Back to all work

Brahms · B2B2C SaaS · E-Commerce

Enabling 2,000+ retailers to launch their online stores

A 0→1 e-commerce platform built to compete with Shopify-level builders: a modular theme system that let retail brands, including Pier 1 and RadioShack, launch customizable storefronts without custom development, reaching 2,000+ stores registered on the platform.

Role

Product designer, owned end-to-end UX of the modular theme builder and store editor.

Team

2 designers, 1 PM, 4 engineers

The story in 30s

The problem. Before this project, theme customization relied heavily on predefined layouts. This limited flexibility for merchants, slowed iteration, and made it difficult to scale across industries: high dependency on predefined themes, slow theme creation and adaptation, and difficulty maintaining consistency at scale.

What I did. I designed a modular theme system composed of configurable, reusable sections, hero, product grids, navigation, footer, and a visual editor that let merchants assemble and customize stores without code, while preserving system rules. Decisions were informed by competitive analysis, qualitative customer insights, and Baymard Institute UX guidelines.

What changed. The platform launched in production with retail brands including Pier 1 and RadioShack, scaling to 2,000+ stores registered on the platform across multiple sectors.

The thinking: four rules that scale

The real risk wasn't any single screen: it was building system design instead of screen design. But the modularity itself had a constraint I didn't choose: for the MVP, engineering defined the building blocks, the actual section types and their limits, so we could ship fast rather than wait on a fully flexible system. My job was to work within that: apply Baymard Institute guidelines to decide which of those engineering-defined blocks actually mattered for merchants trying to convert, and shape the MVP around that subset instead of the full range I originally wanted. Four principles guided every decision within that constraint:

  • → Modularity: sections, not pages. Every page assembled from reusable, interchangeable sections, hero, product grids, navigation, footer.
  • → Constraints by default: fewer options, fewer broken layouts. Limiting what merchants could combine prevented layouts from breaking, instead of relying on merchants to notice.
  • → Predictability: same component, same behavior. Every component behaves consistently, whatever page or context it's dropped into.
  • → Progressive control: power without the overwhelm. Customization exposed gradually, not all at once, so new merchants get a fast start and power users still get depth.
Theme configuration scope diagram

Solution overview

A modular theme system, applied directly against the constraints above:

  • → 14 section types merchants could combine and reconfigure without touching code.
  • → 80+ configuration properties exposed progressively, not all at once.
  • → 6 theme presets giving merchants a fast starting point before customizing further.
  • → A visual editor that can't break the layout. It preserved system rules, so customization was safe by construction, not by the merchant's care.
Before and after comparison

Theme examples

Theme example 1
Theme example 2

Results

  • → Launched in production with retail brands including Pier 1 and RadioShack
  • → 2,000+ stores registered on the platform across multiple sectors
  • → Meaningfully more layout flexibility than the previous static-template approach, without adding custom dev work per merchant

Reflection

  1. 1 Rules scale. Screens don't. Defining components and constraints that could scale with the business mattered more than individual screen decisions.
  2. 2 Flexibility vs. speed, and speed had to win first. The building blocks were engineering-defined for the MVP, which meant less merchant customization than I'd have designed for in an ideal version. I used Baymard's guidelines to prioritize which constraints mattered most for conversion, so the limited set we shipped still worked hard for merchants, even though it wasn't the system I'd have built with more time.
  3. 3 System-level design compounds, even a constrained one. One consistent set of rules, even a narrower set than intended, scales in a way one-off screen decisions never could.
Next: expand the block library beyond the engineering-defined MVP set, giving merchants the layout flexibility that was deferred for launch speed.

Work

Enterprise Analytics Dashboard Redesign AI Translation System for 62+ Languages Scaling a Startup Program Management Platform (Coming soon)