goodport
A multi-tenant wholesale ordering platform built around the reorder, not the browse.
I led design across both portals of a multi-tenant B2B SaaS: research, information architecture, the token set and component library, and every screen. Specs went to engineering as Dev Mode annotations rather than a separate document.
Wholesale buyers do not shop. They reorder a narrow set of SKUs on a schedule, at prices negotiated per account, and the old process ran on phone calls, PDFs and one spreadsheet per customer. Every consumer-ecommerce pattern the incumbent tools borrowed made that slower rather than faster.
Two portals on one multi-tenant platform, where every customer account keeps its own users, roles and negotiated prices. A customer portal built for reorder speed, with quick order by SKU code and saved lists. An admin portal dense enough for sales, finance and logistics to work in all day. Both run on one token set and one component library, with density the only thing that changes between them.
Design process
-
01
Discovery
Account manager interviews Order desk shadowingTwo years of order data Competitor teardown -
02
Structure
Tenant and role permissions Navigation modelOrder state machine Content inventory -
03
Design
Colour and type tokens Component libraryCustomer portal screens Admin portal screens -
04
Handoff
Dev Mode annotations Component specsBuild reviews Design QA -
05
Measure
Reorder completion Time to first orderSupport ticket volume Adoption by role
goodport
A multi-tenant wholesale ordering platform built around the reorder, not the browse.
I led design across both portals of a multi-tenant B2B SaaS: research, information architecture, the token set and component library, and every screen. Specs went to engineering as Dev Mode annotations rather than a separate document.
Wholesale buyers do not shop. They reorder a narrow set of SKUs on a schedule, at prices negotiated per account, and the old process ran on phone calls, PDFs and one spreadsheet per customer. Every consumer-ecommerce pattern the incumbent tools borrowed made that slower rather than faster.
Two portals on one multi-tenant platform, where every customer account keeps its own users, roles and negotiated prices. A customer portal built for reorder speed, with quick order by SKU code and saved lists. An admin portal dense enough for sales, finance and logistics to work in all day. Both run on one token set and one component library, with density the only thing that changes between them.
Design process
-
01
Discovery
- Account manager interviews
- Order desk shadowing
- Two years of order data
- Competitor teardown
-
02
Structure
- Tenant and role permissions
- Navigation model
- Order state machine
- Content inventory
-
03
Design
- Colour and type tokens
- Component library
- Customer portal screens
- Admin portal screens
-
04
Handoff
- Dev Mode annotations
- Component specs
- Build reviews
- Design QA
-
05
Measure
- Reorder completion
- Time to first order
- Support ticket volume
- Adoption by role