A seller listing tool that had outgrown its structure
B-Stock's listing tool accumulated listing types, purchase formats, and shipping modes over time. The combinations were real — but the tool had no clear structure for navigating them. I mapped every field, identified what decisions they each served, and restructured the tool into independent modules. Sellers see only what applies to their configuration.
As B-Stock expanded, the listing tool had to handle more listing types, more purchase formats, and more shipping arrangements. Each addition was a reasonable product decision. Together they created a form that branched in ways sellers couldn't predict.
The combinations were not the problem. The lack of structure for navigating them was.
I mapped each field to the decision it served. What looked like one long workflow was really a set of distinct decisions, each with its own module.
Each module appears only when it applies to the seller's configuration. Required modules are mandatory; optional ones surface based on earlier choices. A seller setting up a fixed-price listing moves through a different set than one running an auction — both see only what's relevant to them.
Each section in the listing detail mapped to a discrete module with a defined scope.
Sellers moved through only the decisions that applied to their listing. Each step had a defined scope, so the path was predictable.
For engineering, new listing types or formats could be added by introducing or modifying the relevant module — without restructuring the whole form. The modular model made the tool easier to extend without breaking what already worked.