طراحی UI موبایل؛ اندازه لمس، ناوبری و فرم

اگر می‌پرسید طراحی UI موبایل دقیقاً چه فرقی با کوچک‌کردن نسخه دسکتاپ دارد، پاسخ در شیوه استفاده است: کاربر با انگشت، روی صفحه‌ای کوچک، اغلب با یک دست و در شرایطی پر از حواس‌پرتی کار می‌کند. بنابراین اندازه هدف لمس، جای دکمه اصلی، ناوبری، کیبورد، بازخورد و وضعیت خطا باید از ابتدا برای موبایل تصمیم‌گیری شوند؛ نه اینکه در پایان پروژه با چند breakpoint اصلاح شوند.

در بررسی Google Suggest برای عبارت اصلی، «طراحی رابط کاربری موبایل» به‌عنوان عبارت نزدیک نمایش داده شد. این مقاله همان نیت اطلاعاتی را پوشش می‌دهد و وارد نیت تجاری «طراحی اپلیکیشن» یا «هزینه طراحی اپ» نمی‌شود؛ آن موضوع‌ها به‌ترتیب در صفحه طراحی اپلیکیشن روبینش و راهنمای هزینه طراحی اپلیکیشن قرار دارند. اینجا تمرکز فقط روی قواعد اجرایی رابط موبایل، از لمس تا تحویل به توسعه‌دهنده است.

Controls should be large enough and spaced far enough apart to make interaction easy and prevent accidental taps.

طراحی رابط کاربری موبایل از کجا شروع می‌شود؟

طراحی رابط کاربری موبایل با انتخاب رنگ یا ساخت کارت شروع نمی‌شود. ابتدا باید کار اصلی هر صفحه را در یک جمله بنویسید: «کاربر اینجا نوبت را انتخاب می‌کند»، «این صفحه مبلغ را تأیید می‌کند» یا «کاربر وضعیت سفارش را می‌بیند». اگر یک صفحه سه کار هم‌ارزش داشته باشد، روی نمایشگر کوچک هیچ‌کدام به اندازه کافی دیده نمی‌شود. نقشه مسیر را پیش از UI در راهنمای یوزر فلو مشخص کنید تا صفحه‌ها از روی عادت ساخته نشوند.

بعد، همان مسیر را روی گوشی واقعی آزمایش کنید. قاب موبایل در Figma تنها عرض را نشان می‌دهد؛ نور محیط، حرکت دست، بازشدن کیبورد، اینترنت کند و اعلان‌های سیستم را شبیه‌سازی نمی‌کند. یک نمونه قابل کلیک بسازید، آن را روی دستگاه باز کنید و ببینید کاربر بدون توضیح طراح به مقصد می‌رسد یا نه. هدف این مرحله پیدا کردن اصطکاک است، نه گرفتن تأیید برای ظاهر زیبا.

اندازه Touch Target چقدر باشد؟

هدف لمس فقط شکل قابل‌دیدن آیکون نیست؛ فضای تعاملی اطراف آن هم جزو هدف است. آیکون ۲۴ پیکسلی می‌تواند داخل ناحیه لمسی بزرگ‌تر قرار بگیرد. برای طراحی عملی، هدف‌های مهم را حدود ۴۴ تا ۴۸ پیکسل در نظر بگیرید و میان دو اقدام حساس فاصله کافی بگذارید. عدد دقیق به راهنمای پلتفرم و مقیاس رابط بستگی دارد، اما اصل ثابت است: کاربر نباید برای زدن دکمه زوم کند یا چند بار ضربه بزند.

دکمه بستن، بازگشت، منوی بیشتر و کنترل‌های ردیف جدول معمولاً کوچک‌ترین هدف‌ها می‌شوند. فقط حالت عادی را نبینید؛ وقتی متن فارسی طولانی است یا کاربر اندازه فونت سیستم را بالا می‌برد، ناحیه لمس نباید روی عنصر کناری بیفتد. در تست، گزینه‌های اشتباه و ضربه‌های تکراری را ثبت کنید. اگر کاربر به‌طور مداوم کنار هدف می‌زند، مشکل «بی‌دقتی کاربر» نیست؛ هندسه رابط مشکل دارد.

منطقه انگشت شست و جای CTA اصلی

بیشتر کاربران در حرکت یا با یک دست گوشی را نگه می‌دارند. بخش پایین و میانی صفحه برای انگشت شست دسترس‌پذیرتر است و گوشه بالایی معمولاً سخت‌تر لمس می‌شود. این به معنی انتقال همه‌چیز به پایین نیست؛ باید اقدام پرتکرار و اصلی را در دسترس نگه دارید و تنظیمات کم‌تکرار را در سطح دوم بگذارید. دکمه خرید، ادامه یا ثبت نوبت می‌تواند پایین صفحه ثابت باشد، به شرطی که محتوا را نپوشاند و با safe area دستگاه تداخل نکند.

جای CTA را با جهت راست‌به‌چپ هم بسنجید. خواندن فارسی از راست شروع می‌شود، اما دست غالب همه کاربران یکسان نیست. به‌جای فرض قطعی درباره دست راست یا چپ، کنترل اصلی را در ناحیه مرکزی و قابل‌دسترسی قرار دهید. اقدام مخرب مثل حذف را کنار اقدام اصلی نگذارید و برای آن تأیید یا امکان بازگردانی فراهم کنید.

ناوبری پایین چه زمانی انتخاب خوبی است؟

ناوبری پایین برای سه تا پنج مقصد پرتکرار مناسب است؛ خانه، جست‌وجو، سفارش‌ها یا حساب کاربری. اگر هفت مقصد را در آن فشرده کنید، متن‌ها کوتاه و هدف‌ها کوچک می‌شوند. مقصدهای کم‌تکرار می‌توانند در منوی بیشتر یا داخل بخش حساب قرار بگیرند. تب فعال باید با شکل و متن قابل تشخیص باشد؛ رنگ تنها برای کاربر کم‌بینا کافی نیست.

برای جریان خطی مثل ثبت‌نام یا پرداخت، ناوبری عمومی همیشه مفید نیست. گاهی بهتر است کاربر مراحل را با یک دکمه ادامه و نشانه پیشرفت طی کند تا وسط کار به بخش دیگری نرود. بازگشت سیستم را هم از بازگشت داخل رابط جدا نکنید؛ کاربر اندروید انتظار دارد دکمه Back مسیر منطقی قبلی را باز کند، نه اینکه ناگهان از حساب خارج شود.

کیبورد و فرم در UI موبایل

هر فیلد باید کیبورد متناسب خودش را باز کند: عدد برای تلفن و مبلغ، ایمیل برای آدرس ایمیل و متن برای نام. برچسب فیلد را بعد از تایپ حذف نکنید؛ placeholder جای label نیست. خطا را نزدیک همان فیلد، با زبان روشن و راه اصلاح نشان دهید. پیام «ورودی نامعتبر است» کافی نیست؛ «شماره موبایل باید ۱۱ رقم باشد» به کاربر می‌گوید چه کند.

وقتی کیبورد باز می‌شود، فیلد فعال و دکمه ادامه باید دیده شوند. صفحه را روی دستگاه‌های کوتاه هم امتحان کنید و فقط به اسکرین‌شات بلند طراح تکیه نکنید. فرم طولانی را به مرحله‌های معنادار تقسیم کنید، نه اینکه برای هر فیلد یک صفحه جدا بسازید. مقدارهایی که سیستم می‌تواند بداند — شهر قبلی، نوع حساب یا اطلاعات پروفایل — دوباره نپرسید.

حالت بارگذاری، خطا و آفلاین را طراحی کنید

صفحه کامل فقط حالت موفق نیست. دکمه بعد از لمس باید بازخورد فوری بدهد، در زمان ارسال دوباره قابل‌فشار نباشد و نتیجه موفق یا ناموفق را روشن نشان دهد. Skeleton برای محتوایی که ساختار آن معلوم است مفید است؛ spinner تمام‌صفحه برای هر تغییر کوچک، حس توقف می‌سازد. اگر عملیات بیشتر از چند ثانیه طول می‌کشد، متن کوتاهی درباره وضعیت نمایش دهید.

در اینترنت ضعیف، داده قبلی را بی‌دلیل پاک نکنید. اگر کاربر فرم را نوشته و ارسال شکست خورده، ورودی‌ها باید باقی بمانند. تفاوت «اینترنت قطع است»، «سرور پاسخ نداد» و «اطلاعات اشتباه است» برای مسیر بعدی مهم است. اپ سازمانی ممکن است صف آفلاین لازم داشته باشد؛ آن تصمیم محصولی را در راهنمای اپلیکیشن سازمانی جدا توضیح داده‌ایم.

الگوی iOS و Android را کورکورانه یکسان نکنید

برند می‌تواند یکپارچه باشد، اما رفتار پلتفرم باید آشنا بماند. جای کنترل بازگشت، انتخاب‌گر تاریخ، مجوزها، اشتراک‌گذاری و اعلان‌ها در iOS و Android تفاوت‌هایی دارد. ساخت یک ظاهر کاملاً سفارشی که رفتارهای شناخته‌شده را حذف کند، هزینه یادگیری و پیاده‌سازی را بالا می‌برد. قبل از طراحی کنترل تازه، ببینید کامپوننت بومی همان کار را با دسترس‌پذیری بهتر انجام می‌دهد یا نه.

اگر محصول با React Native یا Flutter پیاده می‌شود، یک فایل طراحی واحد همچنان می‌تواند تفاوت‌های پلتفرم را با variant نشان دهد. انتخاب فناوری را از قواعد UI جدا نگه دارید؛ برای مقایسه فریم‌ورک‌ها به فلاتر یا ری‌اکت نیتیو بروید. این مقاله روی تجربه و مشخصات رابط می‌ماند، نه تصمیم معماری اپ.

تحویل طراحی UI موبایل به تیم اپ

تحویل خوب فقط چند frame نهایی نیست. اندازه و فاصله، حالت‌های hover نامرتبط نیستند؛ در عوض pressed، focused، disabled، loading، error و empty باید مشخص باشند. رفتار اسکرول، چسبندگی CTA، بازشدن bottom sheet، ارتفاع کیبورد و safe area را کنار صفحه بنویسید. برای متن پویا، کوتاه‌ترین و بلندترین نمونه فارسی را تست کنید.

توکن‌های رنگ، فاصله و تایپوگرافی را با نام معنایی تحویل دهید؛ برای مثال surface-primary بهتر از «آبی شماره ۳» است. کامپوننت مشترک دکمه یا ورودی باید یک منبع حقیقت داشته باشد تا تغییر در ده صفحه تکرار نشود. جزئیات این فرایند را در راهنمای دیزاین هندآف و ساخت اجزای مشترک را در سیستم دیزاین بخوانید.

چک‌لیست کنترل رابط موبایل

1. برای هر صفحه یک کار اصلی و یک CTA غالب تعریف شده است.
2. هدف‌های لمس مهم حداقل حدود ۴۴ تا ۴۸ پیکسل فضا دارند.
3. اقدام اصلی در منطقه قابل‌دسترسی انگشت قرار دارد.
4. ناوبری پایین بیشتر از پنج مقصد هم‌ارزش ندارد.
5. هر فیلد label پایدار، کیبورد مناسب و خطای قابل اصلاح دارد.
6. صفحه با کیبورد باز و روی گوشی کوتاه آزمایش شده است.
7. حالت‌های بارگذاری، خالی، خطا، آفلاین و موفق طراحی شده‌اند.
8. متن فارسی بلند و اندازه فونت بزرگ‌تر چیدمان را نمی‌شکند.
9. رفتارهای متفاوت iOS و Android مستند شده‌اند.
10. نمونه قابل کلیک روی دستگاه واقعی تست شده است.

جمع‌بندی: رابط موبایل یعنی طراحی برای دست، فضا و موقعیت واقعی

طراحی UI موبایل نسخه کوچک‌شده دسکتاپ نیست. هدف لمس، منطقه انگشت شست، ناوبری محدود، فرم سازگار با کیبورد و بازخورد شبکه، کیفیت واقعی تجربه را تعیین می‌کنند. اگر این تصمیم‌ها پیش از توسعه ثبت شوند، تیم اپ کمتر حدس می‌زند و بازکاری پس از ساخت کاهش پیدا می‌کند.

برای طراحی مسیر، پروتوتایپ و سیستم رابط یکپارچه می‌توانید خدمات طراحی UI/UX روبینش را ببینید؛ اگر محصول آماده ورود به توسعه است، مسیر فنی در صفحه طراحی اپلیکیشن قرار دارد. برای بررسی محدوده پروژه نیز از فرم تماس روبینش درخواست مشاوره بفرستید.