پرش به محتویات

استاندارد بررسی UX صفحه‌به‌صفحه در تری‌پیلون

۱. هدف

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

۲. پیش‌نیازهای بررسی

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

  • هدف، محدوده و سناریوها
  • User Flow
  • Workflow و وضعیت‌ها
  • نقش‌ها و دسترسی‌ها
  • اعلان‌ها
  • خطاها و موارد خاص
  • Information Architecture و وایرفریم
  • تصمیم‌های جدید مالک محصول

اگر تعارضی ساختار صفحه یا رفتار اصلی را تغییر دهد، تعارض باید در خروجی ماژول ثبت شود.

۳. ترتیب بررسی

برای هر صفحه این مراحل به‌ترتیب انجام می‌شوند:

  1. تعریف مسئله: کاربر چرا وارد صفحه شده و چه نتیجه‌ای می‌خواهد؟
  2. تعیین Context: کاربر در کدام ساختمان، واحد، نقش، Resource یا مرحله است؟
  3. کنترل مسیر: ورودی‌ها، خروجی موفق، بازگشت، انصراف و مسیر جایگزین چیست؟
  4. ساختار اطلاعات: چه چیزی ضروری، ثانویه یا قابل‌تعویق است؟
  5. کنترل دسترسی: مشاهده و Actionها به چه Role، Permission و Scope نیاز دارند؟
  6. طراحی حالت‌ها: Default، Loading، Empty، Error، Offline، Pending، Success و Stale Data چگونه‌اند؟
  7. تکمیل محتوا: عنوان، توضیح، Label، CTA، Validation، Error و Confirmation نوشته می‌شوند.
  8. طراحی UI: ساختار مصوب با Component و Token ساخته می‌شود.
  9. بازبینی: خروجی با منابع، محتوا و دسترس‌پذیری کنترل می‌شود.
  10. ثبت تصمیم: نتیجه، سؤال باز و وابستگی‌ها در خروجی همان ماژول ثبت می‌شوند.
flowchart LR A["مسئله و Context"] --> B["جریان و دسترسی"] B --> C["حالت‌ها و خطاها"] C --> D["UX Writing"] D --> E["UI Design"] E --> F["Review و ثبت خروجی"]

۴. معیار آماده‌بودن برای UI

یک صفحه زمانی آماده طراحی UI است که:

  • Actor و هدف اصلی روشن باشد.
  • ورودی و خروجی آن در User Flow مشخص باشد.
  • Action اصلی و Actionهای فرعی اولویت‌بندی شده باشند.
  • داده‌های ضروری و اختیاری مشخص باشند.
  • Permission مشاهده و اقدام ثبت شده باشد.
  • حالت‌های ضروری صفحه تعیین شده باشند.
  • متن نسخه اولیه در خروجی UX Writing همان ماژول ثبت شده باشد.
  • سؤال بازی که ساختار صفحه را تغییر می‌دهد باقی نمانده باشد.

۵. معیار تکمیل UX

بررسی UX یک صفحه زمانی کامل است که:

  • مسئله و Context مستند شده‌اند.
  • ساختار اطلاعات و ترتیب Actionها تصمیم‌گیری شده‌اند.
  • مسیر اصلی، جایگزین، خطا و بازیابی پوشش داده شده‌اند.
  • اثر مالی، دسترسی یا تغییر داده برای کاربر روشن است.
  • فرضیه اصلی و روش ارزیابی آن ثبت شده‌اند.
  • تصمیم‌ها و سؤالات باز مالک و وضعیت دارند.
  • لینک خروجی Writing و Frame نهایی قابل ردیابی است.

۶. قالب خروجی صفحه

این بخش برای هر صفحه در فایل UX همان ماژول تکمیل می‌شود:

## WF-XX — نام صفحه

| مورد | خروجی |
| --- | --- |
| وضعیت | در بررسی |
| Actor | ... |
| هدف کاربر | ... |
| نقطه ورود | ... |
| خروجی موفق | ... |
| Action اصلی | ... |
| Action فرعی | ... |
| Permission | ... |
| لینک Writing | ... |
| لینک Figma | ... |

### مسئله و Context

...

### ساختار اطلاعات و تعامل

...

### حالت‌ها

| حالت | رفتار موردنیاز |
| --- | --- |
| Default | ... |
| Loading | ... |
| Empty | ... |
| Error | ... |
| Success | ... |

### فرضیه و روش ارزیابی

...

### تصمیم‌ها

- ...

### سؤالات باز

- ...

۷. معیار ارزیابی

حوزه پرسش Review
وضوح آیا کاربر بدون توضیح بیرونی می‌فهمد کجاست و چه کاری باید انجام دهد؟
کارایی آیا مسیر اصلی با کمترین تصمیم و ورود داده معتبر تکمیل می‌شود؟
پیشگیری از خطا آیا محدودیت‌ها پیش از اقدام نمایش داده می‌شوند؟
بازیابی آیا خطا قابل‌فهم، قابل‌پیگیری و قابل بازیابی است؟
اعتماد آیا اثر مالی، دسترسی یا عضویت پیش از تأیید روشن است؟
Context آیا Resource هدف در Action حساس قابل تشخیص است؟
دسترس‌پذیری آیا متن، کنتراست، اندازه لمس و ترتیب فوکوس مناسب است؟
سازگاری آیا الگو با صفحات تأییدشده و Design System یکسان است؟

۸. کنترل کیفیت

  • خروجی داخل پوشه ماژول است، نه داخل scenario-guides.
  • هر صفحه شناسه پایدار دارد.
  • تصمیم قطعی از پیشنهاد و سؤال باز جدا شده است.
  • همه حالت‌های مرتبط پوشش داده شده‌اند.
  • Writing و UI به صفحه UX لینک دارند.
  • تغییرات فراصفحه‌ای در Decision Log ماژول ثبت شده‌اند.