A Vendor Portal for Procurement
A bilingual (Arabic / English) web portal where suppliers find tenders, bid, sign contracts, deliver and get paid, designed to work as well on a phone as on a desktop.
Role
Lead UX/UI Designer
Timeline
Around 3 months, then a client audit round
Team
PM, me (lead UX/UI), another UX/UI designer
Platform
Web, Tablet and Mobile · Arabic / English
Overview
A full procurement lifecycle in one portal
Suppliers register, find tenders, bid, sign contracts, deliver and get paid, all in one place.
Long chains, strict rules
A purchase order belongs to a contract, a certificate to a purchase order. Every screen had to show where a record sits in that chain.
Lead designer, discovery to audit
I led the UX and UI, built the design system, delivered Arabic and English across Web, Tablet and Mobile, then resolved the client audit.
The process at a glance
Procurement is one long chain where every step depends on the one before it. I mapped that chain first, then structured, wireframed and designed it, and stayed on after handoff to resolve the client's audit.
How a supplier moves from registration to payment, in seven phases.
Open tenders and direct quotation requests start and end differently, so each got its own flow.
Every module grouped into the daily work and the money trail.
Low-fidelity layouts for each module, before any UI.
A library with RTL and device variants, then Web, Tablet and Mobile screens.
Annotated handoff, then a structured round of fixes after the client audit.
Mapping the journey
Working from the client's requirements, I mapped a seven-phase journey, from registration to payment. Two ways in shaped everything: open tenders that any qualified supplier can bid on, and quotation requests sent to one supplier directly.
- Tender published to all qualified suppliers
- Supplier reviews scope, items and documents
- Optional inquiry before the deadline
- Bid with unit prices and documents
- Procurement compares all bids
- Awarded, then a contract
- Request sent to one supplier
- Supplier reviews items and deadline
- Quotation with prices and lead time
- Proposal submitted before the deadline
- Review, may negotiate
- Accepted, then a purchase order directly
Information architecture
The system map split the portal into the daily work (Main) and the money trail (Financials). Every financial record links back to the one it came from, so a supplier always knows where they are in the chain.
- DashboardRequired actions, activity, payments
- TendersDetail, then apply with a bid
- Requests for quotationDetail, then submit a proposal
- My bidsStatus of every submission
- ContractsBasic info, COCs, fines, change orders, warranty letters
- Purchase ordersLinked contract, delivery, COCs
- Down paymentsRequest, then approved or denied
- Certificates of completionPartial per item, then final
- Change ordersPer contract or purchase order
- Profile
- Settings
- Help and support
- Notifications
Design system
I built the system as three Figma files: a component library, plus separate Arabic and English screen files. Components carry RTL and device variants, so one library serves Web, Tablet and Mobile in both languages.
The library is published once; both screen files update from it.
All text uses Neutral 600 or darker.
Long tab bars scroll sideways on small screens.
No desktop sidebar; navigation moves to a menu.
Selected final screens
A few of the final screens. Client names, logos and locations are replaced throughout.
Dashboard: required actions come first, then recent activity, payments and requests.
Tender details: a live countdown, a stages timeline and every tab a bidder needs.
Applying for a tender: a price and quantity table with VAT worked out, then documents.
Contracts: progress, financial summary, products and services, documents and addenda.
Certificates of completion: progress per item, invoice and attachments, plus a communication history.
Responsive and Arabic
Responsive: the same dashboard on desktop, tablet and phone. Cards stack and tables turn into lists on smaller screens.
Arabic: a mirrored right-to-left layout, designed alongside English on every device.
After handoff: the client audit
After handover, the client audited the files and sent a report. With a colleague, I worked through it in order of impact and replied with a report of the fixes done.
Checked every screen across Web, Tablet and Mobile. Tablet screens no longer show the desktop sidebar.
Moved all text to Neutral 600 or darker, instead of changing shared tokens that other products use.
Gave unnamed frames the name of the same screen on another device or in the other language.
English Web became the reference. A screen was added only where no equivalent existed.
RTL variants unified to ON/OFF, unused components removed and detached, library republished without breaking instances.
