Marketplace confidence · Service design + UX/UI
Digikala Promise.
I redesigned the connective tissue between seller choice, split delivery, exceptions, returns and refunds—so one marketplace feels like one reliable service.
Independent, unsolicited concept
Public evidence
Service hypotheses
CompareAll-in offer
PromiseBefore payment
RecoverWithout chasing
ExplainWhy recommended
12:42● ●●
۳ فروشنده
انتخاب مطمئنتر
قیمت نهایی، اعتبار فروشنده و زمان تحویل کنار هم.
پیشنهاد دیجیکالافروشگاه آفتاب
قیمت نهایی۱۸٫۶ م.
تحویلفردا
رضایت97%
مرجوعی۷ روز
ارزانترفروشگاه سپهر
قیمت نهایی۱۷٫۹ م.
تحویل۳ روز دیگر
وعده سفارش
یک بسته · تحویل فردا
در صورت تغییر، اقدام بعدی همینجا نمایش داده میشود.Research integrity
This concept uses public pages, service policies and public app-store themes. I did not interview 200 Digikala customers, observe fulfilment operations or access company analytics. The research plan later in the case study is a proposed protocol—not a completed study disguised as a result.
01 · Executive summary
The customer sees one brand. The service is delivered by many actors.
A marketplace can make selection feel almost limitless, but every additional seller, delivery method and return condition adds invisible coordination. Customers do not experience those systems as an org chart. They experience one order from Digikala.
My concept adds a “promise layer” across the journey. Before payment it explains the all-in offer and who fulfils it. After payment it converts operational status into a customer promise, detects broken promises early, and keeps recovery and refund progress visible without making the customer reconstruct the service from help pages.
Help me know what will arrive, when, from whom—and what happens next if the promise breaks.The customer job I used to unify the marketplace journey
02 · Evidence stack
A large product footprint creates a large trust surface.
Public scale indicators show that this is not a niche edge case. Store listings also surface both sides of the experience: breadth and convenience are valued, while delivery exceptions, app performance, price inconsistency, support and refunds recur as pain themes. These themes guide questions; they do not establish population-level frequency.
Verified: directly observed
Inferred: design interpretation
Proposed: requires validation
One product can have different seller offers.
The public app listing explains that users can inspect seller ratings and comments; identical products can carry different prices, and delivery timing depends on the seller.
Cafe Bazaar Digikala listing [2]Returns span several channels and states.
Digikala documents web, app, contact-form and phone routes. Online requests can be edited, expanded or cancelled, and returned items move through review before refund or return-to-customer.
Official return guidance [4] [5]Support already reflects an ecosystem of exceptions.
The official assistant covers shipment status, incomplete or wrong orders, changes and cancellations, return status, refunded item value and failed-payment refunds.
Official support-assistant FAQ [6]Convenience coexists with operational pain.
Myket’s public review summary praises selection, discounts, instalments, free shipping, delivery and packaging, while also surfacing damaged or delayed orders, app slowness, search issues, pricing inconsistency and slow support/refunds.
Myket review summary [3]Fragmentation becomes the customer’s work.
When seller, carrier, platform and payment states are presented separately, the user has to interpret responsibility and next action. I treat that translation burden as a design problem.
Service-design interpretationA promise should be measurable end to end.
The most useful unit is not “order shipped.” It is whether the displayed price, delivery window, item condition, return decision and refund timing matched what the customer was led to expect.
Measurement model in section 1003 · Diagnosis
Trust leaks at the seams between marketplace systems.
The individual touchpoints can each be usable while the overall service still feels uncertain. The core problem is continuity: an offer selected on the product page must survive checkout, fulfilment, support and return without changing meaning.
Offer ambiguity
Price, shipping, seller confidence, fulfilment ownership and return implications can require separate interpretation. “Cheapest” may not be the lowest total cost or best fit.
Split-order surprise
A cart can become multiple packages, windows or fulfilment owners. The operational reality is often understood after the shopping decision rather than during it.
Tracking without a promise
Operational events describe what the system did. Customers need to know whether delivery is still on track and what will happen if it is not.
Recovery opacity
Eligibility, evidence, pickup, inspection, acceptance and refund are distinct states. Without one visible timeline, the customer has to repeatedly seek status.
Performance as service quality
Public reviews mention app weight, slowness, heating and battery impact. A marketplace cannot feel convenient when browsing itself becomes expensive on the device.
Every marketplace state should answer three questions.
- What is promised? Price, contents, date, condition and policy.
- Who owns the next step? Customer, seller, carrier or Digikala.
- What happens if the promise changes? Options, timing and compensation.
This is not a homepage redesign.
The visual interface is only the frontstage. The concept depends on offer data, fulfilment event quality, seller performance, notification orchestration, support tooling and refund operations.
A polished tracking screen cannot repair an unreliable service model; it can only make the model visible and actionable.
04 · Service blueprint
Design the promise before designing the screen.
I mapped the journey as a contract that moves across systems. Each stage has a customer question, a frontstage answer and a backstage capability. The goal is continuity rather than adding another support feature.
Discover
Find products by need; understand alternatives and price context.
Choose offer
Compare total cost, reliability, delivery and return conditions.
Commit
Preview package split, windows, owners and final promise.
Receive
Track promise health and handle exceptions proactively.
Return
Know eligibility, required evidence and pickup options.
Resolve
See inspection, decision, refund destination and timing.
| Layer | Choose | Checkout | Fulfil | Exception | Return/refund |
|---|---|---|---|---|---|
| User question | Which offer is best for me? | What exactly am I committing to? | Is the promise still on track? | Who is fixing this? | When is this resolved? |
| Frontstage | All-in offer comparison | Shipment/promise preview | Promise tracker | Proactive options + owner | Guided return + refund timeline |
| Backstage | Seller, price and service scoring | Inventory + routing simulation | Event normalization + ETA | Rules, capacity and compensation | Eligibility, inspection and payment rail |
| Evidence | Price + seller + delivery vary | Split complexity to validate | Tracking is a top support intent | Wrong/incomplete order support exists | Multi-step, reviewed return process |
| Opportunity | Explain “why this offer” | Consent to the service shape | Promise health over event list | Action before contact | One visible case record |
05 · Design principles
Six rules for marketplace confidence.
The principles connect choice architecture, service recovery, accessibility and marketplace transparency. They also provide a decision filter when seller growth, conversion and customer outcomes conflict.
01
Show the landed offer
Price, shipping, arrival, seller and return condition belong in one comparable object.
No drip information02
Explain recommendation
A “best” badge states the user goal and evidence. The customer can change the priority.
Explainable ranking03
Preview fragmentation
Reveal packages, fulfilment owners and dates before payment—not as an after-order discovery.
Expectation management04
Track the promise
Operational events are translated into on-track, at-risk or changed, with the next decision attached.
Outcome-oriented status05
Make recovery visible
Return eligibility, evidence, inspection, decision and refund stay in one persistent case record.
Service continuity06
AI assists; users confirm
Conversational discovery can summarize evidence, but must cite its basis, expose uncertainty and never place an order without confirmation.
Human agency in agentic commerce06 · Interactive concept
Let the customer choose what “best” means.
Marketplace rankings often compress several priorities into a single recommendation. The concept makes the trade-off visible. Change the goal below and the recommendation updates with an explanation, all-in cost and service implication.
Which offer fits this order?
Illustrative seller data. A production model should publish the factors used, prevent paid placement from masquerading as quality and let the customer override the ranking.
Prioritize
فروشگاه آفتاب
18.60Mincl. delivery
فروشگاه سپهر
17.90Mincl. delivery
دیجیکالا اکسپرس
18.40Mfree delivery
Recommendation
Aftab
1 package · delivery tomorrow
Recommended because you prioritized arrival speed.
It arrives one day sooner than the next-fastest offer. The all-in price is 200,000 toman higher than Digikala Express and 700,000 higher than the lowest-price option.
Total price18.60M TMN
Seller satisfaction97%
ArrivalTomorrow
FulfilmentSeller → Digikala delivery
07 · Key screens
One promise, carried across six moments.
Each screen has a distinct job, but the same information model: promise, owner, health, next action and evidence. The user should not have to relearn the service when the order moves from shopping to support.
12:42● ●●
۳ فروشنده
انتخاب فروشنده
قیمت نهایی و کیفیت خدمت را یکجا مقایسه کنید.
مناسب برای تحویل سریعآفتاب
نهایی۱۸٫۶ م.
تحویلفردا
رضایت97%
ارسالدیجیکالا
کمترین قیمتسپهر
۱۷٫۹ م. · تحویل ۳ روزه›
01 · Offer
Comparable seller choice
The badge names the goal; total cost and service evidence stay visible.
12:42● ●●
پیشنمایش
این سفارش چگونه میرسد؟
وعده فعلی
۲ بسته · ۲ بازه تحویل
قبل از پرداخت قابل تغییر استبسته ۱فردا ۹–۱۲
موبایل · ارسال دیجیکالا · دریافت حضوری ممکن
بسته ۲شنبه ۱۴–۱۸
قاب · ارسال فروشنده · تغییر بازه محدود
02 · Commit
Shipment preview
Package split, owner and constraints become part of informed checkout.
12:42● ●●
طبق برنامه
وضعیت وعده سفارش
تحویل مورد انتظار
امروز ۱۴ تا ۱۸
آخرین رویداد: ورود به مرکز توزیعانجام شدآمادهسازی فروشنده
انجام شدتحویل به شبکه ارسال
بعدیخروج برای تحویل
03 · Track
Promise health, not event noise
The interface leads with whether the order is still on track.
12:42● ●●
وعده تغییر کرد
تاخیر احتمالی
تحویل امروز دیگر قابل تضمین نیست
تخمین جدید: فردا ۹ تا ۱۲ · مسئول اقدام: دیجیکالا
گزینههای شما
تایید زمان جدیدرایگان
دریافت از مرکز نزدیکامروز
لغو این بستهبازگشت وجه
04 · Recover
Proactive exception choice
The service owns the changed promise and offers resolution before contact.
12:42● ●●
مرحله ۱ از ۳
مرجوعی کالا
ابتدا شرایط این کالا را بررسی میکنم.
واجد شرایطتا ۴ روز دیگر
دلیل انتخابی: آسیب ظاهری هنگام تحویل. برای بررسی سریعتر دو عکس لازم است.
مدرک موردنیاز
عکس بستهبندیافزودن +
عکس آسیبافزودن +
05 · Return
Eligibility before effort
The user knows the condition, deadline and evidence before starting.
12:42● ●●
در حال بررسی
پرونده بازگشت وجه
زمان تخمینی تکمیل
تا دوشنبه
مقصد: کیف پول دیجیپی · ۱۸٫۶ میلیونانجام شددریافت مرجوعی
اکنونبررسی کالا
بعدیتایید و انتقال وجه
اگر تا دوشنبه تکمیل نشد
پرونده خودکار به تیم ارشد خدمات پس از فروش ارجاع میشود.
06 · Resolve
Visible refund case
A single record shows owner, amount, destination, timing and escalation.
08 · Emerging commerce
Use AI to reduce comparison work—not to hide the marketplace.
Shopping platforms are moving toward conversational comparison, price history, cross-merchant carts and agentic checkout. The useful pattern is not “add a chatbot.” It is to let people express intent naturally, show evidence behind the answer, preserve merchant and policy clarity, and require confirmation before consequential action.
“Find a phone for my father under 20 million—simple camera, strong battery, delivery before Friday.”
The assistant translates the request into visible criteria, compares products and seller offers, cites review and specification evidence, then asks the user to confirm which trade-off matters most.
It never turns sponsored placement into an unexplained recommendation.
Conversational research + structured comparison
Amazon’s shopping assistant and Google’s AI shopping experiences combine natural-language requests with product data, comparisons, price tracking and increasingly agentic tasks.
Evidence, uncertainty and confirmation
Every recommendation should expose why it was made, what data may be stale, whether placement is sponsored, and what the assistant will do next. Purchase and cancellation remain explicit user decisions.
09 · Standards + culture
A Persian marketplace needs more than translated components.
The design has to work across scripts, devices, regions and service variability. Cultural design here means respecting how the product is actually used—not making broad claims about “Iranian users.” Every local assumption below is either a technical requirement or a hypothesis to test.
WCAG
2.2 AA
2.2 AA
Accessible commerce and recovery
Touch targets, focus visibility, semantic status, non-colour cues, consistent help and error prevention apply to checkout and return forms alike.
W3C standard [7]ISO
9241
9241
Design the whole interactive system
Human-centred design includes people, software, service, support and documentation—not only the buyer-facing interface.
ISO 9241-210 and 9241-110 [8]RTL
+ BIDI
+ BIDI
Persian first, mixed content safe
Use structural direction, logical properties and isolated LTR fragments for model numbers, prices, order IDs and Latin brand names.
W3C internationalization guidance [9]PRICE
TRUTH
TRUTH
No hidden comparison work
Show the total payable offer before checkout and distinguish product price, delivery, membership benefit and return cost. International dark-pattern guidance is a benchmark, not local law.
Comparable marketplace transparency principles [10]LOW
BANDWIDTH
BANDWIDTH
Performance is inclusion
Set a low-end Android performance budget, lazy-load nonessential media, preserve search and order tracking on weak networks, and avoid battery-heavy decoration.
Supported by public review themes; validate with device telemetryLOCAL
PROMISE
PROMISE
Make fulfilment destination-specific
Delivery confidence must reflect the selected address, seller route and local capacity. Never display a generic national promise where the service varies by destination.
Operational hypothesis to validate across regionsTMN
≠ IRR
≠ IRR
Use explicit money units
Label toman consistently, preserve grouping in long numbers and repeat the refund destination and amount in both numerals and plain language when consequence is high.
Localization and error-prevention requirementSHARE
SAFE
SAFE
Support shared decisions without leaking data
Test a shareable product/offer summary for household decisions, but strip address, payment and account details by default.
Proposed use case—not a cultural claim10 · Validation plan
A mixed-method study built around real orders.
The plan below is ready to run but has not been run. I would recruit for behavioural diversity rather than a large vanity number: new and frequent buyers, Tehran and non-Tehran destinations, marketplace and first-party fulfilment, successful and failed returns, and varied Android devices.
Study status: proposedReplace with real evidence after fieldwork
Discovery interviews
Planned: 18 recent customers using their own order histories. Reconstruct seller choice, checkout expectation, delivery, support and resolution.
Order diary
Planned: 12 participants log confidence at checkout, dispatch, arrival and any exception. Capture screenshots and contact attempts.
Usability benchmark
Planned: 24 participants compare offers, predict package split, handle a delay and start a return across low/mid/high-end devices.
Service pilot
Release promise cards to one category and delivery route. Compare contact rate, exception resolution and repeat purchase with a matched control.
What would change the design?
- Do customers understand why one seller is recommended?
- Which package split becomes unacceptable, and why?
- At what point does tracking stop feeling trustworthy?
- Which return states trigger support contact?
- Does proactive choice reduce frustration or add cognitive load?
What belongs in the final portfolio story.
- Recruitment matrix and exclusions
- Interview guide and consent approach
- Journey evidence mapped to screenshots
- Severity and confidence per finding
- Before/after task data
- Design changes—including ideas rejected
11 · Measurement
Measure whether the promise was kept—and recovered.
Conversion remains important, but the metric tree adds expectation accuracy and recovery. A seller offer that converts well by hiding a slow route is not a healthy recommendation. A delayed order can still retain trust when the change is owned and resolved well.
Promise-kept order rate
Orders where all-in price, package shape, delivery window, item condition and stated policy match the experience—or a changed promise is accepted and resolved.
Offer comprehension
Can customers explain price, owner, delivery and reason for recommendation?
Promise accuracy
Actual arrival versus customer-visible window, segmented by seller and route.
Contactless resolution
Exceptions resolved through clear self-service without repeated contact.
Refund certainty
Accuracy of displayed amount/date plus contact rate during refund.
Offer + promise schema
- Define landed price
- Normalize seller evidence
- Model fulfilment owner
- Instrument expectation events
Frontstage continuity
- Offer comparison
- Shipment preview
- Promise health tracker
- Proactive exception options
One service case
- Guided return eligibility
- Evidence capture
- Inspection/refund timeline
- Automatic escalation
12 · Reflection
The interface is the receipt for an operational promise.
The strongest outcome of this exercise is not a new card or tracker. It is a common service object that the product page, checkout, fulfilment system, seller tools, support agent and return process can all understand.
Without that backstage alignment, a “seamless” UI would be theatre. With it, Digikala can make marketplace complexity visible only when it helps the customer choose—and absorb that complexity when the customer needs recovery.
Source notes
Public references used.
Accessed July 2026. Marketplace counts and public policies can change. Review summaries are directional theme sources, not representative user research. International standards and regulations are design benchmarks, not claims about Digikala’s legal obligations.
01Digikala homepage: support, delivery, payment, return and authenticity promisesOfficial
02Digikala Cafe Bazaar listing: installs, ratings and seller-choice explanationMarketplace
03Digikala Myket listing: downloads, ratings and public review themesMarketplace
04Official methods for submitting and editing a return requestOfficial
05Official return review and refund/return outcome guidanceOfficial
06Official online support-assistant capabilitiesOfficial
07Web Content Accessibility Guidelines 2.2Standard
08ISO 9241-210 human-centred design; paired with ISO 9241-110Standard
09W3C guidance for structural RTL and bidirectional textGuidance
10FTC dark-pattern guidance used as a transparency benchmarkBenchmark
11Google Shopping: intelligent cart and agentic-commerce directionIndustry
12Amazon shopping assistant: comparison, price history and agentic featuresIndustry