منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · شهریور ۱۴۰۵ · زمان مطالعه: حدود ۱۱ دقیقه

تحویل طراحی (Design Handoff) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

Handoff یعنی پاس‌دادن باتون: یکی کارش تمام می‌شود، دیگری شروع می‌کند، و اولی می‌رود.

اما هر چیزی که همین مقاله توصیه می‌کند — کامنت‌گذاشتن در فایل، تگ‌کردن افراد، پرسیدن قالب فایل از توسعه‌دهنده، نمونهٔ تعاملی برای نشان‌دادن حرکت — توصیف یک گفت‌وگوی جاری است، نه یک انتقال.

تعریف

تحویل طراحی فرایند سپردن طراحی نهایی برای پیاده‌سازی است: انتقال قصد و دانش و مشخصات طراح — از عناصر بصری و جریان کاربر و تعامل و انیمیشن و متن تا نقاط شکست واکنش‌گرا و دسترس‌پذیری و اعتبارسنجی داده.

و منبع نکتهٔ مهمی اضافه می‌کند: تحویل، جدا از «چه چیزی» (مشخصات)، می‌تواند «چرا» را هم شامل شود — صورت‌بندی مسئله و منطق کسب‌وکار — تا توسعه‌دهنده بافت تصمیم را بفهمد.

چه چیزی را شامل شود

منبع می‌گوید بسته به نوع تغییر متفاوت است: اگر تغییر عمدتاً بصری است، ابزار طراحی خودش مشخصات فنی را می‌دهد و کافی است توسعه‌دهنده را خبر کنید؛ و اگر تغییر در جریان کاربر یا منطق کسب‌وکار است، باید آن اطلاعات را اضافه کنید. و فهرستش این است:

• - عناصر بصری (رنگ، تایپوگرافی، چیدمان، تصویر، آیکون) — که «توسعه‌دهنده معمولاً بی نیاز به ورودی طراح از ابزار بیرون می‌کشد». برای تصویر و آیکون قالب و رزولوشن و نام‌گذاری را با توسعه‌دهنده چک کنید؛ آیکون برداری (SVG) معمولاً ساده‌ترین است.
• - عناصر تعاملی — دکمهٔ غیرفعال چه شکلی است؟ روی آیکون قابل‌کلیک که رفتید چه می‌شود؟
• - فرم و اعتبارسنجی — حداقل تعداد نویسه، اجباری یا اختیاری، و قالب ورودی مورد انتظار.
• - حالت‌های خطا — سبک و جای پیام خطا روی فیلد، و صفحهٔ ۴۰۴.
• - حالت بارگذاری و حالت خالی — صفحه در حال بارگذاری چه شکلی است؟ و اگر هیچ داده‌ای نبود؟
• - انیمیشن با نمونهٔ تعاملی یا گیف.
• - متن واقعی، نه «لورم ایپسوم».
• - جریان‌ها با فلوچارت و نمونه، تا معلوم شود صفحه‌های مبهم به کجا وصل‌اند.
• - اطلاعات دسترس‌پذیری — اندازهٔ هدف لمسی، متن جانشین تصویر، و اینکه کدام عناصر با صفحه‌کلید فوکوس می‌گیرند و خط فوکوس چه شکلی است.
• - نقاط شکست واکنش‌گرا — دست‌کم دو رزولوشن (موبایل و دسکتاپ) و بهتر سه، به‌همراه اینکه در هر گام چه عنصری حذف می‌شود و ترتیب چطور عوض می‌شود.

و در پرسش‌وپاسخ می‌گوید تحویل خوب بدفهمی را کم می‌کند، کارایی را بالا می‌برد، یکدستی را حفظ می‌کند، همکاری را بهتر می‌کند و دوباره‌کاری را کاهش می‌دهد — و در آن مشارکت طراح و توسعه‌دهنده و مدیر محصول و نویسندهٔ UX لازم است.

خودِ کلمه باگ را می‌سازد

این بخش افزودهٔ مترجم است. آن تناقض ابتدای متن پیامد رفتاری مشخصی دارد:

کلمهٔ «تحویل» به طراح می‌گوید این نقطهٔ خروج اوست. و از آن لحظه، پرسش‌هایی که در میانهٔ ساخت می‌رسند حس وقفه می‌دهند، نه حس کار.

اما آن پرسش‌ها خودِ کار‌اند — چون هر چیزی که در فایل تصریح نشده، دارد همان‌جا تصمیم‌گیری می‌شود، با یا بی حضور شما.

پس صورت‌بندی دقیق‌ترش این است: تحویل، پایان دخالت شما نیست؛ شروع گران‌ترین بخشِ آن است.

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

سند تحویل نباید چیزی داشته باشد که فایل خودش می‌گوید

این بخش هم افزودهٔ مترجم است، و از یک جملهٔ خود منبع بیرون می‌آید که نتیجه‌اش را نمی‌گیرد: «توسعه‌دهنده این اطلاعات را معمولاً بی نیاز به ورودی طراح از ابزار بیرون می‌کشد.»

اگر این درست است — و درست است — پس هر دقیقه‌ای که برای نوشتن کد رنگ و فاصله و اندازهٔ فونت در سند تحویل صرف می‌شود، تکرار کاری است که ابزار انجام می‌دهد. و بدتر: آن تکرار، حجم می‌سازد و چیزهای مهم را زیر خودش پنهان می‌کند.

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

• - حالت‌هایی که صفحه ندارند — و همین‌جاست که بیشترین باگ متولد می‌شود.
• - رفتار در شکست هر درخواست — نه فقط «پیام خطا چه شکلی است»، بلکه کاربر بعدش چه گزینه‌ای دارد.
• - قاعدهٔ تقدم — وقتی دو قاعده با هم برخورد می‌کنند کدام برنده است؟ (کالایی که هم تخفیف دارد و هم ناموجود است چه نشان می‌دهد؟)
• - و «چرا» — که منبع درست به آن اشاره می‌کند ولی جایی وسط متن دفنش می‌کند، در حالی که تنها چیزی است که به توسعه‌دهنده اجازه می‌دهد در موارد پیش‌بینی‌نشده خودش درست تصمیم بگیرد.

و برای اولین قلم، یک ترفند ارزان: حالت‌ها را پیش از طراحی‌شان بشمارید. برای هر صفحه‌ای که در آن داده هست، این نُه حالت را بشمارید:

در حال بارگذاری · خالی · یک آیتم · چند آیتم · بیش‌از‌حد آیتم · خطا · بی‌اینترنت · بی‌دسترسی · دادهٔ کهنه

و بعد: هر حالت را به‌شکل یک فریم واقعی در فایل بگذارید — چون حالتی که فریم ندارد را کسی که کد را می‌نویسد، ساعت شش عصر و تنها، از خودش می‌سازد.

و یک قید روی توصیهٔ «متن واقعی» منبع: کافی نیست. طراح متنی با طول دلپذیر انتخاب می‌کند و در محیط واقعی نام محصول چهل‌و‌سه نویسه است. پس دقیق‌ترش این است: بلندترین متن واقعی، خودش مشخصه است — دست‌کم در یک فریم بگذاریدش و بگویید بعد از آن چه می‌شود (شکستن خط، بریدن، سه‌نقطه، کوچک‌شدن).

در بافت فارسی: راست‌به‌چپ یک قلم تحویل نیست، طراحی دوم است

این بخش هم افزودهٔ مترجم است و چهار نکته دارد.

یک: آینه‌کردن مکانیکی نیست، و اگر سند تحویل نگوید چه چیزی آینه می‌شود، توسعه‌دهنده انتخاب می‌کند — و در صفحه‌های مختلف ناهمسان انتخاب می‌کند.

• - آینه می‌شود: چیدمان، ترتیب ستون‌ها، فلش «بعدی»، جهت پیشرفت، جهت انیمیشن ورود.
• - آینه نمی‌شود: اعداد، کنترل‌های وابسته به زمان (پخش، خط زمان)، استعاره‌های دستگاه فیزیکی، لوگو، شمارهٔ تلفن و کارت، و قطعه‌کد.

و شکل درست تحویلش این است: یک جدول کوتاه «آینه می‌شود / نمی‌شود»، یک‌بار، در سیستم طراحی — نه در هر صفحه از نو.

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

سه: ارقام و تقویم — و این پرتکرارترین نقص تحویل در بازار ماست. برای هر فیلد بگویید ارقام فارسی است یا لاتین؛ و برای تاریخ، ذخیره‌سازی را از نمایش جدا کنید. جملهٔ لازم این است: «در پایگاه داده میلادی و UTC ذخیره می‌شود، در رابط جلالی و به وقت محلی نمایش داده می‌شود». قاطی‌شدن این دو، منبع تقریباً همهٔ باگ‌های تاریخ است.

چهار و مهم: فهرست منبع یک تیم بزرگ فرض می‌گیرد. اینجا معمولاً «توسعه‌دهنده» یک نفر است که همه‌کار می‌کند — و سند دوازده‌صفحه‌ای برای او مرده به‌دنیا می‌آید.

شکل واقع‌گرایانه‌ترش این است: یک فهرست کوتاه از تصمیم‌ها به‌علاوهٔ بیست دقیقه تماس. و آن بیست دقیقه را جای سند طولانی بگذارید، نه علاوه بر آن.

جمع‌بندی

• - تحویل طراحی انتقال قصد و دانش و مشخصات طراحی برای پیاده‌سازی است، و می‌تواند «چرا» را هم شامل شود؛ فهرست منبع از عناصر بصری تا دسترس‌پذیری و نقاط شکست را می‌پوشاند.
• - اما خودِ کلمهٔ «تحویل» باگ را می‌سازد، چون به طراح می‌گوید اینجا نقطهٔ خروج است. دقیق‌ترش: تحویل شروع گران‌ترین بخش دخالت شماست. آزمونش: چند دقیقه از وقت طراح برای دو هفتهٔ بعد بودجه شده؟
• - و سند تحویل نباید چیزی داشته باشد که فایل خودش می‌گوید — تکرار مشخصات بصری فقط حجم می‌سازد و مهم‌ها را پنهان می‌کند.
• - آنچه فایل نمی‌تواند بگوید: حالت‌هایی که صفحه ندارند · رفتار در شکست · قاعدهٔ تقدم · و «چرا».
• - نُه حالت را بشمارید (بارگذاری، خالی، یک، چند، بیش‌از‌حد، خطا، بی‌اینترنت، بی‌دسترسی، کهنه) و هر کدام را فریم واقعی کنید — چون حالت بی‌فریم را کسی که کد می‌نویسد از خودش می‌سازد.
• - و «متن واقعی» کافی نیست: بلندترین متن واقعی خودش مشخصه است، به‌همراه قاعدهٔ سرریز.
• - در بافت ما: جدول «آینه می‌شود / نمی‌شود» یک‌بار در سیستم طراحی · نام فایل و وزن فونت را دقیق بگویید و به ضعیف‌بودن وزن ضخیم فارسی اشاره کنید · ذخیره‌سازی تاریخ را از نمایشش جدا کنید · و برای تیم کوچک، فهرست کوتاه تصمیم‌ها به‌علاوهٔ بیست دقیقه تماس، به‌جای سند بلند.