در مسیر طراحی محصول، بعضی تصمیمها آنقدر بدیهی به نظر میرسند که کمتر دربارهشان سؤال میپرسیم.
یکی از این تصمیمها برای من، طراحی دیزاین سیستم و UI Kit از صفر بود.
مدتها فکر میکردم این کار نشانه تسلط، دقت و حرفهای بودن است. اینکه همهچیز را خودم بسازم، جزئیات را دقیق انتخاب کنم و پایه بصری محصول را شخصیسازی کنم.
اما در تجربههای مختلف کاری فهمیدم این رویکرد همیشه بهترین انتخاب نیست.
بهخصوص در پروژههایی که زمان محدود است، منابع فشردهاند و سرعت تحویل اهمیت بالایی دارد، تأثیر این تصمیم چند برابر میشود.
این نوشته روایت همان تغییر نگاه است.
در یکی از پروژهها، قرار بود محصولی از صفر طراحی و پیادهسازی شود.
تیم ما بزرگ نبود و زمان هم محدود بود.
طبیعی بود که توسعهدهنده برای افزایش سرعت، سراغ یک لایبرری آماده برود تا کامپوننتها را از پایه توسعه ندهد.
در چنین شرایطی، هر تصمیمی که زمان اضافه ایجاد کند، مستقیماً روی سرعت کل تیم اثر میگذارد.
اما من طبق عادت همیشگیام، شروع کردم به طراحی یک UI Kit اختصاصی از صفر.
در ظاهر، همهچیز منطقی بود.
اما در عمل، چالشهایی ایجاد شد که بعدها باعث شد در تصمیمم تجدیدنظر کنم.
۱. برداشت اشتباه از مسئولیت طراح محصول
مدتها تصور میکردم مهمترین مسئولیت من انتخاب دقیق جزئیات رابط کاربری است؛ رنگها، فاصلهها، گردی گوشهها، سایهها و تایپوگرافی.
اثرگذاری خودم را در همین سطح میدیدم. در حالی که نقش طراح محصول فراتر از اینهاست و باید بر رفتار و نیاز کاربر تمرکز کند.
درگیر شدن با تصمیمهای ریز و متعدد، انرژی ذهنی زیادی از من میگرفت. آخر روز، خسته از انتخابهای کوچک بودم و تمرکز کمتری برای تصمیمهای مهمتر محصول داشتم.
۲. منطقه امن در طراحی
طراحی کامپوننت و UI Kit را بهخوبی بلد بودم. دوره دیده بودم، تمرین کرده بودم و در آن احساس تسلط داشتم.
در مقابل، استفاده از یک دیزاین سیستم آماده و تطبیق طراحی با آن، تجربهای بود که کمتر داشتم. طبیعی بود که ناخودآگاه به سمت روشی بروم که برایم آشناتر و امنتر است.
در واقع باید یاد میگرفتم داخل یک چارچوب موجود طراحی کنم، نه اینکه چارچوب را خودم تعریف کنم.
حالا که به آن نگاه میکنم، میبینم انتخابم بیشتر از جنس عادت بود تا تحلیل شرایط.
۳. درک ناقص از نقش دیزاین سیستم در همکاری تیمی
در تجربههای اولیه کاری، در تیمهایی فعالیت کرده بودم که تمرکز اصلیشان یادگیری بود، نه تحویل سریع محصول.
در آن فضاها، دیزاین سیستم بیشتر یک تمرین طراحی بود تا یک ابزار هماهنگی.
مستندات دیزاین سیستمها را میخواندم تا اصولشان را در طراحی شخصی خودم رعایت کنم، اما تجربه کار مستقیم با یک دیزاین سیستم آماده و هماهنگ با تیم توسعه را نداشتم.
۱. سختتر شدن تعامل بین طراحی و توسعه
توسعهدهنده بر اساس لایبرریای که استفاده میکرد صحبت میکرد و من بر اساس ساختاری که در فیگما طراحی کرده بودم.
برای مثال، وقتی او از «گرید چهارستونه در دسکتاپ» حرف میزد، منظورش قرار گرفتن ۴ کارت کنار هم طبق مستندات لایبرری بود. اما من بر اساس گرید ۱۲ ستونهای که در طراحی استفاده میکردم فکر میکردم.
نتیجه چه میشد؟ یا باید طراحی تغییر میکرد، یا توسعه باید از چارچوب خودش خارج میشد. هر دو یعنی زمان بیشتر، بحث بیشتر و اصلاح دوباره. هر دو نگاه منطقی بود، اما هماهنگ کردنشان ساده نبود.
۲. فاصله بین طراحی و پیادهسازی
وقتی UI Kit از صفر طراحی میشد اما توسعه بر اساس یک لایبرری آماده جلو میرفت، اختلافهایی بین طرح و خروجی نهایی ایجاد میشد.
در بهترین حالت، رفتوبرگشت بین من و توسعهدهنده بیشتر میشد. در بدترین حالت، طرحی که قبلاً تأیید شده بود بعد از پیادهسازی نیاز به اصلاح دوباره داشت.
این روند هم زمانبر بود و هم فرسایشی.
در پروژه بعدی، دوباره با شرایط مشابهی روبهرو شدیم. اما این بار توسعهدهنده هنوز لایبرری مشخصی انتخاب نکرده بود.
ما این فرصت را داشتیم که از ابتدا درباره زیرساخت طراحی و توسعه با هم تصمیم بگیریم.
اینجا همان جایی بود که تصمیم گرفتم رویکرد قبلیام را تکرار نکنم.
بهجای اینکه طبق عادت، طراحی UI Kit اختصاصی را از صفر شروع کنم و بعد تلاش کنیم آن را با توسعه هماهنگ کنیم، این بار آگاهانه مکث کردم. از خودم پرسیدم:
آیا واقعاً لازم است دوباره همهچیز را خودم بسازم؟
یا میتوانم از یک چارچوب آماده استفاده کنم و انرژیام را جای دیگری صرف کنم؟
این اولین باری بود که تصمیم گرفتم «کنترل کامل روی جزئیات بصری» را اولویت اول ندانم و بهجای آن، هماهنگی با تیم و سرعت تحویل را در اولویت بگذارم.
بهجای اینکه هرکدام مسیر جداگانهای برویم، تصمیم گرفتیم برای انتخاب دیزاین سیستم یا UI Kit با هم بررسی کنیم.
این بار هدفم ساختن یک سیستم از صفر نبود؛
هدفم انتخاب سیستمی بود که بتوانیم با آن سریعتر و هماهنگتر جلو برویم.
شروع کردم به جستوجو و مقایسه گزینههای موجود.
در این مسیر، نیازهای خودم را بهعنوان طراح شفافتر تعریف کردم:
فایل کامل و قابل استفاده در فیگما وجود داشته باشد
بین کامپوننتهای طراحی و توسعه تطابق واقعی برقرار باشد
از حالت روشن و تاریک پشتیبانی کند
امکان استفاده از وریبلها در طراحی فراهم باشد
و مهمتر از همه، توسعهدهنده هم با آن راحت باشد
این بار انتخاب دیزاین سیستم یک تصمیم مشترک بود، نه انتخاب یکطرفه.
تفاوت اصلی فقط در ابزار نبود؛ در اولویتها بود.
افزایش سرعت توسعه
چون کامپوننتها آماده بودند، بیشتر زمان صرف شخصیسازی میشد تا ساختن از صفر.
کاهش اختلاف بین طراحی و خروجی
رفتوبرگشتها کمتر شد و طراحی دقیقاً با همان اجزایی انجام میشد که در توسعه استفاده میشد.
آرامش ذهنی بیشتر
دیزاین سیستمی که انتخاب کردیم، قبلاً توسط تیمهای دیگر توسعه و بهینه شده بود. اطمینان از پایداری آن باعث شد دغدغههای کمتری درباره سناریوهای مختلف داشته باشم.
در نهایت، انرژی بیشتری برای تمرکز بر مسئله اصلی محصول آزاد شد. البته این رویکرد برای محصولی با زمان محدود و تیم کوچک کاملاً منطقی بود. اگر قرار باشد یک سیستم بزرگ و منحصربهفرد در مقیاس سازمانی بسازیم، ممکن است تصمیم متفاوتی بگیریم.
طراحی از صفر همیشه نشانه حرفهای بودن نیست؛ گاهی نشانه عادت است.
انتخاب دیزاین سیستم باید تصمیمی مشترک بین طراحی و توسعه باشد.
شرایط پروژه، زمان و ساختار تیم در انتخاب رویکرد طراحی تعیینکنندهاند.
ابزارها هم بالغتر شدهاند و استفاده از یک دیزاین سیستم آماده عملیتر از گذشته است.
تغییر رویکرد بخشی از رشد حرفهای است.
امروز قبل از اینکه طراحی UI Kit اختصاصی را از صفر شروع کنم، از خودم میپرسم:
آیا این تصمیم واقعاً به محصول و تیم کمک میکند؟
یا فقط روشی است که به آن عادت کردهام؟
