کاربر با تلفن وارد فرم درخواست می‌شود، چند فیلد را پر می‌کند و با باز شدن صفحه‌کلید، دکمه ثبت از دید خارج می‌شود. این مسئله با کوچک کردن طرح دسکتاپ حل نمی‌شود. طراحی موبایل‌نخست یعنی مسیر اصلی کار را از ابتدا با محدودیت فضا، ورودی و ارتباط در نظر بگیرید؛ سپس آن را برای صفحه‌های بزرگ‌تر گسترش دهید. هدف، شبیه شدن ظاهر سایت به یک اپ بومی نیست. کاربر باید بتواند کارش را بفهمد و انجام دهد.
در این راهنما، یک وب‌اپ فرضی ثبت درخواست را دنبال می‌کنیم. مثال‌ها دستور همگانی برای همه محصول‌ها نیستند؛ فرم بانکی، فروشگاه و پنل مدیریتی ممکن است نیازهای متفاوتی داشته باشند. درصد ترافیک موبایل را نیز نباید بدون داده به همه سایت‌ها نسبت داد. برای تصمیم محصول، دستگاه‌ها و مسیرهای واقعی کاربران خودتان را بررسی کنید و دلیل هر تغییر را به همان نیاز وصل کنید.
موبایل‌نخست با حذف امکانات فرق دارد
از مهم‌ترین کاری که کاربر باید انجام دهد شروع کنید. در سامانه فرضی، او باید نوع درخواست را انتخاب کند، اطلاعات لازم را بدهد و نتیجه ثبت را ببیند. این مسیر نباید زیر مقدمه بلند، کارت‌های تبلیغاتی یا چند دکمه هم‌ارزش پنهان شود. اولویت محتوا یعنی مشخص کنید چه چیزی در هر مرحله لازم است. اطلاعات تکمیلی می‌تواند در جای مناسب بماند، بدون اینکه از دسترس کاربر حذف شود.
اگر یک قابلیت فقط در دسکتاپ قابل استفاده است، درباره علت آن تصمیم روشن بگیرید. دشوار بودن چیدمان دلیل کافی برای پنهان کردن کار اصلی نیست. ممکن است به مسیر مرحله‌ای، فیلتر ساده‌تر یا نمایش متفاوت داده نیاز داشته باشید. از تیم بپرسید آیا کاربر موبایل واقعاً می‌تواند همان درخواست را کامل کند یا فقط بخشی از صفحه را ببیند. این پرسش به نتیجه کار مربوط است، نه تعداد ستون‌های طرح.
ساختار را بر اساس محتوا گسترش دهید
راهنمای طراحی واکنش‌گرا در web.dev بر سازگاری چیدمان با فضای موجود و انتخاب نقطه تغییر بر اساس محتوا تأکید می‌کند. در عمل، از یک ساختار ساده شروع کنید و وقتی فضا اجازه می‌دهد، بخش‌های مرتبط را کنار هم بگذارید. انتخاب یک عرض صرفاً چون نام یک دستگاه مشهور را دارد، نیاز محتوای شما را توضیح نمی‌دهد. متن طولانی یا زبان متفاوت ممکن است همان چیدمان را زودتر به مشکل برساند.
مثلاً خلاصه درخواست در صفحه باریک می‌تواند زیر فرم باشد و در صفحه گسترده کنار آن قرار بگیرد. ترتیب خواندن و ارتباط دکمه‌ها باید همچنان روشن بماند. برای پیاده‌سازی ساختارهای انعطاف‌پذیر، راهنمای CSS Grid با مثال ادامه مرتبطی است. ابزار چیدمان به‌تنهایی تعیین نمی‌کند کدام بخش اول دیده شود؛ این تصمیم باید پیش از نوشتن سبک‌ها در طراحی مشخص شده باشد.
چگالی صفحه را با کاربر و نوع داده بسنجید
بزرگ بودن همه اجزا همیشه تجربه بهتری نمی‌سازد. در یک فهرست، ممکن است کاربر نیاز داشته باشد چند مورد را با هم مقایسه کند. در فرم حساس، فاصله بیشتر برای تشخیص ورودی‌ها مفید است. هدف، یافتن چگالی مناسب برای همان کار است. بین بخش‌های مستقل فاصله بگذارید و اجزای مرتبط را نزدیک‌تر نگه دارید تا رابطه آن‌ها دیده شود. شلوغی صفحه فقط مسئله زیبایی نیست؛ انتخاب را هم دشوار می‌کند.
در کارت درخواست، عنوان، وضعیت و اقدام اصلی باید از هم قابل تشخیص باشند. اگر هر سه با وزن و رنگ یکسان نمایش داده شوند، کاربر باید برای فهم اولویت بیشتر بخواند. راهنمای فضای خالی در طراحی برای بررسی فاصله و گروه‌بندی مفید است. تغییر چند فاصله باید دلیل مشخص داشته باشد؛ اضافه کردن فضای زیاد بدون توجه به طول صفحه ممکن است اطلاعات مرتبط را از هم دور کند.
ناوبری را با مسیر کار انتخاب کنید
ناوبری پایین صفحه برای هر وب‌اپ لازم نیست. اگر چند مقصد اصلی و پرتکرار دارید، ممکن است این الگو مناسب باشد. اگر کاربر در یک فرایند مرحله‌ای است، دکمه ادامه و مسیر بازگشت می‌توانند مهم‌تر باشند. فهرست مقصدها را از ساختار داخلی شرکت برندارید؛ از کارهایی که کاربر می‌خواهد انجام دهد شروع کنید. نام کوتاه و روشن از آیکون تنها قابل فهم‌تر است، به‌ویژه برای کسی که نخستین بار وارد می‌شود.
ژست‌هایی مثل کشیدن برای حذف یا تازه‌سازی نیز باید مسیر جایگزین روشن داشته باشند. کاربر ممکن است آن ژست را نشناسد یا نتواند انجام دهد. عملیات مهم را پشت رفتار پنهان نگذارید. برای حذف، پیامد و راه برگشت را با توجه به نوع داده مشخص کنید. تقلید یک الگوی اپ بومی بدون بررسی رفتار مرورگر و نیاز دسترسی، می‌تواند به‌جای کوتاه کردن مسیر، مرحله‌های مبهمی بسازد.
هدف لمس، نوشته و فاصله را با هم ببینید
دکمه باید قابل تشخیص و انتخاب باشد. معیار اندازه هدف در WCAG 2.2 برای ورودی اشاره‌گر، حداقل ۲۴ در ۲۴ پیکسل CSS را با استثناهایی از جمله فاصله مناسب و بعضی لینک‌های درون متن توضیح می‌دهد. این عدد را نباید به توصیه‌ای برای کوچک کردن همه دکمه‌ها تبدیل کرد. برای اقدام مهم، اندازه و فاصله‌ای انتخاب کنید که با محتوای برچسب و شرایط استفاده سازگار باشد.
برچسب «ثبت درخواست» از «انجام» روشن‌تر است. وضعیت غیرفعال یا در حال ارسال نیز باید معنای مشخصی داشته باشد. اگر دکمه پس از لمس واکنش قابل مشاهده‌ای ندارد، کاربر ممکن است چند بار آن را فشار دهد. طراحی باید پاسخ تعامل را نشان دهد و منطق برنامه هم درباره ارسال تکراری تصمیم داشته باشد. حل این مسئله تنها با تغییر رنگ دکمه کامل نمی‌شود.
فرم موبایلی را با صفحه‌کلید طراحی کنید
نوع ورودی، برچسب و ترتیب فیلدها باید با اطلاعات مورد نیاز هماهنگ باشد. برای هر فیلد، دلیل دریافت را بدانید؛ اطلاعاتی که در این مرحله استفاده نمی‌شود شاید لازم نباشد همین‌جا پرسیده شود. برچسب قابل مشاهده را با متن داخل ورودی جایگزین نکنید، چون پس از تایپ ممکن است کاربر زمینه را از دست بدهد. توضیح قالب مورد انتظار نیز باید پیش از بروز خطا در جای قابل پیدا کردن باشد.
وقتی صفحه‌کلید باز است، کاربر باید فیلد فعال و پیام مرتبط را ببیند. دکمه ثابت پایین صفحه نباید محتوا یا ورودی را بپوشاند. در فرایند چندمرحله‌ای، بازگشت نباید داده واردشده را بی‌دلیل از بین ببرد. برای فرم طولانی، مرحله‌ها را بر اساس گروه اطلاعات تعریف کنید، نه صرفاً برای کم شدن ارتفاع صفحه. کاربر باید بداند چه چیزی باقی مانده و چگونه می‌تواند یک بخش را اصلاح کند.
خطا باید به اقدام قابل فهم برسد
پس از خطا، داده‌های قابل استفاده را حفظ کنید و محل مشکل را نشان دهید. عبارت «خطا رخ داد» برای اصلاح فیلد کافی نیست. اگر شماره با قالب مورد انتظار سازگار نیست، همان مشکل را توضیح دهید؛ اگر ارتباط قطع شده، کاربر نباید فکر کند اطلاعاتش اشتباه بوده است. خطای اعتبارسنجی و شکست ارسال به سرور رفتار و پیام متفاوتی می‌خواهند. این دو را در طرح حالت‌ها جدا ثبت کنید.
برای هماهنگ کردن قواعد داده و پیام رابط، راهنمای اعتبارسنجی با Zod توضیح می‌دهد چگونه ساختار ورودی و رسیدگی به نتیجه را از هم تفکیک کنید. در طراحی، محل پیام، رابطه آن با فیلد و اقدام بعدی را مشخص کنید. مسئولیت بررسی سرور نیز با داشتن فرم خوب حذف نمی‌شود؛ رابط و سرور باید درباره معنای داده و نتیجه عملیات هماهنگ باشند.
حالت انتظار، نبود داده و قطع ارتباط را رسم کنید
طرح کامل تنها صفحه‌ای با اطلاعات درست و ارتباط سریع نیست. برای انتظار، مشخص کنید چه چیزی در حال انجام است و آیا کاربر باید صبر کند. برای فهرست خالی، تفاوت میان «هنوز درخواست ندارید» و «فیلتر نتیجه‌ای پیدا نکرد» را نشان دهید. در شکست دریافت، مسیر تلاش دوباره یا خروج از فرایند باید روشن باشد. این حالت‌ها از همان آغاز به طراحی صفحه مربوط‌اند.
قابلیت آفلاین را نیز فقط وقتی وعده دهید که رفتار آن تعریف شده باشد. نمایش اطلاعات قبلی با ثبت موفق یک عملیات تازه فرق دارد. اگر درخواست به دلیل نبود ارتباط ارسال نشده، باید وضعیت آن مشخص بماند. ممکن است یک محصول به امکان ذخیره پیش‌نویس نیاز داشته باشد و دیگری تنها پیام واضحی برای تلاش بعدی بخواهد. انتخاب به حساسیت داده و منطق همگام‌سازی وابسته است.
کارایی بخشی از تجربه طراحی است
تصویر بزرگ، فایل اضافی یا انتظار طولانی می‌تواند کار اصلی را به تأخیر بیندازد. برای هر رسانه بپرسید چه اطلاعاتی می‌دهد و در کدام اندازه دیده می‌شود. محتوایی که پایین صفحه لازم است الزاماً نباید مسیر نمایش اطلاعات ضروری بالا را سنگین کند. این تصمیم‌ها باید با توسعه‌دهنده هماهنگ شوند. نسخه موبایل با پنهان کردن ظاهری یک بخش، لزوماً هزینه دریافت یا اجرای آن را کم نمی‌کند.
در گزارش کارایی، شرایط بررسی را روشن کنید: دستگاه، ارتباط، صفحه و عملیات مورد نظر. از یک نتیجه روی رایانه سریع، تجربه همه کاربران را نتیجه نگیرید. اگر تیم نیاز به اولویت‌بندی دارد، نخست مسیرهای پرتکرار و نقاط توقف واقعی را بررسی کند. تغییر فناوری یا قالب صفحه زمانی ارزش دارد که به همان مشکل وصل شود و هزینه تازه‌ای در بخش دیگری ایجاد نکند.
یک مسیر کامل را مبنای بازبینی قرار دهید
برای وب‌اپ فرضی، مسیر انتخاب درخواست، ورود اطلاعات، اصلاح خطا و دیدن تأیید را کنار هم بگذارید. ترتیب خواندن، دکمه بازگشت، حالت صفحه‌کلید و پیام‌ها را در این مسیر مرور کنید. صفحه گسترده باید همین کار را با استفاده مناسب از فضا پشتیبانی کند. طرح را با واژه‌ها و داده‌های واقعی محصول تکمیل کنید؛ متن کوتاه آزمایشی ممکن است مشکل عنوان بلند یا وضعیت نامعمول را پنهان کند.
یادداشت تصمیم طراحی را کوتاه نگه دارید: کار اصلی چیست، کدام اطلاعات در هر مرحله لازم است و شکست چگونه به مسیر قابل ادامه برمی‌گردد. اگر این پاسخ‌ها روشن باشند، هم طراح و هم توسعه‌دهنده می‌دانند تغییر بعدی را با چه معیاری بسنجند. موبایل‌نخست از همین تصمیم‌های مشخص ساخته می‌شود؛ مجموعه‌ای از کارت، ناوبری پایین و ژست لمسی به‌تنهایی چنین تجربه‌ای ایجاد نمی‌کند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!