طراحی رابط کاربری اپلیکیشن یعنی طراحی همه‌ی صفحه‌ها، اجزا و تعامل‌هایی که کاربر روی گوشی می‌بیند و لمس می‌کند، به‌شکلی که با یک دست، روی صفحه‌ی کوچک و در میان حواس‌پرتی‌های روزمره هم سریع و بی‌خطا کار کند. یک رابط خوب موبایل از ناحیه‌ی در دسترس شست، اندازه‌ی کافی اهداف لمسی، الگوهای آشنای ناوبری iOS و اندروید و حالت‌هایی مثل خالی، بارگذاری، خطا و آفلاین شروع می‌شود و فقط بعد از آن به رنگ و ظاهر می‌رسد.
در این راهنما، که حاصل تجربه‌ی ما در دییر از طراحی محصولات دیجیتال از سال ۱۳۹۱ تاکنون است، توضیح می‌دهیم طراحی اپلیکیشن موبایل دقیقاً چه تفاوتی با طراحی وب دارد، چه زمانی باید از دستورالعمل‌های اپل و گوگل پیروی کرد و کجا می‌شود یک زبان طراحی واحد ساخت، و برای اپ فارسی چه نکاتی را نباید فراموش کرد. اگر با مفاهیم پایه آشنا نیستید، پیشنهاد می‌کنیم ابتدا راهنمای جامع طراحی UI/UX را بخوانید؛ برای مسیر کامل ساخت اپ هم طراحی نرم‌افزار موبایل از ایده تا انتشار مکمل همین نوشته است.
طراحی رابط کاربری اپلیکیشن چه تفاوتی با طراحی وب دارد؟
بسیاری از تیم‌ها اپلیکیشن را نسخه‌ی کوچک‌شده‌ی سایت می‌بینند و همین نگاه ریشه‌ی بیشتر مشکلات است. کاربر موبایل در صف بانک، داخل مترو یا وسط یک گفت‌وگو سراغ اپ می‌آید، معمولاً فقط چند ثانیه وقت دارد و ممکن است هر لحظه با یک تماس یا اعلان قطع شود. موس و نشانگر دقیق هم وجود ندارد؛ انگشت جای آن را گرفته و بخشی از صفحه را هنگام لمس می‌پوشاند. به همین دلیل طراحی ui اپلیکیشن قواعد خودش را دارد.
ناحیه‌ی شست و استفاده‌ی یک‌دستی
بیشتر مردم بخش زیادی از زمان گوشی را با یک دست نگه می‌دارند و با شست کار می‌کنند. در این حالت پایین و میانه‌ی صفحه راحت در دسترس است، اما گوشه‌های بالایی، به‌ویژه در گوشی‌های بزرگ، سخت‌ترین نقطه‌اند. نتیجه‌ی عملی ساده است: اقدام‌های پرتکرار مثل دکمه‌ی اصلی، تب‌های ناوبری و جست‌وجو را پایین صفحه بگذارید و کارهای کم‌تکرار یا مخرب مثل حذف حساب را به نواحی دورتر ببرید.
اهداف لمسی، ژست‌ها و صفحه‌ی کوچک
اپل در Human Interface Guidelines حداقل ۴۴ در ۴۴ پوینت و گوگل در Material Design حداقل ۴۸ در ۴۸ dp را برای هر هدف لمسی توصیه می‌کند. نکته این است که ناحیه‌ی لمس می‌تواند از ظاهر آیکون بزرگ‌تر باشد؛ یک آیکون ۲۴ پوینتی می‌تواند ناحیه‌ی لمس ۴۴ پوینتی داشته باشد. فاصله‌ی کافی بین اهداف هم به همان اندازه مهم است تا کاربر به‌جای «ذخیره» روی «حذف» نزند.
ژست‌هایی مثل کشیدن برای بازگشت، کشیدن به پایین برای تازه‌سازی یا کشیدن کارت برای حذف، رابط را خلوت‌تر می‌کنند، اما دیده نمی‌شوند. قاعده‌ی ما این است که هر کاری که با ژست انجام می‌شود، یک راه دیدنی هم داشته باشد. صفحه‌ی کوچک هم یعنی اولویت‌بندی بی‌رحمانه: در هر صفحه یک هدف اصلی، یک دکمه‌ی اصلی و حذف هر چیزی که به آن هدف کمک نمی‌کند.
قطع شدن و ازسرگیری
اپ باید فرض کند هر لحظه ممکن است رها شود. فرم نیمه‌کاره باید ذخیره بماند، سبد خرید نباید با بستن اپ خالی شود و کاربری که بعد از ده دقیقه برمی‌گردد باید دقیقاً همان‌جایی را ببیند که ترکش کرده بود. این یک تصمیم طراحی است و باید در سند تحویل ثبت شود.
iOS یا اندروید؛ از کدام دستورالعمل پیروی کنیم؟
اپل و گوگل هر کدام راهنمای مفصلی دارند که رفتارهای مورد انتظار کاربران هر پلتفرم را تعریف می‌کند. کاربر آیفون به دکمه‌ی بازگشت در بالای صفحه و کشیدن از لبه عادت دارد و کاربر اندروید به دکمه یا ژست بازگشت سیستمی. نادیده گرفتن این عادت‌ها، حتی اگر طرح زیبا باشد، حس «غریبه بودن» ایجاد می‌کند.
| موضوع | iOS (Human Interface Guidelines) | اندروید (Material Design) |
|---|---|---|
| حداقل هدف لمسی | ۴۴ × ۴۴ پوینت | ۴۸ × ۴۸ dp |
| ناوبری اصلی | تب‌بار پایین صفحه | نوار ناوبری پایین؛ در اپ‌های بزرگ‌تر کشوی کناری |
| بازگشت | دکمه در نوار بالا و کشیدن از لبه | دکمه یا ژست بازگشت سیستمی |
| اقدام اصلی | معمولاً دکمه در نوار بالا یا داخل محتوا | دکمه‌ی شناور (FAB) یا دکمه‌ی برجسته |
| فونت سیستمی | San Francisco | Roboto و فونت‌های سیستمی سازنده |
| کادرهای هشدار | Alert و Action Sheet از پایین | Dialog و Bottom Sheet |
چه زمانی یک زبان طراحی واحد بسازیم؟
در عمل، بیشتر اپ‌های ایرانی یک هویت بصری مشترک برای هر دو پلتفرم دارند و این انتخاب معقولی است، به شرط آنکه مرز درست کشیده شود. رنگ، تایپوگرافی، آیکون‌ها، کارت‌ها و لحن را یکسان نگه دارید، اما رفتارهای سیستمی مثل بازگشت، انتخاب‌گر تاریخ، کادرهای هشدار، اشتراک‌گذاری و صفحه‌کلید را به پلتفرم بسپارید. اگر اپ با فریم‌ورک‌های چندسکویی مثل Flutter یا React Native ساخته می‌شود، این تصمیم را از ابتدا با تیم توسعه هماهنگ کنید تا بعداً با اجزای سفارشی پرهزینه روبه‌رو نشوید.
کدام الگوی ناوبری برای اپلیکیشن شما مناسب است؟
ناوبری اسکلت اپ است و تغییر آن پس از انتشار بسیار پرهزینه است. پیش از انتخاب، فهرست بخش‌های اصلی را بنویسید و ببینید کاربر هر روز به کدام‌ها سر می‌زند. ابزارهایی مثل کارت سورتینگ و جریان کاربر در این مرحله کمک زیادی می‌کنند.
- تب‌بار پایین: بهترین انتخاب برای ۳ تا ۵ بخش اصلی و پرتکرار. همیشه دیده می‌شود، در ناحیه‌ی شست است و جابه‌جایی بین بخش‌ها را با یک لمس ممکن می‌کند.
- کشوی کناری (Drawer): برای بخش‌های زیاد و کم‌تکرار مثل تنظیمات، راهنما یا گزارش‌ها مناسب است، اما چون پنهان است، بخش‌های اصلی را هرگز فقط داخل آن نگذارید.
- ناوبری پشته‌ای (Stack): برای رفتن از فهرست به جزئیات و مراحل پشت‌سرهم. هر صفحه روی قبلی قرار می‌گیرد و بازگشت باید همیشه قابل پیش‌بینی باشد.
- ترکیب الگوها: بیشتر اپ‌های موفق تب‌بار را برای سطح اول و پشته را داخل هر تب به کار می‌برند و فقط موارد جانبی را در منو یا صفحه‌ی پروفایل جمع می‌کنند.
آنبوردینگ، فرم‌ها و صفحه‌کلید را چطور طراحی کنیم؟
آنبوردینگ کوتاه و مبتنی بر ارزش
چند اسلاید معرفی که کاربر بی‌حوصله رد می‌کند، آنبوردینگ نیست. آنبوردینگ خوب کاربر را هرچه سریع‌تر به اولین لحظه‌ی ارزش می‌رساند: جست‌وجوی اول، اولین سفارش یا اولین پروژه. ثبت‌نام را تا جای ممکن عقب بیندازید، اجازه‌ی دسترسی به مکان یا اعلان را دقیقاً زمانی بخواهید که کاربر دلیلش را می‌فهمد و راهنمایی را به‌صورت نکته‌های کوتاه درون خود صفحه‌ها ارائه کنید.
فرم‌ها و صفحه‌کلید
تایپ روی گوشی کند و پرخطاست و صفحه‌کلید تقریباً نیمی از صفحه را می‌پوشاند. پس هر فیلدی که حذف شود یک پیروزی است. برای شماره‌ی موبایل و کد تأیید صفحه‌کلید عددی باز کنید، کد پیامکی را به‌صورت خودکار پر کنید، برچسب فیلد را بالای آن و همیشه دیدنی نگه دارید و دکمه‌ی ادامه را طوری قرار دهید که با باز شدن صفحه‌کلید پنهان نشود. خطا را کنار همان فیلد و با زبان ساده بگویید؛ نوشتن متن خطا خودش بخشی از نویسندگی تجربه کاربری است.
طراحی رابط کاربری اپلیکیشن فارسی چه نکاتی دارد؟
راست‌چین کردن یک طرح انگلیسی، اپ فارسی نمی‌سازد. طراحی رابط کاربری اپلیکیشن موبایل برای کاربر فارسی‌زبان از همان وایرفریم باید راست‌به‌چپ فکر شود.
- فونت: فونتی انتخاب کنید که در اندازه‌های کوچک خوانا بماند، اعداد فارسی استاندارد داشته باشد و وزن‌های کافی ارائه دهد. ارتفاع سطر متن فارسی معمولاً باید بیشتر از متن لاتین باشد.
- آینه کردن آیکون‌ها: آیکون‌های جهت‌دار مثل بازگشت، ادامه، فلش و نوار پیشرفت باید برعکس شوند، اما آیکون‌هایی مثل ساعت، دکمه‌ی پخش، لوگوها و علامت تیک نباید آینه شوند.
- اعداد: در متن و قیمت از اعداد فارسی استفاده کنید، اما ورودی‌ها باید هر دو نوع عدد را بپذیرند. شماره کارت، شبا و کدها را با فاصله‌گذاری خوانا نمایش دهید.
- متن ترکیبی: نام برندهای لاتین، آدرس ایمیل و شماره‌ها در دل جمله‌ی فارسی جهت‌گیری متن را به هم می‌ریزند و باید روی دستگاه واقعی بررسی شوند.
- تاریخ و تقویم: انتخاب‌گر تاریخ شمسی، نام ماه‌های فارسی و قالب نمایش تاریخ را از ابتدا در دیزاین سیستم تعریف کنید.
حالت‌های صفحه، دسترس‌پذیری و حالت تاریک
در فایل‌های طراحی معمولاً صفحه‌ها در بهترین حالت ممکن دیده می‌شوند: پر از داده، با اینترنت سریع و بدون خطا. اما کاربر واقعی بارها صفحه را در وضعیت‌های دیگر می‌بیند و اگر برای آن‌ها طراحی نکرده باشید، توسعه‌دهنده ناچار است خودش تصمیم بگیرد.
حالت‌های خالی، بارگذاری، خطا و آفلاین
- حالت خالی: به‌جای صفحه‌ی سفید، توضیح دهید اینجا چه چیزی قرار است نمایش داده شود و یک اقدام روشن برای شروع پیشنهاد کنید.
- حالت بارگذاری: برای محتوای فهرستی از اسکلتون (Skeleton) استفاده کنید تا ساختار صفحه از قبل معلوم باشد و انتظار کوتاه‌تر حس شود.
- حالت خطا: بگویید چه شد، تقصیر را گردن کاربر نیندازید و راه بعدی مثل «تلاش دوباره» را بدهید.
- حالت آفلاین: داده‌ی ذخیره‌شده را نشان دهید، وضعیت اتصال را با یک نوار کوچک اعلام کنید و اقدام‌های کاربر را تا برگشت اینترنت در صف نگه دارید.
دسترس‌پذیری و حالت تاریک در اپلیکیشن
دسترس‌پذیری فقط برای کاربران دارای معلولیت نیست؛ کسی که زیر نور آفتاب گوشی را نگاه می‌کند یا اندازه‌ی فونت سیستم را بزرگ کرده هم از آن سود می‌برد. کنتراست کافی بین متن و پس‌زمینه، پشتیبانی از اندازه‌ی متن پویا، برچسب‌گذاری درست برای صفحه‌خوان‌های VoiceOver و TalkBack و انتقال ندادن معنا فقط با رنگ، حداقل‌هایی هستند که در طراحی دسترس‌پذیر مفصل‌تر به آن‌ها پرداخته‌ایم.
حالت تاریک هم صرفاً برعکس کردن رنگ‌ها نیست. سیاه مطلق در کنار متن سفید چشم را خسته می‌کند، سایه‌ها در پس‌زمینه‌ی تیره دیده نمی‌شوند و باید با روشن‌تر کردن سطوح عمق ایجاد کرد، و رنگ‌های برند معمولاً نسخه‌ی کم‌اشباع‌تری لازم دارند. بهترین راه این است که از ابتدا رنگ‌ها را به‌صورت توکن معنایی مثل «سطح» و «متن اصلی» تعریف کنید، نه با کد رنگ مستقیم.
مراحل طراحی رابط کاربری اپلیکیشن به‌صورت گام‌به‌گام
- شناخت کاربر و کسب‌وکار: مصاحبه، بررسی رقبا و داده‌های موجود برای فهم اینکه چه کسی، در چه موقعیتی و برای چه کاری اپ را باز می‌کند.
- تعریف جریان‌های اصلی: چند سفر کلیدی کاربر را مشخص کنید و معماری اطلاعات و ساختار ناوبری را بر اساس آن‌ها بچینید.
- وایرفریم: صفحه‌ها را بدون رنگ و جزئیات بکشید تا تمرکز روی چیدمان، اولویت و ناحیه‌ی شست باشد.
- پروتوتایپ و تست: نسخه‌ی قابل کلیک را روی گوشی واقعی به چند کاربر بدهید و ببینید کجا گیر می‌کنند.
- طراحی بصری و دیزاین سیستم: رنگ، تایپوگرافی و کامپوننت‌ها را تعریف کنید و همه‌ی حالت‌ها را بکشید.
- تحویل و بازبینی پیاده‌سازی: مستندسازی، همراهی تیم توسعه و مقایسه‌ی بیلد با طرح.
- اندازه‌گیری و بهبود: پس از انتشار، داده‌ها و بازخوردها را دنبال کنید و طراحی را در چرخه‌های کوتاه بهتر کنید.
مرحله‌ی تست را نباید فدای زمان‌بندی کرد. حتی پنج جلسه‌ی کوتاه تست کاربردپذیری روی پروتوتایپ معمولاً مشکلاتی را نشان می‌دهد که تیم هفته‌ها از کنارشان رد شده است.
طرحی که فقط روی مانیتور بزرگ طراح خوب به نظر می‌رسد هنوز آزمایش نشده است. هر صفحه‌ی اپ را روی گوشی واقعی، با یک دست و در حال راه رفتن امتحان کنید.
دیزاین سیستم اپلیکیشن و تحویل طرح به توسعه‌دهنده
اپلیکیشنی که قرار است سال‌ها رشد کند بدون دیزاین سیستم به‌سرعت ناهمگون می‌شود. برای اپ موبایل، دیزاین سیستم باید شامل توکن‌های رنگ برای حالت روشن و تاریک، مقیاس تایپوگرافی، فاصله‌گذاری، آیکون‌ها و کامپوننت‌هایی مثل دکمه، فیلد، کارت، تب‌بار، Bottom Sheet و Toast باشد؛ هر کدام با همه‌ی حالت‌هایش، از عادی و فشرده تا غیرفعال و خطا.
تحویل بدون اصطکاک
تحویل طرح فقط فرستادن لینک فایل نیست. توسعه‌دهنده باید رفتار صفحه را در اندازه‌های مختلف گوشی، با صفحه‌کلید باز، با متن طولانی و در حالت‌های خطا بداند. ما در دییر برای هر جریان یک پروتوتایپ قابل کلیک، فهرست حالت‌ها، قواعد انیمیشن و نام‌گذاری یکسان کامپوننت‌ها بین طراحی و کد آماده می‌کنیم و در طول پیاده‌سازی، بازبینی طراحی روی بیلد واقعی انجام می‌دهیم؛ چون خیلی از مشکلات فقط روی گوشی واقعی دیده می‌شوند.
اشتباهات رایج در طراحی اپلیکیشن موبایل
- کپی کردن سایت در اپ و آوردن منوها، جدول‌ها و چیدمان دسکتاپ به صفحه‌ی کوچک.
- قرار دادن اقدام‌های اصلی در گوشه‌های بالای صفحه، دور از دسترس شست.
- دکمه‌ها و آیکون‌های ریز با فاصله‌ی کم که لمس اشتباه را زیاد می‌کنند.
- طراحی فقط برای حالت ایده‌آل و فراموش کردن حالت‌های خالی، خطا و آفلاین.
- نادیده گرفتن رفتارهای سیستمی هر پلتفرم، مثل ژست بازگشت در اندروید.
- آینه کردن ناقص رابط فارسی؛ مثلاً فلش‌هایی که در جهت اشتباه اشاره می‌کنند.
- درخواست همه‌ی مجوزها در اولین باز شدن اپ، پیش از آنکه کاربر ارزشی دیده باشد.
چک‌لیست سریع پیش از تحویل طرح
| بررسی | سؤال کلیدی |
|---|---|
| ناحیه‌ی شست | آیا اقدام‌های پرتکرار با یک دست در دسترس‌اند؟ |
| هدف لمسی | آیا همه‌ی اهداف حداقل ۴۴ پوینت یا ۴۸ dp و با فاصله‌ی کافی‌اند؟ |
| ناوبری | آیا کاربر همیشه می‌داند کجاست و چطور برگردد؟ |
| حالت‌ها | آیا حالت خالی، بارگذاری، خطا و آفلاین طراحی شده است؟ |
| راست‌چین | آیا آیکون‌های جهت‌دار، اعداد و متن ترکیبی درست نمایش داده می‌شوند؟ |
| دسترس‌پذیری | آیا کنتراست، متن پویا و برچسب صفحه‌خوان بررسی شده است؟ |
| حالت تاریک | آیا همه‌ی رنگ‌ها از توکن‌ها می‌آیند و در حالت تاریک تست شده‌اند؟ |
چطور یک شرکت طراحی اپلیکیشن موبایل انتخاب کنیم؟
طراحی اپلیکیشن حرفه‌ای بیش از هر چیز به فرایند و تجربه‌ی تیم وابسته است، نه فقط به زیبایی نمونه‌کارها. هنگام انتخاب شرکت طراحی اپلیکیشن موبایل این موارد را بپرسید: آیا نمونه‌کار اپ واقعی و منتشرشده دارد یا فقط تصاویر مفهومی؟ آیا تحقیق و تست کاربر بخشی از فرایندش است؟ آیا دیزاین سیستم و مستندات تحویل می‌دهد؟ و آیا در دوره‌ی پیاده‌سازی کنار تیم توسعه می‌ماند؟
ما در دییر سال‌هاست روی محصولات دیجیتال پرکاربر ایرانی کار کرده‌ایم که نمونه‌هایی از آن را در نمونه‌کارها، از جمله همکاری با کافه بازار، می‌توانید ببینید. خدمات ما در طراحی محصول و رابط کاربری از تحقیق و وایرفریم تا دیزاین سیستم و همراهی تیم توسعه را پوشش می‌دهد. اگر اپلیکیشنی در دست طراحی یا بازطراحی دارید، از طریق درخواست همکاری با ما در ارتباط باشید تا درباره‌ی مسیر مناسب پروژه‌تان صحبت کنیم.
سؤالات متداول
طراحی رابط کاربری اپلیکیشن چقدر زمان می‌برد؟
به تعداد جریان‌ها، پیچیدگی محصول و میزان تحقیق بستگی دارد. یک اپ ساده با چند جریان اصلی ممکن است در چند هفته طراحی شود، اما محصولات بزرگ با دیزاین سیستم کامل معمولاً چند ماه زمان می‌برند و پس از انتشار هم طراحی به‌صورت مداوم ادامه پیدا می‌کند.
آیا باید برای iOS و اندروید دو طراحی جداگانه داشته باشیم؟
معمولاً نه. یک زبان طراحی مشترک برای هویت بصری کافی است، به شرط آنکه رفتارهای سیستمی مثل بازگشت، کادرهای هشدار و انتخاب‌گرها با قواعد هر پلتفرم هماهنگ باشد.
حداقل اندازه‌ی دکمه در اپلیکیشن موبایل چقدر است؟
اپل حداقل ۴۴ در ۴۴ پوینت و گوگل حداقل ۴۸ در ۴۸ dp را توصیه می‌کند. ظاهر آیکون می‌تواند کوچک‌تر باشد، اما ناحیه‌ی قابل لمس نباید از این اندازه کمتر شود.
طراحی UI اپلیکیشن با چه ابزاری انجام می‌شود؟
ابزارهایی مثل Figma برای طراحی، پروتوتایپ و دیزاین سیستم رایج‌ترند. اما ابزار در درجه‌ی دوم اهمیت است؛ کیفیت نتیجه بیشتر به تحقیق، تست روی گوشی واقعی و همکاری نزدیک با توسعه‌دهنده بستگی دارد.
تفاوت طراحی UI و UX در اپلیکیشن چیست؟
UX تعیین می‌کند کاربر چه مسیری را برای رسیدن به هدفش طی کند و UI تعیین می‌کند این مسیر روی صفحه چگونه دیده و لمس شود. در اپ موبایل این دو به‌شدت به هم وابسته‌اند و معمولاً در یک فرایند واحد طراحی می‌شوند.
