تیم تحریریه LOXX
طراحی دیزاین سیستم سایت زمانی ضروری می‌شود که تصمیم‌های مشابه بارها با پاسخ‌های متفاوت تکرار شوند. یک فرم دکمه آبی دارد، فرم دیگر سبز است و پیام خطا در هر صفحه لحن متفاوتی پیدا می‌کند. مسئله فقط ظاهر نیست؛ کاربر مجبور می‌شود الگوی تعامل را دوباره یاد بگیرد و تیم برای تغییر کوچک چند محل را اصلاح کند. سیستم طراحی باید این تصمیم‌های مشترک را روشن کند، اما اندازه آن باید متناسب با محصول و توان نگهداری تیم باشد.
از موجودی اجزای واقعی شروع کنید
پیش از طراحی کتابخانه تازه، صفحات موجود یا طرح‌های تأییدشده را بررسی کنید. دکمه‌ها، ورودی‌ها، کارت‌ها، جدول‌ها و پیام‌ها را کنار هم بگذارید. تفاوت‌های دارای دلیل را از تفاوت‌های اتفاقی جدا کنید. دکمه حذف و دکمه ادامه نباید صرفاً برای یکسان شدن ظاهر، معنای یکسان پیدا کنند. تعداد دفعات استفاده و اثر هر جزء بر جریان اصلی را ثبت کنید. برای شروع، چند جزء پرکاربرد را انتخاب کنید؛ ساخت ده‌ها جزء بدون مصرف واقعی فقط هزینه مستندسازی و هماهنگی ایجاد می‌کند.
قواعد پایه را به کاربردشان وصل کنید
رنگ‌ها را با نقش تعریف کنید: متن اصلی، متن کمکی، خطا، سطح و اقدام اصلی. نام رنگ به تنهایی توضیح نمی‌دهد کجا باید استفاده شود. برای اندازه متن، فاصله و گوشه‌ها نیز مجموعه محدودی انتخاب کنید که در صفحه واقعی جواب بدهد. فارسی، اعداد، واحد پول و عبارت لاتین را در همان نمونه‌ها امتحان کنید. فونتی که در عنوان کوتاه مناسب است ممکن است در جدول متراکم خوانایی خوبی نداشته باشد. قواعد باید امکان تصمیم گرفتن بدهند، نه اینکه برای هر استثنا تیم را مجبور به حدس زدن کنند.
هر جزء به رفتار و محتوا نیاز دارد
برای ورودی، فقط کادر عادی را نکشید. عنوان فیلد، راهنما، مقدار واردشده، خطا، غیرفعال بودن و نمایش روی موبایل را مشخص کنید. دکمه دارای انتظار باید جلوی ارسال تکراری را مطابق منطق محصول بگیرد و نتیجه را قابل فهم نگه دارد. درباره متن هم قاعده بنویسید: نام اقدام باید نتیجه آن را توصیف کند، پیام خطا باید راه اصلاح داشته باشد و علامت الزامی بودن فیلد توضیح داده شود. رفتار پیچیده را با یک مثال واقعی نشان دهید؛ تصویر ثابت همیشه برای انتقال تصمیم کافی نیست.
مثال فرضی: یکسان کردن جدول‌های پنل
در یک مثال فرضی، تیم فروشگاه سه جدول برای سفارش، مشتری و موجودی دارد. طراح ابتدا نیاز مشترک جست‌وجو، صفحه‌بندی و حالت بدون نتیجه را استخراج می‌کند. سپس تفاوت‌ها را حفظ می‌کند: سفارش به وضعیت پرداخت نیاز دارد و موجودی به آستانه هشدار. اجبار همه جدول‌ها به یک شکل ثابت، اطلاعات مهم را پنهان می‌کند. نتیجه مناسب، پوسته و رفتار مشترک با ستون‌های متناسب است. قبل از تعمیم، یک جدول در کد اجرا و با داده طولانی بررسی می‌شود تا فاصله میان نمونه طراحی و محصول واقعی آشکار شود.
نگهداری را از روز اول تعریف کنید
مشخص کنید چه کسی می‌تواند جزء تازه اضافه کند و تغییر چگونه بررسی می‌شود. اگر فایل طراحی و کتابخانه کد مستقل تغییر کنند، نام مشترک آن‌ها تضمین هماهنگی نیست. برای تغییر اثرگذار، صفحه‌های مصرف‌کننده و روش انتقال را ثبت کنید. گاهی یک اصلاح باید تدریجی منتشر شود تا فرم‌های حساس مختل نشوند. نسخه اولیه سیستم می‌تواند ساده باشد: فهرست اجزا، قواعد پایه، نمونه مصرف و ثبت تغییرات. ابزار پیچیده بدون مالک مشخص، معمولاً پس از چند دور توسعه از واقعیت محصول عقب می‌ماند.
چک‌لیست سیستم قابل استفاده
- هر جزء نمونه واقعی و دلیل استفاده دارد.
- حالت عادی، خطا، انتظار و غیرفعال تعریف شده‌اند.
- قواعد متن فارسی و داده طولانی آزمایش شده‌اند.
- نام و رفتار جزء در طراحی و کد هماهنگ است.
- مسئول تغییر، بازبینی و به‌روزرسانی مستند مشخص است.
برای تصمیم‌های قبل از ساخت اجزا، راهنمای طراحی UI UX را ببینید. برای استفاده روزمره تیم، طراحی پنل مدیریت نمونه مکملی است. محدوده خدمات طراحی رابط می‌تواند از چند جزء پایه تا مستندات یک محصول چندجریانی متناسب با نیاز شما تعریف شود.
این راهنما برای تصمیم‌گیری اولیه نوشته شده است. محدوده، زمان و قیمت هر پروژه پس از بررسی نیاز مشخص می‌شود. نام LOXX تازه معرفی شده؛ تجربه افراد تیم پیش از این نام شکل گرفته و تنها کارهای مجاز و قابل انتشار نمایش داده می‌شوند.