دستیار ساخت رابط با اجزا و سبک طراحی موجود
P17
برنامه شروع
رابط محصول با اجزا و تنظیمات فعلی برند، سریع‌تر و هماهنگ‌تر توسعه یابد.
قدم اول
یک فرم جاری، سه جزء و حالت‌های آن را انتخاب کنید؛ نمونه دستی را زمان‌سنجی و معیار نمایش و صفحه‌کلید را مشخص کنید.
- مسئول پیشنهادی
- مسئول طراحی سیستم و مسئول فنی رابط
- معیار نتیجه
- سه جزء در موبایل، تبلت و دسکتاپ درست کار کنند؛ هویت برند، RTL و دسترسی صفحه‌کلید حفظ و زمان تغییر کمتر شود.
ورودی‌های لازم
- کد و اجزای فعلی رابط
- رنگ، فاصله و قواعد برند
- حالت‌های فرم و اندازه‌های صفحه
کمک هوش مصنوعی: تغییر محدود کد را با جزء و تنظیمات موجود پیشنهاد کند؛ تأیید طراحی و دسترس‌پذیری با بازبین رابط باشد.
روش آزمون و ابزارها
مقایسه با روش فعلی
فهرست دستی جزء و حالت، قرارداد API/HTML، توکن‌های نسخه‌دار و صفحه نمونه در پشته فعلی؛ توسعه‌دهنده یک فرم واقعی را با همان اجزا می‌سازد و بازبین طراحی آن را می‌پذیرد.
نمونه آزمون
پیشنهاد: سه جزء واقعی، هرکدام در حالت عادی، خطا، انتظار، خالی و متن بلند، در عرض موبایل/تبلت/دسکتاپ؛ بعد از تنظیم یک جزء، دو جزء دیگر ارزیابی شوند. پشته دوم یک آزمایش جداست.
- زمان فعال تا پذیرش با احتساب توضیح درخواست، تولید، بازبینی و اصلاح
- تعداد جزء تکراری و انحراف از توکن مصوب، به تفکیک عمدی/ناخواسته
- خطای رفتاری و مجوز در حالت‌های آزموده‌شده و نرخ بازکاری
- خطای axe-core و نتیجه دستی صفحه‌کلید، ترتیب خواندن، RTL و متن بلند
معیار پیشنهادی پذیرش
پیشنهاد: هیچ خطای بحرانی رفتار، دسترسی یا صفحه‌کلید باقی نماند؛ طراح همه تفاوت‌های ظاهری را بپذیرد و هزینه کل ساخت از روش دستی کمتر باشد. نمونه محدود مجوز بازطراحی سراسری یا مهاجرت چارچوب نیست.
ابزارهای مرتبط
- Storybook — مرجع قابل اجرای اجزا
- Style Dictionary — تولید توکن کد
- Playwright — آزمون رفتار و نمایش
- axe-core — بررسی خودکار دسترس‌پذیری
- Aider — پیش‌نویس تغییر محدود
منابع فنی
- B08 · Storybook — نمونه مستقل اجزا، آزمون و مستندسازی — README محیط توسعه و مستندسازی جزء مستقل را توضیح می‌دهد؛ README و LICENSE شاخه next با MIT بررسی شدند.
- B09 · Style Dictionary — تبدیل توکن به خروجی چند پلتفرم — README تعریف رنگ و فاصله به‌صورت توکن و تولید خروجی کد را شرح می‌دهد؛ نشانی قدیمی amzn به مخزن جاری اشاره می‌کند؛ LICENSE جاری Apache-2.0 بررسی شد.
- B10 · Playwright — آزمون مرورگر، assertion و trace — README اجرای Chromium/Firefox/WebKit، جداسازی آزمون، assertion قابل انتظار و trace شکست را مستند می‌کند؛ LICENSE Apache-2.0 خوانده شد.
- B11 · axe-core — موتور بررسی خودکار بخشی از دسترس‌پذیری — README قواعد HTML و موارد نیازمند بازبینی دستی را مشخص می‌کند؛ LICENSE از نوع MPL-2.0 بررسی شد.
- B12 · Aider — تغییر کد و کنترل رفتار Git — README کمک تغییر کد و اتصال مدل را معرفی می‌کند؛ LICENSE.txt با Apache-2.0 و راهنمای رسمی https://aider.chat/docs/git.html بررسی شدند. راهنما خاموش کردن auto-commits و dirty-commits را مستند می‌کند.
جزئیات پروژه و منابع
این پروژه چه کمکی به کار روزانه می‌کند؟
یک مثال فرضی: طراح می‌خواهد فرم جدیدی بسازد که شبیه بقیه محصول باشد. دستیار از دکمه‌ها، رنگ‌ها و فرم‌های موجود استفاده می‌کند.
برای شروع، چه چیزی آماده می‌شود؟
پیش‌نویس فرم ثبت‌نام با ظاهر فعلی محصول، نمایش موبایل، حالت انتظار و پیام خطای شماره نامعتبر آماده می‌شود.
در مرحله بعد، چه می‌توان اضافه کرد؟
الگوهای تأییدشده ذخیره می‌شوند و در تغییر بعدی تفاوت ناخواسته ظاهر صفحه مشخص می‌شود.
تحویل فقط تصویر نیست؛ فرم باید با صفحه‌کلید، متن فارسی و خطاهای واقعی هم درست کار کند.
مراحل پیشنهادی کار
- مرحله ۱
اجزای رابط و تنظیمات طراحی تأییدشده
اجزای فعلی رابط، رنگ‌ها و فاصله‌های برند و کاری را که کاربر باید انجام دهد مشخص می‌کنیم.
- مرحله ۲
پیشنهاد چیدمان رابط کاربری
مدل چیدمان یا ساختار اولیه صفحه را با همان اجزا پیشنهاد می‌دهد.
- مرحله ۳
بررسی طراحی و نمایش راست‌به‌چپ
تیم طراحی ساختار، متن فارسی و نمایش راست‌به‌چپ را تأیید می‌کند.
- مرحله ۴
تغییر محدود کد
تیم فنی فقط تغییر لازم را در کد پیاده می‌کند و آن را برای بازبینی نشان می‌دهد.
- مرحله ۵
آزمون حالت‌ها و اندازه‌ها
حالت عادی، انتظار و خطا را در اندازه‌های مختلف صفحه آزمایش می‌کنیم.
زمان، درستی خروجی و فایده کار را بسنجیم
۱. زمان و هزینه انجام کار
زمان تحویل جزء تا پذیرش
۲. کیفیت و اعتبار
انحراف توکن/RTL و باگ حالت خالی/خطا
۳. فایده و نتیجه اقتصادی
نرخ تکمیل کاربر در مسیر مورد نظر کاربر؛ اثر درآمد وابسته به کاربرد
توضیحات بیشتر برای اجرا و بررسی نتیجه
این کار کجا ثبت می‌شود؟
تیمیک: کار رابط کاربری با نام جزء، حالت صفحه، برند و شرایط تأیید نتیجه؛ کد و تنظیمات طراحی مرجع اصلی‌اند؛ تصویر تولیدشده با مدل جای آن‌ها را نمی‌گیرد
هر مرحله را چه کسی انجام می‌دهد و به چه کسی تحویل می‌دهد؟
- ۱
تیم محصول هدف و حالت
- ۲
طراحی قرارداد جزء
- ۳
فنی پیاده‌سازی
- ۴
بازبین UX و دسترس‌پذیری
تیم محصول کاربرد و حالت‌های صفحه را مشخص می‌کند؛ طراحی شکل و رفتار هر جزء را تعیین می‌کند؛ تیم فنی آن را می‌سازد؛ بازبین تجربه کاربری و دسترس‌پذیری نتیجه را بررسی می‌کند
از کجا بفهمیم آزمون اولیه موفق بوده است؟
سه جزء واقعی در موبایل/تبلت/دسکتاپ؛ ظاهر روشن ریبکس مطابق تصمیم محصول حفظ شود؛ داده و مجوز برای تطابق ظاهری تغییر نکند.
چه زمانی باید کار را متوقف کنیم؟
تولید جزء تکراری یا بازطراحی همه برندها به یک سبک رد شود؛ تصویر زیبا شاهد اجرای درست نیست.
چه کارهای دیگری می‌توان به این پروژه اضافه کرد؟ 1 مورد
کنترل RTL و حالت خطا
اجزا با متن بلند، خطا و اندازه موبایل بررسی شوند.
برای شروع چه لازم است و بعد چه می‌کنیم؟
چه چیزهایی باید آماده باشد؟
این موارد باید از پروژه‌های مرتبط آماده شوند؛ کامل‌شدن همه امکانات آن پروژه‌ها لازم نیست.
- P03؛ دیدن پروژه مرتبط
برای هر کار، مسئله، مسئول، موعد و نشانه تحویل درست نوشته شود؛ مثلاً «فرم با شماره آزمون ثبت‌نام را کامل کند».
- P20؛ دیدن پروژه مرتبط
مسیرهای مهم کاربر و حساب‌ها و داده‌های آزمایشی آماده باشند؛ مثلاً خرید با پرداخت آزمایشی.
مراحل پیشنهادی اجرا و توسعه
این مراحل برنامه پیشنهادی‌اند؛ انجام‌شدن آن‌ها هنوز تأیید نشده است.
- مرحله ۱جمع‌کردن اجزا
دکمه و فرم تأییدشده محصول را مشخص کنید.
- مرحله ۲ساخت صفحه نمونه
فرم جدید را با همان اجزا و حالت خطا و انتظار بسازید.
- مرحله ۳بررسی تحویل
رنگ‌ها و فاصله‌ها، خوانایی متن فارسی، کار با صفحه‌کلید و نمایش در موبایل را بررسی کنید.