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

بازکاری معمولاً از جایی شروع می‌شود که طراح فکر می‌کرد «واضح است» و توسعه‌دهنده حدس زد. این مقاله فهرست مشخصاتی را می‌دهد که حدس را کم می‌کند. بخش‌های منبع‌دار بر پایهٔ راهنمای NN/G برای design spec است؛ فهرست حالت‌ها و قالب معیار پذیرش را جداگانه به‌عنوان توصیهٔ نویسنده و منبع Fowler مشخص کرده‌ایم. عددی دربارهٔ «کاهش بازکاری» ادعا نمی‌کنیم.

دو جزء: فایل طراحی و issue

NN/G می‌گوید design spec دو بخش دارد: فایل طراحی (مثلاً Figma) و issue توسعه در ابزاری مثل GitHub یا Linear. فایل طراحی کار طراح را به تکه‌های قابل‌مصرف تقسیم می‌کند و issue زمینه را می‌دهد. بسیاری از تیم‌ها issue را مثل قراردادی میان طراحی و توسعه می‌بینند: آنچه در آن آمده، آن چیزی است که توسعه‌دهنده باید تحویل دهد.

در فایل طراحی چه باشد؟

طبق NN/G: جریان‌های تعامل (با کلیک یا لمس چه می‌شود)، طراحی بصری با سبک‌های نام‌گذاری‌شدهٔ رنگ و تایپوگرافی، چیدمان با گرید و breakpoint، مؤلفه‌های تعاملی و ریزتعامل‌ها، محتوای واقعی به‌جای جانگهدار، و نیازهای دسترس‌پذیری مثل ترتیب Tab و متن جایگزین.

حالت‌ها و رفتار واکنش‌گرا

این بخش توصیهٔ نویسنده است. برای هر مؤلفه یا صفحه، حالت‌های مرتبط را بنویسید: پیش‌فرض، hover، focus، غیرفعال، در حال بارگذاری، خطا، خالی و موفق؛ همه برای همه‌چیز لازم نیست. جزئیات سه حالت آخر در Empty State، Error State و Loading State آمده است. برای رفتار واکنش‌گرا، web.dev meta viewport و انتخاب breakpoint را توضیح می‌دهد؛ مشخص کنید در هر breakpoint ستون‌ها چه می‌شوند و متن طولانی چه می‌شود.

در issue توسعه چه باشد؟

NN/G فهرست می‌کند: هدف طراحی، دامنهٔ شامل و غیرشامل، نیازهای کارکردی و غیرکارکردی، موارد استفاده و ریسک‌ها با ریشه در نظر صاحب محصول یا رهبر فنی. اسکرین‌شات اگر هست باید با فایل طراحی هم‌خوان باشد و اختلاف‌ها یادداشت شود.

معیار پذیرش

برای هر رفتار یک سناریوی Given-When-Then بنویسید؛ Fowler آن را حالت اولیه، رفتار و نتیجهٔ مورد انتظار می‌نامد. مثال: «با فرم خالی، وقتی دکمهٔ ارسال زده شد، آنگاه زیر هر فیلد اجباری خطای متنی دیده می‌شود.» برای نوشتن سناریوها به User Story چیست؟ هم سر بزنید.

فرایند هم‌راستایی

1. توسعه‌دهنده را پیش از نهایی‌شدن وارد گفت‌وگو کنید (NN/G).
2. پیش از جلسهٔ بازبینی، فرصت کامنت‌گذاری در فایل بدهید (NN/G).
3. برای مصالحه آماده باشید؛ نیاز حیاتی کاربر را حفظ کنید.
4. فهرست حالت‌ها و معیار پذیرش را کنار هر issue بگذارید. برای دید کلی UX چیست؟ را ببینید.

منابع و مراجع

• Creating Design Specs for Development — Nielsen Norman Group (Kelley Gordon)، 2025-06-20.
• Given When Then — Martin Fowler، 2013-08-21.
• Responsive web design basics — web.dev.