Hubsups
How do you design four platforms that feel like one coherent system?
Four platforms. Four user types. One design system, built from scratch.
Hubsups
Hubsups is a B2B/B2C procurement marketplace for the hospitality and real estate industry — built around FF&E (Furniture, Fixtures & Equipment) and OS&E (Operating Supplies & Equipment). Think of it as the infrastructure layer between the people who need products and the vendors who supply them, with everything — browsing, listing, quoting, ordering, and managing — handled inside one place.
Most platforms in this space serve only large-quantity B2B buyers. Hubsups is vendor-driven and open to smaller buyers too — which is rare in this industry, and the product's sharpest competitive edge.
The whole system breaks into four platforms: a buyer-facing marketplace, a vendor management panel, an admin platform, and a procurement panel for quote-based orders. Each one serves a completely different user, with a different mental model and a different job to get done. My job was to design all four — from scratch, as the sole designer.
One place to get it all done
Before Hubsups, procurement in hospitality and real estate meant stitching together multiple platforms — separate tools for browsing products, separate services for procurement, separate relationships with design studios. Nothing talked to each other. Getting a project done meant managing fragmentation as a full-time job.
On top of that, the B2B ecommerce platforms that did exist were built almost entirely for large-quantity buyers. A small hotel group, an independent interior designer, a boutique property — none of them were well-served. The minimum order quantities were too high, the vendor relationships too formal, and the process too slow.
Hubsups was built to close both gaps at once: bring procurement, product browsing, quoting, and vendor management into a single platform, and open it up to small and large buyers alike. The idea was simple. The execution — designing four distinct platforms for four distinct users, coherently — was not.
The listing form was the load-bearing problem
Every vendor listing on Hubsups shows up on the buyer platform. Which means the quality of what a vendor fills in directly determines whether a buyer trusts what they see. A listing with missing specs, a blank description, or patchy attributes doesn't just look incomplete — it makes the whole platform feel untrustworthy.
So the stakes of getting the listing flow right were high. And the first version of it wasn't right.
"It's too long. Too scattered. I don't even know what half of these fields are for."Rahul — composite vendor persona, grounded in usability testing with five active online sellers
We ran usability testing with five vendors — people already running businesses on online stores — alongside stakeholders with deep industry experience. The findings were consistent: the form was lengthy, scattered, and time-consuming. Fields weren't grouped. There was no logic to the order. Filling it in felt like data entry, not product listing.
The problem wasn't just bad UX. It was a trust problem with a business consequence: if vendors find listing painful, they list fewer products. Fewer products means a thinner marketplace. A thinner marketplace means buyers find less. The form was a bottleneck the whole product ran through.
The question wasn't what to require. It was how to show it.
The obvious fix was to cut fields. Make more things optional, reduce the form length, get vendors through faster. The stakeholders leaned that way too — there were a lot of attributes, and requiring them all felt like too much to ask.
But making things optional had a cost on the other side: buyers would see listings with gaps in the exact specs they needed to make a procurement decision. In B2B buying, incomplete technical information doesn't just frustrate — it disqualifies. A buyer ordering 200 chairs for a hotel lobby needs to know materials, dimensions, and load specifications before they place a purchase order worth tens of thousands.
Require too much — vendors abandon the form. Require too little — buyers lose confidence. Neither answer was the right answer.
So we stopped trying to pick one.
The real problem wasn't the number of fields. It was that all of them were being shown to vendors at once, with no signal about what actually mattered. The solution wasn't fewer fields — it was a better way to surface them.
Instead of marking fields mandatory or optional, we grouped attributes into three visibility states: Required, Recommended, and All. Vendors land on Required by default — only the fields that are genuinely load-bearing for buyer trust show up first. Nothing critical can be missed. Nothing overwhelming is forced upfront. The full set is always one click away.
This wasn't a compromise between two bad options. It was a better architecture for the problem entirely.
One design system. Two design languages. Four platforms.
The first real decision I made wasn't about a screen. It was about architecture: do all four platforms share one design system, or do they each get their own?
The answer was neither. The buyer platform got its own design language — consumer-facing, closer to ecommerce than enterprise software, built around browsing and trust. The vendor, admin, and procurement panels share a single Figma component library, with theming and color differentiation applied at the configuration level to distinguish context.
Forcing visual consistency across radically different user behaviors would have created a false sense of coherence. A vendor managing 500 SKUs and a buyer browsing for office furniture are not doing the same thing. The system had to reflect that.
Buyer PlatformSeparate design language
Consumer-facing marketplace with bulk buying, tier pricing, and request-for-quote. Different trust signals, different visual language — closer to ecommerce than the other three panels.
Vendor Panel
The vendor's management platform — product listings, service listings, quotes, orders, returns, earnings, promotions, storefront, and settings. Dense, task-heavy, used by people running a business.
Admin Panel
The platform that manages both sides. Admin is the middleman — verifying vendors, overseeing buyers, and bridging the two. Same component library as vendor, different permissions.
Procurement Panel
Where quote-based orders land. Buyers can request custom quantities or direct manufacturing through this panel — separate workflow from standard purchase orders.
The vendor, admin, and procurement panels share one Figma component library — designed in Figma first, with select complex interaction patterns later prototyped in code using Cursor and Antigravity to stress-test behavior before engineering handoff. The buyer platform is a separate system entirely, because it needed to be.
One designer. Four platforms. No handoffs to myself.
I was the sole designer on Hubsups across all four platforms — which meant every decision, from the design system architecture to the order of fields in a listing form, was mine to make and mine to defend.
In practice, the role wasn't just design. I sat with the business analyst, product managers, and development team before drawing anything complex — scoping what was feasible, negotiating constraints, and in several cases playing the role of BA to push engineering toward implementations they initially thought weren't possible. I monitored what was getting built against what I'd designed, flagged regressions, and pushed back when implementation drifted from intent.
The handoff was never just a Figma file. It was a running conversation.
My Role
Sole UI/UX Designer
Team
BA, PM, Devs, Stakeholders
Design Tool
Figma
Prototyping
Cursor, Antigravity
The decisions that shaped the product
Benchmarking mandatory fields against the industry — not instinct
Before a single field was marked mandatory, I convened a working session with the business team, product owners, and industry stakeholders. We pulled up Amazon and Walmart's listing requirements, mapped them against Hubsups' context — bulk procurement, hospitality-grade products, B2B and B2C buyers side by side — and asked a pointed question: what is the least a buyer needs to see before they trust a listing?
That floor became the mandatory set. Everything above it became optional or recommended. The decision wasn't made by gut feel or by whoever argued loudest in the room. It was made by working backwards from buyer trust.
Required / Recommended / All — a better architecture than mandatory vs. optional
The attributes problem was real. There are a lot of product attributes in this category, and requiring them all upfront was genuinely too much to ask of a vendor listing their first product. But making them optional meant buyers would see listings with gaps in exactly the specs that matter for procurement decisions.
Picking a side would have meant losing one user to serve the other. So we didn't pick a side.
Instead, I grouped attributes into three visibility states — Required, Recommended, and All — and made Required the default view. Vendors see only what's genuinely load-bearing first. Nothing critical is buried. Nothing overwhelming is forced. The full attribute set is always there, one click away.
It's not a compromise. It's a better framing of the problem. The vendor fills what matters first, the buyer always sees complete critical specs, and the stakeholder's concern about friction disappears because the UI handles the prioritisation — not the field list.
AI-assisted autofill — so vendors never start from blank
Even with the right fields in the right order, a blank form is expensive. Vendors listing dozens of products don't want to write a meta description from scratch every time. The cognitive load of starting from empty, multiplied across an entire catalog, was a real barrier to listing volume.
So we made the form do more of the work. Once a vendor enters a product name and selects a category, the system generates a meta description and populates related fields automatically. The vendor edits, rejects, or accepts — but they're never starting from nothing.
The form didn't get shorter. It got smarter. The work that used to be the vendor's is now shared with the system.
The first version had all fields listed linearly — ungrouped, no autofill, no interdependencies. Usability testing surfaced the same words from every participant: lengthy, scattered, time-consuming. We rebuilt the information architecture before touching the visual design.
Why we scrapped the accordion — and what replaced it
The original listing flow used an accordion. Sections collapsed and expanded in place, which felt clean when the field count was low. But as the product scaled and more fields were added, the model broke: every edit meant opening a section, filling a field, closing it, opening the next one. Non-linear editing — jumping back to fix something earlier — became a sequence of unnecessary clicks through collapsed sections.
The structure designed to organize the form was getting in the way of using it.
Accordion works when sections are short, stable, and independent. The moment fields became interdependent and the form grew, the open/close interaction created more friction than a linear step ever would. We moved to a clean stepped flow and layered the grouping, autofill, and attribute filtering on top. The form got longer in field count and shorter in felt effort.
Bulk upload — designed as a collaboration, not a feature
Vendors with large catalogs can't fill a form per SKU. Bulk upload wasn't a nice-to-have — it was the difference between a vendor adopting the platform and not.
The design challenge: every vendor's spreadsheet looks different. Their column names for the same data — product name, category, SKU — are all over the place. A standard CSV import would fail every time it hit a column it didn't recognise.
We designed a column-matching interface: vendors upload their file, the system uses AI to suggest which of their columns maps to which Hubsups field, and the vendor confirms or corrects the mapping before anything is imported. We also built a Hubsups-native upload template for vendors who wanted a clean, guaranteed path from the start.
This was one of the hardest engineering problems in the product. I was in the room with the development team working through the constraints before a single screen was drawn — because there was no point designing something the system couldn't support. A few key interaction patterns from this flow were later prototyped in code using Cursor and Antigravity to communicate the intended behavior to engineers before implementation.
The form that used to take fifteen minutes.
The usability testing had a verdict before we'd made a single change: lengthy, scattered, time-consuming. That was the objection. Everything in the listing flow redesign was an answer to it.
The answer wasn't fewer fields. It was a better way to present them.
Grouping fields into logical clusters — General Information, External Product Identifiers, Attributes, Pricing, Variations — gave the form a structure vendors could navigate, not just endure. AI autofill meant the blank-slate problem disappeared for most fields. The Required/Recommended/All filter meant vendors saw what mattered first, every time.
The result: the same form, covering the same ground, taking a fraction of the time — and producing listings complete enough for buyers to act on. The platform got better for both sides without asking either side to compromise.
A vendor who finds listing painful lists fewer products. Fewer products means a thinner marketplace. A thinner marketplace means buyers find less, trust less, and buy less. Getting the listing flow right wasn't a UX problem — it was a business problem with a UX answer.
The limits I designed inside
No design system to inherit. I built the Figma component library from scratch — every spacing scale, color decision, typography hierarchy, and component pattern established fresh. Every foundational decision was mine to make and mine to maintain as the product grew.
Engineering constraints were real, and early. I sat with the BA, PM, and dev team before designing anything with complex interactions — scoping feasibility before committing to a direction. In several cases I pushed the team toward implementations they initially thought weren't possible. The design was only as good as what could actually be built.
Four platforms, one head. Every decision on the vendor panel had downstream effects on the buyer platform. Admin workflows shaped vendor onboarding. Procurement flows depended on buyer quote behavior. I was the only person holding all of it at once — which meant the cost of a wrong call compounded across platforms, not just screens.
Designing for a product that hadn't stopped growing. Hubsups wasn't a fixed scope — it was a platform being built to scale. That meant designing the MVP while keeping the system open enough to absorb features that didn't exist yet, without a redesign every time the scope expanded.
Handoff wasn't the end. I monitored implementation against the design, flagged regressions, and pushed back when things drifted. The fidelity of what got built was part of the job — not someone else's problem after the Figma file was shared.
What it added up to
Hubsups shipped to a vendor base of 25,000+ US vendors, across four platforms designed to feel like one coherent system. The Figma component library became the source of truth the engineering team built from — three of the four platforms drawing from the same shared library, with theming applied at the configuration level to differentiate context without duplicating work.
The listing flow changes — logical grouping, AI autofill, the Required/Recommended/All attribute filter — shifted the language vendors used to describe the experience. "Lengthy, scattered, time-consuming" stopped being the words in the room. That's a qualitative signal, not a metric, and it's the honest way to say it.
The bulk upload solution removed the single biggest practical barrier to adoption for vendors with established catalogs. A vendor who can't easily bring their inventory across doesn't come across.
Active sellers on the platform.
Sharing a single design system.
Designing all systems end-to-end.
What I'd do differently — and what's still open
The bulk upload column-matching interface works, but the mapping UX has room to be significantly more intuitive — especially for vendors with large, messy catalogs where the edge cases matter most. Another round of usability testing specifically on the import flow would tell us where it still breaks.
Inventory classification — how vendor products are categorised and surfaced on the buyer side — is an area I flagged for a follow-up pass. The current system works. But there's a more intelligent architecture possible that would make discovery better for buyers without adding work for vendors.
Being the only designer means every decision is yours to make — and nobody to pressure-test your assumptions in real time. Looking back, I'd have pushed harder to bring in external design critique at key inflection points, even informally. A second perspective at the right moment is worth more than a week of solo iteration.
The most important design work I did on Hubsups wasn't a screen. It was the session I ran with stakeholders to map out what information a buyer actually needs to trust a listing. Everything downstream of that decision was easier because that decision was right. Get the framing right and the form follows.