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

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

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

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

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

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

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

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

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

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

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

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

تغیرات (Variations)

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

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

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

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

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

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

تغیرات

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

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

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

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

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

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

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

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

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

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

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

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

یہ کہا جا سکتا ہے کہ ان میں سے کچھ تفصیلات اختیاری ہو سکتی ہیں۔

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

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

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

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

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

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

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

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

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

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

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

ساخت

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

جزو کا انداز (Component style)

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

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

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

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

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

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

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

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

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

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

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

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

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

بٹن کا برتاؤ

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

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

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

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

اگر کوئی خرابی کی وجہ سے مرکزی کارروائی - SWAP - دستیاب نہیں ہے، تو اس کی وجہ بٹن کے ذریعے بتائی جا سکتی ہے، جیسے:

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

بٹن کو اس کارروائی سے بھی میپ کیا جا سکتا ہے جو انجام دینے کی ضرورت ہے۔ مثال کے طور پر، اگر صارف سویپ نہیں کر سکتا کیونکہ وہ غلط نیٹ ورک پر ہے، تو بٹن پر "switch to Ethereum" لکھا ہونا چاہیے، اور جب صارف بٹن پر کلک کرے، تو اسے نیٹ ورک کو Ethereum پر تبدیل کر دینا چاہیے۔ اس سے صارف کا فلو نمایاں طور پر تیز ہو جاتا ہے۔

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

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

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

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

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

گڈ لک!