ممکن است فایل دیزاینسیستم مرتب باشد، لایهها اسم داشته باشند و کامپوننتها هم دستهبندی شده باشند، ولی طراح موقع ساختن یک فرم باز نداند کدام نسخه را بردارد. مرتب بودن فایل توضیح نمیدهد چرا یک طراح ارتباط نمونهٔ داخل صفحه را با کامپوننت اصلی قطع کرده یا چرا دو دکمه با کاربرد مشابه، ساختار متفاوتی دارند.
برای پیدا کردن جواب، باید کامپوننتها را در صفحههایی که از آنها استفاده شده هم بررسی کنیم.
در بررسی دیزاینسیستم رایتل، کتابخانهٔ قبلی را کنار نمونههای استفادهشده در محصول گذاشتم. کامپوننتها را بر اساس کاربرد دستهبندی کردم و ساختار، اندازهها، تنظیمات و حالتهایشان را بررسی کردم. مقایسهٔ نمونهٔ داخل صفحه با نسخهٔ اصلی کمک میکرد بفهمم تفاوت دقیقاً کجاست و چه سؤالی باید بپرسم.
ما بهخاطر محدودیت زمان و پیادهسازی از متریال شروع کرده بودیم و برای نیازهای محصول، کامپوننتهای دیگری هم میساختیم. شناخت قواعد متریال کمک میکرد بدانم کامپوننتهای جدید را چطور بسازم. بررسی صفحههای خودمان هم نشان میداد چه نیازهایی هنوز در کتابخانه پاسخ مشخصی ندارند.
از یک کار مشخص در محصول شروع کن
اگر اولین قدم این باشد که «همهٔ صفحهها را جمع کنیم»، ممکن است زمان زیادی صرف جمعآوری شود، بدون اینکه هنوز بدانیم دنبال چه مشکلی هستیم. برای شروع، یکی از کارهایی را انتخاب کن که کاربر در محصول انجام میدهد؛ مثلاً پرکردن و ارسال یک فرم. بعد فیلدها، دکمهها و پیامهای همان فرم را بررسی کن.
در یک صفحهٔ فیگما، نمونههای استفادهشده در فرم را کنار کامپوننتهای اصلی کتابخانه بگذار. لینک صفحهٔ مبدأ را هم نگه دار تا بتوانی محل استفادهٔ هر نمونه را دوباره ببینی. اگر از محصول زنده اسکرینشات گرفتهای، آن را از نمونهٔ فایل طراحی مشخص کن؛ چیزی که در فیگما میبینیم لزوماً همان چیزی نیست که پیاده شده است.
برای هر نمونه، یک یادداشت کوتاه بنویس. مثلاً اگر فیلد شمارهٔ موبایل را بررسی میکنی، مشخص کن:
- این فیلد در کدام فرم استفاده میشود و کاربر چه اطلاعاتی در آن وارد میکند؟
- نمونهٔ داخل صفحه از کدام کامپوننت کتابخانه ساخته شده است؟
- نسبت به نسخهٔ اصلی چه چیزی تغییر کرده است؛ مثلاً ارتفاع، رنگ کادر یا فاصلهٔ متن؟
- برای استفاده در این فرم، چه حالتهایی لازم دارد؛ مثلاً خالی، در حال ورود اطلاعات، شمارهٔ نامعتبر یا غیرفعال؟
بعد وضعیت هر حالت را جدا بنویس. مثلاً «نمایش خطای شمارهٔ نامعتبر در کتابخانه وجود ندارد» با «هنوز بررسی نکردهام که حالت خطا وجود دارد یا نه» فرق دارد. اگر آن قسمت از یادداشت یا جدول را خالی بگذاری، نفر بعدی نمیفهمد چیزی کم است، هنوز بررسی نشده یا اصلاً برای این فرم لازم نیست.
صفحههای قدیمی و کنارگذاشتهشده را جدا نگه دار. آنها ممکن است دلیل یک تصمیم قدیمی را روشن کنند، اما برای اولویتبندی اصلاحات، صفحههایی که هنوز استفاده میشوند معمولاً مهمترند.
کاربرد را مقایسه کن، بعد اسم را
وقتی نامگذاری خودش بخشی از مسئله است، نمیشود فقط بر اساس اسمها دستهبندی کرد. دو کامپوننت همنام ممکن است رفتار متفاوتی داشته باشند و دو کامپوننت با اسمهای متفاوت، یک کار را انجام بدهند.
اول نمونههایی را کنار هم بگذار که کاربرد مشابهی دارند؛ مثلاً فیلدهای ورود اطلاعات، دکمههای انجام کار یا پیامهای خطا. بعد اندازه، ظاهر و رفتار نمونههای هر گروه را با هم مقایسه کن.
در کتابخانهٔ قبلی رایتل، دو مدل فیلد ورودی اندازهای به اسم Large داشتند. ارتفاع یکی ۴۸ پیکسل بود و دیگری ۶۰ پیکسل؛ یعنی حدود یکچهارم بلندتر. اسمشان دلیل این تفاوت را توضیح نمیداد و در نمونههایی که بررسی کرده بودم، کاربرد متفاوتی هم پشت آن نبود.
اگر فقط مینوشتم «فیلدها با هم فرق دارند»، هنوز معلوم نبود چه چیزی باید اصلاح شود. مسئلهٔ دقیق این بود: دو فیلد برای یک نیاز مشابه، با اسم یکسان و ارتفاع متفاوت در دسترساند و طراح نمیداند کدام را انتخاب کند. حالا میشد پرسید: آیا باید ارتفاعشان یکسان شود، یا واقعاً دو کاربرد متفاوت دارند که باید در نام و راهنمای استفاده توضیح داده شود؟
داخل فیگما، لایهبهلایه بررسی کن
ظاهر کامپوننت همهچیز را نشان نمیدهد. داخل فیگما لایهبهلایه بررسی کن و ببین عنوان، متن ورودی، آیکن، متن راهنما و کادر اصلی چطور کنار هم قرار گرفتهاند.
کدام تغییرها را میتوان از پنل Properties انجام داد؟ برای کدام تغییرها باید مستقیماً سراغ لایههای نمونه رفت؟ مثلاً آیا تنظیمی برای نمایش یا مخفیکردن آیکن وجود دارد، یا طراح باید خودش لایهٔ آیکن را پیدا کند و آن را مخفی کند؟
چون پایهٔ کارمان متریال بود، برای شناخت ساختار کامپوننتها و ارتباط لایهها با حالتهای مختلف وقت گذاشتیم. این یادگیری کمک کرد موقع بررسی کامپوننتهای خودمان، فقط به شباهت ظاهری اکتفا نکنم.
در فیگما، تغییر دادن بعضی ویژگیهای یک نمونه بدون تغییر کامپوننت اصلی، Override نام دارد. مثلاً عوضکردن متن دکمه از «ادامه» به «ثبتنام» یک تغییر طبیعی است. پس دیدن Override بهتنهایی نشانهٔ مشکل نیست؛ باید ببینی چه چیزی تغییر کرده و چرا.
اما اگر طراح مجبور شده ارتباط نمونه را با کامپوننت اصلی قطع کند — یعنی آن را Detach کند — دلیلش را بپرس. شاید ساختار فعلی اجازهٔ چیدمان موردنیاز صفحه را نمیداده است. این میتواند نشانهٔ کمبود در کامپوننت باشد، ولی قبل از تصمیم باید نیاز آن صفحه را بفهمی.
بعد بررسی کن کامپوننت هنگام استفاده چه حالتهایی پیدا میکند. برای دکمه، ببین وقتی کاربر با کلید Tab به آن میرسد، آن را فشار میدهد یا دکمه غیرفعال است، ظاهرش چطور تغییر میکند. در نسخهٔ دسکتاپ، حالت قرارگرفتن نشانگر ماوس روی دکمه یا Hover را هم بررسی کن.
برای فیلد ورودی، فقط کادر خالی را نبین. وقتی کاربر چیزی مینویسد، مقدار نامعتبر وارد میکند یا متن راهنما دوخطی میشود، چه اتفاقی میافتد؟ آماده بودن ظاهر اولیهٔ کامپوننت کافی نیست؛ حالتهایی که کاربر در همان صفحه با آنها روبهرو میشود هم باید مشخص باشند.
در دکمههای قدیمی رایتل، شعاع گوشهٔ اندازهٔ Large برابر با ۴ پیکسل بود، ولی Medium شعاع ۱۶ پیکسلی داشت. بعضی حالتهای تعامل هم کامل طراحی نشده بودند. اینها دو مشکل جدا بودند: یکی دربارهٔ قاعدهٔ گردی گوشهها و دیگری دربارهٔ ظاهر دکمه هنگام استفاده. اصلاح یکی، دیگری را حل نمیکرد.
این نمونهها مربوط به کتابخانهٔ رایتل هستند که بررسی کردم؛ موضوع، ایراد در کامپوننتهای اصلی متریال نیست.
کنار هر تصویر، مشکل و قدم بعدی را بنویس
اسکرینشات نشان میدهد چه چیزی دیدهای، اما همیشه دلیل اهمیت آن را توضیح نمیدهد. کنار تصویر یا در یک جدول بنویس مشکل دقیقاً چیست، در کدام صفحه دیده شده و قدم بعدی برای بررسی یا اصلاحش چیست. لینک نمونهٔ فیگما را هم اضافه کن تا دیگران بتوانند همان مورد را پیدا کنند.
جدول زیر یک نمونهٔ آموزشی بر اساس یافتههای رایتل است، نه سند اصلی پروژه. ستون آخر نشان میدهد چطور میتوان از یک مشاهده به یک اقدام مشخص رسید.
| کامپوننت و کاربرد | مشکل مشاهدهشده | بررسی حالتهای مختلف | قدم بعدی |
|---|---|---|---|
| فیلدهای ورود اطلاعات با کاربرد مشابه | دو فیلد با نام Large، یکی با ارتفاع ۴۸ و دیگری ۶۰ پیکسل | این یافته فقط دربارهٔ اندازه است؛ حالتهایی مثل خطا و غیرفعال باید جدا بررسی شوند | دلیل وجود دو ارتفاع را پیدا کن؛ اگر کاربرد یکسان است، اندازه را یکسان کن. اگر کاربرد متفاوت است، نام و توضیح هرکدام را روشن کن |
| دکمههای محصول | شعاع گوشهٔ Large برابر با ۴ و Medium برابر با ۱۶ پیکسل | بعضی حالتهای تعامل طراحی نشدهاند | دلیل تفاوت گوشهها را بررسی کن و بنویس دقیقاً کدام حالتها باید طراحی شوند |
بعد از بررسی، برای هر مورد بنویس چه کاری لازم است. ممکن است کامپوننت درست باشد و فقط توضیح استفادهاش کم باشد. ممکن است دو نسخهٔ تکراری را بتوان ادغام کرد، یا لازم باشد یک حالت جدید به کامپوننت اضافه شود. اگر هنوز دلیل تفاوت روشن نیست، همان سؤال را بنویس و مشخص کن برای جوابش باید با چه کسی صحبت کنی.
برای مثال، شاید یک فیلد کوتاهتر در ردیفهای یک جدول استفاده میشود و ارتفاع بیشتر، جدول را بیش از حد بلند میکند. یا شاید توسعهدهنده برای ساخت بخشی از صفحه از یک ابزار آماده استفاده کرده که تغییر ظاهرش محدودیت داشته است. اینها دلیلهای احتمالیاند؛ باید دربارهٔ همان نمونه از طراح و توسعهدهنده بپرسی. صرف متفاوتبودن ظاهر، دلیل کافی برای حذف یا تغییر آن نیست.
اول مشکلی را حل کن که اثر بیشتری دارد
وقتی زمان محدود است، نمیشود همهٔ موارد را همزمان اصلاح کرد. برای انتخاب نقطهٔ شروع، سه سؤال میپرسم:
- این کامپوننت در چند صفحه استفاده میشود؟ با اصلاحش، چند مورد مشابه بهتر میشود؟
- مشکل چه اثری دارد؟ استفادهٔ کاربر از محصول را سخت میکند، طراح را مجبور به کار تکراری میکند یا فقط یک اختلاف ظاهری است؟
- تغییر چه پیامدهایی دارد؟ کدام صفحهها و بخشهای کد باید همراه با کامپوننت بهروز شوند؟
مثلاً اگر دکمه هنگام فوکوس هیچ نشانهٔ دیداری نداشته باشد، کاربری که با صفحهکلید کار میکند ممکن است نفهمد کدام دکمه انتخاب شده است. رسیدگی به این مشکل از اصلاح یک اختلاف جزئی در گردی گوشههای صفحهای که دیگر استفاده نمیشود، مهمتر است.
اگر طراحها هم برای یک نیاز تکراری مرتب نمونهها را Detach میکنند، ارزش دارد علت را زودتر بررسی کنی. شاید با اضافهکردن یک تنظیم یا اصلاح ساختار کامپوننت، دیگر لازم نباشد هر بار همان تغییر را جداگانه انجام بدهند.
البته تعداد استفاده تنها معیار نیست. دکمهٔ تأیید پرداخت ممکن است فقط در یک صفحه باشد، اما مشکل در آن میتواند جلوی تمامشدن خرید را بگیرد.
چند مورد مهمتر را با توسعهدهنده مرور کن و برای هرکدام مشخص کنید چه چیزی باید اصلاح شود، چه کسی مسئول انجام آن است و نتیجه را در کدام صفحه بررسی میکنید. مثلاً اگر ساختار نمایش خطای فیلد را تغییر میدهید، آن را در فرمی با پیام خطای واقعی و متن چندخطی امتحان کنید.
اصلاح کامپوننت اصلی در فیگما پایان کار نیست. نمونههای استفادهشده در صفحهها را هم بررسی کن تا مطمئن شوی تغییر جدید، چیدمان یا محتوای آنها را به هم نریخته است. بعد نسخهٔ پیادهشده را ببین: آیا همان حالتها و رفتارهای توافقشده را دارد؟
برای شروع اصلاحات، لازم نیست بررسی کل کتابخانه تمام شده باشد. اگر مشکل چند کامپوننت پرکاربرد و راه رسیدگی به آنها روشن است، میتوانی از همانها شروع کنی. موارد نامشخص را با سؤال دقیق و نام کسی که باید پاسخ بدهد نگه دار تا در ادامه فراموش نشوند.
در قسمت بعد، «از مقدار رنگ تا تصمیم طراحی»، سراغ رنگ، فاصله و تایپوگرافی میرویم: چطور برای این انتخابهای تکراری قواعد مشخصی بسازیم و آنها را به شکل توکنهای طراحی نامگذاری کنیم تا کاربرد هرکدام روشن باشد.