Solo senior product designer on a Shariah compliant supply chain finance platform. Two portals, four admin roles, a committee voting process, and a loan lifecycle with eleven states. Four months, end to end. One of the differentiators is a counter offer flow that turns rejection into a negotiation.
Saudi ArabiaTasheelat lets suppliers get paid early on approved invoices instead of waiting weeks for corporates to settle. I designed the whole thing: an admin portal where credit analysts and a decision committee process loan requests, a user portal where companies register, apply, and repay, and a design system holding both together in two languages and two themes.
The hardest problem was not the number of screens. It was that a single loan has to be legible to a supplier and to a credit committee at the same time, moving through a workflow that neither of them can see.
Suppliers in KSA sit on approved invoices and wait. Corporates pay slowly because paying fast costs them working capital. Traditional factoring closes that gap, but it does it with paperwork, phone calls, and no visibility into where anything stands.
Tasheelat digitizes it. Money moves, legal documents get signed, and government registries get queried, so the product is regulated at every step: Watheq for commercial registration, Qawaem and SNP for financial screening, Eiger for the commodity brokerage leg that keeps the structure Shariah compliant. None of that is optional and none of it is invisible to the user. That is the design constraint. Every one of those steps shows up as a state somebody is waiting in.
Mine. Research, competitive teardown, information architecture, the full status model, every flow, the design system and component library, and all UI across both portals. Arabic and English, light and dark, mobile up.
Shared. The counter offer mechanic. The CEO and CTO wanted a way to avoid losing applicants at rejection. I designed what that actually is as a product: the states it needs, the branch logic, the decision surface on both sides.
Set by others. The business model, the credit policy, the committee structure, and the compliance integrations. I did not decide who approves what. I decided how approving anything feels.
Leadership owned what it should be. I owned how it works, how it is organized, and how it looks.
What people struggle with. On the supplier side, applying for financing is a black box that ends in a yes or a no. A no means starting over. On the admin side, the approval process is a chain of people: an analyst reviews, a committee votes, a chair decides, an admin transfers. That chain lived in email and spreadsheets, and nobody in it could see the whole loan.
How I framed it. Not “design a lending portal.” The question was: can one loan record be the single source of truth for a supplier, an analyst, a committee, and a finance admin, without becoming four different products?
The reframe underneath it: the obvious problem is a lot of screens. The real problem is a lot of states. Design the state machine and the screens fall out of it.
I front loaded research and marketplace alignment. Local factoring and lending platforms, what they expose to users, and specifically where their flows dead end. Every competitor stops at approve or reject. That finding shaped the whole product, not just a feature.
The rest of the discovery was domain, not users. This was a room full of banking experience: a CEO out of banking, a CTO who had run technology at a European bank, and a credit team who knew exactly how a loan gets decided and had never seen it written down. Weeks of back and forth with them mapping how a request actually travels through analysis, voting, and a chair's decision. That is where most of the design work happened, before any screen existed.
The status flow is the product.
Eleven states, and the loan crosses portals, roles, and back end integrations as it moves. Pending Tasheelat Approval, Rejected By Tasheelat, Pending User Signature, Pending User Counter Offer, Rejected Counter Offer, Pending Promissory Note, Pending User Promissory Review, Ready To Transfer, Active, Finished. I mapped the entire machine before drawing a screen. Then every screen became a projection of it: the same loan record, rendered by state and by role. The Activity Log tab is that state machine written in human language, so anyone opening the loan can read its history instead of asking someone.
Counter offer, not rejection.
Every competitor gives an admin two buttons. Reject means the supplier reapplies from zero and the lender loses a qualified applicant over an amount. So we made the loan negotiable. The committee can defer with a decreased amount, and the system branches on it: if the approved amount equals the requested amount it resolves as an acceptance, if it is lower it becomes a counter offer the user reviews, accepts, or rejects. That required states nobody else has and a decision surface on the user side that shows what they asked for against what they were offered, clearly enough to answer in one screen. This is the thing I am proudest of, and it is a design decision as much as a business one.
One loan screen, two portals.
The fork: build an admin loan view and a user loan view, or build one loan record with a permissioned action layer. Two views is faster, because every new state has to be designed twice and they drift. I built one. Same tabs on both sides, Loan Details, Company Details, Disbursement History, User Payments, Activity Log, Bank Information. What changes is the action layer. The admin gets accept, reject, counter offer, send promissory note, transfer. The user gets sign, accept, upload payment proof. The record is identical, which is the point: when the supplier calls, both people are looking at the same page.
Admin portal
User portal
Shared
Still pre public launch, so I have no adoption or conversion numbers and I am not going to borrow any. What I have is what MVP testing showed.