چرا همه چی قشنگه ولی هیچی قشنگ نیست؟!

بررسی اهمیت UI Style Guide در طراحی و اجرای اپلیکیشن‌ها


این وسایل رو در نظر بگیرید:

یه مبل راحت، یه ساعت اداری، کاشی‌‌‌های سنتی ایرانی و کف‌پوش ماشین؛ هر کدوم از این وسایلی که دیدیم در جای خودشون چیز خوب و به‌دردبخوری هستن ولی وقتی کنار هم قرار بگیرن:

خیلی چیز جالبی نمی‌شن!


در زمینه نرم‌افزار هم همین داستان صادقه. در زمان قدیم‌‌‌‌‌الایام، همین که برنامه گرافیک داشت و کار می‌کرد، از سر کاربر هم زیاد بود. مثلا این سایت با استانداردهای سال ۲۰۰۰ احتمالاً چیز ردیفی محسوب می‌شده:

سایت وزین arngren.net
سایت وزین arngren.net


ولی الان باید بپذیریم که عجق‌وجقی بیش نیست.


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

ماجرای تم اینه که جناب طراح تلاش می‌کنه تمام عناصری که توی طراحیشون به کار می‌ره با هم سازگاری یا همون هارمونی داشته باشن.

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


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

صفحه اول سایت دیوار
صفحه اول سایت دیوار

مثلاً دیوار نسبت به اون سایت عجق‌وجق خیلی ساده‌تر و زیباتره.


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

در کل دو تا گروه توی این زمینه یعنی طراحی و اجرا کار می‌کنند؛ گروه طراحی و گروه اجرا!

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

مثلا این دو تا کیک رو در نظر بگیرید:

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

توی زمینه نرم‌افزار هم همین داستان صدق می‌کنه. معمولاً برنامه‌نویس‌ها توی پیاده‌سازی طرح، دقت لازم رو در زمینه جزئیات ندارند و درک و بینشی که طراح نسبت به طرح داره رو نمی‌شه از یه برنامه‌نویس انتظار داشت. اونوقته که می‌شه انتظار شنیدن این سوال رو داشت که «چرا همه چی قشنگه ولی هیچی قشنگ نیست؟!».

راه‌حل چیه؟

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

مثلا توی طراحی دکوراسیون اتاق، طراح به مسئول خرید و چیدمان اتاق می‌گه که همه چوب‌های دکوراسیون حتما باید از جنس چوب افرا و به رنگ ماهوگانی باشن، سرامیک کف حتماً باید از برند ایزی‌سرام باشه و مدل R89 رو بخره و... .

چند تا دستورالعمل این مدلی باعث می‌شه تا چیزی که خریداری و چیده می‌شه دقیقاً مطابق نظر طراح باشه و اتاق به همون شکلی که ایده‌ش داده شده بود، به نظر برسه.

در زمینه نرم‌افزار، به این قوانین و استانداردها که باعث می‌شن چیزی که مدنظر طراح هست عیناً پیاده‌سازی بشه، UI Style Guide (راهنمای سَبْک رابط کاربری) می‌گن. به قول امیر تقی‌آبادی:

استایل‌گاید مجموعه‌ای از استانداردهای نوشتاری،‌ طراحی، گریدبندی و... است که کمک می‌کند سرعت و انسجام در طراحی بیشتر شود.


امیر، اینجا درباره مزایای استایل‌گاید و اهمیتش از دید یه طراح نوشته.

https://virgool.io/UIUXcourse/ui-style-guide-%DA%86%DB%8C%D8%B3%D8%AA-fg4ua1axbvkd


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



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

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

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

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

حالا فرض کنید هیچ برنامه‌ریزی و نظمی در کار نباشه و هر برنامه‌نویس یه گوشه از کار رو بگیره و شروع به پیاده‌‌سازی رابط کاربری طراحی شده بکنه. مطمئناً نتیجه شلم‌شوربایی بیش نیست!

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

نمونه ساده ui style guide
نمونه ساده ui style guide

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

البته توی سناریوی ما باید ۶ تا سند تولید بشه. سه تا بانک و برای هر بانک دو تا سند، یکی برای تم روز و یکی هم برای تم شب.

پس اولین و مهمترین مزیت UI Style Guide همین یک‌پارچه‌شدن خروجی‌‌های توسعه‌دهنده‌‌های مختلف و پیاده‌‌‌‌سازی دقیق طرحه.


۲. کاهش هزینه تغییر

مزیت دیگه‌ای که UI Style Guide به وجود می‌آره، کاهش هزینه تغییره.
به عنوان مثال بخشی از خروجی این سند در زمینه رنگ‌ها توی کد نرم‌افزاری چنین چیزی میشه:

کاری که می‌کنیم اینه که میایم و به رنگ‌هایی که توی برنامه استفاده شده، بر حسب کارکردشون اسم می‎‎‌دیم. رنگ اصلی، رنگ اصلی تیره، رنگ ثانویه و... .
حالا مثلاً هر جا نیازی به استفاده از رنگ اصلی و سازمانی بانک مهر هست، به جای کد رنگی #84BD00 از کلمه colorPrimary استفاده می‌شه. در نتیجه اگه روزی بانک تصمیم بگیره رنگ سازمانیش رو عوض کنه (که همین چند وقت پیش هم کرد) دیگه نیازی به تغییر همه اجزای برنامه نیست و صرفاً با یه تغییر ساده، همه جا رنگ به‌روز می‌‌‌شه.


۳. ایجاد یه زبان مشترک بین برنامه‌نویس، مدیر محصول و طراح

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




انتظارات توسعه‌دهنده‌ها از استایل‌گاید

۱. به موقع حاضر باشه

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

نتیجه این حاضر نبودن به موقع می‌شه چنین تسکی:

۲. منطبق با استانداردها باشه

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


۳. کامل باشه

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


۴. تا حد امکان ساده باشه

بعضی از استایل‌گایدها به خاطر خلوت‌تر شدن صفحه یا شلوغی ذهن طراح جوری نوشته می‌شن که تفسیرش نیازمند سال‌‌‌‌‌‌‌‌‌‌‌‌‌‌ها تحصیل در حوزه‌ست! انتظار دیگه‌ای که از استایل‌گاید می‌ره اینه که تا حد امکان ساده و واضح باشن که سادگی غایت کمال است.


خلاصه

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


مطلب قبلیم

https://virgool.io/@khaleghi/poop-rjnqxyqv0jbr