B2B SAAS · MARKETPLACE & ADMIN · SEARCH & DISCOVERY
A domain-fluent filter system built around how wine is actually bought: multi-attribute, taxonomically precise, and architecturally scalable to any auction vertical on the platform.
Wine is bought by specificity. A buyer searching for a 1982 Bordeaux from a named producer under £3,000 had no way to narrow the catalogue.
The platform's filter had no concept of wine attributes: a system built for antiques, applied to a domain where taxonomy, provenance, and storage status are the primary purchase signals.
Bacchus Wine Auctions made it a condition of switching platforms. That condition became the brief.
Scope emerged from research. Wine taxonomy ambiguity, In Bond complexity, and format naming each required structural responses that a standard filter could not provide.
The solution was a multi-attribute filter system covering both marketplace and back-office admin, with a new component set added to the design system. The admin cataloguing interface was redesigned to remove the four-category cap and introduce In Bond duty calculation. Built mobile-first, white-label deployable, and scalable to other auction verticals.
Research came first. Stakeholder interviews, domain research into wine taxonomy and bonded storage regulations, and competitive analysis beyond the wine and auction industry informed every structural decision.
The filter was built mobile-first, with component logic abstracted from the domain so the same architecture can serve any auction vertical.
The process closed with a Figma prototype reviewed and approved by all stakeholders.
The existing filter allowed multiple categories to be selected, but changing a single choice meant resetting everything and starting over. There was no clear structure, no filter hierarchy, and no progressive disclosure. Just a large grid of options with inconsistent naming and no sense of priority. For a user searching for something specific, it was difficult to know whether it existed in the catalogue at all.
Two filters, two platforms, and a clear gap between what existed and what was needed.
The filter was built for a basic auction model in an industry that is traditionally analogue and slowly moving through a digital transformation. Multiple categories could be selected, but removing or changing a single filter meant resetting the entire search. For wine buyers who search with very specific combinations like a region, a grape variety, a vintage, a price range, a format and a producer, this made exploratory browsing nearly impossible. Users had no way to see how results shifted asfilters changed, which removed the core behaviour that drives discovery and bidding intent.The filter list had no hierarchy, required heavy scrolling, and used inconsistent naming that was overwhelming and assumed prior knowledge of the catalogue structure.
In the existing back-office admin, auction houses could assign a maximum of four categories per lot. A single bottle of wine naturally belongs to several categories simultaneously: a country, a region, a grape variety, a producer, and a format. With that limit in place, there was no way for a wine connoisseur to find exactly the right bottle across large, unsorted catalogues. The filter can only surface the data tied to the item, and that data was far too narrow for the wine industry.
Bacchus Wine Auctions had stated explicitly that wine handling across both the marketplace and the admin was a prerequisite for switching to Skeleton. The business pressure was not implicit. It was a commercial condition with a name attached, a timeline, and a competing platform on the other side of the decision.
Discovery spanned six industries and three user segments. Stakeholder interviews across different roles at Bacchus Wine Auctions established who the filter actually needed to serve. Domain vocabulary came from wine and auction, but the competitive analysis extended deliberately into other industries to build on established UX patterns from outside the auction domain.
Stakeholder interviews across commercial, cataloguing, and front-of-house roles at BacchusWine Auctions established three distinct user segments: professional wine merchants with precise requirements, fine restaurants sourcing specific vintages, and first-time bidders the auction house was actively trying to attract. Each segment had a different relationship to the filter. Professionals needed depth and speed. Restaurants needed producer- and vintage-level precision. First-time bidders needed orientation without assuming prior knowledge of wine taxonomy. In the design, these translated into four mental models: collectors, investors, casual buyers, and trade.
The competitive analysis spanned six industries. For wine vocabulary, filter logic and hierarchy, the auction and wine platforms were the primary references. Sotheby's and Wineauctioneer offered two contrasting approaches to expert-oriented filtering, while Systembolaget showed how wine-specific terminology can be made accessible to a broader audience. Tech retail, furniture, fashion, and cars contributed to structural and interaction patterns. Progressive disclosure combined with search-within-filter emerged consistently across all six industries.
Competitive filter analysis: a selection from a broader reference set spanning auction and retail. Sotheby's and Wineauctioneer for expert-oriented auction filtering; Systembolaget for domain-specific retail at scale. Each informed a different part of the design: vocabulary, hierarchy, and interaction structure.
Researching wine naming revealed a structural problem that was easy to miss: in wine, the same word can legitimately refer to different things. Champagne is a region, an appellation, and a wine. Chablis is a village, an appellation, and a Chardonnay, but a buyer unfamiliar with wine would have no way of knowing that from the label alone. In a multi-attribute filter, the same term can appear under Country, Region, Grape Variety, and Wine Type all at once. This was not a content problem to be solved with better copy. It required a specific UI response.
“Some things can complicate matters. A wine may contain several grape varieties, and Champagne can refer both to a region and to the protected appellation. A Jeroboam does not always mean the same thing; in Champagne it holds 3 litres, whereas in Bordeaux it has historically been 5 litres.”
Bacchus Wine Auctions, stakeholder interview
One word, five valid interpretations: protected appellation, geographic region, sparkling wine style, legally incorrect generic term, and a bottle format that means different things depending on where the wine was made. The interface needed to make the distinction navigable without requiring users to already know the difference.
Wine format is not just size. A Jeroboam is 3 litres in Champagne and 5 litres in Bordeaux, a difference rooted in regional naming convention that stretches back centuries. Formats follow a naming tradition with deep historical roots: Rehoboam, Methuselah, Salmanazar, Balthazar, Nebuchadnezzar, each a distinct size, each holding a different number of standard bottles, and each relevant to how auction lots are valued and described. This was an entirely new domain for me, and before I could begin to tackle the design challenge I needed to go deep into the subject matter. Understanding the difference between format, the physical container and its volume, and packaging type, how the lot is presented for sale, was necessary groundwork. Collapsing these into one field would have made the catalogue less meaningful for expert users.
Designing for bonded wine meant going beyond UX into legal and tax territory. Wines stored in bond have unpaid import duties and taxes attached, and the cost difference between buying in bond and duty-paid can be substantial and is easy to miss if you have never come across it before. This demanded a genuine understanding of the regulatory framework: alcohol tax law, customs status, and when duties become payable. The real design challenge was representing that distinction accurately for two very different users: the experienced buyer who expects precision, and the first-time bidder who needs clarity without being overwhelmed. Designing the admin interface also required understanding the duty calculation itself: how quantity, volume, and ABV combine to determine duty in GBP, and why showing each step of that formula matters for operational trust.
Retail sites optimize filters for speed and purchase completion. Wine and auction platforms optimize for expert discovery and exploration. The two rarely appear in the same product, which made the research phase particularly valuable. References spanned six industries: tech, retail, furniture, fashion, cars, auction, and wine. Across all of them, every filter used progressive disclosure and some form of hierarchy, revealing options gradually rather than presenting all categories at once on the same level. That stood in direct contrast to Skeleton's legacy filter, where every category was visible simultaneously with no hierarchy between them.
Process began with a constraint: the filter needed to work for wine today and for cars or watches tomorrow. Every decision was evaluated against both the domain-specific requirements and the underlying architecture.
Designing for scale rather than wine alone was a shared goal from the start. Skeleton's platform strategy meant the filter had to work across any auction vertical without being rebuilt each time, making scalability a direct business requirement tied to onboarding new clients. One of the core design challenges was knowing what to separate: the wine-specific attribute taxonomy on one side, and the global interaction patterns like filter state, chip behaviour, and range logic on the other. Bacchus brought the domain expertise on wine, while the platform architecture was worked out through competitive analysis and close collaboration with the team.
The filter needed to support four distinct mental models: collectors searching by producer, investors by vintage and In Bond status, casual buyers by wine type or region, and trade buyers by format. Each attribute was designed independently based on how that data is actually used. Each filter was designed around how buyers naturally search. Vintage and Estimate combine a range slider with direct input for both exploration and precision. Producer is searchable because the list is too large to browse. Format combines volume, name, and abbreviation (for example, "1.5 L Magnum (mg)") to support both experts and first-time buyers.Facet counts help buyers see what's available before filtering, making the experience feel more exploratory. In Bond was placed at the top because it's an early decision point for experienced buyers and an important concept for newcomers. It also sits outside the core attribute system, reflecting its regulatory and financial role.
One key decision was whether Region should depend on Country or work as its own filter. While some platforms hide regions until a country is selected, Bacchus wanted Region to be independent. This matches how experienced wine buyers search, often starting with regions like Burgundy or Champagne rather than the country. Competitive analysis supported the decision, aligning Bacchus with other expert-focused wine auction platforms.
Selected filter iterations. Country, Region, Format, Producer, and Vintage each resolved a distinct interaction, labelling, or hierarchy challenge.
The count badge on each active category solved a real usability problem. In wine taxonomy, the same term can appear in multiple categories, so users need to see where their selections belong without scanning the entire filter. The idea came from SaaS admin interfaces, where making active selections visible is standard practice. Although engineering questioned it due to time constraints, we kept it because it solved a genuine interaction problem. Without it, the filter would have been harder to understand, especially for users with limited wine knowledge.
A horizontal filter bar does not scale to long attribute lists, range inputs, and search fields. A modal overlay that hides the catalogue entirely is the standard mobile pattern; the decision was to accept that trade-off where it was justified and resolve it where it was not.On mobile, the filter opens as a full-screen overlay. This was a deliberate accessibility call: maintaining a minimum 14px type size, preserving readable facet counts, and keeping touch targets large enough to use without precision all required the full width. The constraint was not the layout; it was legibility at the right scale.On desktop, the panel sits alongside the catalogue. Results update in real time as filters are applied, making the browsing experience more exploratory and easier to read at a glance. The same component, different behaviour per context.
The project brought together a cross-functional team spanning design, product, engineering, sales, and customer success. Research and stakeholder interviews ran in parallel, with regular check-ins ensuring alignment throughout the process.Having a frontend development background made collaboration with engineering significantly more efficient, reducing back-and-forth and allowing design and technical decisions to move forward together rather than in sequence.The process closed with an interactive Figma prototype, reviewed and approved by all stakeholders including Bacchus Wine Auctions.
The solution is a multi-attribute filter designed around how users actually search for wine: byproducer, vintage, region, format, and In Bond status simultaneously. It includes a new filterexperience for buyers, a redesigned cataloguing interface for admins, and a new componentset added to the design system, built to scale across future auction categories.
Filter panel open alongside the catalogue on desktop. Active filters are visible as chips, with facet counts showing available lots per option.
The project expanded the design system with a new set of filtering components, including filter chips, range sliders with direct input, searchable filter lists, facet counts, and category badges for active selections. The previous system supported only basic checkboxes and a single search field, making this a significant step towards a more scalable filtering experience.
The design is built on Raleway, the Barnebys Group typeface, and structured for white-label use. Typography size, line height, and weight are fixed by the system, while typeface, colour and branding are handled separately in each client implementation. The category badge illustrates this in practice: in the Bacchus version it takes on their brand color while the underlying system remains unchanged. Accessibility standards were applied throughout, with the understanding that white-label delivery introduces constraints outside the designer's control.
Filter options that return zero results are disabled rather than hidden. In faceted search, filtersaffect each other, and hiding unavailable options obscures the logic of the system. Keepingthem visible and disabled stabilises the list, communicates that the option is valid but currentlyunmatched, and builds user trust. For an auction platform where inventory changescontinuously and return visits matter, that transparency is commercially relevant
Within each facet, inventory volume takes precedence over alphabetical order, surfacing the most available options first while keeping the full list accessible through search.
The filter panel as a full-screen overlay on the smallest supported screen size. In Bond sits at the top, the estimate range combines a slider with direct input, and active selections are summarised as chips at the bottom. A badge on each category indicates whether it has active selections. The panel closes by swipe or via the close button, supporting both touch interaction and accessibility needs.
The filter can only surface what exists in the catalogue, making the admin cataloguing experience just as critical as the buyer-facing interface. Alongside the new filter, I redesigned the cataloguing workflow within an admin system built on a mix of Ant Design, Telerik, and custom components accumulated over time. One of the broader goals was to make the system more consistent, and this redesign was a step in that direction.
Removing the four-category limitation was an immediate improvement, allowing auction houses to assign as many attributes as a lot required and directly improving the quality of data available to buyers. The most complex part was supporting In Bond calculations. Cataloguers enter quantity, volume, and ABV, and the system calculates total volume, pure alcohol, and duty in GBP. Every step is shown with its underlying formula rather than just the final value, making the process transparent and easy to verify.
To reduce manual work, Bacchus requested document upload support during the research phase. The workflow supports uploads that automatically populate catalogue fields. Users review and edit before publishing, and the validated data flows directly into the existing lot page.
The filter was designed with future configurability in mind, allowing auction houses to manage their own attributes. Due to time and budget constraints, the first release took a simpler approach, with attributes hardcoded and managed by developers.While this creates an ongoing dependency on engineering, the underlying architecture separates attribute taxonomy from the filter structure. This means self-service configuration can be added later without redesigning the system.
The interactive prototype captured the complete filter experience, from an empty state to attribute selection, active filter chips, and category count badges. It was designed to demonstrate how the interface evolved as users refined their search, while validating key interaction patterns before development.The prototype was reviewed and approved by both the internal team and Bacchus Wine Auctions before handoff.
The Catalogue Behind the Filter. The admin interface solution where auction houses catalogue item attributes and calculate In Bond duty, which then surfaces directly in the buyer-facing lot page. Parts of the screen are blurred for confidentiality.
Stakeholder interviews across commercial, cataloguing, and front-of-house roles at Bacchus Wine Auctions revealed three distinct user segments: professional wine merchants with precise requirements, fine restaurants sourcing specific vintages, and first-time bidders the auction house was actively trying to attract. Each segment shaped different parts of the filter's priority hierarchy.
The core design problem was framed as abstraction, not wine. The architecture needed to be domain-agnostic so the same component could serve a car auction or a watch house by reconfiguring the attribute set, not the structure.
Domain research into wine taxonomy and bonded storage regulations shaped specific design decisions. The naming ambiguity in wine, where Champagne is simultaneously a region, an appellation, and a wine, required a structural UI response rather than a content fix. In Bond status required legal accuracy, not just a label.
Each attribute type was designed independently: range sliders for estimate and vintage, checkboxes for multi-select lists, search-within-filter for long taxonomic lists. The right interaction model per data type took priority over visual consistency.
A vertical panel was chosen over a horizontal bar or modal overlay. On desktop, it is the only layout that keeps filter state and catalogue results visible simultaneously and supports eight or more attributes with range inputs. On mobile, the filter occupies the full viewport, with the catalogue accessible by swiping the panel away. The component scales to both without restructuring.
Facet counts update dynamically. Options that would produce zero results are disabled rather than hidden, keeping the filter transparent and the catalogue logic legible to the user.
Collaboration spanned the full team from the outset: engineering, product owner, sales, and customer success. Scalability was a joint decision made early, not a technical constraint retrofitted to a finished design.
The mobile filter as a full-screen overlay, swipeable to reveal the catalogue. Active selections appear as chips, facet counts show available lots per option, and a badge on each category makes it easy to see where selections have been made. The badge was a direct response to wine taxonomy, where the same term can legitimately appear in more than one category at the same time.
The project delivered more than a feature. It opened a commercial opportunity and laid a foundation the platform can build on.
The redesigned filtering experience met Bacchus Wine Auctions' key requirement for switchingplatforms. At stakeholder handoff, they described it as more modern, more user-friendly, andmore capable than their existing system, with better structure, more filtering options, and the wine-specific attributes they needed. The work directly supported Skeleton's commercial acquisition case.
The underlying architecture was designed to scale across future auction categories while providing the structured data needed for capabilities such as AI-powered search, recommendations, and collector dashboards.
As Product Design Lead, I owned the project end-to-end, from discovery and information architecture to interaction design, prototyping, and collaboration with engineering. I worked closely with product, development, sales, and customer success throughout the project. The solution was delivered and approved, pending development.
How research, systems thinking, and platform constraints shaped the final design.
The biggest insight was that the problem wasn't content, it was structure. The same wine attribute could legitimately exist in multiple categories, so the challenge was helping users navigate ambiguity rather than trying to eliminate it. Features like category badges came directly from that understanding.
Designing for a white-label platform also affects how I approached the work. Because branding varies between auction houses, components needed to communicate hierarchy and state through structure and interaction rather than color or visual styling.
Looking back, I would have involved first-time bidders earlier in the research. Stakeholder interviews provided deep domain knowledge, but validating assumptions with less experienced users would have strengthened the solution from the outset.
This project also reinforced the importance of research before solutioning. Understanding wine taxonomy, In Bond regulations, and auction workflows was essential before making design decisions. The interface was only one part of the challenge; building a shared understanding of a complex domain was equally important.