Inxeption's ecommerce platform boasted powerful features—bulk pricing, tax exemptions, advanced quoting, and more. But sellers neglected to create high-quality product listings, leaving pages sparse and unappealing. This hurt their sales and made our marketplace look untrustworthy, threatening its success.
By grouping fields more logically and consolidating them from nine screens into one page with two views, sellers were guided to key fields, reducing time on task by 30%.
A sleeker, less cluttered UI made the process more intuitive.
A new preview feature cut unnecessary navigation.
My documentation and design reviews enabled engineering to implement the overhaul and new features in just four weeks with minimal bugs, reducing rework and freeing time and resources for new features.
Feedback from onboarding specialists confirmed we had solved key pain points, setting the stage for a dramatically improved seller experience.
The initial view for configuring or editing a product used stoplight colors and completion percentages. However, it required extensive reading, and the formulas became outdated as new fields were added.
After clicking into one section, the user had to scan every field to decide what was worth filling out. Our hypothesis was that it led to paralysis and abandonment.
Figma shows annotated instructions to engineering and QA. The final version is V6 at the bottom.
In early 2024, our Chief Design Officer tasked me with addressing sellers' poor product listings, which often lacked photos, descriptions, and specs.
To complete this project, I would:
Interview stakeholders and onboarding specialists
Perform a heuristic review of the existing flows
Research competitors
Present hypotheses to senior leadership for approval to continue
Design and develop detailed requirements for Engineering
Onboarding specialists I interviewed explained that in-person onboarding failed to improve results. Products published to the Inxeption Marketplace (similar to Amazon but for B2B) required minimal fields, but that didn't help, either.
While creating a product, I identified several issues related to a lack of onboarding:
There was no "welcome" guide. A seller first sees a dashboard upon logging in, which is helpful for return sellers, but for new sellers, it's empty. Also, there were no cross-sells or upsells which leadership wished to promote.
There was no hint of how or why to navigate to the Products module to get started. There platform supported customizable, dismissible onboarding blocks at the top, but our admins had not configured them.
From there, sellers needed to click the Create button, which was in a reasonable location, but could be more obvious.
The remaining issues related to a lack of guidance while setting up a product:
The creation screen collected only a few fields to create a database object. Sellers were then taken to the product's edit view, where they had to choose which fields to fill in. If they stopped here, the product would have minimal information.
In the edit view, sellers had to click into nine categories to access product fields. "% complete" indicators aimed to motivate completion but proved ineffective and unsustainable to maintain.
Fields within each category page were displayed with equal importance. Nothing showed which fields were most important to create good listing.
There was no preview. There was only an obscure workaround to see a preview, 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 offerings. Similar to the dashboard, there were no cross-sells or upsells.
Shopify, Square, and WooCommerce all had onboarding guides and simple one-page product creation, which perfectly addressed our two problems. Inspired, I proposed a new home page in place of our dashboards, which would be moved to a separate module.
The home page would have three states:
Onboarding guide for new sellers linking directly to product creation
Intermediate state with partially completed guide and content blocks for completed steps
Minimized guide for sellers who had sufficient content or were aware of further options
Context-sensitive cross-sells and upsells could be included, such as a service to feature products once a seller created their first product.
To address the second problem—lack of guidance while setting up a product—I began sketching a one-page product configuration.
This model reduced clicks, showed the most important fields first, added a preview, and included a context-sensitive progress guide.
Because I was aiming for quick feedback, my wireframes use plain text, magenta callouts, and bold colors to highlight areas that require discussion.
Senior leadership approved the concepts and had me continue. Feedback from onboarding specialists confirmed that this direction addressed sellers' struggles when onboarding and setting up products.
To accelerate progress, I handed off the guided home page design to another designer, reviewing their work weekly, while I focused on product configuration.
Unfortunately, the company went through layoffs at this point. Our team lost the other designer, prompting the Chief Design Officer, Director of Product Management, and me to reassess scope.
We prioritized guiding sellers through product configuration over directing them to the product area, as the former had greater long-term impact—once sellers knew where to go, navigation help became unnecessary, but difficulties in product creation persisted.
Given the project's visual nature and team changes, I also took on the product manager role while balancing two other major initiatives: a third-party payment terms integration and a freight shipping quoting method in checkout.
To begin my design work, I cataloged every feature using the current product groupings, marking the minimum set of required fields versus optional features (see previous diagram).
I then performed a card sort analysis (below) to reorganize groupings. For example, an "Advanced" bucket of features had grown organically over the years, which I moved to their respective sections.
Next, I removed advanced features from the default view, keeping only basic info, fields to persuade a buyer, or fields with code dependencies.
Finally, I added enhancement ideas from stakeholder discussions, and produced the following diagram. I used this to verify my thinking with the Director of PM and as a guide for my wireframes.
A core concept of this model was to initially show only the recommended fields for a solid product listing. But how would we expose the optional advanced fields?
My first attempt displayed optional fields in a modal. Filling those out would add them to the main page. You could edit the field either on the page or in the modal. If you cleared the field, it would disappear off the main page.
I discarded this model after a teammate pointed out that it would be expensive to change the UI based on whether or not a field was filled and lead to a longer implementation timeframe. Also, having the same content in two different screens would be bug-prone.
For my second attempt, you could select simple optional fields in a modal and edit complicated optional fields in a dedicated modal.
This version lasted until after I had moved from wireframes to mockups. But in one team review, the Chief Architect pointed out that it would be expensive to remember the state of the page for every setting, for every product.
For the third attempt, we settled on a more universal and elegant solution: the recommended fields would be displayed by default as "Simple" mode, and all the additional options would be included in "Advanced" mode. If any advanced fields were filled out, the system would display the UI in Advanced mode.
This third iteration reduced complexity while still satisfying the need to provide guidance and speed to the user. We arrived at this solution through discussion I led about my design artifacts.
When the wireflows gained enough consensus within PM, UX, and Eng, I switched to high fidelity mockups.
By adopting the UI from a more recent part of our platform, I modernized and streamlined the look and feel, which had been big, blocky, and "noisy," with many extra lines and containers. Below is just one before vs. after example.
I made heavy use of Figma components. Once the components were built, it was quick to prototype different page states without creating pages for each state. It also made it easy to try out different colors, typography, and spacing.
I worked closely with the Director of Front-End Development, who—using my Figma—pre-built React UI components for our engineering team, speeding up implementation with greater consistency. We met a few times to verify that his components matched my design. As you can see below, the resulting implementation was very close to the design.
As we neared the finish line, the mockups still included enhancements unlikely for MVP. To align the team, I led Product and Engineering through a MoSCoW exercise, ensuring consensus on "Must" and "Should" features. I removed "Could" and "Won't" items from the Figma to finalize the design.
That meant the cross-sell and upsell features requested by leadership fell out of scope, but it was the right approach since they weren't existing features that had to be preserved in this redesign. They could come later.
Given my role on this project as product manager in addition to designer, it was critical that I not only documented my design expectations, but also monitored implementation progress.
Starting with my documentation, I'm proud of the detail and use cases captured in this spec. Rather than a typical 30- to 60-minute spec review and design handover, I ran two extended calls to review the documentation, improving it with team feedback when they caught edge cases I missed. (Note that the PDF below didn't export perfectly, so a few images are rendered out of place.)
To check that implementation was on track, I set up sync calls for engineers to demo work in progress, where I provided early feedback that saved QA's time later.
The result: two engineers finished this huge overhaul 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.
We didn't test on customers due to time and budget constraints. But informally, when comparing how long it took three colleagues to create or edit a product with a couple images and certification badges, description, several key features and specifications, and shipping fields before the redesign vs. after, the time on task dropped from about a minute to 40–45 seconds, indicating an approximate reduction of ~30%. The drop is attributed to the inclusion of all fields on the Simple mode screen in the new design compared to the need to move the mouse to click in the left nav in the old design, even if you knew which section to select.
If we could have tested further, I would have liked to repeat the test with sellers, and then observe an open-ended task to set up a product without specifying fields to see which fields sellers filled out, and how quickly.
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.
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.