بگذارید محصول ابتدا خودش را توضیح دهد
پیش از درخواست اتصال کیف پول، نشان دهید محصول چه کاری انجام می‌دهد، اقدام بعدی چه چیزی می‌خواهد و آیا مرور کردن اصلاً به حساب نیاز دارد یا نه. درخواست اتصال بدون توضیح، کاربر را قبل از آنکه سرویس را بفهمد در برابر یک تصمیم قرار می‌دهد. از یک اقدام اولیه روشن استفاده کنید؛ مانند مشاهده یک محصول، بررسی یک موقعیت یا شروع یک درخواست تعریف‌شده. راه‌اندازی را متناسب با همان اقدام نگه دارید. اگر هم حساب معمولی و هم کیف پول پشتیبانی می‌شود، کاربرد جداگانه هرکدام را توضیح دهید؛ نه اینکه دو روش ورود را طوری نمایش دهید که قابل‌جایگزینی به نظر برسند اما رفتار متفاوتی داشته باشند.
برای هر مجوز معنای جداگانه‌ای تعریف کنید
اتصال کیف پول، امضای پیام، مجاز کردن استفاده از توکن و ارسال تراکنش باید توضیح‌های متفاوتی داشته باشند. پیش از باز کردن کیف پول، درخواست واقعی را توضیح دهید؛ از جمله دارایی، شبکه، مبلغ، گیرنده و سقف مجوز مرتبط. برای مرحله‌هایی که از نظر ماهیت متفاوت‌اند، از دکمه عمومی «ادامه» استفاده نکنید. پس از بازگشت کاربر از کیف پول، اجازه دهید جزئیات را دوباره مرور کند. اگر یک اقدام به چند درخواست نیاز دارد، توالی و مرحله فعلی را نشان دهید. رد شدن یک امضا باید راه روشنی برای توقف یا تلاش دوباره آگاهانه در اختیار کاربر بگذارد.
تغییر حساب و شبکه را رویداد واقعی در نظر بگیرید
EIP-1193 رویدادهای تغییر حساب و زنجیره را برای ارائه‌دهندگان Ethereum تعریف می‌کند. به این تغییرات گوش کنید و به‌جای نگه داشتن برچسب حساب قدیمی روی صفحه، جریان فعال را دوباره ارزیابی کنید. ممکن است لازم باشد یک درخواست امضانشده از نو ساخته شود؛ اما تراکنشی که قبلاً ارسال شده همچنان به زمینه اولیه خودش تعلق دارد. در صورت نیاز، مظنه‌های منقضی و فرضیات مربوط به مجوز را نامعتبر کنید. به کاربر بگویید کدام جزئیات تغییر کرده و چه چیزی را باید دوباره بررسی کند. هرگز فقط به‌دلیل تغییر شبکه در کیف پول یا نامعتبر شدن یک درخواست قبلی، تراکنش جایگزین را بی‌سروصدا ارسال نکنید.
مسیر کاربر را میان اپلیکیشن‌های موبایل طراحی کنید
کیف پول موبایل ممکن است یک اپلیکیشن جداگانه را باز کند و بعد از تأخیر برگردد، یا مرورگر ممکن است پیش از بازگشت کاربر دوباره بارگذاری شود. اقدام پیش‌نویس و مرجع تراکنش آن را حفظ کنید، اما مراجعه دوباره را به‌معنای تأیید ندانید. یک صفحه وضعیت قابل‌ادامه نمایش دهید که حساب و شبکه درگیر را نشان دهد. جابه‌جایی‌های قطع‌شده، کیف پول‌های پشتیبانی‌نشده، درخواست‌های ردشده و قطع اتصال دستگاه را آزمایش کنید. کاربران را در چرخه تکراری درخواست اتصال گرفتار نکنید. جایگزین مفید، توضیح می‌دهد چطور عملیات در انتظار را دوباره باز کنند و اگر کیف پول قبلاً آن را ارسال کرده است، شواهد را کجا پیدا کنند.
انتظار و شکست را دقیق توضیح دهید
برای رد کردن درخواست توسط کاربر، قطع بودن ارائه‌دهنده، شبکه پشتیبانی‌نشده، تراکنش ارسال‌شده در انتظار تأیید و شکست تأییدشده، پیام‌های جداگانه به‌کار ببرید. مرحله بعدی را متناسب با همان وضعیت ارائه کنید. اسپینر نباید مرجع تراکنش را پنهان کند یا زمان قطعی برای تکمیل القا کند. عملیات ارسال‌شده را پس از نوسازی صفحه هم حفظ کنید تا افراد هنگام انتظار دوباره پرداخت نکنند. یک مرجع پشتیبانی ارائه دهید که اسرار را افشا نکند. نه رابط کاربری و نه دستورالعمل‌های پشتیبانی هرگز نباید از کاربران بخواهند عبارت بازیابی یا مواد خصوصی امضا را ارسال کنند.
دسترس‌پذیری را در معیار پذیرش بگنجانید
کل مسیر را با کیبورد، وضعیت‌های فوکوس خوانا، متن بزرگ‌نمایی‌شده و برچسب‌های ترجمه‌شده آزمایش کنید. در عربی، آدرس‌ها، مبالغ و شناسه‌های شبکه را در چیدمان راست‌به‌چپ خوانا نگه دارید؛ یک اقدام کپی قابل‌اعتماد فراهم کنید، بدون اینکه مقدار زیرساختی تغییر کند. برای تشخیص وضعیت‌های در انتظار و تکمیل‌شده فقط به رنگ تکیه نکنید. از آزمایشگری که با محصول آشنا نیست بخواهید پیش از تأیید، هر مجوز درخواستی را توضیح دهد. جاهایی را که توضیح ناموفق بوده ثبت کنید. آنبوردینگ خوب، زنجیره‌ای از تصمیم‌های قابل‌فهم با مسیر بازیابی روشن است که با وضعیت فنی دقیق پشتیبانی می‌شود.