विकेंद्रित एक्सचेंज (DEX) डिझाइनच्या सर्वोत्तम पद्धती

2018 मध्ये युनिस्वॅप लाँच झाल्यापासून, डझनभर वेगवेगळ्या चेन्सवर शेकडो विकेंद्रित एक्सचेंजेस लाँच केले गेले आहेत. यापैकी अनेकांनी नवीन घटक सादर केले किंवा स्वतःचा एक वेगळा टच दिला, परंतु इंटरफेस साधारणपणे तसाच राहिला आहे.

याचे एक कारण म्हणजे जेकबचा नियम (Jakob’s Law) (opens in a new tab):

वापरकर्ते त्यांचा बहुतांश वेळ इतर साइट्सवर घालवतात. याचा अर्थ असा की वापरकर्त्यांना तुमची साइट त्यांनी आधीच ओळखत असलेल्या इतर सर्व साइट्सप्रमाणेच काम करावी असे वाटते.

युनिस्वॅप, Pancakeswap आणि Sushiswap सारख्या सुरुवातीच्या नवकल्पकांमुळे, विकेंद्रित वित्त (DeFi) वापरकर्त्यांना DEX कसा दिसतो याची एक सामूहिक कल्पना आहे. या कारणास्तव, आता “सर्वोत्तम पद्धत” (best practice) सारखे काहीतरी उदयास येत आहे. आम्ही साइट्सवर अधिकाधिक डिझाइन निर्णय प्रमाणित होताना पाहत आहोत. तुम्ही DEXes ची उत्क्रांती हे थेट चाचणीचे (testing it live) एक मोठे उदाहरण म्हणून पाहू शकता. ज्या गोष्टींनी काम केले त्या राहिल्या, ज्यांनी केले नाही त्या काढून टाकल्या गेल्या. यात अजूनही स्वतःचे वेगळेपण दाखवण्यास वाव आहे, परंतु काही विशिष्ट मानके आहेत ज्यांचे DEX ने पालन केले पाहिजे.

हा लेख खालील गोष्टींचा सारांश आहे:

• काय समाविष्ट करावे
• ते शक्य तितके वापरण्यायोग्य कसे बनवावे
• डिझाइन सानुकूलित करण्याचे मुख्य मार्ग

सर्व उदाहरण वायरफ्रेम्स विशेषतः या लेखासाठी बनवल्या गेल्या आहेत, जरी त्या सर्व वास्तविक प्रकल्पांवर आधारित आहेत.

Figma किट देखील तळाशी समाविष्ट केले आहे - मोकळेपणाने त्याचा वापर करा आणि तुमच्या स्वतःच्या वायरफ्रेम्सचा वेग वाढवा!

DEX ची मूलभूत रचना

UI मध्ये साधारणपणे तीन घटक असतात:

1. मुख्य फॉर्म
2. बटण
3. तपशील पॅनेल

प्रकार (Variations)

हा या लेखातील एक सामान्य विषय असेल, परंतु हे घटक आयोजित करण्याचे विविध मार्ग आहेत. “तपशील पॅनेल” खालीलप्रमाणे असू शकते:

• बटणाच्या वर
• बटणाच्या खाली
• अकोर्डियन पॅनेलमध्ये लपवलेले
• आणि/किंवा “पूर्वावलोकन” (preview) मोडलवर

टीप: “पूर्वावलोकन” मोडल ऐच्छिक आहे, परंतु जर तुम्ही मुख्य UI वर खूप कमी तपशील दाखवत असाल, तर ते आवश्यक बनते.

मुख्य फॉर्मची रचना

हा तो बॉक्स आहे जिथे तुम्ही प्रत्यक्षात निवडता की तुम्हाला कोणत्या टोकनची अदलाबदल करायची आहे. या घटकामध्ये एका रांगेत एक इनपुट फील्ड आणि एक लहान बटण असते.

DEXes सामान्यतः वरच्या एका रांगेत आणि खालच्या एका रांगेत अतिरिक्त तपशील प्रदर्शित करतात, जरी हे वेगळ्या प्रकारे कॉन्फिगर केले जाऊ शकते.

प्रकार

येथे दोन UI प्रकार दर्शविले आहेत; एक कोणत्याही बॉर्डरशिवाय, जे अतिशय खुले डिझाइन तयार करते आणि दुसरे ज्यामध्ये इनपुट रांगेला बॉर्डर आहे, जे त्या घटकावर लक्ष केंद्रित करते.

ही मूलभूत रचना डिझाइनमध्ये माहितीचे चार प्रमुख भाग दर्शविण्याची परवानगी देते: प्रत्येक कोपऱ्यात एक. जर फक्त एक वरची/खालची रांग असेल, तर फक्त दोनच जागा असतात.

DeFi च्या उत्क्रांतीदरम्यान, येथे बऱ्याच वेगवेगळ्या गोष्टी समाविष्ट केल्या गेल्या आहेत.

समाविष्ट करण्यासाठी प्रमुख माहिती

• वॉलेटमधील शिल्लक
• कमाल (Max) बटण
• फियाट समतुल्य
• “प्राप्त” रकमेवर किंमत प्रभाव

DeFi च्या सुरुवातीच्या काळात, फियाट समतुल्य अनेकदा गहाळ असायचे. जर तुम्ही कोणत्याही प्रकारचा Web3 प्रकल्प तयार करत असाल, तर फियाट समतुल्य दर्शविणे आवश्यक आहे. वापरकर्ते अजूनही स्थानिक चलनांच्या संदर्भात विचार करतात, त्यामुळे वास्तविक जगाच्या मानसिक मॉडेल्सशी जुळण्यासाठी, याचा समावेश केला पाहिजे.

दुसऱ्या फील्डवर (जिथे तुम्ही अदलाबदल करण्यासाठी टोकन निवडता) तुम्ही इनपुट रक्कम आणि अंदाजित आउटपुट रक्कम यातील फरकाची गणना करून, फियाट चलन रकमेच्या पुढे किंमत प्रभाव देखील समाविष्ट करू शकता. समाविष्ट करण्यासाठी हा एक अतिशय उपयुक्त तपशील आहे.

टक्केवारी बटणे (उदा. 25%, 50%, 75%) हे एक उपयुक्त वैशिष्ट्य असू शकते, परंतु ते अधिक जागा घेतात, अधिक कॉल टू ॲक्शन्स जोडतात आणि अधिक मानसिक भार वाढवतात. टक्केवारी स्लाइडर्सचेही तसेच आहे. यापैकी काही UI निर्णय तुमच्या ब्रँड आणि तुमच्या वापरकर्त्याच्या प्रकारावर अवलंबून असतील.

अतिरिक्त तपशील मुख्य फॉर्मच्या खाली दर्शविले जाऊ शकतात. या प्रकारची माहिती बहुतांशी प्रो वापरकर्त्यांसाठी असल्याने, खालीलपैकी एक करणे अर्थपूर्ण ठरते:

• ते शक्य तितके कमीत कमी ठेवा, किंवा;
• ते अकोर्डियन पॅनेलमध्ये लपवा

समाविष्ट करण्यासाठी अतिरिक्त माहिती

• टोकनची किंमत
• स्लिपेज
• किमान प्राप्त
• अपेक्षित आउटपुट
• किंमत प्रभाव
• गॅस खर्चाचा अंदाज
• इतर शुल्क
• ऑर्डर राउटिंग

कदाचित, यापैकी काही तपशील ऐच्छिक असू शकतात.

ऑर्डर राउटिंग मनोरंजक आहे, परंतु बहुतेक वापरकर्त्यांसाठी त्याचा फारसा फरक पडत नाही.

काही इतर तपशील फक्त तीच गोष्ट वेगवेगळ्या प्रकारे पुन्हा सांगत आहेत. उदाहरणार्थ “किमान प्राप्त” आणि “स्लिपेज” या एकाच नाण्याच्या दोन बाजू आहेत. जर तुम्ही स्लिपेज 1% वर सेट केले असेल, तर तुम्हाला मिळण्याची किमान अपेक्षा = अपेक्षित आउटपुट-1% असू शकते. काही UIs अपेक्षित रक्कम, किमान रक्कम आणि स्लिपेज दाखवतील... जे उपयुक्त आहे परंतु कदाचित गरजेपेक्षा जास्त (overkill) आहे.

बहुतेक वापरकर्ते तसेही डीफॉल्ट स्लिपेजच ठेवतील.

“किंमत प्रभाव” अनेकदा “to” फील्डमध्ये फियाट समतुल्यच्या पुढे कंसात दर्शविला जातो. जोडण्यासाठी हा एक उत्तम UX तपशील आहे, परंतु जर तो येथे दर्शविला असेल, तर तो खरोखर खाली पुन्हा दर्शविण्याची आवश्यकता आहे का? आणि मग पुन्हा पूर्वावलोकन स्क्रीनवर?

अनेक वापरकर्ते (विशेषतः जे लहान रकमेची अदलाबदल करत आहेत) या तपशीलांची पर्वा करणार नाहीत; ते फक्त एक संख्या प्रविष्ट करतील आणि अदलाबदल (swap) वर क्लिक करतील.

नेमके कोणते तपशील दर्शविले जातील हे तुमच्या प्रेक्षकांवर आणि तुम्हाला ॲपचा अनुभव कसा असावा असे वाटते यावर अवलंबून असेल.

जर तुम्ही तपशील पॅनेलमध्ये स्लिपेज टॉलरन्स समाविष्ट करत असाल, तर तुम्ही ते थेट येथून संपादन करण्यायोग्य देखील बनवले पाहिजे. हे “ॲक्सिलरेटर” चे एक चांगले उदाहरण आहे; एक उत्तम UX युक्ती जी ॲपच्या सामान्य उपयोगितेवर परिणाम न करता अनुभवी वापरकर्त्यांच्या प्रवाहाचा वेग वाढवू शकते.

एका स्क्रीनवरील केवळ एका विशिष्ट माहितीबद्दलच नव्हे, तर संपूर्ण प्रवाहाबद्दल काळजीपूर्वक विचार करणे ही एक चांगली कल्पना आहे: मुख्य फॉर्ममध्ये संख्या प्रविष्ट करणे → तपशील स्कॅन करणे → पूर्वावलोकन स्क्रीनवर क्लिक करणे (जर तुमच्याकडे पूर्वावलोकन स्क्रीन असेल). तपशील पॅनेल नेहमी दृश्यमान असावे, की वापरकर्त्याला ते विस्तृत करण्यासाठी त्यावर क्लिक करण्याची आवश्यकता आहे? तुम्ही पूर्वावलोकन स्क्रीन जोडून अडथळा (friction) निर्माण करावा का? हे वापरकर्त्याला वेग कमी करण्यास आणि त्यांच्या व्यापाराचा विचार करण्यास भाग पाडते, जे उपयुक्त ठरू शकते. पण त्यांना तीच सर्व माहिती पुन्हा पाहायची आहे का? या टप्प्यावर त्यांच्यासाठी सर्वात उपयुक्त काय आहे?

डिझाइन पर्याय

नमूद केल्याप्रमाणे, यातील बऱ्याच गोष्टी तुमच्या वैयक्तिक शैलीवर अवलंबून असतात तुमचा वापरकर्ता कोण आहे? तुमचा ब्रँड काय आहे? तुम्हाला प्रत्येक तपशील दर्शविणारा “प्रो” इंटरफेस हवा आहे, की तुम्हाला किमान (minimalist) राहायचे आहे? जरी तुम्ही शक्य ती सर्व माहिती हवी असलेल्या प्रो वापरकर्त्यांना लक्ष्य करत असाल, तरीही तुम्ही ॲलन कूपरचे शहाणपणाचे शब्द लक्षात ठेवले पाहिजेत:

तुमचा इंटरफेस कितीही सुंदर असला, कितीही छान असला, तरी तो जितका कमी असेल तितका चांगला.

रचना

• डावीकडे टोकन्स, किंवा उजवीकडे टोकन्स
• 2 रांगा किंवा 3
• बटणाच्या वर किंवा खाली तपशील
• तपशील विस्तृत केलेले, कमी केलेले किंवा न दर्शविलेले

घटक शैली

• रिक्त (empty)
• आउटलाइन केलेले
• भरलेले (filled)

शुद्ध UX दृष्टिकोनातून, UI शैलीचा तुम्ही विचार करता त्यापेक्षा कमी फरक पडतो. व्हिज्युअल ट्रेंड्स चक्रांमध्ये येतात आणि जातात आणि बरीचशी पसंती व्यक्तिनिष्ठ असते.

याची जाणीव करून घेण्याचा - आणि विविध कॉन्फिगरेशन्सबद्दल विचार करण्याचा - सर्वात सोपा मार्ग म्हणजे काही उदाहरणे पाहणे आणि नंतर स्वतः काही प्रयोग करणे.

समाविष्ट केलेल्या Figma किटमध्ये रिक्त, आउटलाइन केलेले आणि भरलेले घटक आहेत.

तुम्ही हे सर्व एकत्र कसे करू शकता याचे वेगवेगळे मार्ग पाहण्यासाठी खालील उदाहरणांवर एक नजर टाका:

पण टोकन कोणत्या बाजूला असावे?

थोडक्यात सांगायचे तर, उपयोगितेमध्ये याचा कदाचित फार मोठा फरक पडत नाही. तथापि, काही गोष्टी लक्षात ठेवण्यासारख्या आहेत, ज्या तुम्हाला एका किंवा दुसऱ्या बाजूला वळवू शकतात.

काळाबरोबर फॅशन बदलताना पाहणे थोडे मनोरंजक आहे. युनिस्वॅपमध्ये सुरुवातीला टोकन डावीकडे होते, परंतु तेव्हापासून ते उजवीकडे हलवले गेले आहे. Sushiswap ने देखील डिझाइन अपग्रेड दरम्यान हा बदल केला. बहुतांश, पण सर्वच नाही, प्रोटोकॉल्सनी याचे अनुकरण केले आहे.

आर्थिक संकेत पारंपारिकपणे चलनाचे चिन्ह संख्येच्या आधी ठेवतात, उदा. $50, €50, £50, परंतु आपण म्हणतो 50 डॉलर्स, 50 युरो, 50 पाउंड.

सामान्य वापरकर्त्यासाठी - विशेषतः जो डावीकडून उजवीकडे, वरून खाली वाचतो - उजवीकडील टोकन कदाचित अधिक नैसर्गिक वाटते.

टोकन डावीकडे आणि सर्व संख्या उजवीकडे ठेवणे सुखदपणे सममितीय (symmetrical) दिसते, जी एक जमेची बाजू आहे, परंतु या लेआउटचा आणखी एक तोटा आहे.

समीपतेचा नियम (law of proximity) सांगतो की जवळ असलेल्या वस्तू संबंधित मानल्या जातात. त्यानुसार, आपण संबंधित वस्तू एकमेकांच्या शेजारी ठेवू इच्छितो. टोकन शिल्लक थेट टोकनशीच संबंधित असते आणि जेव्हा नवीन टोकन निवडले जाते तेव्हा ती बदलेल. त्यामुळे टोकन शिल्लक टोकन निवड बटणाच्या शेजारी असणे थोडे अधिक अर्थपूर्ण ठरते. ते टोकनच्या खाली हलवले जाऊ शकते, परंतु त्यामुळे लेआउटची सममिती (symmetry) खंडित होते.

शेवटी, दोन्ही पर्यायांसाठी फायदे आणि तोटे आहेत, परंतु उजवीकडील टोकनकडे कल कसा दिसून येतो हे मनोरंजक आहे.

बटणाचे वर्तन

मंजूर करा (Approve) साठी वेगळे बटण ठेवू नका. तसेच मंजूर करा साठी वेगळा क्लिक ठेवू नका. वापरकर्त्याला अदलाबदल (Swap) करायची आहे, त्यामुळे बटणावर फक्त “अदलाबदल” म्हणा आणि पहिली पायरी म्हणून मंजुरी सुरू करा. एक मोडल स्टेपरसह प्रगती दर्शवू शकतो, किंवा एक साधी “tx 1 of 2 - approving” सूचना दर्शवू शकतो.

संदर्भात्मक मदत म्हणून बटण

बटण अलर्ट म्हणून दुहेरी काम करू शकते!

हा प्रत्यक्षात Web3 च्या बाहेर एक अतिशय असामान्य डिझाइन पॅटर्न आहे, परंतु त्यामध्ये तो प्रमाणित झाला आहे. हा एक चांगला नाविन्यपूर्ण शोध आहे कारण यामुळे जागेची बचत होते आणि लक्ष केंद्रित राहते.

जर मुख्य कृती - अदलाबदल (SWAP) - त्रुटीमुळे अनुपलब्ध असेल, तर त्याचे कारण बटणाद्वारे स्पष्ट केले जाऊ शकते, उदा.:

• नेटवर्क बदला
• वॉलेट कनेक्ट करा
• विविध त्रुटी

बटण करावयाच्या कृतीशी मॅप देखील केले जाऊ शकते. उदाहरणार्थ, जर वापरकर्ता चुकीच्या नेटवर्कवर असल्यामुळे अदलाबदल करू शकत नसेल, तर बटणावर “इथेरियमवर स्विच करा” असे म्हटले पाहिजे आणि जेव्हा वापरकर्ता बटणावर क्लिक करतो, तेव्हा त्याने नेटवर्क इथेरियमवर स्विच केले पाहिजे. यामुळे वापरकर्त्याच्या प्रवाहाचा वेग लक्षणीयरीत्या वाढतो.

या Figma फाइलसह तुमचे स्वतःचे तयार करा

अनेक प्रोटोकॉल्सच्या कठोर परिश्रमामुळे, DEX डिझाइनमध्ये खूप सुधारणा झाली आहे. वापरकर्त्याला कोणती माहिती हवी आहे, ती आपण कशी दाखवली पाहिजे आणि प्रवाह शक्य तितका सुरळीत कसा बनवायचा हे आपल्याला माहीत आहे. आशा आहे की हा लेख UX तत्त्वांचे एक ठोस विहंगावलोकन प्रदान करेल.

जर तुम्हाला प्रयोग करायचा असेल, तर कृपया मोकळेपणाने Figma वायरफ्रेम किट वापरा. ते शक्य तितके सोपे ठेवले आहे, परंतु विविध प्रकारे मूलभूत रचना तयार करण्यासाठी त्यात पुरेशी लवचिकता आहे.

Figma वायरफ्रेम किट (opens in a new tab)

DeFi विकसित होत राहील आणि सुधारणेला नेहमीच वाव असतो.

शुभेच्छा!