استاندارد طراحی وایرفریم کامل و موبایل‌محور در تریپیلون

۱. هدف

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

وایرفریم کامل باید به این پرسش‌ها پاسخ دهد:

• هر بازیگر از کجا وارد قابلیت می‌شود؟
• در هر صفحه چه اطلاعات و Actionهایی می‌بیند؟
• تفاوت نقش‌ها و Scope دسترسی چگونه دیده می‌شود؟
• مسیر اصلی، جایگزین، خطا، انتظار و بازگشت چیست؟
• هر Action در Context کدام موجودیت قرار دارد؟
• وضعیت قبل و بعد از Action چگونه به کاربر اعلام می‌شود؟
• طراحی در عرض واقعی موبایل قابل استفاده است؟

۲. جایگاه در فرایند طراحی ماژول

وایرفریم آخرین مرحله تحلیل محصول و نخستین مرحله تبدیل تصمیم‌ها به رابط کاربری است.

ترتیب استاندارد:

1. هدف، محدوده و سناریوها
2. User Flow
3. Workflow و وضعیت‌ها
4. نقش‌ها و دسترسی‌ها
5. اعلان‌ها
6. خطاها و موارد خاص
7. Information Architecture
8. Wireframe

وایرفریم نباید برای پرکردن خلأ اسناد قبلی، Business Rule جدیدی را پنهانی قطعی کند. اگر تصمیم لازم وجود ندارد، مورد با برچسب «تصمیم باز» ثبت می‌شود.

۳. منابع اجباری پیش از طراحی

پیش از کشیدن اولین صفحه، همه اسناد مرتبط ماژول باید خوانده و با یکدیگر تطبیق داده شوند:

منبع	چیزی که از آن استخراج می‌شود
هدف، محدوده و سناریوها	قابلیت‌ها، قواعد و موارد خارج از محدوده
User Flow	نقطه شروع، گام‌ها، تصمیم‌ها و پایان‌ها
Workflow	وضعیت‌ها، Transitionها و Actionهای مجاز
دسترسی‌ها	Actor، Role، Permission، Scope و Guard
اعلان‌ها	وضعیت‌های قابل مشاهده و Deep Link
خطاها	Validation، Empty، Conflict، Pending و Recovery
اسناد دامنه	واژگان، موجودیت‌ها و روابط مرجع
بازخورد صریح محصول	تصمیم‌های جدیدتر و اصلاح‌کننده

ترتیب اعتبار تصمیم:

1. بازخورد صریح و جدید کاربر یا مالک محصول
2. تصمیم ثبت‌شده و قطعی در اسناد ماژول
3. استانداردهای مشترک پروژه
4. فرض موقت و صریح

اگر میان اسناد تعارض وجود دارد، طراحی متوقف نمی‌شود؛ تعارض ثبت و جدیدترین تصمیم معتبر مبنا قرار می‌گیرد.

۴. خروجی‌های الزامی

خروجی وایرفریم هر ماژول باید حداقل شامل این بخش‌ها باشد:

1. قرارداد طراحی و ابعاد هدف
2. تصمیم‌های مهم Information Architecture
3. ماتریس پوشش Flowها و سناریوها
4. نقشه صفحه‌ها و ارتباط آن‌ها
5. وایرفریم تمام صفحه‌های لازم
6. نقش‌ها و تفاوت دسترسی در صفحه
7. وضعیت‌های اجباری هر صفحه
8. مسیرهای اصلی، جایگزین و خطا
9. قواعد Responsive و دسترس‌پذیری
10. تصمیم‌های باز
11. چک‌لیست کنترل کیفیت

۵. اصل پوشش کامل

۵.۱. ماتریس پوشش

پیش از طراحی جزئیات، برای همه User Flowها ماتریس پوشش ساخته شود:

Flow	بازیگر	نقطه شروع	صفحه‌های لازم	مسیر جایگزین	خطا و Pending	وضعیت
[MOD]-UF-01	...	...	WF-01 تا WF-04	...	...	کامل/ناقص

هیچ Flow تأییدشده‌ای نباید بدون صفحه یا توضیح روشن باقی بماند.

۵.۲. پوشش سناریو به صفحه

برای هر سناریو مشخص شود:

• صفحه ورود به سناریو کدام است؟
• Action آغازکننده کجاست؟
• تصمیم کاربر در کدام صفحه گرفته می‌شود؟
• نتیجه موفق کجا نمایش داده می‌شود؟
• نتیجه رد، انتظار یا شکست کجا نمایش داده می‌شود؟
• کاربر چگونه به Context قبلی بازمی‌گردد؟

۵.۳. پوشش Actor

فقط مسیر مدیر طراحی نشود. برای هر Actor مؤثر بررسی شود:

• مدیر و نقش‌های مدیریتی
• کارکنان و نقش‌های عملیاتی
• مالک، مستأجر، ساکن و اعضای خانواده
• پرداخت‌کننده یا درخواست‌کننده
• شخص دعوت‌شده
• Reviewer یا Approver
• پشتیبانی یا ادمین پلتفرم، در صورت وجود

اگر یک Actor صفحه مستقل ندارد، تجربه او در همان Context مرتبط نمایش داده شود.

۶. Information Architecture و Context

۶.۱. Action نزدیک به Resource

هر Action باید تا حد ممکن در Context موجودیت هدف قرار گیرد:

• دعوت مالک یا مستأجر از «لیست واحدها» یا «جزئیات واحد»
• تغییر یا پایان رابطه از «افراد و نقش‌های واحد»
• دعوت عضو هیئت‌مدیره از «تیم مدیریت»
• انتصاب نگهبان از «کارکنان و موقعیت‌ها»
• تأیید قبض از «مالی / پرداخت‌ها / قبض‌های در انتظار»

ایجاد صفحه مستقل مانند «مرکز دعوت‌ها» فقط زمانی مجاز است که واقعاً یک مقصد اصلی با حجم، جست‌وجو، فیلتر و کار روزانه مستقل باشد.

۶.۲. آزمون صفحه مستقل

پیش از ساخت صفحه مستقل پرسیده شود:

1. آیا کاربر بدون دانستن Resource اصلی به این صفحه می‌آید؟
2. آیا صفحه مجموعه‌ای بزرگ و چندمنبعی را مدیریت می‌کند؟
3. آیا جست‌وجو، فیلتر یا عملیات گروهی مستقل دارد؟
4. آیا Action از چند Context متفاوت به یک Queue واقعی می‌رسد؟
5. آیا صفحه مقصد Deep Link اعلان‌هاست؟

اگر پاسخ بیشتر پرسش‌ها منفی است، Action باید در Context موجودیت اصلی بماند.

۶.۳. حفظ موقعیت کاربر

پس از Action باید Context حفظ شود:

• بازگشت به همان واحد، Role یا قبض
• حفظ فیلتر و Scroll در لیست
• نمایش نتیجه در همان ردیف
• نمایش وضعیت جدید بدون نیاز به جست‌وجوی دوباره

۷. طراحی نقش‌ها و دسترسی‌ها

۷.۱. نمایش Role در وایرفریم

وایرفریم نباید Roleها را پشت عبارت عمومی «مدیر» پنهان کند. در صفحه‌های مرتبط این موارد مشخص شوند:

• نام Role
• متصدی فعلی یا «بدون متصدی»
• وضعیت دعوت یا پذیرش
• Scope
• بسته دسترسی
• Actionهای مجاز
• Actionهای غیرمجاز یا نیازمند تأیید

نمونه گروه‌بندی:

خانواده	نمونه Role
حاکمیتی	مدیر ساختمان، رئیس هیئت‌مدیره، عضو هیئت‌مدیره
مالی	مدیر مالی، حسابدار، خزانه‌دار، بازرس مالی
عملیاتی	مدیر تأسیسات، نگهبان، سرایدار، مسئول پذیرش
روابط واحد	مالک، مستأجر، ساکن، عضو خانواده

۷.۲. تفاوت Role و Relationship

• Role مسئولیت و Permission ایجاد می‌کند.
• Relationship ارتباط شخص با واحد را بیان می‌کند.
• مالک یا مستأجر بودن به‌تنهایی دسترسی مدیریتی ایجاد نمی‌کند.
• شخص می‌تواند هم‌زمان Relationship و چند Role داشته باشد.

این تفاوت باید در عنوان، Badge، توضیح یا گروه‌بندی صفحه قابل فهم باشد.

۷.۳. Action بر اساس دسترسی

برای Action حساس یکی از این رفتارها انتخاب شود:

• نمایش فعال برای Actor مجاز
• نمایش غیرفعال همراه دلیل، اگر دانستن قابلیت مفید است
• عدم نمایش، اگر افشای قابلیت یا Resource نامناسب است
• نمایش با Guard و مرحله تأیید

وایرفریم نباید با نمایش یکسان دکمه‌ها برای همه Roleها، Permission Model را بی‌اثر کند.

۷.۴. تفکیک وظایف

در فرایندهای حساس، نقش ثبت‌کننده، بررسی‌کننده و تأییدکننده جدا دیده شوند؛ برای نمونه:

• پرداخت‌کننده قبض را ثبت می‌کند.
• حسابدار آن را بررسی می‌کند.
• مدیر مالی یا مدیر مجاز آن را تأیید می‌کند.
• Ledger فقط پس از Transition معتبر تغییر می‌کند.

۸. طراحی قابلیت‌ها

۸.۱. فهرست قابلیت‌ها پیش از صفحه

قبل از طراحی، Capability Inventory تهیه شود:

قابلیت	Actor	Resource	Context	Action اصلی	وضعیت‌ها
...	...	...	...	...	...

برای جلوگیری از جاافتادن امکانات، قابلیت‌ها بر اساس حوزه دسته‌بندی شوند؛ نه بر اساس چند مثال ابتدایی.

۸.۲. دسته‌بندی کامل

برای فهرست‌های گسترده مانند امکانات ساختمان، دسته‌های دامنه نمایش داده شوند:

• ورزشی و تندرستی
• گردهمایی و کار
• فضای باز و خانواده
• پارکینگ و انبار
• خدمات مشترک
• زیرساخت
• ایمنی و دسترسی
• مورد سفارشی

۸.۳. تفاوت نوع قابلیت

اقلام مشابه ظاهری ممکن است رفتار متفاوت داشته باشند:

• امکان رزروی: ظرفیت، تقویم، هزینه، قوانین و تأیید
• زیرساخت: وضعیت، مسئول، سرویس دوره‌ای و هشدار
• خدمت مشترک: ساعات استفاده، ظرفیت یا مسئول ارائه
• مورد سفارشی: نام، نوع و رفتار انتخاب‌شده

یک فرم عمومی برای همه انواع کافی نیست.

۹. مسیر اصلی و جایگزین

هر Capability مهم باید حداقل این حالت‌ها را داشته باشد:

1. ورود و معرفی Context
2. Empty State
3. حالت دارای داده
4. ایجاد یا ویرایش
5. بازبینی
6. تأیید یا ثبت
7. نتیجه موفق
8. Validation Error
9. خطای موقت و Retry
10. Pending یا Under Review
11. رد یا نیازمند اصلاح
12. لغو یا بازگشت امن

برای Action حساس این موارد نیز بررسی شوند:

• Confirmation
• نمایش اثر اقدام
• Reason یا مدرک
• OTP یا تأیید تقویت‌شده
• Audit Summary
• جلوگیری از Double Submit

۱۰. طراحی فرایندهای مالی

۱۰.۱. نمایش همه روش‌های معتبر

اگر چند روش دریافت وجه وجود دارد، وایرفریم باید همه آن‌ها را نشان دهد:

• پرداخت آنلاین به‌عنوان روش پیشنهادی یا پیش‌فرض
• کارت‌به‌کارت
• حساب‌به‌حساب

«پیش‌فرض بودن» روش آنلاین به معنی حذف روش‌های دیگر نیست.

۱۰.۲. تنظیم مدیر

برای هر روش این اطلاعات طراحی شود:

• فعال یا غیرفعال
• مقصد وجه
• صاحب حساب
• بانک و شناسه‌های لازم
• روش نمایش به پرداخت‌کننده
• Role مجاز برای بررسی و تأیید
• قواعد مبلغ و تطبیق

۱۰.۳. تجربه پرداخت‌کننده

برای پرداخت دستی:

1. انتخاب کارت‌به‌کارت یا حساب‌به‌حساب
2. مشاهده مقصد و امکان کپی
3. انجام واریز خارج از اپ
4. ثبت مبلغ، تاریخ و کد پیگیری
5. ارسال تصویر قبض
6. مشاهده وضعیت «در انتظار بررسی»
7. دریافت نتیجه تأیید، رد یا نیازمند اصلاح

۱۰.۴. تجربه مدیر

صف بررسی باید نشان دهد:

• پرداخت‌کننده و واحد
• مبلغ ادعاشده
• بدهی یا Bill مرجع
• مقصد واریز
• تاریخ و کد پیگیری
• تصویر قبض
• سابقه بررسی
• Actionهای تأیید، رد و درخواست اصلاح

۱۰.۵. اثر مالی

وایرفریم باید صریح نشان دهد:

• ارسال قبض به‌تنهایی مانده را تغییر نمی‌دهد.
• بررسی قبض به‌تنهایی مانده را تغییر نمی‌دهد.
• فقط تأیید معتبر و ایجاد Payment یکتا باعث کاهش مانده می‌شود.
• تأیید تکراری نباید دوباره از مانده کم کند.
• رد یا درخواست اصلاح باید دلیل قابل مشاهده داشته باشد.

۱۱. طراحی دعوت، عضویت و رابطه

۱۱.۱. دعوت Contextual

دعوت از ردیف یا جزئیات Resource آغاز شود:

• شخص مرتبط با واحد
• Role تیم مدیریت
• موقعیت شغلی

در همان Context این وضعیت‌ها دیده شوند:

• دعوت نشده
• ارسال‌شده
• تحویل ناموفق
• منقضی
• پذیرفته
• ردشده
• لغوشده

Actionهای Resend و Cancel نیز در همان Context قرار گیرند.

۱۱.۲. پایان یا جایگزینی

پایان و جایگزینی Relationship از جزئیات همان واحد یا Role انجام شود و شامل این موارد باشد:

• شخص و رابطه جاری
• Effective Date
• دلیل
• اثر روی اعضای وابسته
• اثر روی دسترسی
• اثر روی بدهی و تاریخچه
• شخص و رابطه جایگزین
• بازبینی قبل از ثبت

تاریخچه حذف نمی‌شود؛ رابطه قبلی با End Date آرشیو می‌شود.

۱۲. قرارداد موبایل

۱۲.۱. ابعاد

• عرض مبنا: 390px
• حداقل عرض قابل کنترل: 320px
• طراحی Desktop نباید صرفاً کوچک شود.
• هر صفحه باید در یک ستون اصلی قابل استفاده باشد.

۱۲.۲. قواعد چیدمان

• Action اصلی در محدوده قابل دسترس انگشت باشد.
• دکمه‌های اصلی تمام‌عرض یا به‌اندازه کافی بزرگ باشند.
• هدف لمسی حداقل حدود 44px باشد.
• عنوان و وضعیت Context در App Bar باقی بمانند.
• Tabهای زیاد Scroll افقی کنترل‌شده داشته باشند.
• جدول عریض به Card، List یا Detail Row تبدیل شود.
• فرم طولانی به Section یا Step منطقی شکسته شود.
• Action مخرب از Action اصلی فاصله بصری داشته باشد.
• Bottom Sheet برای انتخاب‌های کوتاه و Contextual ترجیح دارد.
• Modal نباید فرم بلند یا فرایند چندمرحله‌ای را در خود جا دهد.

۱۲.۳. متن و RTL

• جهت صفحه و کنترل‌ها rtl باشد.
• اعداد، موبایل، شبا و کد رهگیری خوانا نمایش داده شوند.
• Label حذف نشود و فقط Placeholder جای آن را نگیرد.
• متن دکمه فعل و نتیجه روشن داشته باشد.
• Badge به‌تنهایی متکی به رنگ نباشد.

۱۳. قالب استاندارد هر وایرفریم

هر صفحه در سند Markdown با این شناسنامه معرفی شود:

### `WF-01` — [عنوان صفحه]

- Flowهای مرتبط:
- Actorهای اصلی:
- نقطه ورود:
- هدف صفحه:
- Context:
- Permission مؤثر:
- وضعیت نمایش‌داده‌شده:

[وایرفریم]

Action اصلی:
Actionهای ثانویه:
حالت‌های اجباری:
Deep Link یا بازگشت:

شناسه‌ها پایدار و دو رقمی باشند:

WF-01, WF-02, ...

۱۴. نمایش Low-fidelity در Markdown

در وایرفریم متنی:

• عرض قاب‌ها کوتاه و نزدیک موبایل باشد.
• سلسله‌مراتب با عنوان، Section، Card و Action روشن شود.
• از خطوط بسیار بلند و جدول‌های عریض پرهیز شود.
• محتوای واقعی و فارسی استفاده شود؛ نه Lorem ipsum.
• وضعیت‌ها با متن مانند [در انتظار] نمایش داده شوند.
• Action اصلی و مخرب قابل تشخیص باشند.
• Navigation و نقطه بازگشت مشخص باشد.

نمونه:

┌──────────────────────────────┐
│ ‹ واحد ۱۰۱    افراد و نقش‌ها │
├──────────────────────────────┤
│ مریم احمدی                   │
│ مالک · فعال                  │
│ [مشاهده] [پایان رابطه]       │
├──────────────────────────────┤
│ سارا محمدی                   │
│ مستأجر · دعوت ارسال‌شده      │
│ [ارسال مجدد] [لغو دعوت]      │
├──────────────────────────────┤
│       + افزودن شخص یا نقش     │
└──────────────────────────────┘

۱۵. نسخه تعاملی یا HTML

اگر علاوه بر Markdown نسخه تعاملی ساخته می‌شود:

• فایل HTML هر ماژول باید داخل همان پوشه ماژول و کنار فایل 07 وایرفریم‌ها.md نگهداری شود.
• نام فایل HTML باید پایدار، انگلیسی و با الگوی lowercase-hyphenated باشد.
• فایل Markdown وایرفریم باید نسخه HTML همان پوشه را با iframe نمایش دهد و از تکرار وایرفریم‌ها به‌صورت بلوک‌های text پرهیز کند.
• مسیر src باید با ساختار خروجی MkDocs کنترل شود؛ چون صفحه Markdown در پوشه‌ای با index.html ساخته می‌شود، فایل HTML هم‌سطح معمولاً با مسیر ../filename.html فراخوانی می‌شود.
• زیر iframe یک لینک مستقیم Markdown به فایل هم‌سطح، مانند (filename.html)، قرار گیرد تا MkDocs مسیر خروجی را بازنویسی کند و نمایش‌دهنده‌های بدون پشتیبانی iframe نیز مقصد جایگزین داشته باشند.
• همان شناسه و عنوان صفحه‌های Markdown را حفظ کند.
• تمام گروه‌های Flow قابل انتخاب باشند.
• قبلی/بعدی و شماره صفحه داشته باشد.
• در عرض 390px و 320px بررسی شود.
• Theme روشن و تاریک را پشتیبانی کند.
• بدون تعامل نیز Context و Action اصلی قابل فهم باشد.
• JavaScript و Render نهایی اعتبارسنجی شود.
• نسخه تعاملی جایگزین سند پوشش و قواعد محصول نیست.

۱۶. حالت‌های اجباری صفحه

برای هر صفحه مرتبط، نیاز به این حالت‌ها بررسی شود:

حالت	سؤال کنترل
Loading	آیا Skeleton یا Progress لازم است؟
Empty	اولین Action کاربر چیست؟
Populated	اطلاعات چگونه اولویت‌بندی می‌شود؟
Validation	خطا کنار کدام فیلد است؟
Partial	کدام بخش موفق و کدام ناموفق است؟
Pending	چه چیزی در حال بررسی است و کاربر چه کند؟
Permission Denied	آیا دلیل یا مسیر درخواست دسترسی وجود دارد؟
Offline	داده حفظ می‌شود و Retry چگونه است؟
Conflict	کاربر چگونه وضعیت جدید را Reload می‌کند؟
Success	نتیجه و Action بعدی چیست؟
Rejected	دلیل و امکان اصلاح چیست؟

۱۷. اعلان و Deep Link

هر اعلان عملیاتی باید به نزدیک‌ترین Context معتبر باز شود:

• دعوت واحد ← جزئیات واحد و ردیف شخص
• Role پیشنهادی ← همان Role Assignment
• قبض در انتظار ← جزئیات قبض در واحد
• تأیید یا رد قبض ← وضعیت پرداخت همان واحد
• جایگزینی رابطه ← تاریخچه افراد و نقش‌های واحد

Deep Link نباید به صفحه عمومی و مبهم برسد و جای Permission Check را نمی‌گیرد.

۱۸. دسترس‌پذیری

• ترتیب Focus با ترتیب بصری یکسان باشد.
• همه Actionها Label متنی قابل فهم داشته باشند.
• وضعیت فقط با رنگ منتقل نشود.
• کنتراست در نسخه نهایی Design بررسی شود.
• اندازه هدف لمسی مناسب باشد.
• Error به فیلد مرتبط متصل شود.
• Drawer، Sheet و Modal قابل بستن و بازگشت باشند.
• اعداد حساس و اطلاعات بانکی برای خواندن و کپی‌کردن تفکیک شوند.

۱۹. موارد ممنوع

• طراحی فقط Happy Path
• کشیدن چند صفحه نمونه و اعلام پوشش کامل
• مخفی‌کردن همه Actorها پشت عنوان «مدیر»
• ساخت صفحه مستقل برای Action کاملاً Contextual
• حذف روش جایگزین به‌دلیل وجود روش پیش‌فرض
• تغییر Ledger پیش از تأیید معتبر
• استفاده از یک فرم یکسان برای قابلیت‌هایی با رفتار متفاوت
• نمایش Action حساس بدون Permission و Guard
• طراحی Desktop عریض و نام‌گذاری آن به‌عنوان موبایل
• اتکا به رنگ برای وضعیت
• استفاده از Placeholder به‌جای Label
• حذف Empty، Pending، Rejected و Error State
• ایجاد Business Rule جدید بدون ثبت فرض یا تصمیم باز
• ناهماهنگی میان شناسه‌های Flow، Workflow و Wireframe

۲۰. روش اجرای استاندارد

1. همه اسناد ماژول خوانده می‌شوند.
2. تصمیم‌های قطعی، فرض‌ها و تعارض‌ها استخراج می‌شوند.
3. Actor و Role Inventory ساخته می‌شود.
4. Capability Inventory ساخته می‌شود.
5. Resourceها و Context مناسب هر Action تعیین می‌شوند.
6. ماتریس پوشش Flow به صفحه ساخته می‌شود.
7. نقشه صفحه‌ها و Navigation ترسیم می‌شود.
8. مسیر اصلی هر Actor طراحی می‌شود.
9. مسیرهای جایگزین و Roleهای دیگر افزوده می‌شوند.
10. حالت‌های Empty، Pending، Error، Rejected و Success طراحی می‌شوند.
11. Permission، Scope و Guard هر Action کنترل می‌شود.
12. اعلان‌ها و Deep Linkها به Context صحیح متصل می‌شوند.
13. وایرفریم‌ها با عرض مبنای 390px نوشته یا ترسیم می‌شوند.
14. نسخه 320px از نظر Overflow و خوانایی کنترل می‌شود.
15. ماتریس پوشش دوباره با اسناد مبنا تطبیق داده می‌شود.
16. سند Markdown و نسخه تعاملی، در صورت وجود، Render و بازبینی می‌شوند.
17. تصمیم‌های جدید حاصل از طراحی به اسناد قبلی بازگردانده می‌شوند.

۲۱. چک‌لیست کنترل کیفیت

پوشش

• همه User Flowهای تأییدشده در ماتریس پوشش هستند.
• هر Flow حداقل یک نقطه ورود، نتیجه موفق و نتیجه ناموفق دارد.
• همه Actorهای مؤثر دیده شده‌اند.
• همه قابلیت‌های داخل محدوده در Capability Inventory هستند.
• مسیرهای جایگزین و عملیات حساس پوشش داده شده‌اند.

نقش و دسترسی

• Role و Relationship از هم تفکیک شده‌اند.
• نام Role، Scope و وضعیت انتساب قابل مشاهده است.
• Action حساس فقط برای Actor مجاز نمایش داده می‌شود.
• Guard، تأیید و تفکیک وظایف رعایت شده‌اند.
• Self-service با Permission مدیریتی اشتباه نشده است.

معماری اطلاعات

• هر Action کنار Resource اصلی قرار دارد.
• صفحه مستقل بدون نیاز واقعی ساخته نشده است.
• بازگشت، Deep Link و حفظ Context مشخص‌اند.
• Navigation با مدل ذهنی کاربر سازگار است.

صفحه و وضعیت

• Empty State Action روشن دارد.
• Loading، Pending و Error از یکدیگر متمایزند.
• Validation ورودی کاربر را حفظ می‌کند.
• رد یا نیازمند اصلاح دلیل قابل مشاهده دارد.
• نتیجه موفق، وضعیت جدید و Action بعدی را نشان می‌دهد.
• Action مخرب Confirmation و اثر روشن دارد.

مالی

• روش پیش‌فرض و روش‌های جایگزین همگی نمایش داده شده‌اند.
• مقصد وجه و Role تأییدکننده مشخص‌اند.
• ثبت قبض، بررسی و تأیید صفحه یا وضعیت قابل مشاهده دارند.
• مانده فقط پس از Payment معتبر تغییر می‌کند.
• تأیید تکراری اثر مالی تکراری ندارد.

موبایل

• عرض مبنا 390px است.
• خروجی در 320px Overflow مخرب ندارد.
• جدول عریض به ساختار موبایلی تبدیل شده است.
• Action اصلی دسترس‌پذیر و هدف لمسی مناسب دارد.
• متن RTL، Labelها و اعداد خوانا هستند.

ردیابی و اعتبارسنجی

• هر Wireframe شناسه پایدار دارد.
• شناسه Flowها، Workflowها و Errorها درست ارجاع شده‌اند.
• تصمیم باز به‌عنوان تصمیم قطعی نمایش داده نشده است.
• فایل Markdown بدون ایراد ساختاری است.
• نسخه تعاملی، در صورت وجود، از نظر JavaScript و Render بررسی شده است.
• HTML در پوشه همان ماژول و کنار سند وایرفریم قرار دارد.
• iframe و لینک مستقیم HTML در خروجی ساخته‌شده MkDocs باز می‌شوند.
• ساخت سایت مستندات با موفقیت انجام شده است.

۲۲. معیار پذیرش

یک مجموعه وایرفریم زمانی «کامل» محسوب می‌شود که:

1. تمام Flowها و Actorهای داخل محدوده قابل ردیابی باشند.
2. قابلیت مهم یا روش جایگزین ثبت‌شده‌ای حذف نشده باشد.
3. Role، Permission و Scope روی Actionهای حساس اثر قابل مشاهده داشته باشند.
4. مسیرهای Contextual در همان Resource اصلی قرار گرفته باشند.
5. حالت‌های Empty، Pending، Success، Rejected و Error برای مسیرهای لازم مشخص باشند.
6. وایرفریم در عرض موبایل واقعی قابل استفاده باشد.
7. سند با Workflow، اعلان، خطا و قواعد مالی تناقض نداشته باشد.
8. خروجی نهایی Render و کنترل شده باشد.