End-to-end UX/UI design for a Saudi Arabian consumer marketplace — combining fixed-price listings, live auctions, and free item giveaways with trust-first features including biometric identity verification and secure integrated payments. 

OfferYard is a consumer marketplace built for the Saudi Arabian market — enabling buyers and sellers to transact in brand-new and pre-owned items across furniture, electronics, cars, and more. As the sole designer, I owned the complete UX/UI across iOS, Android, and web — from research and IA through to final UI, a component library, and developer handoff. 

The Challenge

The Saudi online resale market was growing rapidly, but existing platforms were leaving critical user needs unaddressed. Buyers and sellers in KSA faced a fragmented landscape: platforms that were either too basic to build trust or too complex to use casually. 

The business challenge for OfferYard was to design a marketplace experience that felt as easy as Haraj, as trustworthy as eBay, and as locally relevant as OpenSooq — while introducing auction functionality and identity-verified transactions that none of the direct local competitors offered.  

The Three Core UX Problems  

My Role 

This was a solo design engagement — I was the only designer on the project. All UX decisions, design directions, and component-level details were owned and executed by me from discovery through to handoff.

Research & Discovery 

Methods Used

• Stakeholder brief review — product vision, target market, and feature requirements from OfferYard founders 

• Competitive analysis — deep audit of Haraj, OpenSooq, and eBay across listing flows, trust mechanisms, auction UX, and discovery patterns 

• Market context review — KSA consumer behaviour, Absher identity infrastructure, and local payment expectations 

• Heuristic evaluation — identifying UX patterns to adopt, avoid, and differentiate on  

Competitive Analysis 

Key Insight from Competitive Analysis 

No existing platform in the KSA market combined auction functionality, verified identity, secure payments, dispute handling, and free-item listings in one coherent experience. OfferYard’s opportunity was not to out-feature competitors — it was to out-trust them. In a market where uncertainty slows conversion, trust architecture becomes the product.

User Personas 

User Journey & Core Flows 

Seller Journey diagram

Click thumbnail to view full journey flow

Buyer Journey Diagram

Click thumbnail to view full journey flow

Key Journey Insights 

• Trust verification had to appear before the first offer action — not buried in the seller profile. Buyers needed to see the TruYou badge at the listing level to feel confident enough to engage. 

• The selling model selector (Fixed / Auction / Free) needed to be a guided choice, not a dropdown — casual sellers didn't know the difference and needed context at the point of decision. 

• Post-upload confirmation needed to preview how the listing would appear to buyers — sellers had no mental model of what a good listing looked like. 

• The auction flow needed a clear countdown, current bid visibility, and outbid notifications — without these, auction participation drops because buyers don't trust the process. 

Design Process 

I approached OfferYard as a trust-first marketplace — meaning every flow had to answer the question 'does this make the user feel safe enough to proceed?' before it answered 'is this fast enough?' That priority shaped every major decision from IA to final UI. 

Phase 1 — Competitive Research & Benchmarking

• Audited Haraj, OpenSooq, and eBay across 8 feature dimensions — identifying gaps and opportunities specific to the KSA market. 

• Mapped the trust gap as the primary design problem — every other feature decision was downstream of this. 

• Defined three selling models as first-class concepts: Fixed Price, Auction, and Free — each needing its own visual identity and flow logic. 

Phase 2 — Information Architecture & Flows 

• Designed the full IA across buyer, seller, and guest user states. 

• Created detailed user flows for: onboarding + TruYou verification, listing creation (all 3 models), auction bidding, offer management, and in-app messaging. 

• Mapped edge cases: outbid states, expired auctions, free item claims, and listing expiry. 

Phase 3 — Wireframing 

• Lo-fi wireframes for all core flows — prioritizing hierarchy and decision logic over visual polish. 

• Mid-fi wireframes for listing creation, auction flow, and buyer discovery — tested internally with stakeholders for alignment before moving to UI. 

• Iterated the selling model selector 3 times before landing on a card-based guided choice — the dropdown tested poorly in stakeholder review. 

Phase 4 — UI Design & Component Library  

• Designed final high-fidelity UI across iOS, Android, and web — adapting layouts for platform conventions while maintaining visual consistency. 

• Built a UI component library covering: listing cards, trust badges, auction timers, category chips, bottom sheets, modals, form states, and notification patterns. 

• Applied OfferYard's red brand palette with high contrast — ensuring accessibility across the product.  

Phase 5 — Handoff 

• Delivered annotated Figma files with component specs, interaction notes, and flow documentation for the development team. 

• Created a handoff guide covering responsive breakpoints, component states, and animation intent. 

  
  

Key Design Decisions 

Decision 1

TruYou verification badge at listing level, not just profile level 

The problem:  Trust in marketplace UX is only useful at the moment of decision. Buyers encounter seller profiles briefly — but they spend more time on listing pages deciding whether to bid or buy. 

What we tried:  A verification badge visible only on the seller's profile page. 

What we shipped:  A TruYou badge displayed prominently on every listing card and listing detail page — tied to Absher identity verification — so buyers see trust confirmation exactly where they need it. 

Why:  This moved trust from a background feature to a foreground signal. It reduced the cognitive load of evaluating a seller and directly addressed the primary reason KSA buyers hesitate on unfamiliar platforms. 

Decision 2

Card-based selling model selector instead of a dropdown 

The problem:  Casual sellers in KSA didn't have a clear mental model of the difference between Fixed Price, Auction, and Free listing models. A dropdown assumed knowledge they didn't have — and guesses at this step led to incorrect listing types and seller frustration. 

What we tried:  A standard dropdown selector labelled 'Listing Type' — fast but context-free. 

What we shipped:  A three-card guided selector showing each model with a label, one-line description, and a visual icon — presented as the first major choice in the listing creation flow. 

Why:  Sellers now make an informed choice rather than a guess. This reduced incorrect listing type selection and gave OfferYard's three-model structure a visible, differentiated identity that competitors lacked. 

Decision 3

Real-time auction UI with outbid push notification architecture

The problem:  Auction participation requires confidence in the process. If bidders don't see live bid counts, current prices, and clear countdown timers — and if they don't get notified when outbid — they disengage and don't return.  

What we tried:  A basic auction listing page showing start price and end date only. 

What we shipped:  A live auction UI with: current bid prominently displayed, participant count, countdown timer with urgency states (24hr / 1hr / ending), and a push notification trigger for outbid events. 

Why:  Auction engagement depends on re-entry — getting outbid and coming back is the core loop. The notification architecture was designed to drive that re-entry. Without it, OfferYard's auction feature would have looked like a feature but functioned like a dead-end.

Decision 4

Free item listing as a first-class selling model

The problem:  Platforms that only support paid transactions miss a significant driver of community trust and early user acquisition. Free item listings attract new users with zero transaction anxiety — and convert them into buyers and eventual sellers.   

What we tried:  A 'free item' tag added to standard fixed-price listings set to zero. 

What we shipped:  Free items as a distinct listing model with its own card badge, discovery filter, and dedicated entry point in browse — making free items visually distinct and easily findable.

Why:  This gave OfferYard a low-friction entry point for new users who weren't ready to transact with money. It also created a community-positive feature that differentiated the platform from purely commercial competitors.

Final Solution 

The final design covered all primary flows across buyer, seller, and guest states on iOS, Android, and web — with a consistent component library underpinning every surface. 

UI Component Library 

I built a structured component library in Adobe XD covering all reusable UI elements across the product — enabling consistent implementation across iOS, Android, and web and reducing development ambiguity during handoff. 

• Listing cards — Fixed, Auction, and Free variants with badge system and TruYou indicator 

• Auction timer component — with three urgency states (standard, 24hr warning, ending soon) 

• Trust badges — TruYou verified, unverified, and pending states 

• Bottom sheets, modals, and action sheets — for offer actions, confirmations, and selling model selection 

• Form states — empty, active, error, and success for listing creation and checkout flows 

• Category chips and filter bar — for browse and search surfaces 

• Notification patterns — outbid, offer received, listing expiry, and payment confirmation 

Results & Impact

Qualitative Outcomes 

• Stakeholder alignment confirmed the design addressed all three core UX problems identified in discovery — trust, listing complexity, and selling model clarity. 

• The TruYou badge architecture was validated as a key differentiator from existing KSA competitors — none of which offered visible listing-level identity verification. 

• The three-model selling structure gave OfferYard a distinct product identity versus Haraj and OpenSooq — creating a clearer market position before launch. 

• The component library significantly reduced estimated development time for the handoff phase — providing a single source of truth across all three platforms. 

Learnings & Reflection  

What worked well 

• Treating trust as the primary design problem — not a feature — meant every other decision had a clear priority filter. When in doubt: does this increase or decrease transaction confidence? 

• The competitive analysis structured as a gap analysis (not just a feature list) directly generated the three design problems. That framing made stakeholder alignment much faster. 

• Building the component library in parallel with the UI — not after — meant components were already validated in context by the time handoff happened. 

What I'd do differently 

• Conduct at least 5 user interviews with real KSA buyers and sellers before finalising the listing creation flow. Stakeholder briefs gave us direction, but real user validation would have reduced the iteration cycles on the selling model selector. 

• Design the Al-Waseet dispute and escrow flow in V1 — even as a light version. Leaving it entirely out of scope means the trust story has a visible gap for higher-value transactions that could slow early adoption. 

What this project taught me 

Designing for a consumer marketplace in an emerging market is fundamentally about designing for trust before designing for features. The technical capability to transact existed — what OfferYard needed was a design that made users feel safe enough to use it. Every screen, every badge, every flow was ultimately answering the same question: does this person feel confident enough to proceed?