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:
Sellers would encounter our BI dashboard upon logging in. However, all the dashboard charts would be empty for a new seller. There was no "welcome" guide. There were no cross-sells or upsells.
Sellers would need to click to go to the Products module, but there was no indication of where to begin. There could be customizable, dismissible onboarding blocks at the top, but our admins had not configured those to instruct sellers to create a project.
From there, sellers would need to click the Create button, which was placed in a reasonable location, but could be more obvious.
The creation screen collected only a few fields to create a database object and landed sellers in the product's edit view, where they would have to figure out the important fields to create a good product listing.
In the edit view, sellers would have to click into nine category blocks to fill out fields for the product listing. The categories and fields within each category were displayed with equal importance. There was no guide to help a seller create a good product listing.
While setting up a product, there was no preview. There was a workaround to see a preview, but it wasn't obvious, so sellers didn't know what their product would look like until they finished configuring it.
While setting up a product, there was no education about other Inxeption offerings. Similar to the dashboard, there were no cross-sells or upsells.
To improve, I researched onboarding flows and e-commerce product creation flows from Shopify, Square, and others.
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.pdfSPC-lucid-reorg.pdfI began a clickable low-fidelity wireflow demonstrating how advanced fields could be revealed.
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.
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.
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.pdfSPC-sheet-base-vs-advanced.pdfAs 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.
SPC-UX-Product Creation Streamlining-150824-192133.pdfI 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.