توی کتابخانهٔ قبلی رایتل، دو مدل فیلد ورودی داشتیم که اسم هر دو «Large» بود. ارتفاع یکی ۴۸ پیکسل بود و دیگری ۶۰ پیکسل.
از روی اسم نمیشد فهمید کدام را باید انتخاب کرد.
تفاوت مشخصی هم در کاربردشان وجود نداشت که این اختلاف ارتفاع را توضیح بدهد. دو طراح میتوانستند برای یک نیاز مشابه، دو فیلد متفاوت انتخاب کنند و فرمهایی با اندازههای متفاوت بسازند. هر دو هم از کامپوننتهای خود کتابخانه استفاده کرده بودند.
وقتی روی تکامل دیزاینسیستم رایتل کار میکردم، این نمونه برایم مسئله را روشنتر کرد. کامپوننت داشتیم، اما قواعد انتخاب و استفاده از بعضی از آنها مشخص نبود.
چرا از متریال شروع کردیم؟
تیم ما هم از نظر زمان تحت فشار بود و هم برای پیادهسازی محدودیت داشت. لازم بود از یک پایهٔ آماده استفاده کنیم تا بتوانیم کار را جلو ببریم. برای همین Material Design را مبنای دیزاینسیستم قرار دادیم.
اما کامپوننتهای آماده تمام نیازهای محصول را پوشش نمیدادند. بعضی کامپوننتها را باید خودمان میساختیم و در ساختشان قواعد متریال را رعایت میکردیم.
بخش قابلتوجهی از وقت ما صرف شناخت همین قواعد شد: اینکه هر کامپوننت از چه اجزایی ساخته شده، لایهها چطور کنار هم قرار میگیرند و برای نمایش حالتهای مختلف چه تغییری میکنند.
قبل از گسترش یک کامپوننت، باید منطق ساختش را میفهمیدم. صرفاً شبیهکردن ظاهر آن به متریال کافی نبود.
متریال نقطهٔ شروع را مشخص کرد، ولی تصمیم دربارهٔ تطبیق آن با محصول و مستندکردن کامپوننتهای جدید همچنان با ما بود. ناهماهنگیهایی که اینجا بررسی میکنم، مربوط به کتابخانهٔ رایتلاند؛ آنها را در کتابخانهٔ اصلی متریال پیدا نکرده بودم.
وقتی کتابخانه جواب روشنی ندارد
اختلاف ارتفاع بهراحتی دیده میشد. با بررسی دقیقتر، مشکلات دیگری هم پیدا کردم: کامپوننتهایی که یک کار را انجام میدادند ولی اسمهای متفاوتی داشتند، گردی گوشههایی که از قاعدهٔ مشخصی پیروی نمیکرد و تنظیماتی که معلوم نبود چطور باید تغییرشان داد.
بعضی کامپوننتها هم همهٔ حالتهای لازم را نداشتند؛ مثلاً مشخص نبود دکمه هنگام فوکوس یا غیرفعالشدن چه ظاهری باید داشته باشد.
هر کدام از این کمبودها، تصمیمی را به طراح صفحه واگذار میکرد.
فرض کن یک فرم به نمایش پیام خطا نیاز دارد، ولی کامپوننت برای آن طراحی نشده است. طراح هم باید فرم را تحویل بدهد. پس همان نمونه را تغییر میدهد و کارش را جلو میبرد. مشکل آن صفحه حل میشود، اما اگر این تغییر به کتابخانه برنگردد، نفر بعدی دوباره باید برای همان نیاز راهحل پیدا کند.
به همین شکل، تعداد کامپوننتها بیشتر میشود، ولی اختلاف بین صفحهها هم بیشتر میشود. وقتی از یک کامپوننت دوباره استفاده میکنیم، تصمیمهای داخل آن هم تکرار میشوند؛ حتی اگر آن تصمیمها از ابتدا روشن نبوده باشند.
از یک دیزاینسیستم چه انتظاری دارم؟
برای من، کتابخانه باید کمک کند کامپوننت موردنیازم را پیدا کنم. دیزاینسیستم باید جواب سؤالهای بعدی را هم داشته باشد: این کامپوننت برای این موقعیت مناسب است؟ چه بخشهایی از آن را میتوانم تغییر بدهم؟ وقتی کاربر با آن کار میکند چه اتفاقی باید بیفتد؟
مثلاً برای یک فیلد ورودی، دانستن ارتفاع و رنگ کادر کافی نیست. باید تکلیف عنوان، متن راهنما، آیکنها و نحوهٔ نمایش خطا مشخص باشد. باید بدانم کدام بخشها ثابتاند و کدام بخشها میتوانند با توجه به کاربرد تغییر کنند.
این تصمیمها به پیادهسازی هم میرسند. حالت فوکوسی که در فیگما طراحی میکنیم، باید در محصول هم درست نمایش داده شود. اسم یک کامپوننت باید برای طراح و توسعهدهنده به یک چیز اشاره کند. اگر نیاز تازهای پیش آمد، باید مشخص باشد چه کسی آن را بررسی میکند و چطور به کتابخانه اضافه میشود.
بهنظرم بخش اصلی کار همینجاست: تصمیمهای تکراری را آنقدر روشن کنیم که استفاده از کتابخانه به حضور سازندهاش وابسته نباشد.
هر تفاوت باید دلیل مشخصی داشته باشد
قرار نیست همهٔ کامپوننتها یکشکل و هماندازه باشند. ممکن است در یک موقعیت به فیلدی جمعوجور نیاز داشته باشیم و در موقعیتی دیگر به فیلدی با فضای بیشتر.
اما باید مشخص باشد هر کدام برای چه نیازی ساخته شده و چه زمانی باید انتخاب شود.
در نمونهٔ رایتل، یکی از فیلدها حدود یکچهارم بلندتر بود، ولی هر دو اسم یکسانی داشتند. نام و توضیحاتشان کمکی به انتخاب نمیکرد. قبل از اینکه هر دو اندازه را در کتابخانه نگه دارم، باید میفهمیدم آیا واقعاً به هر دو نیاز داریم.
قاعدهای که برای بررسی داشتم این بود: اگر تفاوت از یک نیاز واقعی میآید، آن را حفظ کن و کاربردش را روشن بنویس. اگر دلیل مشخصی پیدا نمیکنی، بررسی کن این تفاوت از کجا آمده و آیا باید در نسخهٔ بعد هم باقی بماند.
یکدستسازی عجولانه هم میتواند مشکل درست کند. ممکن است چیزی را حذف کنیم که یک صفحه یا جریان خاص واقعاً به آن نیاز دارد. برای همین، اول باید دلیل تفاوتها را بفهمیم و بعد دربارهٔ حفظ، ادغام یا حذفشان تصمیم بگیریم.
انتخابها باید داخل خود فیگما مشخص باشند
شناخت ساختار کامپوننتهای متریال به کارم در نسخهٔ جدید جهت داد. روی ساختار اجزا، تنظیمات قابلتغییر، نسخههای مختلف هر کامپوننت، حالتهای تعامل و راهنمای استفاده کار کردم تا انتخابها برای طراح روشنتر باشند.
برای فیلدهای ورودی، این کار شامل سازماندهی مدلهای Filled و Outlined، عنوان، متن ورودی، آیکنها و حالتهای مختلف بود. باید مشخص میشد هر گزینه چه کاری انجام میدهد و چطور میتوان آن را تغییر داد.
برای کامپوننتهایی که بهخاطر نیاز محصول اضافه میکردیم هم همین بررسی لازم بود. ممکن بود یک کامپوننت مشکل یک صفحه را حل کند، ولی برای استفاده در صفحههای دیگر هنوز به اصلاح نیاز داشته باشد.
این تصمیمها باید همانجایی در دسترس باشند که طراح کار میکند. اگر میتوان به ابتدای فیلد آیکن اضافه کرد، این امکان باید در تنظیمات کامپوننت پیدا شود. اگر دو ظاهر متفاوت برای دو کاربرد متفاوت داریم، راهنما باید توضیح بدهد چه زمانی از هر کدام استفاده کنیم.
در نسخهٔ جدید فیلدها، مدلهای ظاهری، حالتهای تعامل، تم روشن و تیره و تنظیمات محتوا در یک ساختار مشترک قرار گرفتند تا برای هر تغییر کوچک، نیازی به ساختن نسخهای جدا نباشد.
برای شروع، یک کامپوننت را بررسی کن
یک کامپوننت انتخاب کن که در چند صفحهٔ فعال استفاده شده باشد. نمونههای داخل صفحهها را کنار نسخهٔ اصلی کتابخانه بگذار و این سؤالها را بپرس:
- بدون پرسیدن از سازنده، میتوانم بفهمم کدام نسخه را باید استفاده کنم؟
- تفاوتها از نیازهای متفاوت آمدهاند یا از تصمیمهای جداگانهٔ طراحان؟
- اگر کتابخانه بر پایهٔ یک سیستم آماده ساخته شده، کامپوننتهایی که خودمان اضافه کردهایم هم قواعد آن را رعایت میکنند؟
- با تنظیمات موجود میتوانم محتوا و حالتهایی را که صفحه نیاز دارد، نمایش بدهم؟
- اگر کامپوننت چیزی را که برای طراحی صفحه لازم دارم نداشته باشد، میدانم با چه کسی دربارهٔ اضافهکردنش صحبت کنم؟
اگر هر ابهام را کنار نمونهٔ کامپوننت و صفحهای که در آن استفاده شده ثبت کنی، میدانی چه مسئلهای را باید حل کنی؛ بعد میتوانی سراغ اصلاح کتابخانه بروی.
در قسمت بعد، «قبل از ساختن، ببین چه چیزهایی از قبل داری»، همین بررسی را جلو میبریم: چطور نمونهها را از صفحهها و کتابخانه جمع کنیم، بر اساس کاربرد دستهبندی کنیم و تصمیم بگیریم کدام مشکل را زودتر حل کنیم.