Archive resale
Admin App
An operational platform for managing resale inventory and merchandising – a model traditional e-commerce tools weren't built to support.
Project Overview
About archive resale
Archive builds and operates resale-as-a-service programs for enterprise brands, powering buy-back, listing, resale storefronts, and the operational tools that support them.
the problem
Traditional e-commerce platforms are built around products with relatively stable inventory. Resale introduces a fundamentally different model: each product can contain dozens of unique listings, each with its own seller, condition, pricing, and fulfillment. Existing admin tools weren't built for that model, and as Archive expanded, the internal tooling had grown piecemeal around evolving business needs rather than a cohesive system.
the solution
Rather than tackling disconnected feature requests, I approached Admin as a platform that would grow over time. I rolled out the experience through four deliberate phases: Collections, Listings, Listing Review, and Discounts & Seller Incentives. Each release solved an immediate business problem while laying the groundwork for the next. In parallel, I led a full visual redesign of Admin as part of Archive's company-wide rebrand.
MY ROLE
I was the sole designer on Admin, working directly with an engineering partner and product management to define product direction, translate ambiguous business requirements into scalable product decisions, and design the end-to-end experience across every phase of Merchandising and the rebrand.
The Difference in Data Models
Traditional e-commerce
Taylor Dress
Colors
Blue, Green
Sizes
S, M, L
Inventory
Static (100 units)
Price
$148
Resale e-commerce
Taylor Dress
Colors
Blue, Green
Sizes
S, M, L
Inventory
Dynamic (3 units)
Listing · Brand-owned
Size M · Green · Like New · Brand Seller
$60
Listing · P2P
Size S · Blue · Excellent · Seller Name
$50
Listing · P2P
Size L · Green · Good · Seller Name
$40
Shaping the platform
Before designing interfaces, I worked with Product, Growth, and Engineering to define how the platform should evolve –evaluating tradeoffs, prioritizing opportunities, and translating an emerging resale business into scalable product decisions.
Considerations & Goals
Design constraints
- Data quality varied a lot brand to brand – some had rich attribute data (season, color), others didn't
- Requirements were still evolving alongside the underlying business model
- Patterns needed to scale to future modules – Products, Collections, Discounts
Business Goals
- Reduce operational dependence on engineering for routine listing and merchandising work
- Establish design patterns that could extend cleanly to future Admin modules, like Discounts
- Replace a manual, spreadsheet-driven merchandising process with something that scales
User needs
- Find and edit a listing without going through engineering or a workaround tool
- Understand what's actually live vs. sold at a glance
- Trust that bulk, irreversible-feeling actions are actually safe and reversible
Process
Build vs. Buy
Before investing in a custom solution, we evaluated whether an existing merchandising platform could support Archive's resale workflows.
While it handled traditional collections well, it couldn't model resale-specific logic without significant customization. We chose to build a purpose-built solution instead.
Iterative Releases
Rather than planning the entire platform upfront, we prioritized features based on the operational work consuming the most time for Brand Success.
Collections came first because brands were repeatedly exporting and rebuilding spreadsheets to merchandise inventory.
From there, we worked in iterative releases: scope the smallest useful version, ship it, test it with real users, then re-evaluate and reprioritize what came next.
Rule Definition
Many of the hardest design decisions weren't about interface, they were about idenitfying users’ mental models and defining how the product should behave.
Questions like whether "All Products" should include historical inventory, or how search should behave inside collection rules, needed consistent answers before engineering could begin.
Documenting those decisions upfront reduced ambiguity and prevented inconsistent implementations later.
Mapping the System
Before designing individual screens, I mapped how Products, Listings, Collections, Review, and Discounts could relate to one another, along with opportunities and possible issues.
Understanding those relationships made it easier to identify reusable workflows, expose brand-specific requirements early, and design patterns that could scale instead of solving each feature independently.
For example, one brand wanted manual control over which color faced out on a shared PLP, another ran seasonal drops that needed rule-based ranking instead of hand-sorting, and several brands had no color-attribute data to filter on at all.
Soltutions
The platform evolved through four deliberate phases, with each release solving an immediate operational need while establishing the foundation for what came next.
phase 1
Collections
Before
Merchandised collections existed, but building one meant exporting a spreadsheet, filtering it manually, and uploading a static CSV of items. Nothing could sort or update itself as inventory changed, so every refresh was a manual redo.
After
First, collections became rule-based instead of static. Rules were defined by attributes (price, brand-owned vs. peer-to-peer, listing age) rather than a fixed CSV, so the collections could update as stock changed.
Once rules existed, sort followed. A default sort could be set to apply to every collection, using priority order of metrics like sell-through rate, size availability, condition. A custom sort could also be applied per collection.
User Testing Collections
Ahead of rolling out rule-based collections, we ran moderated testing sessions with brand users, walking through the collection-building flow and probing for gap between how the tool worked and how people expected it to work.
Users defaulted to "in stock" thinking
Some users assumed they were only ever working with in-stock products and were confused when out-of-stock items appeared. The default view was changed to match that mental model.
Sort logic needed to be visible
Users' instinct was to drag and drop every item into order by hand, even though sorting was rule-based. This was a sign the logic needed to be legible, not just correct.
Icons carried unintended risk
A trashcan icon for removing an item from a collection read as permanent deletion to several testers, prompting a look at lower-anxiety alternatives like a show/hide toggle.
phase 2
Listings
One of the biggest limitations of the original Admin experience was that it only surfaced Products (the top-level catalog record).
However, products aren't what customers buy in resale, they buy individual listings. Every listing has its own seller, condition, size, and pricing. Not surfacing listings meant Brand Success couldn't effectively search, merchandise, or troubleshoot the inventory that was actually live on site.
Listings table
Each listing received its own searchable index, detail page, filters, and actions, allowing users to work directly with the individual items moving through the marketplace instead of navigating through the product catalog first.
Listings VIew
Brand teams could now view the details and history of all listings. Collections could now merchandise inventory based on listing-level attributes like condition, seller type, or listing age.
Other features like Listing Review could build on the same underlying patterns instead of introducing separate workflows.
phase 3
Listing Review
After seeing how successful the new Listing Details pattern was, I identified an opportunity to reuse it within Listing Review. By extending an existing design pattern rather than creating a separate workflow, we improved review efficiency while minimizing implementation effort.
Before
Getting user-submitted or unassociated warehouse listings reviewed in a timely manner meant increased supply.
However, the listing review portal was divided, clunky, and required users to go back and forth and scroll unnecessarily. The view of the listings was also a PDP preview, which lead with product information and a user had to dig to get to the listing information.
Additionally, for listings that had receipt review, accessing the receipt images required multiple steps and was not accessed in an intuitive manner.
After
On my own initiative, I applied that same Listing Details pattern to Listing Review and designed a queue where user-submitted (peer-to-peer) and warehouse listings get approved before going live.
Reviewers got the same searchable, detailed view instead of a separate, thinner workflow, which made review faster and got new supply onto the site sooner.
Benefitting from the increased ease of development with Agentic tools, I worked with engineering to slot this in and delivered a time-saving tool to our users without disrupting our road map.
phase 4
Discounts & Seller Incentives
Discounts
With Collections and Listings both structured and rule-driven, discounts could finally be applied on top. We were also able to facilitate discounts with eligibility rules (customer type, minimum purchase, max uses) and a start/end schedule, instead of being handled as one-off, manual price edits.
Seller incentives
Once the discount structure existed, the same rule and schedule model translated directly into seller incentives. These promotions encouraged sellers to list inventory without inventing a second system to do it.
ongoing
Visual System & Rebrand
Before
The original Admin interface used a dense, orange-accented visual system inherited from an earlier stage of the product and brand: large type, a bright CTA orange, and spread-out information.
Additionally, when I started there was no design system or consistency across our internal tools (Admin, Customer Service, Warehouse Management).
After
The new system moved to a quieter black, white, and single-accent palette and modern typography. I found that most admin tooling defaults to dense, small type to maximize information on screen. However, after interviewing the people who used Admin every day, we kept body and table text noticeably larger than that convention, trading some density for legibility and reduced fatigue across long sessions.
In tandem, I created a design system across all of our internal tools. Even though the tools did not have the same users, consistent formatting and components increased polish to potential customers and reduced design and engineering time. Instead of creating new, custom components for each new feature, we had a library to build from.
Impact
Metrics have been generalized to protect confidential business performance data.
Operational Self-Service
Internal and external users could search, view, and safely edit listings without an engineering workaround for the first time
Merchandising Efficiency
A manual, spreadsheet-driven process repeated every few weeks per brand became a rule-based system that keeps itself current
Third-Party Dependence
Building in-house avoided a costly, poorly-fitted vendor tool and let sort logic reflect resale-specific signals instead
Reusable Design Patterns
Table, bulk-action, and detail-page patterns established here became the default starting point for later Admin features and other internal tools
jump to
Archive resale
Admin App
An operational platform for managing resale inventory and merchandising – a model traditional e-commerce tools weren't built to support.
Project Overview
About archive resale
Archive builds and operates resale-as-a-service programs for enterprise brands, powering buy-back, listing, resale storefronts, and the operational tools that support them.
the problem
Traditional e-commerce platforms are built around products with relatively stable inventory. Resale introduces a fundamentally different model: each product can contain dozens of unique listings, each with its own seller, condition, pricing, and fulfillment. Existing admin tools weren't built for that model, and as Archive expanded, the internal tooling had grown piecemeal around evolving business needs rather than a cohesive system.
the solution
Rather than tackling disconnected feature requests, I approached Admin as a platform that would grow over time. I rolled out the experience through four deliberate phases: Collections, Listings, Listing Review, and Discounts & Seller Incentives. Each release solved an immediate business problem while laying the groundwork for the next. In parallel, I led a full visual redesign of Admin as part of Archive's company-wide rebrand.
MY ROLE
I was the sole designer on Admin, working directly with an engineering partner and product management to define product direction, translate ambiguous business requirements into scalable product decisions, and design the end-to-end experience across every phase of Merchandising and the rebrand.
The Difference in Data Models
Traditional e-commerce
Taylor Dress
Colors
Blue, Green
Sizes
S, M, L
Inventory
Static (100 units)
Price
$148
Resale e-commerce
Taylor Dress
Colors
Blue, Green
Sizes
S, M, L
Inventory
Dynamic (3 units)
Listing · Brand-owned
Size M · Green · Like New · Brand Seller
$60
Listing · P2P
Size S · Blue · Excellent · Seller Name
$50
Listing · P2P
Size L · Green · Good · Seller Name
$40
Shaping the platform
Before designing interfaces, I worked with Product, Growth, and Engineering to define how the platform should evolve –evaluating tradeoffs, prioritizing opportunities, and translating an emerging resale business into scalable product decisions.
Considerations & Goals
Design constraints
- Data quality varied a lot brand to brand – some had rich attribute data (season, color), others didn't
- Requirements were still evolving alongside the underlying business model
- Patterns needed to scale to future modules – Products, Collections, Discounts
Business Goals
- Reduce operational dependence on engineering for routine listing and merchandising work
- Establish design patterns that could extend cleanly to future Admin modules, like Discounts
- Replace a manual, spreadsheet-driven merchandising process with something that scales
User needs
- Find and edit a listing without going through engineering or a workaround tool
- Understand what's actually live vs. sold at a glance
- Trust that bulk, irreversible-feeling actions are actually safe and reversible
Process
Build vs. Buy
Before investing in a custom solution, we evaluated whether an existing merchandising platform could support Archive's resale workflows.
While it handled traditional collections well, it couldn't model resale-specific logic without significant customization. We chose to build a purpose-built solution instead.
Iterative Releases
Rather than planning the entire platform upfront, we prioritized features based on the operational work consuming the most time for Brand Success.
Collections came first because brands were repeatedly exporting and rebuilding spreadsheets to merchandise inventory.
From there, we worked in iterative releases: scope the smallest useful version, ship it, test it with real users, then re-evaluate and reprioritize what came next.
Rule Definition
Many of the hardest design decisions weren't about interface, they were about idenitfying users’ mental models and defining how the product should behave.
Questions like whether "All Products" should include historical inventory, or how search should behave inside collection rules, needed consistent answers before engineering could begin.
Documenting those decisions upfront reduced ambiguity and prevented inconsistent implementations later.
Mapping the System
Before designing individual screens, I mapped how Products, Listings, Collections, Review, and Discounts could relate to one another, along with opportunities and possible issues.
Understanding those relationships made it easier to identify reusable workflows, expose brand-specific requirements early, and design patterns that could scale instead of solving each feature independently.
Mapping it this way surfaced real, brand-specific needs early. One brand wanted manual control over which color faced out on a shared PLP, another ran seasonal drops that needed rule-based ranking instead of hand-sorting, and several brands had no color-attribute data to filter on at all.
For example, one brand wanted manual control over which color faced out on a shared PLP, another ran seasonal drops that needed rule-based ranking instead of hand-sorting, and several brands had no color-attribute data to filter on at all.
Soltutions
The platform evolved through four deliberate phases, with each release solving an immediate operational need while establishing the foundation for what came next.
phase 1
Collections
Before
Merchandised collections existed, but building one meant exporting a spreadsheet, filtering it manually, and uploading a static CSV of items. Nothing could sort or update itself as inventory changed, so every refresh was a manual redo.
After
First, collections became rule-based instead of static. Rules were defined by attributes (price, brand-owned vs. peer-to-peer, listing age) rather than a fixed CSV, so the collections could update as stock changed.
Once rules existed, sort followed. A default sort could be set to apply to every collection, using priority order of metrics like sell-through rate, size availability, condition. A custom sort could also be applied per collection.
User Testing Collections
Ahead of rolling out rule-based collections, we ran moderated testing sessions with brand users, walking through the collection-building flow and probing for gap between how the tool worked and how people expected it to work.
Users defaulted to "in stock" thinking
Some users assumed they were only ever working with in-stock products and were confused when out-of-stock items appeared. The default view was changed to match that mental model.
Sort logic needed to be visible
Users' instinct was to drag and drop every item into order by hand, even though sorting was rule-based. This was a sign the logic needed to be legible, not just correct.
Icons carried unintended risk
A trashcan icon for removing an item from a collection read as permanent deletion to several testers, prompting a look at lower-anxiety alternatives like a show/hide toggle.
phase 2
Listings
One of the biggest limitations of the original Admin experience was that it only surfaced Products (the top-level catalog record).
However, products aren't what customers buy in resale, they buy individual listings. Every listing has its own seller, condition, size, and pricing. Not surfacing listings meant Brand Success couldn't effectively search, merchandise, or troubleshoot the inventory that was actually live on site.
Listings table
Each listing received its own searchable index, detail page, filters, and actions, allowing users to work directly with the individual items moving through the marketplace instead of navigating through the product catalog first.
Listings VIew
Brand teams could now view the details and history of all listings. Collections could now merchandise inventory based on listing-level attributes like condition, seller type, or listing age.
Other features like Listing Review could build on the same underlying patterns instead of introducing separate workflows.
phase 3
Listing Review
After seeing how successful the new Listing Details pattern was, I identified an opportunity to reuse it within Listing Review. By extending an existing design pattern rather than creating a separate workflow, we improved review efficiency while minimizing implementation effort.
Before
Getting user-submitted or unassociated warehouse listings reviewed in a timely manner meant increased supply.
However, the listing review portal was divided, clunky, and required users to go back and forth and scroll unnecessarily. The view of the listings was also a PDP preview, which lead with product information and a user had to dig to get to the listing information.
Additionally, for listings that had receipt review, accessing the receipt images required multiple steps and was not accessed in an intuitive manner.
After
On my own initiative, I applied that same Listing Details pattern to Listing Review and designed a queue where user-submitted (peer-to-peer) and warehouse listings get approved before going live.
Reviewers got the same searchable, detailed view instead of a separate, thinner workflow, which made review faster and got new supply onto the site sooner.
Benefitting from the increased ease of development with Agentic tools, I worked with engineering to slot this in and delivered a time-saving tool to our users without disrupting our road map.
phase 4
Discounts & Seller Incentives
Discounts
With Collections and Listings both structured and rule-driven, discounts could finally be applied on top. We were also able to facilitate discounts with eligibility rules (customer type, minimum purchase, max uses) and a start/end schedule, instead of being handled as one-off, manual price edits.
Seller incentives
Once the discount structure existed, the same rule and schedule model translated directly into seller incentives. These promotions encouraged sellers to list inventory without inventing a second system to do it.
ongoing
Visual System & Rebrand
Before
The original Admin interface used a dense, orange-accented visual system inherited from an earlier stage of the product and brand: large type, a bright CTA orange, and spread-out information.
Additionally, when I started there was no design system or consistency across our internal tools (Admin, Customer Service, Warehouse Management).
After
The new system moved to a quieter black, white, and single-accent palette and modern typography. I found that most admin tooling defaults to dense, small type to maximize information on screen. However, after interviewing the people who used Admin every day, we kept body and table text noticeably larger than that convention, trading some density for legibility and reduced fatigue across long sessions.
In tandem, I created a design system across all of our internal tools. Even though the tools did not have the same users, consistent formatting and components increased polish to potential customers and reduced design and engineering time. Instead of creating new, custom components for each new feature, we had a library to build from.
Impact
Metrics have been generalized to protect confidential business performance data.
Operational Self-Service
Internal and external users could search, view, and safely edit listings without an engineering workaround for the first time
Third-Party Dependence
Building in-house avoided a costly, poorly-fitted vendor tool and let sort logic reflect resale-specific signals instead
Merchandising Efficiency
A manual, spreadsheet-driven process repeated every few weeks per brand became a rule-based system that keeps itself current
Reusable Design Patterns
Table, bulk-action, and detail-page patterns established here became the default starting point for later Admin features and other internal tools
jump to
Archive resale
Admin App
An operational platform for managing resale inventory and merchandising – a model traditional e-commerce tools weren't built to support.
Project Overview
About archive resale
Archive builds and operates resale-as-a-service programs for enterprise brands, powering buy-back, listing, resale storefronts, and the operational tools that support them.
the problem
Traditional e-commerce platforms are built around products with relatively stable inventory. Resale introduces a fundamentally different model: each product can contain dozens of unique listings, each with its own seller, condition, pricing, and fulfillment. Existing admin tools weren't built for that model, and as Archive expanded, the internal tooling had grown piecemeal around evolving business needs rather than a cohesive system.
the solution
Rather than tackling disconnected feature requests, I approached Admin as a platform that would grow over time. I rolled out the experience through four deliberate phases: Collections, Listings, Listing Review, and Discounts & Seller Incentives. Each release solved an immediate business problem while laying the groundwork for the next. In parallel, I led a full visual redesign of Admin as part of Archive's company-wide rebrand.
MY ROLE
I was the sole designer on Admin, working directly with an engineering partner and product management to define product direction, translate ambiguous business requirements into scalable product decisions, and design the end-to-end experience across every phase of Merchandising and the rebrand.
The Difference in Data Models
Traditional e-commerce
Taylor Dress
Colors
Blue, Green
Sizes
S, M, L
Inventory
Static (100 units)
Price
$148
Resale e-commerce
Taylor Dress
Colors
Blue, Green
Sizes
S, M, L
Inventory
Dynamic (3 units)
Listing · Brand-owned
Size M · Green · Like New · Brand Seller
$60
Listing · P2P
Size S · Blue · Excellent · Seller Name
$50
Listing · P2P
Size L · Green · Good · Seller Name
$40
Shaping the platform
Before designing interfaces, I worked with Product, Growth, and Engineering to define how the platform should evolve –evaluating tradeoffs, prioritizing opportunities, and translating an emerging resale business into scalable product decisions.
Considerations & Goals
Design constraints
- Data quality varied a lot brand to brand – some had rich attribute data (season, color), others didn't
- Requirements were still evolving alongside the underlying business model
- Patterns needed to scale to future modules – Products, Collections, Discounts
Business Goals
- Reduce operational dependence on engineering for routine listing and merchandising work
- Establish design patterns that could extend cleanly to future Admin modules, like Discounts
- Replace a manual, spreadsheet-driven merchandising process with something that scales
User needs
- Find and edit a listing without going through engineering or a workaround tool
- Understand what's actually live vs. sold at a glance
- Trust that bulk, irreversible-feeling actions are actually safe and reversible
Process
Build vs. Buy
Before investing in a custom solution, we evaluated whether an existing merchandising platform could support Archive's resale workflows.
While it handled traditional collections well, it couldn't model resale-specific logic without significant customization. We chose to build a purpose-built solution instead.
Iterative Releases
Rather than planning the entire platform upfront, we prioritized features based on the operational work consuming the most time for Brand Success.
Collections came first because brands were repeatedly exporting and rebuilding spreadsheets to merchandise inventory.
From there, we worked in iterative releases: scope the smallest useful version, ship it, test it with real users, then re-evaluate and reprioritize what came next.
Rule Definition
Many of the questions weren't about interface, they were about users’ mental models and how they should influence the product’s behavior.
Questions like whether "All Products" should include historical inventory, or how search should behave inside collection rules, needed consistent answers before engineering could begin.
Documenting those decisions upfront reduced ambiguity and prevented inconsistent implementations later.
Mapping the System
Before designing individual screens, I mapped how Products, Listings, Collections, Review, and Discounts could relate to one another, along with opportunities and possible issues.
Understanding those relationships made it easier to identify reusable workflows, expose brand-specific requirements early, and design patterns that could scale instead of solving each feature independently.
For example, one brand wanted manual control over which color faced out on a shared PLP, another ran seasonal drops that needed rule-based ranking instead of hand-sorting, and several brands had no color-attribute data to filter on at all.
Solutions
The platform evolved through four deliberate phases, with each release solving an immediate operational need while establishing the foundation for what came next.
phase 1
Collections
Before
Merchandised collections existed, but building one meant exporting a spreadsheet, filtering it manually, and uploading a static CSV of items. Nothing could sort or update itself as inventory changed, so every refresh was a manual redo.
After
First, collections became rule-based instead of static. Rules were defined by attributes (price, brand-owned vs. peer-to-peer, listing age) rather than a fixed CSV, so the collections could update as stock changed.
Once rules existed, sort followed. A default sort could be set to apply to every collection, using priority order of metrics like sell-through rate, size availability, condition. A custom sort could also be applied per collection.
User Testing Collections
Ahead of rolling out rule-based collections, we ran moderated testing sessions with brand users, walking through the collection-building flow and probing for gap between how the tool worked and how people expected it to work.
Users defaulted to "in stock" thinking
Some users assumed they were only ever working with in-stock products and were confused when out-of-stock items appeared. The default view was changed to match that mental model.
Sort logic needed to be visible
Users' instinct was to drag and drop every item into order by hand, even though sorting was rule-based. This was a sign the logic needed to be legible, not just correct.
Icons carried unintended risk
A trashcan icon for removing an item from a collection read as permanent deletion to several testers, prompting a look at lower-anxiety alternatives like a show/hide toggle.
phase 2
Listings
One of the biggest limitations of the original Admin experience was that it only surfaced Products (the top-level catalog record).
However, products aren't what customers buy in resale, they buy individual listings. Every listing has its own seller, condition, size, and pricing. Not surfacing listings meant Brand Success couldn't effectively search, merchandise, or troubleshoot the inventory that was actually live on site.
Listings table
Each listing received its own searchable index, detail page, filters, and actions, allowing users to work directly with the individual items moving through the marketplace instead of navigating through the product catalog first.
Listings VIew
Brand teams could now view the details and history of all listings. Collections could now merchandise inventory based on listing-level attributes like condition, seller type, or listing age.
Other features like Listing Review could build on the same underlying patterns instead of introducing separate workflows.
phase 3
Listing Review
After seeing how successful the new Listing Details pattern was, I identified an opportunity to reuse it within Listing Review. By extending an existing design pattern rather than creating a separate workflow, we improved review efficiency while minimizing implementation effort.
Before
Getting user-submitted or unassociated warehouse listings reviewed in a timely manner meant increased supply.
However, the listing review portal was divided, clunky, and required users to go back and forth and scroll unnecessarily. The view of the listings was also a PDP preview, which lead with product information and a user had to dig to get to the listing information.
Additionally, for listings that had receipt review, accessing the receipt images required multiple steps and was not accessed in an intuitive manner.
After
On my own initiative, I applied that same Listing Details pattern to Listing Review and designed a queue where user-submitted (peer-to-peer) and warehouse listings get approved before going live.
Reviewers got the same searchable, detailed view instead of a separate, thinner workflow, which made review faster and got new supply onto the site sooner.
Benefitting from the increased ease of development with Agentic tools, I worked with engineering to slot this in and delivered a time-saving tool to our users without disrupting our road map.
phase 4
Discounts & Seller Incentives
Discounts
With Collections and Listings both structured and rule-driven, discounts could finally be applied on top. We were also able to facilitate discounts with eligibility rules (customer type, minimum purchase, max uses) and a start/end schedule, instead of being handled as one-off, manual price edits.
Seller incentives
Once the discount structure existed, the same rule and schedule model translated directly into seller incentives. These promotions encouraged sellers to list inventory without inventing a second system to do it.
ongoing
Visual System & Rebrand
Before
The original Admin interface used a dense, orange-accented visual system inherited from an earlier stage of the product and brand: large type, a bright CTA orange, and spread-out information.
Additionally, when I started there was no design system or consistency across our internal tools (Admin, Customer Service, Warehouse Management).
After
The new system moved to a quieter black, white, and single-accent palette and modern typography. I found that most admin tooling defaults to dense, small type to maximize information on screen. However, after interviewing the people who used Admin every day, we kept body and table text noticeably larger than that convention, trading some density for legibility and reduced fatigue across long sessions.
In tandem, I created a design system across all of our internal tools. Even though the tools did not have the same users, consistent formatting and components increased polish to potential customers and reduced design and engineering time. Instead of creating new, custom components for each new feature, we had a library to build from.
Impact
Metrics have been generalized to protect confidential business performance data.
Operational Self-Service
Internal and external users could search, view, and safely edit listings without an engineering workaround for the first time
Third-Party Dependence
Building in-house avoided a costly, poorly-fitted vendor tool and let sort logic reflect resale-specific signals instead
Merchandising Efficiency
A manual, spreadsheet-driven process repeated every few weeks per brand became a rule-based system that keeps itself current
Reusable Design Patterns
Table, bulk-action, and detail-page patterns established here became the default starting point for later Admin features and other internal tools
jump to