تحویل فایل طراحی به برنامه‌نویس؛ چک‌لیست هندآف بدون اصطکاک
فایل طراحی را چطور آماده کنیم که توسعه‌دهنده کمتر سؤال بپرسد؟ از نام‌گذاری لایه‌ها و استایل‌ها تا حالت‌های تعاملی و خروجی دارایی‌ها.
هندآف بد چه هزینه‌ای دارد؟
سناریوی آشنا: فایل طراحی «تمام‌شده» به برنامه‌نویس می‌رسد؛ بعد از دو روز، پیام‌ها شروع می‌شود — «این فاصله چند پیکسله؟»، «این رنگ دقیقاً چیست؟»، «وقتی روی دکمه کلیک شود چه اتفاقی می‌افتد؟». نتیجه، ده‌ها رفت‌وبرگشت پیام، نارضایتی دوطرفه و محصولی است که نه به طراحی می‌رسد نه به اعصاب هیچ‌کدام. هندآف (تحویل فایل) پلی است که کیفیت طراحی را به کد منتقل می‌کند و کیفیت این پل، به اندازهٔ خود طراحی اهمیت دارد.
حقیقت تلخ اما مفید: هندآفِ بد، تقصیر مشترک است اما پیشگیری‌اش دست طراح است. هر سؤالی که برنامه‌نویس می‌پرسد، نشانهٔ یک گم‌شدگی در فایل است؛ و هر گم‌شدگی، یا در نام‌گذاری است یا در مشخصات یا در سناریوهای تعامل. این سه محور را درست کنیم، اصطکاک تقریباً صفر می‌شود. تفاوت نقش‌ها را هم از اول شفاف کنید که انتظارات واقعی شکل بگیرد؛ برای این، تفاوت UI و UX مرور خوبی است.
آماده‌سازی فایل فیگما: به اسم کد فکر کنید
قدم اول، بهداشتی‌کردن فایل است. لایه‌های بی‌نامِ «Frame 47» و «Rectangle 23» را با نام معنادار جایگزین کنید: btn/primary، card/product، input/search. منطق نام‌گذاری را ساده و ثابت نگه دارید — الگوی نوع/نام برای همهٔ فایل یکسان. فریم‌های صفحه هم باید اسم صفحات واقعی را بگیرند (home، product-detail) نه «نسخه نهایی۲». اگر جریان کار با فیگما برایتان تازه است، آموزش فیگما از صفر پایه‌های همین نظم را می‌سازد.
قدم دوم، حذف زباله‌هاست: لایه‌های مخفی و قفل‌شدهٔ فراموش‌شده، وکتورهای تستی، نسخه‌های قدیمی که سر راه‌اند و صفحهٔ اکسپلور ایده‌ها. یک قاعدهٔ سریع: هر چیزی که نمی‌خواهید برنامه‌نویس ببیند، قبل از تحویل حذف یا به صفحهٔ آرشیو منتقل شود. قدم سوم، چیدمان با اتولی‌اوت است؛ فریمی که با اتولی‌اوت چیده شده، در پنل Inspect فاصله‌های تمیز و منطقی نشان می‌دهد اما فریم دستی، اعداد تصادفی می‌دهد و توسعه‌دهنده را وادار می‌کند حدس بزند. اگر هنوز با اتولی‌اوت راحت نیستید، همین یک مهارت، بزرگ‌ترین سرمایه‌گذاری روی هندآف شماست.
مشخصات دقیق: فاصله، رنگ و فونت
برنامه‌نویسِ حرفه‌ای از Dev Mode فیگما استفاده می‌کند و همهٔ اعداد را می‌بیند؛ اما وظیفهٔ شما اطمینان از خوانا بودن این اعداد است. فاصله‌ها باید ضریبی از ۴ یا ۸ باشند تا در کد هم به توکن تبدیل شوند؛ رنگ‌ها باید استایل تعریف‌شده داشته باشند (نه کد هگز مستقیم روی هر لایه) تا معلوم باشد کدام رنگ «رنگ اصلی» است و کدام «حالت هاور». فونت‌ها هم همین‌طور: سه سطح تیتر، بدنه و کپشن، هرکدام با سایز و وزن و ارتفاع خط مشخص، در صفحهٔ Typography مستند شوند.
یک صفحهٔ راهنما به اول فایل اضافه کنید با سه بخش: پالت رنگ با نام نقش‌ها (brand/primary، text/secondary)، تایپوگرافی با نمونهٔ هر سطح، و اجزای پرتکرار (دکمه‌ها با همهٔ حالت‌ها). این صفحه در عمل، نسخهٔ کوچک و اولیهٔ سیستم طراحی است و دقیقاً همان چیزی که توسعه‌دهنده برای ساختن کامپوننت‌های کد لازم دارد. اگر اعداد فاصله‌تان هنوز قانونمند نیست، قبل از هر تحویلی، یک دور بازبینی فاصله‌ها بگذارید؛ سی ثانیه برای شما، ساعت‌ها صرفه‌جویی برای تیم.
حالت‌های تعاملی: طراحیِ همهٔ اتفاق‌ها
رایج‌ترین حفرهٔ فایل‌های تحویلی: فقط حالت خوش‌بختی طراحی شده است. دکمه در حالت عادی زیباست؛ اما حالت هاور؟ حالت غیرفعال؟ حالت لودینگ؟ فرم وقتی خطا دارد چه شکلی است؟ لیست وقتی خالی است و وقتی ۲۰۰ آیتم دارد؟ هر کدام از این حالت‌ها که طراحی نشده، در کد به سلیقهٔ توسعه‌دهنده ساخته می‌شود و آن‌جا دیگر از طراحی شما خبری نیست.
راه‌حل سیستماتیک، واریانت‌های کامپوننت است: برای هر جزء تعاملی، همهٔ حالت‌ها را در یک کامپوننت با واریانت‌های default/hover/disabled/error بسازید. برای پروژه‌های فارسی یک واریانت RTL هم اضافه کنید اگر رابط دوزبانه است؛ نکات کاملش در طراحی راست‌به‌چپ برای محتوای فارسی آمده. و در کنار حالت‌ها، انوتیشن (یادداشت روی طرح): با ابزار نوت فیگما برای هر رفتار غیربدیهی توضیح کوتاه بگذارید — «این لیست تا ۵ آیتم بدون اسکرول است»، «کلیک روی کارت به صفحهٔ جزئیات می‌رود نه فقط دکمه». این یادداشت‌ها همان پاسخ‌های ازپیش‌آمادهٔ سؤال‌های بعدی‌اند.
خروجی دارایی‌ها و نام‌گذاری فایل‌ها
برای تصاویر و آیکون‌ها، خروجی را خودتان آماده کنید تا کیفیت و فرمت درست باشد، نه اینکه توسعه‌دهنده از سرنوشت خودش اسکرین‌شات بگیرد. آیکون‌ها همیشه SVG (وکتور، کم‌حجم، رنگ‌پذیر در کد)؛ عکس‌ها PNG با مقیاس ۲x برای تراکم نمایشگرهای رتینا؛ و اگر تصویر عکس واقعی است، در جای درست خودش (سرور یا CDN) باشد نه داخل فایل فیگما. نام فایل‌ها هم قانونمند: icon-search.svg، [email protected] — نه عکس نهایی.png.
خروجی گرفتن در فیگما ساده است (انتخاب لایه → پنل Export → فرمت و مقیاس) اما دو نکتهٔ حرفه‌ای دارد: اول، آیکون‌ها را قبل از خروجی مطمئن شوید روی فریم ۲۴×۲۴ سوارند و fill رنگ دارند نه استروک ترکیبی؛ دوم، برای دارایی‌های تکرارشونده در سایزهای مختلف، از Export settings ذخیره‌شده روی کامپوننت استفاده کنید تا هر بار با یک کلیک، همهٔ سایزها بیرون بیایند.
گفت‌وگوی هندآف: تحویل، جلسه و چرخهٔ بازخورد
تحویل فایل بدون جلسهٔ کوتاه معرفی، نصفه است. یک جلسهٔ ۳۰ دقیقه‌ای بگذارید، صفحه‌ها را ورق بزنید، تصمیم‌های مهم را شفاهی توضیح دهید و جا برای سؤال بگذارید؛ این نیم ساعت، معمولاً یک هفته رفت‌وبرگشت پیامی را حذف می‌کند. در طول توسعه هم چرخه را روشن نگه دارید: هر تغییری در طراحی، با نام و تاریخ در همان فایل فیگما (نه اسکرین‌شات در واتساپ!) و با اطلاع به توسعه‌دهنده. ابزارهای مدیریت ورک‌فلو تیمی برای همین چرخه ساخته شده‌اند و آخرین بخش چک‌لیست شماست.
چک‌لیست نهایی تحویل: لایه‌ها نام‌گذاری‌شده و زباله‌ها پاک شده؛ همهٔ اجزا کامپوننت با واریانت کامل؛ استایل‌های رنگ و متن تعریف‌شده؛ حالت‌های خالی/خطا/لودینگ طراحی‌شده؛ انوتیشن رفتارها نوشته شده؛ دارایی‌ها با نام درست خروجی گرفته شده؛ جلسهٔ معرفی برگزار شده. وقتی این هفت مورد تیک می‌خورد، شما دیگر «فایل فرستاده‌اید»؛ یک همکاری حرفه‌ای آغاز کرده‌اید و این دقیقاً همان چیزی است که تیم‌ها یک طراح را برایش نگه می‌دارند.
این مطلب برایتان مفید بود؟
با پسندیدن، به ما کمک می‌کنید مطالب بهتری منتشر کنیم.
