تحویل طراحی به تیم فنی
طراحی تمام شده، فایل تحویل تیم فنی شده. دو هفته بعد، محصولی ساخته شده که شبیه طرح هست ولی طراح راضی نیست و توسعهدهنده کلافه است.
این اتفاق تقریباً همیشه نه از بیدقتی، بلکه از یک سوءتفاهم ساختاری میآید: فایل طراحی یک تصویر است، و محصول یک سامانهٔ زنده با حالتهای متعدد.
طراح یک حالت را کشیده. توسعهدهنده باید بیست حالت را بسازد و برای نوزدهتای دیگر خودش تصمیم گرفته.
آنچه در فایل طراحی نیست و باید باشد
فهرستی که اگر رعایت شود، بیشتر اصطکاک از بین میرود:
حالتهای هر عنصر. عادی، روی آن، فشرده، فوکوس، غیرفعال، در حال بارگذاری، خطا. حالت فوکوس را جدی بگیرید — طراحان اغلب حذفش میکنند و برای کاربر صفحهکلید ضروری است، همانطور که در دسترسپذیری وب گفتیم.
حالت خالی. فهرستی که هنوز داده ندارد. پرتکرارترین چیزی که جا میماند و مهمترین صفحه برای کاربر تازه — تفصیلش در تجربهٔ اولین اجرا.
حالت خطا. سرور جواب نداد، شبکه قطع است، دسترسی ندارید. برای هرکدام چه دیده میشود؟
حالت بارگذاری. صفحهٔ اسکلتی یا چرخنده؟
محتوای کوتاه و بلند. نام محصولی که دو کلمه است و نام محصولی که پنج خط است. در فارسی این مهمتر است، چون ترجمهٔ متنهای کوتاه انگلیسی معمولاً بلندتر میشود و دکمه را میشکند.
عدد بزرگ. «۱۲۵٬۰۰۰٬۰۰۰ تومان» در جایی که طرح «۵۰٬۰۰۰» را نشان میداد.
نقاط شکست چیدمان. طرح دسکتاپ و موبایل هست؛ بین این دو چه اتفاقی میافتد؟
اسکرول. اگر محتوا از صفحه بیشتر شد، چه چیزی ثابت میماند؟
آنچه توسعهدهنده لازم دارد
توکنها، نه مقادیر. طرحی که میگوید «این فاصله ۱۶ است» بهتر از طرحی است که هر جا عدد متفاوتی دارد. اگر دیزاین سیستم دارید، تحویل بهمراتب سادهتر است — چون بهجای مشخصات هر صفحه، ارجاع به قواعد مشترک میدهید.
مقیاس محدود. اگر فاصلهها هر عددی باشند، توسعهدهنده هر بار باید اندازه بگیرد. شش مقدار مشخص کافی است.
نامگذاری یکسان با کد. اگر طراح میگوید «کارت محصول» و در کد اسمش چیز دیگری است، هر گفتوگویی ترجمه لازم دارد.
رفتار، نه فقط ظاهر. این دکمه چه میکند؟ بعدش چه میشود؟ اگر شکست خورد؟ بخش زیادی از این اطلاعات در ذهن طراح است و در فایل نیست.
اولویت. اگر فضا کم آمد، چه چیزی حذف میشود؟
راستبهچپ، که باید در طراحی حل شود
بندی که مخصوص ماست:
طرح را از ابتدا راستبهچپ بکشید، نه اینکه طرح چپبهراست را آینه کنید. آینهکردن مکانیکی، نتایج عجیب میدهد.
مشخص کنید چه چیزی نباید بچرخد: شمارهٔ تلفن، کد ملی، ایمیل، آدرس اینترنتی، نمادهای پخش رسانه. اینها در راستبهچپ هم چپبهراست میمانند.
نمادهای جهتدار. فلش «بعدی» در فارسی به چپ اشاره میکند. اگر در طرح مشخص نشود، توسعهدهنده حدس میزند و نیمی از مواقع اشتباه میزند.
اعداد. کجا فارسی، کجا لاتین؟ این تصمیم طراحی است و باید یک بار گرفته و ثبت شود.
فهرست کاملش در وب فارسی.
تحویل، یک رویداد نیست
بزرگترین تغییر ذهنیتی که پیشنهاد میکنیم: طراحی را قبل از تمام شدن نشان دهید.
الگویی که در پروژههای ما جواب داده:
۱. توسعهدهنده در جلسهٔ اول طراحی حاضر باشد. پنج دقیقه گفتوگو دربارهٔ اینکه چه چیزی گران است و چه چیزی ارزان، ساعتها بازکاری را حذف میکند. طراحی که میداند فیلتر لحظهای روی ده هزار رکورد گران است، طرح دیگری میکشد.
۲. طرح ناقص را زود نشان دهید. بازخورد فنی روی طرح نیمهکاره ارزان است؛ روی طرح تمامشده گران.
۳. اولین صفحه را با هم بسازید. طراح و توسعهدهنده کنار هم. الگوهایی که اینجا کشف میشوند، بقیهٔ پروژه را سریع میکنند.
۴. طراح نتیجه را در محصول واقعی ببیند، نه در فایل. فاصلهٔ فایل با مرورگر همیشه بیشتر از انتظار است.
۵. بازبینی طراحی پیش از انتشار، بهعنوان بندی از تعریف اتمام کار — که در تعریف اتمام کار گفتیم.
دو اشتباه متقارن
طراح: کشیدن چیزی که فنی گران است، بدون پرسیدن. انیمیشن پیچیده، چیدمانی که با دادههای واقعی نمیخواند، فونتی که حجمش بالاست.
توسعهدهنده: تغییر خودسرانه در طرح چون «اینطوری راحتتر بود». اگر چیزی سخت است، بگویید سخت است و گزینه بخواهید — نه اینکه بیصدا چیز دیگری بسازید.
هر دو از یک ریشه میآیند: نبود گفتوگو در زمان درست.
فایلهای تحویلی
- فایل طراحی با لایههای مرتب و نامگذاریشده.
- نمادها بهصورت SVG، نه تصویر. مقیاسپذیر و رنگپذیر.
- تصاویر در چند اندازه و قالب مدرن.
- فونتها با مجوز روشن. این را زود بررسی کنید — فونت فارسیای که مجوز تجاری ندارد، مشکلی است که در روز انتشار کشف میشود.
- مستند حالتها، همان فهرست ابتدای مقاله.
سنجهٔ ساده
اگر میخواهید بدانید تحویل خوب بوده یا نه، یک عدد کافی است:
چند سؤال از طراح پرسیده شد که جوابش باید در فایل میبود؟
اگر زیاد است، فایل ناقص بوده. اگر صفر است، یا فایل کامل بوده یا — محتملتر — توسعهدهنده حدس زده و شما بعداً میفهمید.