تجربهٔ مهاجرت تیمی به فیگما

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

اینکه چرا در دو سال گذشته اکثر تیم‌ها و طراحان (حداقل اونایی که در نظرسنجی uxtools.co سال ۲۰۲۱ شرکت کردن) فیگما رو به عنوان ابزار اصلی انتخاب کردن دلایل متفاوتی داره، از امکانات هر یک از ابزارهای مشابه تا نیازمندی‌ها و ترجیحات هر تیم. شاید در یه مطلب دیگه به مقایسهٔ چند رقیب شناخته‌شدهٔ این حوزه از نظر امکانات و فارغ از نیازمندی‌هایی که ما داشتیم بپردازم. اما این مطلب تمرکزش تجربه‌ایه که ما در انتخاب فیگما و مهاجرت به اون داشتیم.

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

چرا؟

مشکلات‌مون روی Sketch داشت زیاد می‌شد

اسکچ مشکلاتی در همگام‌سازی کتابخونه‌ها داشت که از نسخهٔ ۷۰ خیلی جدی‌تر شد. در فایل‌هایی که اجزاشون رو از کتابخونه‌ ارث می‌بردن به صورت عجیبی اتصال بین کامپوننت‌ها و کتابخونه‌شون قطع می‌شد (مشکل معروف Missing Symbol). البته در به‌روزرسانی‌هایی سعی می‌کردن برطرفش کنن، ولی باز هم پیش میومد و هر دفعه باید دوباره همهٔ کامپوننت‌هایی که به مشکل خورده‌ بودن رو دستی به کتابخونه متصل می‌کردیم. در نتیجه انرژی و زمانی که می‌تونست صرف حل مسأله بشه برای این موارد صرف می‌شد. همچنین باعث می‌شد که دقت طرحی که تحویل داده می‌شد تضمین‌شدنی نباشه و گاهی بعضی کامپوننت‌ها یا رنگ و سایر overrideهاشون حذف بشه و هنگام پیاده‌سازی دیده نشه. از طرفی به خاطر ابعاد تیم‌ها و تعداد کسانی که تحت تأثیر این مشکل بودن کارها پیچیده‌تر می‌شد.

دسترسی تیم‌های توسعه به طرح‌ها سخت شده بود

ما از Zeplin برای انتقال طرح‌ها به تیم توسعه و از Overflow برای انتقال جریان‌ها (Flow) استفاده می‌کردیم، و مشکلاتی که هر کدوم داشتن (مثلاً کند بودن Overflow یا مشکلات سمت سرور Zeplin) باعث می‌شد به فکر ابزارهای بهتری باشیم.

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

اسکچ دیگه تنها ابزار نبود

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

فیگما به نیازهای ما نزدیک‌تر بود

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

فیگما برای ما ارزون‌تر تموم می‌شد

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

آیندهٔ روشن‌تری رو برای فیگما می‌دیدیم

مسیر توسعهٔ فیگما و امکاناتی که ارائه می‌داد، شیب رشدش، جذب نیروهای قوی و ۵ سری جذب سرمایه (اون موقع آخرینش سال ۲۰۲۰ از Andreessen Horowitz بود و بعد از اون هم جذب سرمایه داشت) باعث می‌شد ادامهٔ کار با فیگما رو بهتر ببینیم. خوبه نگاهی به آمار نظرسنجی‌ای که به تازگی از جامعهٔ طراحان منتشر شد بندازیم:

زمان و شرایط برای مهاجرت مناسب بود

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

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

مشکلاتی مثل عدم پشتیبانی فارسی (که با پلاگین قابل حل بود و وعدهٔ درست‌شدنش رو هم داده بودن) یا نیاز به اینترنت برای باز‌شدن فایل‌ها، یا ریسک بسته‌شدن اکانت (که با بکاپ‌گیری ضرر احتمالیش رو کاهش دادیم)

چطور؟

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

در نتیجه قبل از اینکه همهٔ فایل‌ها رو وارد کنیم، مفصل دنبال ابزاری برای تبدیل فایل‌های اسکچ به فیگما گشتیم و چیزای مختلفی رو تست کردیم اما هر کدوم نواقصی داشتن. می‌شه گفت بهترینشون xd2sketch بود که اخیراً اسمش شده Magicul. این سایت در ازای پرداخت هزینه، فایل‌های مختلف رو به هم تبدیل می‌کرد، ولی باز هم اون چیزی که ما می‌خواستیم نبود. (الان شاید بهتر شده باشه)

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

ما مسیر مهاجرتمون رو به سه قسمت تقسیم کردیم:

• واردکردن فایل اسکچ کتابخونهٔ سنّت به فیگما و اصلاحش بر اساس تفاوت‌های فیگما + وارد کردن فایل‌های دیزاین هر تیم

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

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

• اصلاح فایل‌های دیزاین هر تیم

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

• اتصال نماها به هم با استفاده از prototype

در نهایت هم دیزاینرها با استفاده از پروتوتایپ، نماها رو به هم متصل کردن تا فلوها رو هم در همهٔ فایل‌ها داشته‌ باشیم.

مسائل، چالش‌ها و راهکارهایی که براشون داشتیم

عدم پشتیبانی فیگما از فارسی و چالش انتقال متن به توسعه‌دهنده‌ها

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

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

اتصال اجزای صفحات به Library

برای اینکه نیاز نباشه تک‌تک کامپوننت‌ها رو به کتابخونه متصل کنیم نیاز به ابزاری بود که فایل رو مرور کنه و خودکار اجزا رو به کتابخونهٔ کامپوننت‌ها لینک کنه. این شد که پلاگین FigLink رو ساختیم، که در نسخهٔ اول صرفاً لیست کامپوننت‌های کتابخونه رو می‌گرفت و در یک فایل می‌گشت تا هر instance هم‌نامی پیدا می‌کرد با اون جایگزین کنه. در ادامه بهبودش دادیم تا بشه بین کامپوننت‌های کتابخونه جستجو کرد و یک کامپوننت رو با هر چیزی جایگزین کرد و مهمتر از همه متن‌ها رو هم نگه‌داشت. مدتی بعد فیگما امکان سوییچ کتابخونه رو اضافه کرد، البته که اگه زودتر هم اضافه می‌شد برای مورد ما نیاز به این پلاگین بود و هنوز هم کاربرد داره.

انتقال فلوها به توسعه‌دهنده‌ها در بستر فیگما

در اون زمان (حوالی تیر ۱۴۰۰) فیگما در نمای توسعه‌دهنده، فلوها رو نمایش نمی‌داد و توسعه‌دهنده نمی‌تونست یک جریان رو دنبال کنه تا منطقش رو پیاده کنه. از طرفی دیگه نمی‌خواستیم ابزار جدیدی از خارج محیط فیگما به فرایندمون اضافه کنیم، بنابراین پلاگین ProToFlow رو توسعه دادیم تا تعامل‌ها رو خودکار تبدیل به بردارهایی بین مبدأ و مقصد کنه و توسعه‌دهنده هم بتونه اون‌ها رو ببینه. شاید در یه مطلب دیگه در مورد جزییاتش بنویسم.

البته توی به‌روزرسانی‌های اخیر فیگما توسعه‌دهنده‌ها هم میتونن فلوها رو با زدن Shift+E ببینن و مرورشون کنن، در نتیجه اخیراً این قسمت تبدیل فلوها از چرخهٔ کاری طراحان تیم حذف شد.

نمایش وضعیت طرح‌ها در فایل‌های پروژه‌های مختلف

برای هم‌سویی تیم‌ها و بازبینی طرح‌ها، به فریم‌ها تگ‌های مختلفی زده می‌شه تا بشه وضعیتشون رو دنبال کرد. پلاگین‌هایی برای این موضوع بودن اما باز هم اونی که ما می‌خواستیم نبود. در نتیجه پلاگین FigTag رو هم توسعه دادیم تا بشه از قابلیت Variant component فیگما برای تگ‌زدن به فریم‌ها استفاده کرد. با این پلاگین شما از یک ورینت کامپوننت به عنوان تگ استفاده می‌کنین و پلاگین همون رو کنار فریم(های) مورد نظر شما قرار می‌ده. هر زمان که نیاز به تغییر وضعیت اون فریم باشه می‌شه بدون باز کردن پلاگین و فقط از طریق تغییر تنظیمات Variant انجامش داد.

احتمال بسته‌شدن حسابمون در فیگما به لطف تحریم‌ها

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

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

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

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