کارگاه را با یک کار مشخص شروع کنید
برای این کارگاه، یک رابط فرضی رزرو نوبت طراحی می‌کنیم. کاربر باید خدمت را انتخاب کند، زمان آزاد را ببیند و پیش از ثبت، خلاصهٔ انتخابش را بخواند. همین جمله دامنهٔ تمرین را محدود می‌کند. صفحهٔ پرداخت، حساب کاربری و پنل مدیریت در این تمرین نیستند. اگر بدون دامنه شروع کنیم، چند frame زیبا ساخته می‌شود اما مسیر اصلی کاربر ناقص می‌ماند. Figma ابزار طراحی و prototype است؛ روشن کردن مسئله و تصمیم‌های UX مسئولیت تیم باقی می‌ماند.
این مقاله روش انجام تمرین را توضیح می‌دهد و فایل Figma، تصویر یا نتیجهٔ تست واقعی ایجاد نمی‌کند. داده‌ها و خدمت نمونه فرضی‌اند و باید در پروژهٔ واقعی با اطلاعات معتبر جایگزین شوند. Prototype هم برنامهٔ متصل به سیستم رزرو نیست؛ ظرفیت، احراز هویت و ثبت درخواست را شبیه‌سازی می‌کند. این مرز را از ابتدا در brief بنویسید تا کسی از دیدن مسیر قابل کلیک، آماده بودن محصول برای استفادهٔ واقعی را نتیجه نگیرد.
Brief و فرض‌ها را در فایل قابل پیدا کردن نگه دارید
یک صفحهٔ Brief بسازید و هدف، مخاطب و مسیر اصلی را کوتاه ثبت کنید. فرض این تمرین این است که کاربر با تلفن وارد می‌شود و یک نوبت می‌خواهد. مشخص کنید کدام پرسش‌ها هنوز پاسخ ندارند: آیا خدمت‌ها زمان برابر دارند؟ آیا کاربر می‌تواند نوبت را لغو کند؟ آیا شمارهٔ تماس لازم است؟ پاسخ فرضی را با واقعیت تأییدشده مخلوط نکنید. این یادداشت‌ها بعداً کمک می‌کنند دلیل یک field یا مرحله قابل دنبال کردن باشد.
صفحه‌های Flow، Components و Screens را جدا نام‌گذاری کنید. هدف جداسازی، پیدا کردن مسئولیت‌هاست و تعداد صفحه‌ها قانون ثابت نیست. در Flow ارتباط مرحله‌ها و مسیر برگشت را نشان دهید. در Components کنترل‌های مشترک و حالت‌ها قرار می‌گیرند. Screens نسخه‌های مسیر اصلی را نگه می‌دارد. از اسم‌هایی مثل final و final-new برای تشخیص نسخه استفاده نکنید؛ نام مرحله و وضعیت طراحی روشن‌تر است. تغییر فرض دامنه باید در brief هم ثبت شود، نه فقط در frame تازه.
Wireframe ترتیب اطلاعات را مشخص می‌کند
برای سه مرحلهٔ اصلی، ابتدا wireframe ساده بسازید. مرحلهٔ انتخاب خدمت عنوان واضح، توضیح کوتاه و گزینه‌ها دارد. مرحلهٔ زمان، تاریخ و زمان‌های قابل انتخاب را نشان می‌دهد. خلاصه، نام خدمت، زمان و راه برگشت برای اصلاح انتخاب را دارد. پیش از رنگ و سایه، معلوم شود کدام اطلاعات برای تصمیم لازم است. حذف label برای زیباتر شدن فرم، مسئلهٔ wireframe را حل نمی‌کند. متن دکمه باید مرحلهٔ بعد را قابل فهم کند.
یک مسیر ناموفق هم اضافه کنید: برای تاریخ انتخابی زمان آزاد نیست. کاربر باید راه انتخاب تاریخ دیگر داشته باشد، نه یک بن‌بست بی‌توضیح. انتخاب زمان گذشته یا از دست رفتن ظرفیت نیز در محصول واقعی قواعد دامنه می‌خواهد. در تمرین، فقط وضعیت خالی را با دادهٔ فرضی نشان می‌دهیم. همین محدودیت را کنار frame یادداشت کنید. اگر همهٔ صفحه‌ها فقط حالت موفق دارند، prototype بخشی از تجربه را پنهان می‌کند و تصمیم دربارهٔ خطا به مرحلهٔ اجرا موکول می‌شود.
Auto Layout رابطه را تعریف می‌کند
به جای جابه‌جایی دستی هر کنترل، گروه‌های دارای رابطه را با Auto Layout بسازید. در فرم، label و field رابطهٔ نزدیک دارند و بخش‌های مختلف فاصلهٔ بزرگ‌تری می‌خواهند. برای دکمه، padding و رفتار اندازه را تعریف کنید تا تغییر متن شکل را خراب نکند. Hug contents و Fill container معناهای متفاوت دارند و باید مطابق نقش انتخاب شوند. راهنمای Auto Layout رفتارهای فعلی را شرح می‌دهد.
Auto Layout به تنهایی responsive بودن سایت نهایی را تضمین نمی‌کند. ترتیب layer، min و max اندازه و رفتار محتوا باید درست باشد و بعد به قرارداد layout در کد ترجمه شود. برای عنوان طولانی و چندخطی جا بگذارید و ارتفاع ثابت بی‌دلیل ندهید. frame را باریک‌تر کنید و ببینید کدام رابطه نیاز به تصمیم تازه دارد. این کار بخشی از تمرین طراحی است و با تأیید اجرای مرورگر فرق دارد. مدل Figma همهٔ محدودیت‌های CSS را دقیقاً شبیه‌سازی نمی‌کند.
Typography و tokenها را از نقش انتخاب کنید
برای عنوان صفحه، عنوان بخش، متن توضیح و label نقش‌های مشخص بسازید. اندازه و line-height را بر اساس خوانایی و تراکم محتوا انتخاب کنید، نه فقط تفاوت نمایشی. یک text style مشترک به اصلاح منظم کمک می‌کند. راهنمای Text Styles ساخت و مصرف آن‌ها را توضیح می‌دهد. متن واقعی فارسی و عددهای واقعیِ فرض تمرین را استفاده کنید تا طول محتوا در تصمیم دیده شود.
رنگ و فاصلهٔ مشترک می‌توانند در variables و collectionهای نام‌دار ثبت شوند. نام semantic مثل رنگ متن اصلی یا سطح خطا از نام صرفاً عددی رنگ قابل فهم‌تر است. Modeها هم باید نیاز واقعی، مثل تفاوت theme، را پاسخ دهند. راهنمای Variables این قرارداد را معرفی می‌کند. داشتن variable به تنهایی design system کامل ایجاد نمی‌کند؛ روش مصرف و حالت‌های component باید ثبت شوند.
Component را با حالت‌های لازم تعریف کنید
دکمه و گزینهٔ زمان را به component تبدیل کنید. برای گزینهٔ زمان، default، selected و unavailable نیازهای روشن‌اند. نام property باید معنی حالت را بگوید. ساخت تمام ترکیب‌های ممکن قبل از شناخت مصرف‌کننده می‌تواند مجموعه را بزرگ و مبهم کند. راهنمای Variants روش گروه‌بندی حالت‌ها را توضیح می‌دهد. Instance در صفحه باید از قرارداد همان component استفاده کند تا اصلاح مشترک قابل کنترل باشد.
Unavailable با selected فقط رنگ متفاوت نیست. کاربر باید بفهمد کدام گزینه قابل انتخاب است و کدام انتخاب فعلی است. برای کنترل‌های واقعی، وضعیت focus و تعامل keyboard هم در handoff لازم است؛ ممکن است در prototype کوتاه همهٔ آن‌ها اجرا نشوند، اما نباید فراموش شوند. اگر حالت خطا دارید، پیام باید راه اصلاح را بگوید. نوشتهٔ دسترس‌پذیری از روز اول کمک می‌کند طراحی component کنار معنای HTML و رفتار تعامل بماند.
Prototype یک روایت قابل کلیک می‌سازد
برای مسیر اصلی، یک نقطهٔ شروع روشن تعیین کنید. انتخاب خدمت به مرحلهٔ زمان، انتخاب زمان به خلاصه و دکمهٔ اصلاح به مرحلهٔ مربوط وصل می‌شود. Transition کوتاه می‌تواند تغییر مرحله را توضیح دهد؛ جلوهٔ پیچیده برای این تمرین لازم نیست. راهنمای Prototype در Figma تعریف ارتباط و flow را بیان می‌کند. Prototype خوب باید مسیر و فرض‌ها را قابل گفتگو کند، نه اینکه قابلیت‌های نمایش را به رخ بکشد.
اگر state فقط با چند frame شبیه‌سازی شده است، معلوم کنید کدام ترکیب انتخاب‌ها واقعاً در تمرین پوشش دارد. یک دکمهٔ ثبت که همیشه به پیام موفق می‌رود، شاهد ثبت نوبت نیست. دریافت خطای server و هم‌زمانی ظرفیت در این prototype پیاده نشده است. اگر از variable یا conditional interaction استفاده می‌کنید، قرارداد و محدودهٔ آن را هم بنویسید. تلاش برای شبیه‌سازی تمام backend در فایل طراحی می‌تواند از هدف بررسی مسیر اصلی دور شود.
متن رابط بخشی از تمرین است
در خلاصه، تاریخ و زمان را با شکل قابل فهم نمایش دهید و واحدها را روشن نگه دارید. «ادامه» برای همهٔ مرحله‌ها ممکن است مبهم باشد؛ «انتخاب زمان» یا «بررسی نوبت» مقصد را بهتر بیان می‌کند. پیام خالی باید بگوید چه اتفاقی افتاده و کار بعدی چیست. از متن تبلیغاتی در محل خطا استفاده نکنید. اگر اطلاعات تماس لازم است، دلیل درخواست آن را کوتاه توضیح دهید. متن خوب جلوی چند حدس کاربر را می‌گیرد و فضای interface را واقعی‌تر می‌کند.
در صفحهٔ فارسی، جهت layout، رقم و قطعهٔ لاتین را جدا در نظر بگیرید. نام یا ایمیل طولانی می‌تواند layout را عوض کند. شکل یک screenshot ثابت، رفتار همهٔ داده‌ها را نشان نمی‌دهد. مقالهٔ RTL و Logical Properties برای ترجمهٔ این تصمیم به کد مفید است. فاصلهٔ دکمه و label هم باید بر اساس ساختار واقعی محتوا باشد، نه فقط تراز ظاهری در یک frame.
برای بازبینی، کار بدهید و راه‌حل را نگویید
در بررسی بعدی می‌توان از فرد خواست یک نوبت فرضی انتخاب کند و پیش از ثبت زمان را تغییر دهد. متن task نباید نام دکمهٔ درست را لو بدهد. مشاهده کنید کجا مکث می‌کند، چه چیزی را اشتباه می‌فهمد و آیا مسیر برگشت را پیدا می‌کند. یادداشت‌ها باید رفتار دیده‌شده را از برداشت طراح جدا کنند. این مقاله چنین جلسه‌ای برگزار نکرده و نرخ موفقیت یا نتیجهٔ کاربران گزارش نمی‌کند؛ روش تمرین برای پروژهٔ بعدی ارائه شده است.
بعد از بازبینی، اصلاح را به مسئلهٔ مشخص وصل کنید. اگر عنوان گزینه نامفهوم بود، تغییر سایهٔ کارت پاسخ آن نیست. اگر کاربر مرحلهٔ خلاصه را با تأیید نهایی اشتباه گرفت، متن و hierarchy نیاز به بازبینی دارند. نسخهٔ اصلاح‌شده را با دلیل کوتاه در فایل ثبت کنید. تغییرهای زیاد و هم‌زمان بدون ارتباط با مشاهده، فهم اثر اصلاح را سخت می‌کند. تست کوچک هم دربارهٔ مخاطب‌های محدود خود شاهد می‌دهد و نباید نتیجهٔ عمومی همهٔ کاربران معرفی شود.
Handoff باید رفتار را هم منتقل کند
کنار screenها، حالت خالی، خطا، محدودیت متن و رفتار اندازه را مشخص کنید. اندازهٔ آیکون با محدودهٔ clickable یکسان نیست؛ مقالهٔ اصول طراحی آیکون این فرق را توضیح می‌دهد. همچنین loading و غیرفعال شدن کنترل هنگام درخواست باید در قرارداد باشد. نوشتهٔ وضعیت بارگذاری این بخش را ادامه می‌دهد. توسعه‌دهنده نباید تمام رفتار پنهان را از یک frame موفق حدس بزند.
برای انتقال به کد، Figma Dev Mode ابزار مشاهدهٔ مشخصات است و جای گفت‌وگوی رفتار را نمی‌گیرد. در پایان تمرین باید مسیر انتخاب، حالت‌های لازم و قرارداد component قابل پیدا کردن باشند. اگر یک جزئیات هنوز تصمیم ندارد، آن را باز ثبت کنید و به عنوان تصمیم قطعی تحویل ندهید. خروجی مفید کارگاه، مجموعه‌ای از تصمیم‌های قابل دنبال کردن است که prototype آن‌ها را نشان می‌دهد؛ تعداد frameها معیار کامل بودن تجربه نیست.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!