Case Study: Streamlining Product Configuration

Help new sellers sell faster by simplifying product creation and editing

Summary

To increase the quantity and quality of product listings created by sellers, I redesigned the product configuration screens. After conducting interviews with stakeholders and onboarding specialists, competitive analysis, and a heuristic evaluation of the existing flow, I condensed the information architecture from nine pages to two views and modernized the UI to reduce distractions. I collaborated closely with Engineering and carefully considered user scenarios to provide detailed requirements. This collaboration enabled the team to successfully implement the overhaul in just four weeks.

Background

The core of Inxeption's seller platform centered around creating and selling products, similar to Shopify or Amazon, but with advanced B2B features. Our offering included robust features such as unlimited variant combinations, tax exemptions, advanced quoting and bidding, certification management (e.g., UL, CE, ISO), Docusign integration, multiple sales channels, and more.

Pain point

After sellers signed up, few created quality product listings. Given the breadth of our platform, why were sellers not using basic functionality? We hypothesized that the complexity of the onboarding or product setup processes was a barrier.

Goal

My task was to brainstorm high-level approaches to address these problems, present them to senior leadership who would narrow our focus, and develop detailed requirements for Engineering.

I would need to ideate on multiple potential approaches. Once we narrowed our scope, I would have to refamiliarize myself with all the features to ensure that we prioritized them appropriately and no feature was forgotten.

Furthermore, I also took on a product management role because it was a visually heavy initiative better suited to UX team ownership than PM ownership, while balancing two other significant projects: a third-party financing integration and a new freight shipping quoting method in the checkout flow.

Discover: What are the problems?

In early 2024, our Chief Design Officer tasked me with addressing sellers' poor product listings, which often lacked photos, descriptions, and specs. Our Support team's in-person onboarding failed to improve results. Products published to the Inxeption Marketplace (similar to Amazon but for B2B sellers) required critical fields, but they were still poor quality listings.

I reviewed a new seller's experience and identified key issues:

BI dashboard that new sellers see upon logging in, with no welcome guide.
Previous UI of product configuration page, with nine category blocks that sellers had to click into to see the fields. This UI used % complete indicators to guide sellers toward completion, but they proved ineffective and it wasn't scalable to update the % complete formulas as we added functionality over the years. A better UI with more transparency and guidance was needed.

To improve, I researched onboarding flows and e-commerce product creation flows from Shopify, Square, and others.

Conceptual wireframe "sketch" of a new home page setup guide with hovers to show more detail. The first step would direct sellers to create a product as their first goal. 
Sketch of an intermediate state of this new home page indicating completed steps and showing blocks related to completed steps.
Sketch of a final state of the new home page showing the all the blocks that could be available once all the modules were set up. The setup guide would be minimized.

I created wireframes for two areas: a guided home page for sellers (shown above) and a streamlined product creation flow that defaulted to critical fields with the option to add advanced fields. Senior leadership approved, and I moved forward.

After interviewing onboarding specialists, I learned sellers struggled with unclear initial steps and prioritization when filling out fields to create products. I then refined the wireframes based on this feedback.

Define: What's the flow? Which approach do we take?

To accelerate progress, I handed off the guided home page design to another designer, reviewing their layouts and interactions weekly. I focused on product configuration: mapping out existing product fields, their categories, and whether they should appear during creation. To simplify the information architecture, I reorganized categories and hid advanced fields from the initial view. Any field which contained basic information (such as name or price), which a buyer would want to see to help make a decision (such as product images, key features, or specifications), or which had to be defined up front due to other dependent fields (such as shipping, physical product vs. service, or one-time vs. subscription purchase) was included in the initial view.

SPC-lucid-feature-inv.pdf
SPC-lucid-reorg.pdf

I began a clickable low-fidelity wireflow demonstrating how advanced fields could be revealed.

Click to view larger

Because I was moving fast and sketching just enough to get internal feedback, this stage of wireframes uses plain text, magenta callouts, and bold colors to draw the eye towards areas that require discussion.

Click to open the v1 Figma screen

Unfortunately, after layoffs, our team lost the other designer, which led the Chief Design Officer, Director of Product Management, and me to reassess the project's scope. We shelved the guided home page design in favor of continuing to enhance product configuration, reasoning that guiding sellers to product creation would be futile if they encountered obstacles there, whereas helping sellers craft higher quality listings would have greater impact.

Design: What does the solution look like?

I iterated on my wireflow twice by May, improving interactions thanks to team feedback. Initially, I displayed key fields by default. Sellers could fill out additional fields in a modal. Upon saving, those fields would also appear on the page and be editable. I abandoned this approach when I received feedback that allowing editing both on the page and in a modal would lead to complications and an extended timeframe for implementation.

I updated the modal so that sellers could choose which simple fields to display on the page, while more complex functionality would be edited only in a dedicated modal.

First version: Edit additional fields in a modal and on-page
Next version: Select simple fields in a modal and edit them on-page
Additional iteration: Edit complex functionality only in a modal

After building a complete wireflow using this model, I presented to stakeholders to confirm the project direction. At this point, I switched to high fidelity mockups to bring in the UI from a more recent part of our platform. 

As I built out the final mockup, I made heavy use of Figma components to demonstrate my expectation of CSS and behavior, and so that it was quick to prototype different page states without creating entire pages for each state.

I also continued to present updated mockups internally, resulting in steady improvements. For instance, during one session, our Chief Architect pointed out that the current proposal would require us to save the display state of fields for every product, for every user, which would be expensive. We shifted to offering a "Simple" and "Advanced" mode. By default, products started in "Simple" mode, which contained the fields we felt were necessary for a quality listing. Any fields that we had planned to select in a modal were added to the "Advanced" view.

Transitioning from wireframe to final mockup:

Wirefame elements laid out on the page

Beginning to incorporate more polished UI and moving sections around based on feedback

Final design including the new "Simple" vs "Advanced" modes and "scrollspy" left nav

SPC-sheet-potential-features.pdf
MoSCoW exercise to define which functionality we were committing to.
SPC-sheet-base-vs-advanced.pdf
Comparing functionality that was available in the base channel vs additional channels against our proposal for "Simple" vs "Advanced" modes to make sure we didn't create impossible scenarios.

As we approached the finish line, I clarified what would be in the initial release by listing all the product configuration functionality and leading Product and Engineering through a MoSCoW exercise. We committed to all the Musts and Shoulds. I finished my design based on this list, removing the Could and Won't items from the mockups.

The second diagram shows another example of this kind of detailed feature planning to examine the effects of our new "Simple" and "Advanced" modes on our existing base channel and additional channel model.

Feel free to click through the Figma prototype. The final version is V6 at the bottom.

Deliver: What should engineering build?

My standard practice is to provide written UX requirements alongside mockups so the engineer has a checklist and the QA tester understands what to test. My documentation usually supplements the Jira story written by product management and engineering.

For this design-heavy feature, my documentation was the primary resource, detailing visual changes that might be overlooked, and I'm proud of how thorough it was.

Feel free to peruse my specifications to get a sense for the quality of my deliverables. These were written in Confluence which doesn't export perfectly. View the PNG images for the exact layout of the documentation, or download the PDF for smaller file size and legibility (though the layout of the images is buggy).
PNG, screen 1 of 5
PNG, screen 2 of 5
PNG, screen 3 of 5
PNG, screen 4 of 5
PNG, screen 5 of 5
SPC-UX-Product Creation Streamlining-150824-192133.pdf
PDF, forgive the imperfect export layout

I worked closely with the Director of Front-End Development, who pre-built components for our engineering team, which sped up implementation.

Normally, a design handover takes an hour or less, but for this feature, I ran two extended design handover calls to present the documentation and mockup. I also set up sync calls for engineers to demo work in progress, where I provided early feedback that saved QA's time later.

After about five months of design, two engineers finished in only four weeks! This is an example of "a stitch in time saves nine" and slowing down to speed up, exemplifying the value of thorough preparation that I bring to the table.

Conclusion

Many projects come with challenges. For this one, balancing two other high-priority projects and navigating layoffs while managing a visually focused project was particularly tough.

My design thinking, project ownership, cross-team consensus, and deep product knowledge helped define clear feature requirements, which enabled engineers to implement them swiftly. Addressing edge cases early also contributed to a faster rollout.

While the project took longer than usual, complete redesigns like this require a simultaneous release of all changes to avoid losing functionality, unlike incremental feature updates. Furthermore, excluding the time spent on other projects, the design phase would have taken 2–3 months, on par with a typical module redesign.

Despite Inxeption's closing before launch, feedback from onboarding specialists—who interact most with sellers—suggests we effectively addressed key pain points such as inadequate field collection, lack of guidance during editing, and visibility of fields. Had the feature been launched, it would have simplified and significantly improved the visual appeal and user experience.