أفضل ممارسات تصميم منصات التداول اللامركزية (⁦DEX⁩)

منذ إطلاق يونيسواب في عام 2018، تم إطلاق المئات من منصات التداول اللامركزية عبر العشرات من السلاسل المختلفة. قدم العديد منها عناصر جديدة أو أضاف لمسته الخاصة، لكن الواجهة ظلت كما هي بشكل عام.

أحد أسباب ذلك هو قانون جاكوب (opens in a new tab):

يقضي المستخدمون معظم وقتهم في مواقع أخرى. هذا يعني أن المستخدمين يفضلون أن يعمل موقعك بنفس الطريقة التي تعمل بها جميع المواقع الأخرى التي يعرفونها بالفعل.

بفضل المبتكرين الأوائل مثل يونيسواب وPancakeswap وSushiswap، أصبح لدى مستخدمي التمويل اللامركزي (DeFi) فكرة جماعية عما تبدو عليه منصة التداول اللامركزية (DEX). لهذا السبب، بدأ يظهر الآن ما يشبه "أفضل الممارسات". نرى المزيد والمزيد من قرارات التصميم يتم توحيدها عبر المواقع. يمكنك رؤية تطور منصات التداول اللامركزية (DEXs) كمثال ضخم على الاختبار المباشر. الأشياء التي نجحت بقيت، والأشياء التي لم تنجح تم التخلص منها. لا يزال هناك مجال لإضافة طابع شخصي، ولكن هناك معايير معينة يجب أن تتوافق معها منصة التداول اللامركزية (DEX).

هذه المقالة هي ملخص لما يلي:

• ما يجب تضمينه
• كيفية جعله قابلاً للاستخدام قدر الإمكان
• الطرق الرئيسية لتخصيص التصميم

تم تصميم جميع الإطارات الشبكية (wireframes) التوضيحية خصيصًا لهذه المقالة، على الرغم من أنها تستند جميعها إلى مشاريع حقيقية.

تم تضمين مجموعة Figma أيضًا في الأسفل - لا تتردد في استخدامها وتسريع إنشاء إطاراتك الشبكية!

التشريح الأساسي لمنصة التداول اللامركزية (DEX)

تحتوي واجهة المستخدم (UI) بشكل عام على ثلاثة عناصر:

1. النموذج الرئيسي
2. الزر
3. لوحة التفاصيل

الاختلافات

سيكون هذا موضوعًا متكررًا في هذه المقالة، ولكن هناك طرق مختلفة ومتنوعة يمكن من خلالها تنظيم هذه العناصر. يمكن أن تكون "لوحة التفاصيل":

• فوق الزر
• أسفل الزر
• مخفية في لوحة قابلة للطي (accordion)
• و/أو في نافذة منبثقة (modal) "للمعاينة"

ملاحظة: النافذة المنبثقة "للمعاينة" اختيارية، ولكن إذا كنت تعرض تفاصيل قليلة جدًا في واجهة المستخدم الرئيسية، فإنها تصبح ضرورية.

هيكل النموذج الرئيسي

هذا هو المربع الذي تختار فيه فعليًا الرمز المميز الذي تريد مبادلته. يتكون المكون من حقل إدخال وزر صغير في صف واحد.

تعرض منصات التداول اللامركزية (DEXs) عادةً تفاصيل إضافية في صف واحد بالأعلى وصف واحد بالأسفل، على الرغم من أنه يمكن تكوين ذلك بشكل مختلف.

الاختلافات

يظهر هنا اختلافان في واجهة المستخدم؛ أحدهما بدون أي حدود، مما يخلق تصميمًا مفتوحًا للغاية، والآخر يحتوي فيه صف الإدخال على حدود، مما يخلق تركيزًا على ذلك العنصر.

يسمح هذا الهيكل الأساسي بعرض أربع معلومات رئيسية في التصميم: واحدة في كل زاوية. إذا كان هناك صف علوي/سفلي واحد فقط، فلن يكون هناك سوى مكانين.

خلال تطور التمويل اللامركزي (DeFi)، تم تضمين الكثير من الأشياء المختلفة هنا.

المعلومات الرئيسية التي يجب تضمينها

• الرصيد في المحفظة
• زر الحد الأقصى (Max)
• المعادل بالعملة الورقية (Fiat)
• تأثير السعر على المبلغ "المُستلم"

في الأيام الأولى للتمويل اللامركزي (DeFi)، كان المعادل بالعملة الورقية مفقودًا في كثير من الأحيان. إذا كنت تبني أي نوع من مشاريع Web3، فمن الضروري عرض المعادل بالعملة الورقية. لا يزال المستخدمون يفكرون بلغة العملات المحلية، لذلك من أجل مطابقة النماذج العقلية في العالم الحقيقي، يجب تضمين ذلك.

في الحقل الثاني (الحقل الذي تختار فيه الرمز المميز الذي تقوم بمبادلته إليه)، يمكنك أيضًا تضمين تأثير السعر بجوار مبلغ العملة الورقية، عن طريق حساب الفرق بين مبلغ الإدخال ومبالغ الإخراج المقدرة. هذه تفصيلة مفيدة جدًا لتضمينها.

يمكن أن تكون أزرار النسبة المئوية (مثل 25%، 50%، 75%) ميزة مفيدة، لكنها تشغل مساحة أكبر، وتضيف المزيد من الدعوات لاتخاذ إجراء (CTAs)، وتزيد من العبء الذهني. ينطبق الشيء نفسه على أشرطة التمرير للنسبة المئوية. ستعتمد بعض قرارات واجهة المستخدم هذه على علامتك التجارية ونوع المستخدم الخاص بك.

يمكن عرض تفاصيل إضافية أسفل النموذج الرئيسي. نظرًا لأن هذا النوع من المعلومات مخصص في الغالب للمستخدمين المحترفين، فمن المنطقي إما:

• إبقاؤها في الحد الأدنى قدر الإمكان، أو؛
• إخفاؤها في لوحة قابلة للطي (accordion)

معلومات إضافية يجب تضمينها

• سعر الرمز المميز
• الانزلاق السعري
• الحد الأدنى المُستلم
• المخرجات المتوقعة
• تأثير السعر
• التكلفة المقدرة للغاز
• رسوم أخرى
• توجيه الطلب (Order routing)

يمكن القول إن بعض هذه التفاصيل قد تكون اختيارية.

توجيه الطلب أمر مثير للاهتمام، لكنه لا يحدث فرقًا كبيرًا لمعظم المستخدمين.

بعض التفاصيل الأخرى هي ببساطة إعادة صياغة لنفس الشيء بطرق مختلفة. على سبيل المثال، "الحد الأدنى المُستلم" و"الانزلاق السعري" هما وجهان لعملة واحدة. إذا قمت بتعيين الانزلاق السعري عند 1%، فإن الحد الأدنى الذي يمكنك توقع استلامه = المخرجات المتوقعة - 1%. ستعرض بعض واجهات المستخدم المبلغ المتوقع، والحد الأدنى للمبلغ، والانزلاق السعري... وهو أمر مفيد ولكنه قد يكون مبالغًا فيه.

سيترك معظم المستخدمين الانزلاق السعري الافتراضي على أي حال.

غالبًا ما يظهر "تأثير السعر" بين قوسين بجوار المعادل بالعملة الورقية في حقل "إلى" (to). هذه تفصيلة رائعة لتجربة المستخدم (UX) يمكن إضافتها، ولكن إذا تم عرضها هنا، فهل تحتاج حقًا إلى عرضها مرة أخرى بالأسفل؟ ثم مرة أخرى في شاشة المعاينة؟

لن يهتم العديد من المستخدمين (خاصة أولئك الذين يبادلون مبالغ صغيرة) بهذه التفاصيل؛ سيقومون ببساطة بإدخال رقم والضغط على مبادلة.

ستعتمد التفاصيل الدقيقة التي يتم عرضها على جمهورك والشعور الذي تريد أن يمنحه التطبيق.

إذا قمت بتضمين نسبة تحمل الانزلاق السعري في لوحة التفاصيل، فيجب عليك أيضًا جعلها قابلة للتعديل مباشرة من هنا. هذا مثال جيد على "المُسرّع" (accelerator)؛ وهي حيلة ذكية في تجربة المستخدم (UX) يمكنها تسريع تدفقات المستخدمين ذوي الخبرة، دون التأثير على قابلية الاستخدام العامة للتطبيق.

من الجيد التفكير بعناية ليس فقط في معلومة واحدة محددة على شاشة واحدة، ولكن في التدفق بأكمله من خلال: إدخال الأرقام في النموذج الرئيسي ← مسح التفاصيل ← النقر للوصول إلى شاشة المعاينة (إذا كان لديك شاشة معاينة). هل يجب أن تكون لوحة التفاصيل مرئية في جميع الأوقات، أم يحتاج المستخدم إلى النقر عليها لتوسيعها؟ هل يجب عليك خلق احتكاك (friction) عن طريق إضافة شاشة معاينة؟ هذا يجبر المستخدم على التمهل والتفكير في تداوله، وهو ما يمكن أن يكون مفيدًا. ولكن هل يريدون رؤية نفس المعلومات مرة أخرى؟ ما هو الأكثر فائدة لهم في هذه المرحلة؟

خيارات التصميم

كما ذكرنا، يعود الكثير من هذا إلى أسلوبك الشخصي من هو مستخدمك؟ ما هي علامتك التجارية؟ هل تريد واجهة "احترافية" تعرض كل التفاصيل، أم تريد أن تكون مبسطة (minimalist)؟ حتى لو كنت تستهدف المستخدمين المحترفين الذين يريدون كل المعلومات الممكنة، يجب أن تتذكر دائمًا كلمات آلان كوبر الحكيمة:

بغض النظر عن مدى جمال واجهتك، وبغض النظر عن مدى روعتها، سيكون من الأفضل لو كان هناك القليل منها.

الهيكل

• الرموز المميزة على اليسار، أو الرموز المميزة على اليمين
• صفان أو 3 صفوف
• التفاصيل فوق الزر أو أسفله
• التفاصيل موسعة، أو مصغرة، أو غير معروضة

نمط المكون

• فارغ
• محدد بخطوط (outlined)
• ممتلئ (filled)

من وجهة نظر تجربة المستخدم (UX) البحتة، فإن نمط واجهة المستخدم (UI) يهم أقل مما تعتقد. تأتي الاتجاهات البصرية وتذهب في دورات، والكثير من التفضيلات تكون ذاتية.

أسهل طريقة للتعود على هذا - والتفكير في التكوينات المختلفة المتنوعة - هي إلقاء نظرة على بعض الأمثلة ثم القيام ببعض التجارب بنفسك.

تحتوي مجموعة Figma المضمنة على مكونات فارغة ومحددة بخطوط وممتلئة.

ألقِ نظرة على الأمثلة أدناه لرؤية طرق مختلفة يمكنك من خلالها تجميع كل ذلك معًا:

ولكن في أي جانب يجب أن يوضع الرمز المميز؟

الخلاصة هي أنه ربما لا يحدث فرقًا كبيرًا في قابلية الاستخدام. ومع ذلك، هناك بعض الأشياء التي يجب وضعها في الاعتبار، والتي قد تميل بك إلى اتجاه أو آخر.

كان من المثير للاهتمام إلى حد ما رؤية الموضة تتغير بمرور الوقت. في البداية، كان لدى يونيسواب الرمز المميز على اليسار، لكنه نقله منذ ذلك الحين إلى اليمين. أجرى Sushiswap أيضًا هذا التغيير أثناء ترقية التصميم. حذت معظم البروتوكولات حذوها، ولكن ليس جميعها.

تضع الأعراف المالية تقليديًا رمز العملة قبل الرقم، على سبيل المثال، $50، €50، £50، لكننا نقول 50 دولارًا، 50 يورو، 50 جنيهًا.

بالنسبة للمستخدم العادي - خاصة الشخص الذي يقرأ من اليسار إلى اليمين، ومن أعلى إلى أسفل - فإن وجود الرمز المميز على اليمين ربما يبدو أكثر طبيعية.

وضع الرمز المميز على اليسار وجميع الأرقام على اليمين يبدو متماثلًا بشكل مبهج، وهو أمر إيجابي، ولكن هناك جانب سلبي آخر لهذا التخطيط.

ينص قانون التقارب (law of proximity) على أن العناصر القريبة من بعضها البعض يُنظر إليها على أنها مرتبطة. وبناءً على ذلك، نريد وضع العناصر المرتبطة بجوار بعضها البعض. يرتبط رصيد الرمز المميز ارتباطًا مباشرًا بالرمز المميز نفسه، وسيتغير كلما تم تحديد رمز مميز جديد. لذلك، من المنطقي أكثر بقليل أن يكون رصيد الرمز المميز بجوار زر تحديد الرمز المميز. يمكن نقله أسفل الرمز المميز، لكن ذلك يكسر تماثل التخطيط.

في النهاية، هناك إيجابيات وسلبيات لكلا الخيارين، ولكن من المثير للاهتمام كيف يبدو أن الاتجاه يتجه نحو وضع الرمز المميز على اليمين.

سلوك الزر

لا تضع زرًا منفصلاً للموافقة (Approve). ولا تطلب نقرة منفصلة للموافقة أيضًا. يريد المستخدم إجراء مبادلة (Swap)، لذا اكتب ببساطة "مبادلة" على الزر وابدأ الموافقة كخطوة أولى. يمكن أن تعرض النافذة المنبثقة التقدم باستخدام مؤشر خطوات (stepper)، أو إشعار بسيط مثل "المعاملة 1 من 2 - جاري الموافقة".

الزر كمساعدة سياقية

يمكن للزر أن يؤدي مهمة مزدوجة كونه تنبيهًا!

هذا في الواقع نمط تصميم غير معتاد إلى حد ما خارج Web3، ولكنه أصبح معيارًا داخله. هذا ابتكار جيد لأنه يوفر المساحة، ويحافظ على تركيز الانتباه.

إذا كان الإجراء الرئيسي - مبادلة (SWAP) - غير متاح بسبب خطأ ما، فيمكن شرح السبب باستخدام الزر، على سبيل المثال:

• تبديل الشبكة
• ربط المحفظة
• أخطاء مختلفة

يمكن أيضًا ربط الزر بالإجراء الذي يجب تنفيذه. على سبيل المثال، إذا لم يتمكن المستخدم من إجراء مبادلة لأنه على الشبكة الخاطئة، فيجب أن يقول الزر "التبديل إلى إيثيريوم"، وعندما ينقر المستخدم على الزر، يجب أن يقوم بتبديل الشبكة إلى إيثيريوم. هذا يسرع من تدفق المستخدم بشكل كبير.

قم ببناء تصميمك الخاص باستخدام ملف Figma هذا

بفضل العمل الجاد للعديد من البروتوكولات، تحسن تصميم منصات التداول اللامركزية (DEX) كثيرًا. نحن نعرف المعلومات التي يحتاجها المستخدم، وكيف يجب أن نعرضها، وكيف نجعل التدفق سلسًا قدر الإمكان. نأمل أن تقدم هذه المقالة نظرة عامة قوية على مبادئ تجربة المستخدم (UX).

إذا كنت ترغب في التجربة، فلا تتردد في استخدام مجموعة الإطارات الشبكية (wireframe) من Figma. تم إبقاؤها بسيطة قدر الإمكان، ولكنها تتمتع بمرونة كافية لبناء الهيكل الأساسي بطرق مختلفة.

مجموعة الإطارات الشبكية من Figma (opens in a new tab)

سيستمر التمويل اللامركزي (DeFi) في التطور، وهناك دائمًا مجال للتحسين.

حظًا موفقًا!