Confidential client / B2B SaaS / Dubai
From group chat.
To governed trade.
I designed an electronics trading platform end to end, taking an offline, relationship-led business into a shared digital workflow for buyers, sellers and logistics.
Follow a trade
A note for recruiters & hiring teams
The screens are confidential.
The thinking is on show.
The client’s product screens and identity are withheld to respect proprietary confidentiality. I cannot publish the interface or recreate it here.
This case study instead makes my contribution visible through the problem framing, end-to-end trading flow, information architecture, role-based access and critical decision paths. The diagrams are explanatory, and all interactive examples use fictional data.
Business context / Wholesale electronics
How wholesale electronics trading works.
Who trades, and what they trade
Companies buy and sell bulk electronics stock, including iPhones. Sellers offer lots with specific models, regional specifications, storage, colors and quantities. Buyers source stock for their businesses; traders both buy and sell.
Where stock is held and checked
The seller’s logistics partner holds the inventory. The buyer agrees a price with the seller, then checks the goods through an agreed QA route. The buyer decides whether the inspected quantity and condition are acceptable before fulfillment.
How payment and settlement work
After acceptance, the buyer pays logistics, which fulfills the order. Logistics then settles with the seller on their agreed cycle. Several companies are responsible for different parts of this relationship-led wholesale trade.
How the business ran before the platform
Sellers, buyers, traders and logistics providers met in WhatsApp groups to find stock and negotiate. Once a seller accepted a buyer’s bid, the remaining work moved offline.
- 01
In the group chat
The seller puts forward an offer
A seller shares the electronics available, quantity and asking price with the group. Buyers and traders review the offer.
- 02
In the group chat
A buyer bids. The seller agrees
The buyer proposes a price and quantity. When the seller accepts the bid, the deal moves into offline coordination.
- 03
Offline / Stock inspection
The physical stock is checked
The seller’s logistics partner holds the inventory. With the buyer’s agreement, QA is done by that provider, the buyer or their representative, or the buyer’s partnered logistics.
- 04
Offline / Buyer decision
The buyer reviews the findings
The inspection reports the available quantity and undamaged, partially damaged or fully damaged units. The buyer decides whether to accept that outcome or reject the deal.
- 05
Offline / Payment & fulfillment
Logistics receives payment and fulfills
If the buyer accepts, they pay logistics. Logistics holds the payment and fulfills the order for the accepted goods.
- 06
Offline / Seller settlement
The seller is paid on the agreed cycle
Logistics settles with the seller according to their partnership agreement, described as a monthly cycle. Buyer payment and seller settlement happen at different times.
The deal moved offline.
Visibility stopped there.
After buyers and sellers agreed on a price in WhatsApp, the trade continued offline. Other participants could not clearly see what had happened, what was still pending, or who needed to act next.
Stock checks, QA findings, acceptance, fulfillment and payment updates stayed with the people handling each step. Buyers and sellers had to ask for progress, while the admin lacked a shared view of the trade to understand delays or troubleshoot disputes. The problem was not just coordination. It was a lack of transparency across the whole transaction.
One visible trade.
Clear responsibility at every step.
I connected offers, agreed terms, QA evidence, buyer acceptance, fulfillment and settlement in one shared trade record. Relevant participants can follow what is happening through role-appropriate access, while authorized admin staff can review the transaction history and evidence to investigate disputes. Transparency comes from the same records, not separate versions of the story.
Progress disappears between handoffs
Without a shared trade status, participants chase updates and the admin has to piece together what happened.
Agreement happens twice
The seller accepts a bid. Later, the buyer accepts or rejects the inspected outcome.
Visibility is not authority
Seeing an order does not mean having permission to change every part of it.
Business impact
Confidential client / Internal testing
Take the offline trade online, without losing accountability.
The product connects offers, bids, logistics-led stock inspection, buyer acceptance and settlement. The business goal is a traceable trading workflow with less dependence on disconnected coordination, while preserving the relationships that make the trade work.
- Current evidence
- I delivered the end-to-end product design. The platform has been showcased at industry events and is now in internal testing, so measured business results are not yet available.
- What to measure next
- Measure bid-to-agreement time, on-time QA completion, buyer understanding of inspection findings, acceptance drop-off, dispute frequency and settlement reconciliation effort.
Competitor analysis
A trading floor is only the start.
Mobile Dubai was part of my design-phase competitor analysis. I looked beyond getting an offer in front of a buyer: the harder design problem was coordinating what happens after both sides agree on a price.
Design-phase competitor
Mobile Dubai
Its public site describes electronics buying and selling, supplier price lists, price comparison and delivery. Its app listing also describes transaction reports, verification documents and notifications.
Discovery and trading convenience are established expectations.Additional category benchmark
gsmExchange
A live wholesale trading floor with stock specifications, matching, enquiries, messaging and preferred partners. Membership includes verification and trading feedback.
Trust and product matching matter alongside price.Additional category benchmark
Handelot
A wholesale electronics marketplace built around offers, requests, direct member-to-member trading, company verification and trading information.
A trusted network helps people find counterparties; operational ownership still needs to be explicit.The design opportunity
Connect the complete operating model.
The distinctive scope of this design brings governed catalogue offers, buyer-submitted bids with seller acceptance or rejection, buyer-agreed QA routes, damage-aware acceptance, logistics-held inventory and settlement, delegated staff permissions and deposit-based trade limits into one connected workflow.
That is the intended differentiation: not simply another place to list electronics, but a shared operating experience for the people responsible for completing the trade.
What the comparison establishes. The public pages reviewed do not document this exact combined workflow. That is an opportunity identified from the available material, not proof that competitors lack these capabilities. “First of its kind” is not established by this review. Additional benchmarks were reviewed for this case-study presentation; no private competitor account audit is claimed.
Service ecosystem
The warehouse is the hinge.
Logistics was not a delivery option at checkout. It held the inventory and connected inspection, fulfillment and money movement. That changed how I structured the entire experience.
Seller
Owns the stock
Sets the offer
Logistics partner
Custody · QA · Fulfillment · Settlement
Buyer
Reviews the evidence
Accepts the outcome
Seller
Offers the stockLists approved product variants, stock quantity, asking price and minimum order quantity. Accepts or rejects a buyer’s bid.
Buyer
Decides what to acceptChooses quantity and price, agrees who inspects the stock, and accepts or rejects the QA findings before fulfillment.
Trader
Buys and sellsUses both buyer and seller capabilities. The context of each transaction determines the actions available.
Logistics
Connects stock to settlementHolds seller inventory, coordinates inspection, fulfills accepted orders and settles with the seller on the agreed cycle.
Platform admin
Governs participationReviews company applications, controls the product catalogue and handles escalations through authorized operations staff.
An organization is not one login. Sellers, buyers, logistics providers and the admin can delegate work to employees. I separated the company’s role from each employee’s permissions. A trader combines buying and selling capabilities; it does not need a second copy of the data.
The end-to-end service blueprint
A deal is a sequence of decisions.
I mapped the handoffs around business responsibility. Select a stage to see who acts, what happens and the rule that allows the trade to move forward.
Admin → Seller
Catalogue & listing
The admin defines the eligible product catalogue. The seller selects a precise variant and adds a commercial offer: stock, price and minimum quantity.
Make the next responsibility visible
Seller acceptance triggers a logistics notification and a visible inspection deadline. The buyer can understand who is acting next and when an update is expected, instead of chasing the trade through separate messages.
Keep the physical work honest
The platform coordinates and records inspection and fulfillment. It does not turn a physical stock check into a purely digital task. The design keeps that real-world work visible in the order’s progress.
The critical decision
A QA pass is not a buyer’s yes.
Condition is not simply pass or fail. A buyer may accept a damaged subset, accept only a revised outcome, or reject the offer. I separated the inspection record from the commercial acceptance.
Seller-arranged QA through logistics
The buyer can ask the seller to arrange QA. The seller requests it through its logistics partner, which inspects the stock and records the findings. The seller does not perform the inspection directly. This logistics provider may also be partnered with the buyer.
Buyer’s representative
The buyer inspects personally or sends an authorized person to check the physical stock.
Buyer’s logistics
The buyer’s partnered logistics provider carries out the agreed inspection.
Illustrative QA record / 100 phones requested
Report the condition.
Preserve the choice.
- Undamaged
- 95
- Partially damaged
- 03
- Fully damaged
- 02
100 units found does not mean 100 units acceptable. Specification, available quantity and condition are separate checks.
The buyer makes the call.
In this example, five units have damage. The buyer can accept the reported outcome if it suits the deal, or reject it. The report itself stays intact.
Awaiting buyer review. Inspection is complete; commercial acceptance is still pending.
Separate how stock is packed from its condition.
I designed separate fields for packaging and product condition. Master-carton counts and units per carton describe how the stock is grouped. Product condition and QA findings describe the state of the goods. This lets buyers review the quantity and condition independently before deciding what to accept.
Information architecture & authorization model
Same records.
Different responsibilities.
I organized the shared business objects first, then mapped the actors, their organizational scope, delegated permissions and permitted actions. Different workspaces are different views of the same trade, not independent versions of the truth.
Shared business records
Catalogue → Listing → Bid → Order → QA report → Acceptance → Payment → Settlement
Role
What kind of participant am I?
Scope
Which company or assigned trade?
Permission
What can this employee do?
Entitlement
What does membership unlock?
State
What action is valid now?
A role-appropriate view of the same underlying data.
Role-based access with contextual scope
Role-based access control (RBAC) defines capabilities. Company ownership, partnerships and order assignments limit their scope. Employees receive delegated permissions rather than inheriting every capability of the business owner.
Transparency without unrestricted disclosure
Relevant parties can follow the same trade and evidence. Membership may hide price and market detail, while company boundaries protect unrelated records. Shared truth does not mean every person can see or edit every field.
This is the product and UX authorization model. It does not claim a particular database, backend architecture or verified security implementation.
Relationship management / CRM
Manage the relationship.
Keep the trade in context.
I designed embedded relationship-management capabilities across the trading workspaces. Company profiles connected contacts, relevant trade history and follow-ups, while order pages retained the transaction details and decision controls.
Why I kept relationship management inside the platform
The relationships were already connected to the work happening here: reviewing submitted bids, coordinating inspection, reviewing acceptance and following settlement. I kept contacts and follow-ups close to those trades so users could manage the relationship without switching to a separate CRM and finding the order again. The online flow is a buyer submitting a price and quantity, followed by the seller accepting or rejecting the bid.
This direction reused the platform’s company and trade context, with role-based access and delegated employee responsibilities. It supported repeat business and team handovers within the existing workspaces. No external CRM was used. These capabilities belong within company profiles, contacts, trade history and follow-ups; they do not require a separate “CRM” destination in the product interface.
One relationship record. Connected trade history.
A company profile brings together its authorized contacts, the employee responsible for follow-up, linked enquiries and trades, and outstanding tasks. Operational updates come from the same order, QA and settlement records used elsewhere in the platform.
Seller
Buyers & logistics partners
Relationship context
Buyer contacts, enquiries, bid history, agreed orders and the logistics partner holding each lot.
What they follow up on
Assign an employee to follow up on an open bid, coordinate buyer-requested QA through logistics, and check which seller settlements remain pending.
Why it matters
Review buyer relationships with the submitted bid, quantity and order history in view.
Buyer
Suppliers & inspection partners
Relationship context
Supplier contacts, offers previously considered, purchase history, QA findings and the buyer’s acceptance decisions.
What they follow up on
Follow up on a bid, arrange the agreed inspection route, or contact a previous supplier about the same UK-specification stock. Keep the next action linked to the relevant purchase.
Why it matters
Source repeat stock with context from earlier purchases and inspection outcomes.
Trader
Buying and selling relationships
Relationship context
One company contact record, with purchase and sale histories clearly separated. The same business can be a supplier on one trade and a customer on another.
What they follow up on
In buying mode, manage supplier enquiries, bids and inspection follow-ups. In selling mode, manage buyer enquiries, offers and settlement follow-ups. Each task retains its order and trading role.
Why it matters
Switch responsibilities without confusing money owed on a purchase with settlement due on a sale.
Logistics
Partner sellers & assigned buyers
Relationship context
Seller partnerships, warehouse and company contacts, assigned stock, QA requests, delivery contacts and payment or settlement records.
What they follow up on
Assign QA and fulfillment follow-ups to the right staff. Contact the buyer about an inspection decision, coordinate accepted goods, and follow up on seller settlement within the agreed cycle.
Why it matters
Keep custody, inspection, delivery and settlement handoffs connected to the correct company and order.
Admin
Participant companies & dispute contacts
Relationship context
Company applications, approval or resubmission history, authorized contacts and the trade evidence linked to a dispute.
What they follow up on
Assign onboarding follow-ups or a dispute to an authorized operations employee, request missing information and record the resolution. Govern eligible catalogue products without deciding a seller’s price or a buyer’s purchase.
Why it matters
Resolve participation issues and disputes with a traceable history, while commercial decisions stay with the trading parties.
A follow-up stays attached to the trade.
For the fictional T-104 order, Harbour Devices is buying 100 UK-specification iPhone 15 phones from Atlas Electronics. Logistics records 95 undamaged units and five with damage. The buyer’s company profile links Atlas’s contact, the order history and a follow-up to review the findings. That follow-up takes the buyer to T-104, where the QA report and acceptance controls remain. The buyer accepts or rejects the outcome on the order page. The seller can see that acceptance is pending; logistics follows the same order before fulfilling it. Admin reviews the evidence if a dispute is raised, without making the purchase decision.
Shared history, controlled access. Company records and tasks follow organizational scope and delegated staff permissions. Internal relationship notes stay private to their company; agreed terms, QA evidence and trade status retain their existing access rules. A contact record does not unlock another company’s orders, restricted prices or decision rights.
How I handed off the CRM design.
I translated my CRM design decisions into a shared implementation reference for the development team. I explained how the information was organized, what each field meant, how the flows behaved and what needed to be built. I brought annotated designs, a linked written specification and a developer walkthrough together so the team could connect the interface to the product rules.
I mapped the information architecture and user flows
Flow maps linked to the Figma designs. I connected Company → Contacts → Trade history → Follow-ups and mapped the buyer, seller, trader, logistics and admin journeys. I showed how a follow-up led to its order, giving developers a clear route through the information and screens.
I defined the data behind each screen
A field-definition table linked to the relevant Figma frames. I documented each field’s purpose, input format, required or optional status, source, validation and viewing or editing permissions. I defined what the experience needed to capture and display, while developers determined the database and API implementation.
I annotated the designs and demonstrated the interactions
Annotated Figma screens, reusable components and a clickable prototype. I explained selection, saving, assignment and completion, including loading, empty, error and restricted states. I connected the behavior notes to the relevant designs so developers could inspect the visual details and understand the interaction rules together.
I walked developers through the flow and reviewed the build
A developer walkthrough, linked implementation references and design QA. I walked through a complete trading scenario with the team, clarified questions and agreed the expected behavior. I kept design decisions and changes connected to the shared references, then reviewed the implemented experience against the designs and flows to identify corrections.
An example of the field specification
Illustrative follow-up task linked to the T-104 trade. This explains the handoff format without exposing client documentation.
| Information | What the developer needs to know |
|---|---|
| Related company & order | Link Atlas Electronics and T-104 using existing records. Display their names; do not ask the user to retype the order details. |
| Follow-up description | Required text explaining the action, such as “Review the QA findings.” Show a field-level message if saved empty. |
| Assigned employee | Select an eligible employee from the current company. Specify the unassigned state and who has permission to reassign the task. |
| Internal note | Optional text, visible only to authorized staff in the same company. It must not appear in another participant’s shared order view. |
How I explained the flow
I used a connected journey to explain the behavior: supplier profile → assigned follow-up → linked order → QA findings → buyer decision. In the fictional T-104 example shown here, Harbour can accept or reject on the order page; Atlas can see the status but cannot decide for the buyer. This illustrates how I made the intended flow and role boundaries clear to developers.
CRM was part of the product design. The role-specific examples and handoff requirements here reconstruct its intended scope from the trading model; they do not reproduce proprietary screens or represent measured CRM outcomes.
Comparable offers
Seller ranking.
Lowest price first.
Seller ranking helps buyers find the lowest comparable asking price without manually sorting through offers. For the same product, specifications and quantity, the lower-priced seller appears higher in the list.
Match the product
Model, regional specification, storage, color and condition.
Match the quantity
Compare the same requested lot size and minimum order eligibility.
Rank by asking price
The lowest comparable price takes position one.
Illustrative listing comparison
iPhone 15 · 256 GB · Black
UK specification · New condition · Master-carton stock
| Rank | Seller | Quantity / MOQ | Asking price / unit | Why this position |
|---|---|---|---|---|
| 1 | Seller A | 100 / 100 units | AED 2,450 | Lowest comparable price |
| 2 | Seller B | 100 / 100 units | AED 2,480 | Next-lowest price |
| 3 | Seller C | 100 / 100 units | AED 2,510 | Higher asking price |
| 4 | Seller D | 100 / 100 units | AED 2,540 | Highest price in this set |
Why is seller ranking useful?
It helps buyers find a seller to strike a deal with. Once they have chosen the exact product specification and quantity, the ranking brings the lowest comparable asking price to the top. The buyer can quickly identify whom to approach, submit a bid and begin the agreement process.
A cheaper offer for a different storage size, condition or quantity is not a like-for-like comparison. Ranking helps the buyer choose a seller and submit a bid; QA and buyer acceptance still determine whether the deal proceeds.
Participation & commercial guardrails
Access is earned.
Actions have limits.
Onboarding approval, membership, trading deposit and employee permissions answer different questions. I kept them separate so one successful step did not imply unrestricted access.
A company applies
Role-specific onboarding captures company details, country, employee information and relevant trading categories.
Admin reviews
Approval enables the next stage of participation. Rejection includes actionable feedback and a resubmission path.
Staff gets access
Owners delegate the actions employees need. Logistics staff and admin operations roles have different responsibilities.
A deposit sets a ceiling
Participants can trade up to ten times their qualifying deposit. The caution deposit is a participation requirement; it is distinct from paying for an order.
Membership unlocks detail
A visitor can discover products while price and market information remain masked. Membership unlocks commercial detail; it does not grant another role’s operational permissions.
The catalogue is governed
The admin controls eligible products and variants. Sellers create offers against those catalogue entries rather than inventing duplicate product definitions. Regional specification, storage, color and relevant technical attributes remain explicit.
Money follows a different clock from stock.
Buyer → logistics payment supports the order. Logistics → seller settlement follows their commercial agreement, described as a monthly cycle. I treated these as separate states so an order payment could not be mistaken for completed seller settlement.
How I approached the design
Model the business.
Then design the workspace.
My work was translating the client’s operating rules into clear decisions, objects, states and responsibilities before arranging the experience around each participant.
Map the service before the interface
Trace the offline deal from an offer in a group to seller settlement. Separate the digital handoffs from physical inspection and delivery.
Define the objects once
Distinguish catalogue products from seller offers, bids from agreed orders, QA findings from acceptance, and buyer payment from seller settlement.
Map actors to actions
Define business roles, employee responsibilities, organizational boundaries and transaction assignments against the same records.
Design the decisions and recovery paths
Make approval, rejection, resubmission, inspection outcomes and acceptance explicit. Make the reason and next responsible actor visible.
Design for the difficult cases
- Company application rejected → show reasons and allow resubmission.
- Inspection finds a shortfall or damage → require a buyer decision.
- Buyer does not trust holding logistics → support an agreed alternate QA route.
- Trade exceeds the deposit ceiling → explain eligibility before commitment.
- A dispute arises → route evidence to authorized admin operations staff.
- A trader buys and sells → keep each transaction’s responsibility clear.
Validate the uncertainty in internal testing
Check whether each role can identify the next owner, distinguish bid acceptance from QA acceptance, understand masked membership data and interpret payment versus settlement.
Internal testing also needs to validate how the platform handles stock committed to multiple trades, missed inspection deadlines, reserved trading capacity and disputed payouts.
WCAG 2.2 Level AA is the accessibility reference for clear status labels, keyboard access, visible focus and information that does not rely on color alone. This is a design requirement, not a conformance certification.
Developer handoff / A shareable reference
The design system is private.
Explore my approach.
I designed the design system and developer handoff for this platform, but they are covered by the same proprietary confidentiality as its screens. I cannot publish them here.
Explore my other design systems to see how I structure foundations, reusable components, interaction states and implementation guidance. They demonstrate the same approach I brought to this project’s developer handoff.
These are examples from separate projects, illustrating my working method rather than revealing this client’s system.
See my handoff approachThe design contribution
Digitize the coordination.
Respect the trust.
The result was an end-to-end product design for a business where a transaction is more than a buyer and seller agreeing on price. Inventory custody, independent decisions and controlled access became part of one coherent experience.
The product is in internal testing. Commercial outcomes and usability results are not quantified in this case study.
Explore more of my work.
Arrivals / Contact
Every great journey starts
with a conversation.
Open to senior product design roles and thoughtful product collaborations.