لامركزی ایکسچینج (⁦DEX⁩) ڈیزائن کی بہترین مشقیں

⁦2018⁩ میں یونی سویپ کے آغاز کے بعد سے، درجنوں مختلف چینز پر سینکڑوں لامركزی ایکسچینجز شروع کی گئی ہیں۔ ان میں سے بہت سوں نے نئے عناصر متعارف کرائے یا اپنا منفرد انداز شامل کیا، لیکن انٹرفیس عام طور پر ایک جیسا ہی رہا ہے۔

اس کی ایک وجہ جیکب کا قانون (Jakob’s Law) (opens in a new tab) ہے:

صارفین اپنا زیادہ تر وقت دوسری سائٹس پر گزارتے ہیں۔ اس کا مطلب ہے کہ صارفین ترجیح دیتے ہیں کہ آپ کی سائٹ بھی اسی طرح کام کرے جیسے وہ تمام دوسری سائٹس جنہیں وہ پہلے سے جانتے ہیں۔

یونی سویپ، ⁦Pancakeswap⁩، اور Sushiswap جیسے ابتدائی جدت طرازوں کی بدولت، غیر مرکزی مالیات (DeFi) کے صارفین کو اجتماعی طور پر اندازہ ہے کہ ایک ⁦DEX⁩ کیسی دکھتی ہے۔ اس وجہ سے، اب 'بہترین مشق' جیسی کوئی چیز ابھر رہی ہے۔ ہم دیکھتے ہیں کہ سائٹس پر زیادہ سے زیادہ ڈیزائن کے فیصلوں کو معیاری بنایا جا رہا ہے۔ آپ ⁦DEXes⁩ کے ارتقاء کو لائیو ٹیسٹنگ کی ایک بڑی مثال کے طور پر دیکھ سکتے ہیں۔ جو چیزیں کارآمد رہیں وہ برقرار رہیں، جو نہیں رہیں، انہیں نکال دیا گیا۔ اب بھی انفرادیت کی گنجائش موجود ہے، لیکن کچھ مخصوص معیارات ہیں جن پر ایک ⁦DEX⁩ کو پورا اترنا چاہیے۔

یہ مضمون درج ذیل کا خلاصہ ہے:

• کیا شامل کیا جائے
• اسے زیادہ سے زیادہ قابل استعمال کیسے بنایا جائے
• ڈیزائن کو حسب ضرورت بنانے کے اہم طریقے

تمام مثالی وائر فریمز خاص طور پر اس مضمون کے لیے بنائے گئے تھے، حالانکہ وہ سب حقیقی پروجیکٹس پر مبنی ہیں۔

Figma کٹ بھی نیچے شامل کی گئی ہے - بلا جھجھک اسے استعمال کریں اور اپنے وائر فریمز کو تیز کریں!

ایک ⁦DEX⁩ کی بنیادی ساخت

⁦UI⁩ میں عام طور پر تین عناصر ہوتے ہیں:

1. مین فارم
2. بٹن
3. تفصیلات کا پینل

تغیرات (Variations)

یہ اس مضمون میں ایک عام موضوع ہوگا، لیکن ان عناصر کو منظم کرنے کے مختلف طریقے ہیں۔ 'تفصیلات کا پینل' ہو سکتا ہے:

• بٹن کے اوپر
• بٹن کے نیچے
• ایک اکارڈین (accordion) پینل میں چھپا ہوا
• اور/یا 'پیش نظارہ' (preview) موڈل پر

نوٹ: ایک 'پیش نظارہ' موڈل اختیاری ہے، لیکن اگر آپ مین ⁦UI⁩ پر بہت کم تفصیلات دکھا رہے ہیں، تو یہ ضروری ہو جاتا ہے۔

مین فارم کی ساخت

یہ وہ باکس ہے جہاں آپ اصل میں انتخاب کرتے ہیں کہ آپ کس ٹوکن کا تبادلہ کرنا چاہتے ہیں۔ یہ جزو ایک ان پٹ فیلڈ اور ایک قطار میں ایک چھوٹے بٹن پر مشتمل ہوتا ہے۔

⁦DEXes⁩ عام طور پر ایک قطار اوپر اور ایک قطار نیچے اضافی تفصیلات دکھاتی ہیں، حالانکہ اسے مختلف طریقے سے ترتیب دیا جا سکتا ہے۔

تغیرات

یہاں دو ⁦UI⁩ تغیرات دکھائے گئے ہیں؛ ایک بغیر کسی بارڈر کے، جو ایک بہت کھلا ڈیزائن بناتا ہے، اور دوسرا جہاں ان پٹ قطار کا ایک بارڈر ہوتا ہے، جو اس عنصر پر توجہ مرکوز کرتا ہے۔

یہ بنیادی ڈھانچہ ڈیزائن میں معلومات کے چار اہم حصوں کو دکھانے کی اجازت دیتا ہے: ہر کونے میں ایک۔ اگر صرف ایک اوپر/نیچے کی قطار ہے، تو صرف دو جگہیں ہوتی ہیں۔

غیر مرکزی مالیات (DeFi) کے ارتقاء کے دوران، یہاں بہت سی مختلف چیزیں شامل کی گئی ہیں۔

شامل کرنے کے لیے اہم معلومات

• والیٹ میں بیلنس
• میکس (Max) بٹن
• فیاٹ (Fiat) کے مساوی
• 'موصول شدہ' رقم پر قیمت پر اثر

غیر مرکزی مالیات (DeFi) کے ابتدائی دنوں میں، فیاٹ کے مساوی اکثر غائب ہوتا تھا۔ اگر آپ کسی بھی قسم کا Web3 پروجیکٹ بنا رہے ہیں، تو یہ ضروری ہے کہ فیاٹ کے مساوی دکھایا جائے۔ صارفین اب بھی مقامی کرنسیوں کے لحاظ سے سوچتے ہیں، لہذا حقیقی دنیا کے ذہنی ماڈلز سے مطابقت رکھنے کے لیے، اسے شامل کیا جانا چاہیے۔

دوسرے فیلڈ پر (وہ جہاں آپ اس ٹوکن کا انتخاب کرتے ہیں جس میں آپ تبادلہ کر رہے ہیں) آپ ان پٹ کی رقم اور تخمینی آؤٹ پٹ کی رقوم کے درمیان فرق کا حساب لگا کر، فیاٹ کرنسی کی رقم کے آگے قیمت پر اثر بھی شامل کر سکتے ہیں۔ یہ شامل کرنے کے لیے کافی مفید تفصیل ہے۔

فیصد بٹن (جیسے، 25%، 50%، 75%) ایک مفید خصوصیت ہو سکتے ہیں، لیکن وہ زیادہ جگہ لیتے ہیں، مزید کال ٹو ایکشنز (call to actions) کا اضافہ کرتے ہیں، اور ذہنی بوجھ بڑھاتے ہیں۔ فیصد سلائیڈرز کے ساتھ بھی ایسا ہی ہے۔ ان میں سے کچھ ⁦UI⁩ فیصلے آپ کے برانڈ اور آپ کے صارف کی قسم پر منحصر ہوں گے۔

اضافی تفصیلات مین فارم کے نیچے دکھائی جا سکتی ہیں۔ چونکہ اس قسم کی معلومات زیادہ تر پرو (pro) صارفین کے لیے ہوتی ہیں، اس لیے یہ سمجھ میں آتا ہے کہ یا تو:

• اسے جتنا ممکن ہو کم سے کم رکھیں، یا؛
• اسے ایک اکارڈین پینل میں چھپائیں

شامل کرنے کے لیے اضافی معلومات

• ٹوکن کی قیمت
• سلپج
• کم از کم موصول شدہ
• متوقع آؤٹ پٹ
• قیمت پر اثر
• گیس کی لاگت کا تخمینہ
• دیگر فیسیں
• آرڈر روٹنگ (Order routing)

قابل بحث طور پر، ان میں سے کچھ تفصیلات اختیاری ہو سکتی ہیں۔

آرڈر روٹنگ دلچسپ ہے، لیکن زیادہ تر صارفین کے لیے اس سے زیادہ فرق نہیں پڑتا۔

کچھ دوسری تفصیلات محض ایک ہی چیز کو مختلف طریقوں سے بیان کر رہی ہیں۔ مثال کے طور پر 'کم از کم موصول شدہ' اور 'سلپج' ایک ہی سکے کے دو رخ ہیں۔ اگر آپ نے سلپج کو 1% پر سیٹ کیا ہے، تو کم از کم جو آپ وصول کرنے کی توقع کر سکتے ہیں = متوقع آؤٹ پٹ - 1%۔ کچھ ⁦UIs⁩ متوقع رقم، کم از کم رقم، اور سلپج دکھائیں گے... جو مفید ہے لیکن ممکنہ طور پر ضرورت سے زیادہ ہے۔

زیادہ تر صارفین ویسے بھی ڈیفالٹ سلپج ہی چھوڑ دیں گے۔

'قیمت پر اثر' اکثر 'to' فیلڈ میں فیاٹ کے مساوی کے آگے بریکٹ میں دکھایا جاتا ہے۔ یہ شامل کرنے کے لیے ایک زبردست ⁦ux⁩ تفصیل ہے، لیکن اگر اسے یہاں دکھایا گیا ہے، تو کیا واقعی اسے نیچے دوبارہ دکھانے کی ضرورت ہے؟ اور پھر پیش نظارہ اسکرین پر دوبارہ؟

بہت سے صارفین (خاص طور پر وہ جو چھوٹی رقوم کا تبادلہ کر رہے ہیں) ان تفصیلات کی پرواہ نہیں کریں گے؛ وہ بس ایک نمبر درج کریں گے اور تبادلہ پر کلک کریں گے۔

بالکل کیا تفصیلات دکھائی جاتی ہیں اس کا انحصار آپ کے سامعین اور اس بات پر ہوگا کہ آپ ایپ کو کیسا احساس دینا چاہتے ہیں۔

اگر آپ تفصیلات کے پینل میں سلپج کی برداشت (tolerance) کو شامل کرتے ہیں، تو آپ کو اسے براہ راست یہاں سے قابل تدوین بھی بنانا چاہیے۔ یہ ایک 'ایکسلریٹر' (accelerator) کی ایک اچھی مثال ہے؛ ایک عمدہ ⁦UX⁩ ترکیب جو ایپ کی عمومی افادیت کو متاثر کیے بغیر، تجربہ کار صارفین کے فلو (flows) کو تیز کر سکتی ہے۔

یہ ایک اچھا خیال ہے کہ نہ صرف ایک اسکرین پر معلومات کے ایک مخصوص حصے کے بارے میں، بلکہ پورے فلو کے بارے میں احتیاط سے سوچا جائے: مین فارم میں نمبر درج کرنا → تفصیلات کو اسکین کرنا → پیش نظارہ اسکرین پر کلک کرنا (اگر آپ کے پاس پیش نظارہ اسکرین ہے)۔ کیا تفصیلات کا پینل ہر وقت نظر آنا چاہیے، یا صارف کو اسے پھیلانے کے لیے کلک کرنے کی ضرورت ہے؟ کیا آپ کو پیش نظارہ اسکرین شامل کر کے رگڑ (friction) پیدا کرنی چاہیے؟ یہ صارف کو سست ہونے اور اپنی ٹریڈ پر غور کرنے پر مجبور کرتا ہے، جو مفید ہو سکتا ہے۔ لیکن کیا وہ وہی تمام معلومات دوبارہ دیکھنا چاہتے ہیں؟ اس مقام پر ان کے لیے سب سے زیادہ مفید کیا ہے؟

ڈیزائن کے اختیارات

جیسا کہ ذکر کیا گیا ہے، اس میں سے بہت کچھ آپ کے ذاتی انداز پر منحصر ہے آپ کا صارف کون ہے؟ آپ کا برانڈ کیا ہے؟ کیا آپ ایک 'پرو' انٹرفیس چاہتے ہیں جو ہر تفصیل دکھائے، یا آپ کم سے کم (minimalist) رہنا چاہتے ہیں؟ یہاں تک کہ اگر آپ ان پرو صارفین کو نشانہ بنا رہے ہیں جو ہر ممکن معلومات چاہتے ہیں، تب بھی آپ کو ایلن کوپر (Alan Cooper) کے دانشمندانہ الفاظ یاد رکھنے چاہئیں:

آپ کا انٹرفیس کتنا ہی خوبصورت کیوں نہ ہو، کتنا ہی شاندار کیوں نہ ہو، یہ بہتر ہوگا اگر یہ کم ہو۔

ساخت

• ٹوکنز بائیں طرف، یا ٹوکنز دائیں طرف
• 2 قطاریں یا 3
• تفصیلات بٹن کے اوپر یا نیچے
• تفصیلات پھیلی ہوئی، چھوٹی کی گئی، یا نہیں دکھائی گئیں

جزو کا انداز

• خالی
• آؤٹ لائنڈ (outlined)
• بھرا ہوا (filled)

خالص ⁦UX⁩ نقطہ نظر سے، ⁦UI⁩ کا انداز آپ کی سوچ سے کم اہمیت رکھتا ہے۔ بصری رجحانات چکروں میں آتے اور جاتے ہیں، اور بہت سی ترجیحات موضوعی (subjective) ہوتی ہیں۔

اس کا اندازہ لگانے - اور مختلف کنفیگریشنز کے بارے میں سوچنے - کا سب سے آسان طریقہ یہ ہے کہ کچھ مثالوں پر نظر ڈالیں اور پھر خود کچھ تجربات کریں۔

شامل کردہ Figma کٹ میں خالی، آؤٹ لائنڈ اور بھرے ہوئے اجزاء شامل ہیں۔

یہ دیکھنے کے لیے کہ آپ ان سب کو کن مختلف طریقوں سے ایک ساتھ رکھ سکتے ہیں، ذیل کی مثالوں پر نظر ڈالیں:

لیکن ٹوکن کس طرف ہونا چاہیے؟

لب لباب یہ ہے کہ اس سے افادیت پر شاید کوئی بڑا فرق نہیں پڑتا۔ تاہم، ذہن میں رکھنے کے لیے کچھ چیزیں ہیں، جو آپ کو ایک یا دوسری طرف مائل کر سکتی ہیں۔

وقت کے ساتھ فیشن کو بدلتے دیکھنا قدرے دلچسپ رہا ہے۔ یونی سویپ میں ابتدائی طور پر ٹوکن بائیں طرف تھا، لیکن بعد میں اسے دائیں طرف منتقل کر دیا گیا۔ Sushiswap نے بھی ڈیزائن اپ گریڈ کے دوران یہ تبدیلی کی۔ زیادہ تر، لیکن تمام نہیں، پروٹوکولز نے اس کی پیروی کی ہے۔

مالیاتی روایت روایتی طور پر کرنسی کی علامت کو نمبر سے پہلے رکھتی ہے، جیسے، $50، €50، £50، لیکن ہم کہتے ہیں 50 ڈالر، 50 یورو، 50 پاؤنڈ۔

عام صارف کے لیے - خاص طور پر وہ جو بائیں سے دائیں، اوپر سے نیچے پڑھتا ہے - دائیں طرف ٹوکن شاید زیادہ فطری محسوس ہوتا ہے۔

ٹوکن کو بائیں طرف اور تمام نمبروں کو دائیں طرف رکھنا خوشگوار حد تک متوازی (symmetrical) لگتا ہے، جو کہ ایک پلس پوائنٹ ہے، لیکن اس لے آؤٹ کا ایک اور نقصان بھی ہے۔

قربت کا قانون (law of proximity) کہتا ہے کہ جو اشیاء ایک دوسرے کے قریب ہوتی ہیں انہیں متعلقہ سمجھا جاتا ہے۔ اس کے مطابق، ہم متعلقہ اشیاء کو ایک دوسرے کے آگے رکھنا چاہتے ہیں۔ ٹوکن کا بیلنس براہ راست خود ٹوکن سے متعلق ہے، اور جب بھی کوئی نیا ٹوکن منتخب کیا جائے گا تو یہ بدل جائے گا۔ اس لیے یہ قدرے زیادہ معقول ہے کہ ٹوکن کا بیلنس ٹوکن منتخب کرنے والے بٹن کے آگے ہو۔ اسے ٹوکن کے نیچے منتقل کیا جا سکتا ہے، لیکن اس سے لے آؤٹ کا توازن ٹوٹ جاتا ہے۔

آخر کار، دونوں اختیارات کے فائدے اور نقصانات ہیں، لیکن یہ دلچسپ ہے کہ رجحان دائیں طرف ٹوکن کی طرف کیسے ظاہر ہوتا ہے۔

بٹن کا برتاؤ

منظور کرنا (Approve) کے لیے الگ بٹن نہ رکھیں۔ اس کے علاوہ منظور کرنا کے لیے الگ کلک بھی نہ رکھیں۔ صارف تبادلہ کرنا چاہتا ہے، لہذا بٹن پر صرف 'تبادلہ' (swap) کہیں اور پہلے قدم کے طور پر منظوری شروع کریں۔ ایک موڈل اسٹیپر (stepper) کے ساتھ پیشرفت دکھا سکتا ہے، یا ایک سادہ 'tx 1 of 2 - منظور کیا جا رہا ہے' نوٹیفکیشن۔

سیاق و سباق کی مدد کے طور پر بٹن

بٹن الرٹ کے طور پر دوہرا کام کر سکتا ہے!

یہ دراصل Web3 کے باہر ایک کافی غیر معمولی ڈیزائن پیٹرن ہے، لیکن اس کے اندر معیاری بن گیا ہے۔ یہ ایک اچھی جدت ہے کیونکہ یہ جگہ بچاتی ہے، اور توجہ مرکوز رکھتی ہے۔

اگر بنیادی کارروائی - تبادلہ (SWAP) - کسی خرابی کی وجہ سے دستیاب نہیں ہے، تو اس کی وجہ بٹن کے ساتھ بیان کی جا سکتی ہے، جیسے:

• نیٹ ورک تبدیل کریں
• والیٹ منسلک کریں
• مختلف خرابیاں

بٹن کو اس کارروائی سے بھی میپ (mapped) کیا جا سکتا ہے جو انجام دینے کی ضرورت ہے۔ مثال کے طور پر، اگر صارف تبادلہ نہیں کر سکتا کیونکہ وہ غلط نیٹ ورک پر ہے، تو بٹن پر 'ایتھیریم پر سوئچ کریں' لکھا ہونا چاہیے، اور جب صارف بٹن پر کلک کرتا ہے، تو اسے نیٹ ورک کو ایتھیریم پر سوئچ کرنا چاہیے۔ یہ صارف کے فلو کو نمایاں طور پر تیز کرتا ہے۔

اس figma فائل کے ساتھ اپنا خود کا بنائیں

متعدد پروٹوکولز کی محنت کی بدولت، ⁦DEX⁩ ڈیزائن میں بہت بہتری آئی ہے۔ ہم جانتے ہیں کہ صارف کو کن معلومات کی ضرورت ہے، ہمیں اسے کیسے دکھانا چاہیے، اور فلو کو جتنا ممکن ہو ہموار کیسے بنانا ہے۔ امید ہے کہ یہ مضمون ⁦UX⁩ کے اصولوں کا ایک ٹھوس جائزہ فراہم کرتا ہے۔

اگر آپ تجربہ کرنا چاہتے ہیں، تو براہ کرم بلا جھجھک Figma وائر فریم کٹ استعمال کریں۔ اسے جتنا ممکن ہو سادہ رکھا گیا ہے، لیکن اس میں بنیادی ڈھانچے کو مختلف طریقوں سے بنانے کے لیے کافی لچک موجود ہے۔

Figma وائر فریم کٹ (opens in a new tab)

غیر مرکزی مالیات (DeFi) کا ارتقاء جاری رہے گا، اور بہتری کی گنجائش ہمیشہ موجود رہتی ہے۔

گڈ لک!

صفحہ کی آخری اپ ڈیٹ: ۲۱ اکتوبر، ۲۰۲۵

p (opens in a new tab)

j (opens in a new tab)

c (opens in a new tab)

+3

تعاون کنندگان دیکھیں