از زمان راه‌اندازی یونی سواپ در سال 2018، صدها صرافی غیرمتمرکز در شبکه‌های مختلف راه‌اندازی شده است. بسیاری از این صرافی‌ها یک عنصر جدید یا شیوه‌ی مختص به خود را معرفی کردند، اما رابط کاربری به‌صورت کلی به همان شکل مانده است.

یکی از دلایل آن قانون جیکوب(opens in a new tab) است:

کاربران بیشتر وقت خود را در وب سایت‌های دیگر صرف می‌کنند. این بدان معناست که کاربران ترجیح می‌دهند تا سایت شما مشابه سایت‌هایی عمل کند که در حال حاضر با آن‌ها آشنا هستند.

به لطف نوآورانی همچون یونی سواپ، پنکیک سواپ و سوشی سواپ، کاربران حوزه دیفای یک ایده کلی از این دارند که صرافی غیرمتمرکز چگونه باید به نظر برسد. به همین دلیل، چیزهایی مثل "بهترین شیوه" هم اکنون در حال ظهور هستند. می‌توان مشاهده کرد که تصمیمات طراحی در میان سایت‌های مختلف بیشتر و بیشتر استانداردسازی می‌شود. تکامل صرافی‌های غیرمتمرکز یک مثال بزرگ از تست کردن پروژه با استفاده از اجرا و انتشار آن می‌باشد. چیزهایی که کار کردند همانطور ماندند و چیزهایی که کار نکردند، دور انداخته شدند. هنوز جا برای شخصی سازی وجود دارد، اما استانداردهای خاصی وجود دارند که یک صرافی غیرمتمرکز باید به آن‌ها پایبند باشد.

این مقاله خلاصه ای است از:

• چه چیزی را شامل شود
• چگونه آن را تا حد امکان قابل استفاده کنیم
• راه های اصلی برای سفارشی سازی طراحی

همه وایرفریم‌های نمونه به‌طور خاص برای این مقاله ساخته شده‌اند، اگرچه همه آنها بر اساس پروژه‌های واقعی هستند.

کیت Figma نیز در پایین موجود است - از آن استفاده کنید و سرعت وایرفریم های خود را افزایش دهید!

آناتومی ساده یک صرافی غیرمتمرکز

رابط کاربری معمولا شامل 3 چیز است:

1. فرم اصلی
2. دکمه
3. پنل جزئیات

تغییرات

این یک موضوع رایج در این مقاله خواهد بود، اما روش‌های مختلفی برای سازماندهی این عناصر وجود دارد. "پنل جزئیات" می تواند بدین شکل باشد:

• بالای دکمه
• زیر دکمه
• مخفی در پنل آکاردئونی
• و/یا در حالت "پیش نمایش"

نکته حالت "پیش نمایش" اختیاری است، اما اگر جزئیات بسیار کمی را در رابط کاربری اصلی نشان می دهید، ضروری می شود.

ساختار فرم اصلی

این کادری است که در واقع انتخاب می‌کنید کدام توکن را می‌خواهید تعویض کنید. کامپوننت شامل یک فیلد ورودی و یک دکمه کوچک در یک ردیف است.

DEX ها معمولاً جزئیات اضافی را در یک ردیف بالا و یک ردیف پایین نمایش می دهند، اگرچه می توان آن را به طور متفاوت پیکربندی کرد.

تغییرات

دو تغییر رابط کاربری در اینجا نشان داده شده است. یکی بدون هیچ حاشیه ای، یک طرح بسیار باز ایجاد می کند، و دیگری که در آن ردیف ورودی دارای یک حاشیه است که تمرکز روی آن عنصر ایجاد می کند.

این ساختار اساسی به چهار اطلاعات کلیدی اجازه می دهد تا در طراحی نشان داده شوند: یکی در هر گوشه. اگر فقط یک ردیف بالا/پایین وجود داشته باشد، تنها دو نقطه وجود دارد.

در طول تکامل دیفای، موارد مختلف زیادی در اینجا گنجانده شده است.

اطلاعات کلیدی برای درج

• موجودی در کیف پول
• دکمه Max
• معادل قیمت به فیات
• تاثیر قیمت بر مبلغ "دریافت شده"

در روزهای اولیه دیفای، معادل فیات اغلب گم می شد. اگر در حال ساخت هر نوع پروژه Web3 هستید، ضروری است که معادل فیات نشان داده شود. کاربران هنوز بر حسب ارزهای محلی فکر می کنند، بنابراین برای مطابقت با مدل های ذهنی دنیای واقعی، باید این مورد لحاظ شود.

در فیلد دوم (محلی که توکنی را انتخاب می‌کنید که با آن مبادله می‌کنید) می‌توانید با محاسبه تفاوت بین مقدار ورودی و مقدار خروجی تخمینی، تأثیر قیمت را در کنار مقدار ارز فیات لحاظ کنید. این جزئیات کاملا مفیدی برای گنجاندن است.

دکمه های درصد (مثلاً 25٪، 50٪، 75٪) می توانند یک ویژگی مفید باشند، اما فضای بیشتری را اشغال می کنند، تماس بیشتری را به اقدامات اضافه می کنند و بار ذهنی بیشتری را اضافه می کنند. در مورد لغزنده های درصد نیز همینطور است. برخی از این تصمیمات UI به برند و نوع کاربری شما بستگی دارد.

جزئیات اضافی را می توان در زیر فرم اصلی نشان داد. از آنجایی که این نوع اطلاعات بیشتر برای کاربران حرفه ای است، منطقی است که:

• آن را تا حد امکان مینیمال نگه دارید، یا؛
• آن را در پنل آکاردئونی پنهان کنید

اطلاعات اضافی برای درج

• قیمت توکن
• افت
• حداقل دریافتی
• خروجی مدنظر
• اثر قیمت
• تخمین هزینه گس
• باقی کارمزدها
• مسیردهی سفارش

مسلماً برخی از این جزئیات می توانند اختیاری باشند.

مسیریابی سفارش جالب است، اما برای اکثر کاربران تفاوت چندانی ایجاد نمی کند.

برخی جزئیات دیگر به سادگی یک چیز را به روش های مختلف بازگو می کنند. برای مثال «حداقل دریافتی» و «افت قیمت» دو روی یک سکه هستند. اگر افت قیمت را روی 1% تنظیم کرده‌اید، حداقل مقداری که می‌توانید دریافت کنید = خروجی مدنظر - 1%. برخی از رابط‌های کاربری مقدار مورد انتظار، حداقل مقدار و افت را نشان می‌دهند… که مفید است اما احتمالاً بیش از حد است.

اکثر کاربران به هر حال افت قیمت پیش فرض را خالی می گذارند.

"تأثیر قیمت" اغلب در پرانتز در کنار معادل فیات در قسمت "به" نشان داده می شود. این اطلاعات عالی درباره ux برای افزودن است، اما اگر در اینجا نشان داده شود، آیا واقعاً باید دوباره در زیر نشان داده شود؟ و سپس دوباره در یک صفحه پیش نمایش بیاید؟

بسیاری از کاربران (مخصوصاً آنهایی که مقادیر کم را مبادله می کنند) به این جزئیات اهمیت نمی دهند. آنها به سادگی یک عدد وارد می کنند و swap را می زنند.

اینکه دقیقاً چه جزئیاتی نشان داده می شود به مخاطبان شما و احساسی که می خواهید برنامه داشته باشد بستگی دارد.

اگر آستانه تحمل افت را در پنل جزئیات لحاظ کنید، باید آن را مستقیماً از اینجا نیز قابل ویرایش کنید. این مثال خوبی از "شتاب دهنده" است. یک ترفند ساده UX که می‌تواند جریان کاربران با تجربه را سرعت بخشد، بدون اینکه بر قابلیت استفاده عمومی برنامه تأثیر بگذارد.

این ایده خوبی است که نه تنها در مورد یک قطعه خاص از اطلاعات در یک صفحه، بلکه در مورد کل جریان از طریق آن به دقت فکر کنید: وارد کردن اعداد در فرم اصلی ← جزئیات اسکن ← کلیک کردن برای پیش نمایش صفحه (اگر صفحه پیش نمایش دارید). آیا پنل جزئیات باید همیشه قابل مشاهده باشد یا کاربر برای بزرگ شدن باید روی آن کلیک کند؟ آیا باید با افزودن یک صفحه پیش نمایش اصطکاک ایجاد کنید؟ این امر کاربر را مجبور می کند تا سرعت خود را کاهش دهد و مبادله خود را در نظر بگیرد که می تواند مفید باشد. اما آیا آنها می خواهند همه همان اطلاعات را دوباره ببینند؟ چه چیزی در این مرحله برای آنها مفیدتر است؟

گزینه های طراحی

همانطور که گفته شد، بسیاری از این موارد به سبک شخصی شما برمی گردد کاربر شما کیست؟ برند شما چیست؟ آیا یک رابط حرفه ای می خواهید که تمام جزئیات را نشان دهد یا می خواهید مینیمالیستی باشید؟ حتی اگر به دنبال کاربران حرفه‌ای هستید که همه اطلاعات را می‌خواهند، باز هم باید سخنان حکیمانه آلن کوپر را به خاطر بسپارید:

هر چقدر هم که رابط کاربری شما زیبا باشد، بهتر است کمتر از آن استفاده کنید.

ساختار

• توکن ها در سمت چپ یا توکن ها در سمت راست
• 2 ردیف از 3
• جزئیات بالا یا زیر دکمه
• جزئیات گسترش یافته، حداقل شود یا نشان داده نشود

استایل کامپوننت

• خالی
• تاکید شده
• پر شده

از نقطه نظر UX خالص، سبک UI کمتر از آنچه فکر می کنید اهمیت دارد. روندهای بصری در چرخه می آیند و می روند و بسیاری از اولویت ها ذهنی است.

ساده ترین راه برای درک این موضوع - و فکر کردن به پیکربندی های مختلف - این است که به چند نمونه نگاه کنید و سپس خودتان آزمایش کنید.

کیت Figma شامل اجزای خالی، پیشفرض و پر شده است.

به مثال های زیر نگاهی بیندازید تا روش های مختلفی را مشاهده کنید که می توانید همه آن ها را کنار هم قرار دهید:

اما توکن باید به کدام سمت برود؟

نکته اصلی این است که احتمالاً تفاوت زیادی در قابلیت استفاده ایجاد نمی کند. با این حال، چند نکته وجود دارد که باید به خاطر داشته باشید، که ممکن است شما را به یک جهت تحت تاثیر قرار دهد.

دیدن تغییر مد با گذشت زمان کمی جالب است. Uniswap در ابتدا توکن را در سمت چپ داشت، اما از آن زمان آن را به سمت راست منتقل کرده است. Sushiswap نیز این تغییر را طی یک ارتقاء طراحی ایجاد کرد. بیشتر پروتکل‌ها، اما نه همه، از همین روند پیروی کرده‌اند.

قوانین مالی به طور سنتی نماد ارز را قبل از عدد قرار می دهد، به عنوان مثال. $50، €50، £50، اما ما می گوییم 50 دلار، 50 یورو، 50 پوند.

برای کاربر عمومی - به خصوص کسی که از چپ به راست، از بالا به پایین می خواند - نشانه سمت راست احتمالا طبیعی تر است.

قرار دادن توکن در سمت چپ و همه اعداد در سمت راست به طرز خوشایندی متقارن به نظر می رسند، که یک امتیاز مثبت است، اما یک نقطه ضعف دیگر در این طرح وجود دارد.

قانون مجاورت بیان می کند که مواردی که نزدیک به هم هستند به عنوان مرتبط تلقی می شوند. بر همین اساس می خواهیم موارد مرتبط را در کنار یکدیگر قرار دهیم. موجودی توکن مستقیماً با خود توکن مرتبط است و هر زمان که یک توکن جدید انتخاب شود تغییر خواهد کرد. بنابراین کمی منطقی تر است که موجودی توکن در کنار دکمه انتخاب نشانه باشد. می‌توان آن را به زیر نشانه منتقل کرد، اما این تقارن طرح‌بندی را می‌شکند.

در نهایت، نکات مثبت و منفی برای هر دو گزینه وجود دارد، اما جالب است که به نظر می رسد چگونه روند به سمت توکن سمت راست است.

رفتار دکمه

دکمه جداگانه ای برای تأیید نداشته باشید. همچنین یک کلیک جداگانه برای تأیید نداشته باشید. کاربر می‌خواهد Swap را انجام دهد، بنابراین فقط روی دکمه بگویید «swap» و تأیید را به عنوان اولین مرحله آغاز کنید. یک مودال می‌تواند پیشرفت را با یک استپر یا یک اعلان ساده "tx 1 of 2 - تایید" نشان دهد.

دکمه به عنوان راهنمای متنی

این دکمه می تواند به عنوان یک هشدار، وظیفه ای مضاعف را انجام دهد!

این در واقع یک الگوی طراحی نسبتاً غیرعادی در خارج از Web3 است، اما در داخل آن استاندارد شده است. این یک نوآوری خوب است زیرا باعث صرفه جویی در فضا می شود و توجه را متمرکز نگه می دارد.

اگر عمل اصلی - SWAP - به دلیل خطا در دسترس نیست، دلیل آن را می توان با دکمه توضیح داد، به عنوان مثال.:

• تعویض شبکه
• اتصال کیف پول
• خطاهای متعدد

این دکمه همچنین می تواند به عملکرد که باید انجام شود نگاشت شود. به عنوان مثال، اگر کاربر نمی تواند به دلیل اینکه در شبکه اشتباهی قرار دارد، مبادله کند، دکمه باید بگوید “switch to Ethereum” و زمانی که کاربر روی دکمه کلیک می کند، باید شبکه را به اتریوم تغییر دهد. این سرعت جریان کاربر را به میزان قابل توجهی افزایش می دهد.

مال خودتان را با این فایل فیگما بسازید

به لطف کار سخت پروتکل های متعدد، طراحی DEX بسیار بهبود یافته است. ما می دانیم که کاربر به چه اطلاعاتی نیاز دارد، چگونه باید آن را نشان دهیم و چگونه جریان را تا حد امکان روان کنیم. امیدواریم این مقاله یک نمای کلی از اصول UX ارائه دهد.

اگر می‌خواهید آزمایش کنید، لطفاً از کیت وایرفریم فیگما استفاده کنید. تا حد امکان ساده نگه داشته می شود، اما انعطاف کافی برای ساختن ساختار اصلی به روش های مختلف دارد.

کیت وایرفریم فیگما(opens in a new tab)

دیفای به تکامل خود ادامه خواهد داد و همیشه جایی برای بهبود وجود دارد.

موفق باشید!