بهبود روابط طراح و دولوپر با چک لیست هندآف طراحی

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

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

داک هندآف چیه؟

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

چرا داک هندآف؟

توی دنیای امروز شرکت‌ها دیگه نه تنها برای ساختن بهترین تجربه باهم رقابت می‌کنن بلکه بحث سرعت مطرحه، اینکه چه شرکتی می‌تونه سریع‌تر فیچر یا محصولی رو به بازار عرضه کنه. شرکت‌ها اغلب ترجیح میدن زودتر شکست بخورن (failing fast) تا اینکه وقتشون رو روی چیزی تلف کنن که کار نمی‌کنه. همچنین یه محصول موفق صرفا نباید درست کار کنه بلکه طراحیش باید هدفمند انجام شده باشه و هویت برند رو نشون بده، بخاطر همین داک هندآف کمک می‌کنه تا دولوپر و دیزاینر کاملا باهم سینک باشن.

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

داک هندآف چه کمک‌هایی به تیم ما می‌کنه؟

1. ارتباط بین برنامه نوبس و دیزاینر رو سریع‌تر و رون‌تر می‌کنه.
2. طراحی‌ها رو به روز نگه می‌داره.
3. باعث ایجاد یکپارچگی می‌شه چون همه چیز مستند شده خواهد بود.
4. به کارمنداهای جدید کمک می کنه تا روند آنبوردینگشون سریع‌تر اتفاق بیفته.

روند تهیه چک لیست تحویل دیزاین به برنامه نویس

با استفاده از متد اکشن ریسرچ که یه روش سرچ اکادمیک ۵ مرحله ای هست، روند ایجاد یه چک لیست هندآف برای یه شرکت فنلاندی اجرا و اعتبار سنجی شد. (اسم شرکت به درخواست خودشون ذکر نشده)

۱. تشخیص

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

۲. برنامه ریزی

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

۳. اقدام

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

۴ و ۵. ارزیابی و مشخص کردن یافته‌ها

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

نتیجه

توی این جریان با ۷ دولوپر و ۲ طراح مصاحبه کردن و نتایج این تحقیق که با پرسیدن ۴ تا سوال اندازه‌گیری شده بود مثبت‌تر از حد انتظار بود. سوالاتی که توی مصاحبه از برنامه نویس‌ها و طراح‌ها پرسیده شد شامل این ۴ سوال بود:
۱. آیا حس می‌کنین که دارین کاری رو مدام تکرار می‌کنین؟ بعد از استفاده از چک لیست آیا تغییری در این حس به وجود اومد؟

۲.حس می‌کنین که بعد از استفاده از چک لیست ارتباطتون با برنامه نویس بیشتر یا کمتر شده؟

۳.آیا حس کردی که چک لیست چیزی کم داره؟

۴. این چک لیست چطور کارهای روزمرتون رو تحت تاثیر قرار داده؟

نتیجه همه این سوالات درصد بالای بهبود عملکرد در روند تحویل طراحی به دولوپر ها بود. حالا بریم سراغ مواردی که توی چک لیست وجود داشت. (البته من کمی تغییرش دادم)

بعضی از مواردی که در چک لیست گنجونده شده بود:

۱. معرفی، یه توضیح کلی از اینکه این فیچر چیه، برای چی طراحی شده و قراره در نهایت چیکار کنه
۲..یورز استوری‌ها (تا برنامه نویس علت ساخت یک فیچر رو متوجه بشه)
۳. سایت مپ (برای ساختن استراکچر درست و معماری اطلاعات)
۳. کامپوننت‌ها به همراه تمامی حالت‌‌هاشون (که با داشتن دیزاین سیستم می‌تونه حل بشه)
۴. یوایکس رایتینگ‌ها
۵.قراردادهای نامگذاری (کامپوننت‌ها و آرتبرد‌ها و...)
۶. یوزر فلو، برای اینکه هیچ استیتی از دست نره
۷. پروتوتایپ
۸. گریدبندی
۹. فواصل (مارجین‌ها و پدینگ‌ها)
۱۰. assets شامل آیکون، عکس و ...
۱۱. لینک‌های مرتبط (فایل طراحی، ریسرچ ...)

نکته‌ها

• حتما بعد از نوشتن چک لیست طی یک جلسه اون رو برای برنامه نویس‌ها ارائه کنید تا کامل نحوه کار با اون رو بدونن و نظراتشون برای بهتر کردنش بهتون بگن.
• ما طراح‌ها عادت زیادی به داستان سرایی داریم، اما فراموش نکنین که این سند باید جامع و خلاصه نوشته بشه، همچنین از اصطلاحات تخصصی دیزاین و اضافه گویی پرهیز کنین.
• نکته‌ی مهم‌ای که وجود داره اینه که با تصور برنامه نویس‌ها توی سرتون داک رو بنویسن، ،به عنوان یک طراح یوزرِ سندی که آماده می‌کنین (که برنامه نویس‌ها هستن) رو باید مبنا قرار بدین و چیزی که اونها براشون مهمه و قراره تحویل بگیرن رو وارد داک کنین. همینطور می‌تونین باهاشون صحبت کنین و ببینین چه چیزهایی براشون مهمه.

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

• هر دو تیم برنامه نویسی و طراحی باید از دنیای هم دیگه خبرداشته باشن، خودتون رو توی دنیای برنامه نویس‌ها غرق کنین و با ساختار تحلیلیشون آشنا بشین. چیزهایی که برای اون‌ها مهمه گاهی جنس خیلی متفاوتی داره مثلا برنامه نویس‌ها به مواردی مثل:
  ریسپانسیو بودن محصول، کارکردش روی مرورگرهای مختلف، سرعت لود صفحات، تعداد ریکوعست‌هایی که وجود داره، بهینه بودن کد و بهینه بودن تصاویر فکر می‌‌کنن، اینکه هر صفحه چطور کار می‌کنه و چه قوانین و گایدلاین‌هایی وجود داره یا تمامی استیت‌ها و یا اج کیس‌هایی که ممکنه توی حالت‌های مختلف پیش بیاد، همونطور که گفتم یوزراستوری‌ها توی این مورد به کمک برنامه نویس میاد.
• تیم‌هایی که از نعمت دیزاین سیستم و استایل گاید برخوردارن، نیاز داکیومنت کردن خیلی از موارد بالا رو ندارن، کامپوننت‌ها، فواصل، است‌ها و.. توی دیزاین سیستم مستند شدن و خود دولوپرها هم از کامپوننت‌هایی که دلوپ کردن استفاده می‌کنن، اما موارد دیگه ای مثل یوزر فلو و توضیحات مهم نسبت به کارکرد هر صفحه برای دولوپر رو می‌تونین توی ابزار طراحیتون (فیگما، اسکچ،..) لحاظ کنین.
• با وجود دیزاین سیستم، استایل گاید، اسناد و قوانین نوشتن کپی و... این تصور رو نداشته باشین که تمامی موارد بالا در یک داک واحد خلاصه بشن، طراحی‌ها، دیزاین سیستم، پروتوتایپ و اسناد دیگه‌ای مثل کپی رایتینگ ممکنه در فایل‌های جداگانه وجود داشته باشن و باعث بشن که داک هندآف شما صرفا شامل لینک‌هایی به این فایل‌ها و توضیحاتی برای پیاده‌سازی مثل یوزر استوری‌ها متریک‌ها و.. بشه.
• اگه قراره یه داک هنداف تهیه کنین این مقاله یا مقالات مشابه صرفا باعث آشنایی شما با این مسئله و روش‌هایی که توی شرکت‌های مختف پیاده سازی می‌شن خواهد بود، اول با تحقیق و صحبت با دولوپرها و طرا‌ح‌ها توی تیم خودتون شروع کنین، نیازها و چالش‌ها رو پیدا کنین و با توجه به شرایط و منابعی که دارین بهترین روش ممکن برای تحویل طراحی به برنامه نویس‌ها رو انتخاب کنین.
• فراموش نکنین که وجود یه داک هندآف هرچقدر هم که خوب باشه نمی‌تونه جای برگزاری جلساتی برای ارایه طراحی و یا ایده پردازی که طراح و دولوپر هر دو در اون شرکت می‌کنن رو بگیره.
• توی بعضی از تیم‌ها مدیر محصول وظیفه نوشتن این سند رو داره که می‌تونین باهاش همکاری داشته باشین تا از دوباره نوشتن جلوگیری بشه.
• مواردی مثل متریک‌ها، اکشن لاگ‌ها و ایونت‌هایی که برای سنجش کارایی طراحیتون بهشون احتیاج دارین یا مواردی که QA باید توجه بیشتری بهش داشته باشن هم می‌تونین به این سند اضافه کنین.

لینک پایان نامه

خوشحال می‌شم توی کامنت‌ها موارد دیگه‌ای که می‌تونه این چک لیست رو کامل کنه و یا از تجربتون از تحویل دیزاین به دولوپرها برام بنویسن.