ابتدا مرز امضا را ترسیم کنید
کار را با نموداری شروع کنید که نشان دهد چه کسی می‌تواند یک انتقال را مجاز کند. رابط کیف پول و حساب بلاکچینی یک چیز نیستند؛ یک داشبورد جذاب مشخص نمی‌کند کنترل امضا در اختیار چه کسی است. برای محصول پیشنهادی خود، دستگاه مشتری، سرورهای اپلیکیشن، هر ارائه‌دهنده نگه‌داری دارایی، و ابزارهای مدیریتی را مشخص کنید. بپرسید کدام جزء درخواست تراکنش را دریافت می‌کند و کدام جزء واقعاً می‌تواند آن را تأیید کند. ثبت کنید هر طرف به‌تنهایی چه کاری می‌تواند انجام دهد. این تمرین فرض‌هایی را آشکار می‌کند که فهرست قابلیت‌ها پنهان می‌کند، به‌ویژه وقتی تأمین‌کننده چند چیدمان متفاوت را صرفاً با عنوان کیف پول معرفی می‌کند.
برای هر دارایی یک هویت بدون ابهام تعریف کنید
کاتالوگ دارایی را بر پایه شبکه و شناسه قرارداد یا دارایی بومی بسازید، سپس نام و نماد آشنا را برای نمایش اضافه کنید. تعیین کنید دارایی‌های پشتیبانی‌نشده، موجودی‌های خرد، و فیدهای قیمتِ در دسترس نبودنی چگونه نمایش داده شوند. مشتری باید پیش از کپی‌کردن آدرس بداند انتقال روی کدام شبکه دریافت می‌شود. مقدار دارایی نگه‌داری‌شده را از ارزش برآوردی ارزی جدا کنید و نشان دهید این برآورد چه زمانی به‌روزرسانی شده است. در مشخصات، نمونه‌ای بیاورید که در آن دو شبکه نماد توکن یکسانی را نمایش می‌دهند تا بازبینان بتوانند بررسی کنند رابط آن‌ها را از هم متمایز نگه می‌دارد.
پیش از درخواست تأیید، تراکنش را توضیح دهید
صفحه بازبینی‌ای طراحی کنید که دارایی موردنظر، گیرنده، شبکه، مبلغ، و هزینه تخمینی شبکه را توضیح دهد. ورود به وب‌سایت نباید به‌عنوان اجازه جابه‌جایی پول نمایش داده شود. برای آماده‌سازی تراکنش، تأیید مشتری، ارسال، و تأیید نهایی، وضعیت‌های جداگانه در نظر بگیرید. وقتی ارائه‌دهنده پس از ارسال دچار وقفه زمانی می‌شود، به‌جای تشویق فوری به انجام انتقال دیگر، امکان بررسی وضعیت را ارائه کنید. یک مرجع پایدار نگه دارید که پشتیبانی بتواند بدون درخواست اسرار امضا از آن استفاده کند. پرسش اصلی طراحی این است که آیا کاربر می‌تواند بفهمد چه اتفاقی افتاده و چه چیزی هنوز نامطمئن است.
بازیابی را به یک مسیر کامل برای مشتری تبدیل کنید
برای گم‌شدن دستگاه، فراموشی رمز عبور اپلیکیشن، در دسترس نبودن ارائه‌دهنده امضا، و احتمال به‌خطر افتادن امنیت، سناریوهای جداگانه بنویسید. این وضعیت‌ها لزوماً راه‌حل یکسانی ندارند. در چیدمان خودحضانتی، بازنشانی رمز عبور وب‌سایت نباید این تصور را ایجاد کند که پشتیبانی می‌تواند کلید خصوصی ازدست‌رفته را دوباره بسازد. اگر معماری انتخابی شما کنترل‌های بازیابی دارد، مستند کنید چه کسی می‌تواند آن‌ها را آغاز کند، چه شواهدی لازم است، و چه تأخیر یا اعلانی اعمال می‌شود. این مسیر را با کسی که آن را نساخته آزمایش کنید، از جمله پیام‌هایی که هنگام ناممکن بودن بازیابی نمایش داده می‌شود.
برای اپراتورها محیط کاری محدود و کاربردی بسازید
داشبورد عملیات باید به پرسش‌های عملی پاسخ دهد، بدون آنکه اختیار بیشتری از نیاز کاربرانش در اختیارشان بگذارد. آیا کارشناس می‌تواند یک انتقال در انتظار را شناسایی کند، آخرین پاسخ ارائه‌دهنده را بفهمد، و پرونده را ارجاع دهد؟ آیا مدیر می‌تواند سیاست آدرس را بدون تغییر پنهانی در مجوزهای مشتری تغییر دهد؟ پشتیبانی روزمره را از اقداماتی که بر قواعد امضا یا برداشت اثر می‌گذارند جدا کنید. برای تغییرات حساس، عامل انجام‌دهنده، دلیل، و تنظیمات قبل و بعد را ثبت کنید. توافق کنید کدام رویدادها نیازمند بازبینی‌اند، چه کسی آن‌ها را دریافت می‌کند، و تیم در صورت در دسترس نبودن ارائه‌دهنده خارج از ساعات کاری عادی چگونه عمل می‌کند.
یک سیستم قابل بهره‌برداری بخرید، نه فقط یک نمایش
معماری را به معیارهای پذیرش تبدیل کنید: بازیابی یک نسخه پشتیبان پشتیبانی‌شده، لغو پیش از امضا، رسیدگی به درخواست ردشده، بازکردن دوباره تراکنش در انتظار، و تغییر به شبکه پشتیبانی‌نشده. برای این تمرین‌ها از محیط‌های آزمایشی و حساب‌های کنترل‌شده استفاده کنید. دستورالعمل‌های استقرار، وابستگی‌های ارائه‌دهنده، مسئولیت‌های مدیریت کلید، و راهنمای اجرای بازیابی را به‌عنوان بخشی از تحویل درخواست کنید. یک شرح نیاز مفید برای کیف پول، محدودیت‌ها را از همان ابتدا قابل مشاهده می‌کند. این کار به تیم شما اجازه می‌دهد محصولی را انتخاب کند که مدل امضا، بار کاری پشتیبانی، و وعده‌های آن به مشتری با سرویسی که واقعاً قصد بهره‌برداری از آن را دارید سازگار باشد.