goodport
A wholesale ordering platform built around the reorder, not the browse.
I led design across both portals: 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 system. A customer portal built for reorder speed, with quick order by SKU code, saved lists and per-account pricing. 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
Role and permission map 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 wholesale ordering platform built around the reorder, not the browse.
I led design across both portals: 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 system. A customer portal built for reorder speed, with quick order by SKU code, saved lists and per-account pricing. 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
- Role and permission map
- 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