یکی از چالشهای همیشگی بعد از نهایی شدن طراحی صفحات، ارتباط بین طراح و توسعهدهنده است. ارتباطی که اگر به درستی شکل نگیرد، ضریب خطای پیادهسازی را بالا میبرد. یکی از مواردی که در این ارتباط مهم است، تحویل فایلهای استفاده شده در طراحی، مثل عکسها، تصویرسازیها و فونتهاست. در این مقاله، قرار است راجع به این ارتباط صحبت کنیم و یکی از روشهای بهینه کردنش را با هم ببینیم.
سرنوشت را به شانس واگذار نکنید
روشهای مرسومی که اکثر طراحان برای تحویل فایلها استفاده میکنند، میتواند بهویژه در تیمهای بزرگ مشکلاتی به وجود بیاورد. این مشکلات اغلب به دلیل برخورد سلیقهای طراحان و توسعهدهندگان اتفاق میافتد. در این خصوص مثالهای مختلفی میتوان زد:
- استفاده از فرمتهای مختلف تصویری؛ مثلا یکی ممکن است از فرمت پیانجی استفاده کند و توسعهدهندهای دیگر از اسویجی که این باعث عدم یکپارچگی تصاویر میشود.
- استفاده از سایزهای مختلف تصویر؛ مثلا ممکن است توسعهدهندهای خودش برود از طراح فایل بنر با کیفیت سهبرابری بگیرد در صورتی که بقیه توسعهدهندگان از فایلهایی با همان رزولوشن طراحیها استفاده کنند که باز هم یکپارچگی را از بین میبرد.
- گاهی پیش میآید که یک طراح فایلی را برای توسعهدهنده در یک پیامرسان میفرستد و همین فایل وقتی جای دیگری به آن نیاز میشود، افراد به آن دسترسی ندارند.
- بهروزرسانی فایلها هم در روش سنتی سخت است. طرحها معمولاً بعد از تحویل به توسعهدهنده بارها تغییر پیدا میکنند و از جایی به بعد هیچکس نمیداند فایل نهایی دست کیست!
برای حل این مسائل خوب است که فرآیندی مشخص برای تحویل فایلها از تیم طراحی به تیم توسعه داشته باشیم. یکی از ابزارهایی که در این فرآیند از آن استفاده میکنیم، نامش گیت است.
اولین کاری که باید بکنیم، داشتن یک دید کلی و منظم نسبت به مدل فایلهای خروجی است. قرار است سایز هر دسته فایل مشخص باشد. تمهای رنگی مشخص باشد. فرمتهای خروجی مشخص باشد و کاملاً آیندهنگرانه به این موارد نگاه شود.
نسخه اصلی این نوشته را میتوانید در مدیوم بخوانید.
قبل از دیزاین
برای اینکه بتوانیم از گیت استفاده کنیم، اول باید کمی به سر و گوش فایلهایمان بکشیم. باید تا جای ممکن فایلها را دستهبندی کنیم. این دستهبندیها باید قابل توسعه و آیندهنگرانه تعیین شوند. مثلاً یک دستهبندی کلی خواهیم داشت به نام تصویرسازیها که خودش زیرمجموعههایی دارد مثل تصاویر استیتهای خالی، تصاویر رنگی، و هر دستهبندی دیگری که مطابق محصول شما میتواند متغیر باشد. یا یک دستهبندی کلی آیکونها خواهیم داشت که خودش زیرمجموعههایی مثل آیکونهای سیستم و آیکونهای سهبعدی و از این قبیل میتواند داشته باشد.
در این دستهبندیها قطعاً به مواردی برمیخورید که در هیچکدام از دستهبندیهای رایج قرار نمیگیرند که این موارد را هم میتوانید بر اساس ویژگیهای محصول دستهبندی کنید.
در مورد فرمتهای خروجی هم خوب است که با توسعهدهندگان مشورت کنید که برای هر دسته از چه خروجیهایی قرار است استفاده کنند تا برای آنها هم فولدرهایی داخل دستهبندیها تشکیل دهید. حتی برای تمهایی مثل دارک و لایت هم فولدرهای جداگانه تشکیل دهید. این فولدرها میتوانند قبل از فرمت فایل قرار بگیرند. در نهایت قرار است از این فولدرها به چشم سوییچ نگاه کنیم و فایلهای خروجی در همه این فولدرها نامهای یکسانی داشته باشند و بتوان به راحتی بینشان سوییچ کرد.
این موارد معمولاً یک بار همان اول دربارهاش تصمیمگیری میشود و سعی میکنیم که در ادامه تغییری در آن ایجاد نکنیم.
مسیر حرکت؛ از تسک تا محصول
در هر تیم و شرکتی، فلوی متفاوتی برای انجام تسکها پیش میرود. اما اینجا میخواهم از مسیری صحبت کنم که برای ما جواب داده است.
تیم طراحی ما به ۱۵ نفر میرسد. تعداد لاینهای محصولی زیاد شده و سه تیم فرانت همزمان سه نسخه از اپ را پیادهسازی میکنند. واضح است که نداشتن فلوی صحیح و منظم میتواند برای ما بسیار دردسرساز شود.
طراحی ویژوالهای بلو همزمان با رسیدن به یک نسخه نهایی از رابط کاربری شروع میشود. طراح محصول فیچری که دارد روی آن کار میکند را با ویژوال دیزاینر به اشتراک میگذارد و از او فیدبک میگیرد. این دو با هم سعی میکنند تا بهینهترین مدل استفاده از ویژوال برای محصول در دست طراحی را پیدا کنند. حتی بیشترین تلاش خود را میکنند تا در جایی که افزودن تصویرسازی یا آیکون کمکی به سادگی و فهم بیشتر محصول نمیکند، از استفاده از ویژوالها پرهیز کنند. در صفحاتی ویژوال دیزاینر پیشنهادهایی برای تصویرسازی و هر مورد بصری دیگری مطرح میکند و این دو در نهایت به لیستی از موارد بصری مورد نیاز برای این فیچر میرسند. با همراهی تیم لید و پروداکت منیجر، این لیست به صورت تسکهایی مشخص برای ویژوال دیزاینر قرار داده میشود تا طبق زمانبندی مشخص آنها را تحویل دهد.
مشخصاً ما همه تصویرسازیها، آیکونها، بنرها و … را در فیگما و در محیط ایزولهای به نام ویژوال کیت انجام میدهیم. بعد از نهایی شدن این تصویرسازیها، آنها به صورت کامپوننت در اختیار دیزاین سیستم منیجر قرار میگیرند تا در کیت اصلی بلو و در جای درست دوباره کامپوننت شوند و در کتابخانه تیم به اشتراک گذاشته شوند.
حالا و برای تحویل فایلها به تیم توسعه، آنها را با فرمتهای مورد نظرمان خروجی میگیریم و در پوشه درست خودشان در گیت قرار میدهیم. این تغییر را کامیت میکنیم و هلش میدهیم به سمت ریپوزیتوری گیتمان.
حالا وقت اطلاعرسانی است. ما یک کانال برای آپدیتهای دیزاین سیستم و ویژوالهایمان داریم که همه طراحان و بچههای توسعه در آن عضو هستند. میآییم و در یک پیام جدا، چیزی که اضافه شده، لینک کامیت و لینک آن در دیزاین سیستم را میگذاریم و کسانی که باید از این پیام حتماً مطلع شوند را منشن میکنیم. سعی میکنیم یک تصویر از موارد اضافه شده یا تغییر داده شده ضمیمه پیام کنیم. یک کپی از همین متن را تسک مرتبطش کامنت میکنیم و تسک را برای ریویو میفرستیم.
همین!
به همین سادگی ما موفق شدیم که طراحی ویژوالها را در بلوبانک کاملاً فرآیندمحور جلو ببریم. این کار به ما بسیار کمک کرد که در طول سالها یکپارچگی بصریمان را حفظ کنیم و همزمان برای لاینهای مختلف آیکون و تصویرسازی طراحی کنیم. این روزها داریم به این فکر میکنیم که چطور میتوانیم این فرآیند را از این هم سریعتر و بهینهتر کنیم. شاید یک پلاگین؟