طراحی اپلیکیشن اندروید یعنی ساختن محصولی که روی هزاران مدل گوشی با اندازه‌ی صفحه، نسخه‌ی سیستم‌عامل و قدرت سخت‌افزاری متفاوت درست کار کند و حس آشنای اندروید را به کاربر بدهد. یک اپ اندرویدی موفق علاوه بر رابط کاربری خوب، باید ناوبری بازگشت، مجوزها، نوتیفیکیشن‌ها، کارایی روی گوشی‌های ضعیف و انتشار در کافه‌بازار، مایکت و گوگل‌پلی را از روز اول جدی بگیرد.
اصول عمومی طراحی صفحه‌ها مثل ناحیه‌ی شست، آنبوردینگ و فرم‌ها را در مقاله‌ی طراحی رابط کاربری اپلیکیشن موبایل مفصل نوشته‌ایم و اینجا تکرارشان نمی‌کنیم؛ تمرکز این مقاله روی چیزهایی است که مخصوص اندروید است.
طراحی اپلیکیشن اندروید چه تفاوتی با طراحی یک اپ موبایل عمومی دارد؟
بیشتر اصول تجربه کاربری بین iOS و اندروید مشترک است، اما اندروید چند ویژگی دارد که تصمیم‌های طراحی و فنی را تغییر می‌دهد. مهم‌ترینش این است که اندروید یک اکوسیستم باز است: سازندگان مختلف گوشی، پوسته‌های اختصاصی، نسخه‌های قدیمی سیستم‌عامل که هنوز در دست کاربران است و فروشگاه‌های متعدد.
- تنوع دستگاه: از گوشی‌های اقتصادی با صفحه‌ی کوچک و حافظه‌ی کم تا تبلت و گوشی‌های تاشو.
- ناوبری سیستمی: دکمه یا ژست «بازگشت» بخشی از سیستم‌عامل است و کاربر انتظار دارد همه‌جا رفتار قابل پیش‌بینی داشته باشد.
- مجوزها و محدودیت‌های پس‌زمینه: هر نسخه‌ی جدید اندروید قواعد سخت‌گیرانه‌تری برای دسترسی به موقعیت، فایل‌ها، نوتیفیکیشن و اجرای کار در پس‌زمینه می‌گذارد.
- توزیع چندگانه: در ایران معمولاً اپ همزمان در کافه‌بازار، مایکت و گاهی گوگل‌پلی منتشر می‌شود و هر کدام قواعد، پرداخت درون‌برنامه‌ای و فرایند بررسی خودش را دارد.
به همین دلیل ما در دییر طراحی اپ اندرویدی را از همان ابتدا با توسعه‌دهنده‌ی اندروید جلو می‌بریم؛ چون بسیاری از تصمیم‌ها، مثل اینکه یک صفحه با دکمه‌ی بازگشت کجا برود یا یک مجوز چه زمانی درخواست شود، هم تصمیم طراحی است و هم تصمیم فنی.
Material Design 3 در طراحی اپلیکیشن اندروید چه نقشی دارد؟
Material Design زبان طراحی رسمی گوگل برای اندروید است و نسخه‌ی سوم آن (که با نام Material You هم شناخته می‌شود) مجموعه‌ای از کامپوننت‌ها، توکن‌های رنگ و تایپوگرافی، قواعد فاصله‌گذاری و الگوهای تعامل را در اختیار تیم می‌گذارد. پیروی از آن یعنی کاربر بدون آموزش می‌فهمد دکمه‌ی شناور، نوار پایین، برگه‌ی پایینی (Bottom Sheet) یا اسنک‌بار چه کاری می‌کنند.
چه چیزهایی را از Material بگیریم؟
- کامپوننت‌های استاندارد مثل Navigation Bar، Top App Bar، Chip، Dialog و Bottom Sheet که در Jetpack Compose آماده‌اند و رفتار دسترس‌پذیری درستی دارند.
- شبکه‌ی فاصله‌گذاری مبتنی بر مضرب‌های ۴ و ۸ و حداقل ناحیه‌ی لمسی ۴۸dp برای هر عنصر قابل لمس.
- سیستم رنگ مبتنی بر نقش (Primary، Surface، Error و…) که حالت تاریک و رنگ پویا را ساده می‌کند.
چه زمانی از Material فاصله بگیریم؟
Material نقطه‌ی شروع است، نه زندان. قاعده‌ی ما ساده است: رفتار را استاندارد نگه دارید و ظاهر را برندسازی کنید. یعنی دکمه‌ی بازگشت، لیست‌ها، دیالوگ‌ها و ژست‌ها همان‌طور کار کنند که کاربر اندروید انتظار دارد، اما رنگ، فونت و جزئیات بصری مال برند شما باشد. برای اینکه این تصمیم‌ها در کل اپ یکدست بماند، آن‌ها را در قالب توکن‌های طراحی و یک دیزاین سیستم کوچک ثبت می‌کنیم تا طراح و توسعه‌دهنده‌ی Compose از یک منبع واحد استفاده کنند.
با تنوع دستگاه و اندازه صفحه در اندروید چه کنیم؟
پراکندگی دستگاه (Fragmentation) شاید بزرگ‌ترین چالش ساخت اپلیکیشن اندروید باشد. به جای طراحی برای یک «گوشی نمونه»، باید برای بازه‌ای از عرض‌ها طراحی کنید. گوگل این بازه را در قالب کلاس‌های اندازه‌ی پنجره (Window Size Classes) دسته‌بندی کرده است.
| کلاس عرض | بازه‌ی تقریبی | دستگاه معمول | الگوی پیشنهادی |
|---|---|---|---|
| فشرده (Compact) | کمتر از ۶۰۰dp | اغلب گوشی‌ها در حالت عمودی | نوار ناوبری پایین، یک ستون |
| متوسط (Medium) | ۶۰۰ تا ۸۴۰dp | تبلت کوچک، گوشی تاشوی باز | Navigation Rail، دو ستون در صورت نیاز |
| گسترده (Expanded) | بیشتر از ۸۴۰dp | تبلت افقی، دسکتاپ | فهرست و جزئیات کنار هم (List-Detail) |
برای بیشتر کسب‌وکارهای ایرانی کلاس فشرده مهم‌ترین است، اما همین کلاس هم تنوع زیادی دارد: صفحه‌ی ۵ اینچی با تراکم پیکسل پایین تا گوشی‌های بلند و باریک. چند قاعده‌ی عملی که در پروژه‌ها رعایت می‌کنیم:
- طراحی را در کوچک‌ترین عرض هدف (مثلاً ۳۶۰dp) و یک عرض بزرگ‌تر هر دو بررسی کنید؛ متن‌های فارسی طولانی معمولاً در عرض کم می‌شکنند.
- به جای ارتفاع ثابت از چیدمان انعطاف‌پذیر و اسکرول استفاده کنید تا در صفحه‌های کوتاه دکمه‌ی اصلی زیر کیبورد یا نوار ناوبری پنهان نشود.
- نمایش لبه‌به‌لبه (Edge-to-Edge) را که در نسخه‌های جدید اندروید پیش‌فرض شده جدی بگیرید و فاصله از نوار وضعیت و نوار ناوبری سیستم را درست مدیریت کنید.
- اندازه‌ی فونت سیستم را بزرگ کنید و دوباره بررسی کنید؛ بسیاری از کاربران مسن‌تر فونت گوشی را بزرگ می‌کنند.
رفتارهای سیستمی اندروید: بازگشت، جهت، مجوزها و نوتیفیکیشن
ناوبری بازگشت و راست‌چین بودن اپ فارسی
در iOS برگشت معمولاً با دکمه‌ای در گوشه‌ی بالا یا کشیدن از لبه انجام می‌شود، اما در اندروید «بازگشت» یک رفتار سیستمی است که کاربر از هر جای اپ و با دکمه یا ژست کناری به آن دسترسی دارد.
- بازگشت باید یک قدم به عقب در مسیر کاربر باشد، نه پرش به صفحه‌ی خانه یا خروج ناگهانی.
- در فرم‌های طولانی، قبل از دور ریختن داده‌ی واردشده با بازگشت، از کاربر تأیید بگیرید یا پیش‌نویس را ذخیره کنید.
- بازگشت روی برگه‌ی پایینی، دیالوگ یا جست‌وجوی باز، اول همان لایه را ببندد.
- از «بازگشت پیش‌بین» (Predictive Back) که در نسخه‌های جدید اندروید پیش‌نمایش مقصد را هنگام کشیدن نشان می‌دهد پشتیبانی کنید؛ این کار نیاز دارد معماری ناوبری اپ تمیز باشد.
در اپ فارسی موضوع جهت هم اضافه می‌شود. اندروید از چیدمان راست‌به‌چپ پشتیبانی کامل دارد، به شرط اینکه توسعه‌دهنده به جای چپ و راست از start و end استفاده کند. با این حال همه‌چیز نباید آینه شود: آیکون پخش ویدیو، نمودارهای زمانی، شماره‌ی کارت بانکی و کدهای عددی جهت خودشان را دارند. فلش بازگشت در اپ راست‌چین به سمت راست اشاره می‌کند و ژست بازگشت سیستمی هم از هر دو لبه کار می‌کند؛ پس طراحی نباید عنصر مهمی را درست کنار لبه‌ها بگذارد که با ژست سیستم تداخل کند.
از اندروید ۶ به بعد مجوزهای حساس در زمان اجرا از کاربر گرفته می‌شوند و از اندروید ۱۳ ارسال نوتیفیکیشن هم به اجازه‌ی صریح کاربر نیاز دارد. یعنی دیگر نمی‌شود فرض کرد اپ بعد از نصب به همه‌چیز دسترسی دارد. اگر کاربر یک مجوز را چند بار رد کند، سیستم دیگر پنجره‌ی درخواست را نشان نمی‌دهد و او باید خودش به تنظیمات برود؛ پس هر درخواست مجوز یک فرصت محدود است.
مجوزها را چطور بخواهیم که کاربر رد نکند؟
- مجوز را درست در لحظه‌ای بخواهید که کاربر به آن نیاز دارد؛ مثلاً دسترسی دوربین وقتی روی «اسکن بارکد» می‌زند، نه در اولین اجرای اپ.
- قبل از پنجره‌ی سیستمی، با یک صفحه‌ی کوتاه توضیح دهید چرا این دسترسی لازم است و چه سودی برای کاربر دارد.
- برای حالت رد شدن، مسیر جایگزین طراحی کنید؛ مثلاً وارد کردن دستی آدرس اگر دسترسی موقعیت داده نشد.
نوتیفیکیشن مفید، نه مزاحم
نوتیفیکیشن ابزار مهمی برای بازگرداندن کاربر است، اما اگر زیاد و بی‌ربط باشد به خاموش کردن یا حذف اپ منجر می‌شود. در اندروید نوتیفیکیشن‌ها در قالب کانال (Notification Channel) دسته‌بندی می‌شوند و کاربر می‌تواند هر کانال را جدا خاموش کند. پیشنهاد ما این است که کانال‌ها را بر اساس نیت کاربر تعریف کنید، مثلاً «وضعیت سفارش» جدا از «پیشنهادهای ویژه»، تا کاربری که تبلیغات نمی‌خواهد مجبور نشود اطلاع‌رسانی سفارشش را هم از دست بدهد. درخواست اجازه‌ی نوتیفیکیشن را هم بعد از اینکه کاربر ارزش اپ را دید، مثلاً بعد از اولین سفارش، مطرح کنید.
هر پنجره‌ی درخواست مجوز یک سؤال از کاربر است: «به ما اعتماد داری؟» اگر قبل از اینکه ارزشی نشان داده باشید این سؤال را بپرسید، جواب معمولاً منفی است.
کارایی روی گوشی‌های ضعیف؛ بخش فراموش‌شده‌ی طراحی اپلیکیشن اندروید
بخش قابل توجهی از کاربران ایرانی با گوشی‌های اقتصادی یا چندساله، حافظه‌ی محدود و اینترنت ناپایدار از اپ استفاده می‌کنند. اپی که روی گوشی پرچم‌دار تیم طراحی روان است، ممکن است روی گوشی کاربر واقعی کند باز شود، هنگام اسکرول لگ بزند یا به خاطر کمبود حافظه بسته شود. بسیاری از تصمیم‌های طراحی مستقیم روی کارایی اثر می‌گذارند.
- حجم نصب: تصاویر و انیمیشن‌های سنگین، فونت‌های متعدد و کتابخانه‌های غیرضروری حجم اپ را بالا می‌برند و دانلود و به‌روزرسانی را برای کاربر با حافظه‌ی کم سخت می‌کنند.
- زمان شروع: صفحه‌ی اول را سبک طراحی کنید و محتوای غیرضروری را بعداً بارگذاری کنید؛ صفحه‌ی اسپلش طولانی جای اپ کند را نمی‌گیرد.
- لیست‌های طولانی: کارت‌های ساده‌تر با تصاویر بهینه و اندازه‌ی مشخص، اسکرول روان‌تری روی سخت‌افزار ضعیف دارند.
- حالت آفلاین و شبکه‌ی ضعیف: اسکلتون، کش محلی و پیام خطای قابل اقدام به جای صفحه‌ی سفید و چرخش بی‌پایان.
در فاز فنی هم ابزارهایی مثل R8 برای کوچک کردن کد، Baseline Profile برای بهتر شدن زمان شروع و فرمت WebP برای تصاویر کمک می‌کنند. اما مهم‌ترین کار این است که اپ را از همان نسخه‌های اولیه روی یک گوشی ارزان واقعی تست کنید، نه فقط روی شبیه‌ساز یا گوشی تیم. در تست کاربردپذیری هم بهتر است بخشی از شرکت‌کنندگان با گوشی خودشان کار کنند تا مشکلات واقعی دیده شود.
ساخت اپلیکیشن اندروید: نیتیو با Kotlin یا کراس‌پلتفرم؟
یکی از اولین سؤال‌هایی که مشتری‌ها می‌پرسند این است که اپ را نیتیو بسازیم یا با فریم‌ورک‌های کراس‌پلتفرم مثل Flutter و React Native. پاسخ به نیاز محصول و برنامه‌ی آینده بستگی دارد.
| معیار | نیتیو (Kotlin و Jetpack Compose) | کراس‌پلتفرم (Flutter یا React Native) |
|---|---|---|
| دسترسی به امکانات سیستم | کامل و بدون واسطه | از طریق پلاگین؛ گاهی نیاز به کد نیتیو |
| کارایی روی گوشی ضعیف | معمولاً بهترین نتیجه | خوب، با بهینه‌سازی بیشتر |
| حس اندرویدی و Material | طبیعی و به‌روز | نزدیک، بسته به فریم‌ورک و پیاده‌سازی |
| یک کد برای iOS و اندروید | خیر | بله، با بخش‌های اختصاصی |
| مناسب برای | اپ‌های پیچیده، پرکاربرد یا وابسته به سخت‌افزار | MVP، اپ‌های محتوایی و فروشگاهی، تیم کوچک |
اگر فعلاً فقط بازار اندروید ایران هدف شماست و اپ قرار است با سخت‌افزار گوشی، پرداخت درون‌برنامه‌ای استورها یا کارهای پس‌زمینه زیاد سروکار داشته باشد، نیتیو با Kotlin انتخاب امن‌تری است. اگر از ابتدا iOS هم در برنامه است و منطق اپ بیشتر نمایش داده و فرم است، کراس‌پلتفرم می‌تواند زمان و هزینه را کم کند. در هر دو حالت، طراحی رابط باید رفتارهای اندرویدی را رعایت کند.
انتشار در کافه‌بازار، مایکت و گوگل‌پلی چه نکاتی دارد؟
برای اپ ایرانی، انتشار فقط آپلود یک فایل نیست. هر استور فرایند بررسی، قواعد محتوا و سرویس پرداخت درون‌برنامه‌ای خودش را دارد و برخی از این تفاوت‌ها روی طراحی و معماری اپ اثر می‌گذارد.
- پرداخت درون‌برنامه‌ای: اگر اپ اشتراک یا محصول دیجیتال می‌فروشد، کافه‌بازار و مایکت هر کدام سرویس پرداخت خودشان را دارند و معمولاً باید نسخه‌های جداگانه برای هر استور ساخت (Build Flavor). این موضوع باید از ابتدا در طراحی صفحه‌ی خرید دیده شود.
- صفحه‌ی اپ در استور: آیکون، تصاویر و توضیحات بخشی از تجربه‌ی کاربری‌اند؛ اولین چیزی که کاربر قبل از نصب می‌بیند. اسکرین‌شات‌ها باید ارزش اپ را نشان دهند، نه فقط صفحه‌ی ورود را.
- به‌روزرسانی و نسخه‌های قدیمی: کاربران همیشه به‌روزرسانی نمی‌کنند؛ اپ باید بتواند به‌روزرسانی اجباری یا پیشنهادی را با پیام روشن مدیریت کند و API سمت سرور با نسخه‌های قدیمی سازگار بماند.
- گوگل‌پلی: الزام‌های سطح API هدف، سیاست‌های حریم خصوصی و فرم اطلاعات امنیت داده را دارد و برای توسعه‌دهندگان داخل ایران محدودیت‌های حساب و پرداخت هم مطرح است که باید پیش از برنامه‌ریزی بررسی شود.
تجربه‌ی همکاری ما با کافه‌بازار به ما نشان داد که اکوسیستم اندروید ایران قواعد و عادت‌های کاربری خودش را دارد و طراحی اپ بدون شناخت این بستر به نتیجه‌ی دلخواه نمی‌رسد. اگر هدفتان طراحی اپلیکیشن فروشگاهی اندروید است، نکات اختصاصی آن مثل جست‌وجو، سبد و تسویه را در راهنمای طراحی اپلیکیشن فروشگاهی جداگانه بررسی کرده‌ایم.
مراحل طراحی اپلیکیشن اندروید از ایده تا انتشار
فرایند ما برای ساخت اپلیکیشن اندروید مرحله‌به‌مرحله پیش می‌رود و هر مرحله خروجی مشخصی دارد:
- کشف و تحقیق: شناخت کاربران هدف، گوشی‌هایی که استفاده می‌کنند، رقبا در استورها و هدف کسب‌وکار.
- معماری و جریان کاربر: تعریف صفحه‌ها، مسیرهای اصلی و نقشه‌ی ناوبری، از جمله رفتار دکمه‌ی بازگشت و لینک‌های عمیق (Deep Link).
- وایرفریم و پروتوتایپ: آزمودن جریان‌ها روی گوشی واقعی قبل از طراحی بصری.
- طراحی رابط و دیزاین سیستم: کامپوننت‌ها بر پایه‌ی Material 3، تایپوگرافی فارسی، حالت تاریک و همه‌ی حالت‌های صفحه.
- توسعه و تست: پیاده‌سازی، تست روی چند دستگاه با اندازه و نسخه‌ی متفاوت و تست کاربردپذیری.
- انتشار و بهبود مستمر: آماده‌سازی صفحه‌ی استور، انتشار مرحله‌ای، پایش خطاها و تحلیل رفتار کاربران.
ما در خدمات طراحی محصول فاز تحقیق و طراحی را انجام می‌دهیم و در توسعه وبسایت و اپلیکیشن همان طرح را به اپ قابل انتشار تبدیل می‌کنیم؛ این پیوستگی باعث می‌شود جزئیاتی مثل رفتار بازگشت یا حالت‌های خطا بین طراحی و کد گم نشوند.
هزینه طراحی اپلیکیشن اندروید به چه چیزهایی بستگی دارد؟
قیمت ثابتی برای طراحی اپلیکیشن اندروید وجود ندارد، چون دو اپ با ظاهر شبیه می‌توانند پشت صحنه‌ی کاملاً متفاوتی داشته باشند. عوامل اصلی که روی هزینه اثر می‌گذارند:
- تعداد صفحه‌ها و پیچیدگی منطق کسب‌وکار؛ مثلاً یک اپ محتوایی با یک اپ فروشگاهی یا خدماتی با چند نقش کاربری قابل مقایسه نیست.
- انتخاب نیتیو یا کراس‌پلتفرم و اینکه iOS هم در برنامه هست یا نه.
- بک‌اند، API و پنل مدیریت که اغلب به اندازه‌ی خود اپ کار دارند.
- پرداخت درون‌برنامه‌ای چند استور، نقشه، چت یا اتصال به سرویس‌های بیرونی.
- نگهداری بعد از انتشار: به‌روزرسانی برای نسخه‌های جدید اندروید و الزامات استورها.
جزئیات این عوامل، سهم هر مرحله و هزینه‌های پنهان را در مقاله‌ی هزینه ساخت اپلیکیشن کامل توضیح داده‌ایم. برای برآورد قابل اتکا، یک بریف روشن از هدف و امکانات نسخه‌ی اول مهم‌تر از هر جدول قیمتی است.
سؤالات متداول
طراحی اپلیکیشن اندروید چقدر زمان می‌برد؟
به دامنه‌ی پروژه بستگی دارد. یک MVP با چند جریان اصلی در زمان بسیار کوتاه‌تری نسبت به یک اپ کامل با پنل مدیریت، پرداخت و چند نقش کاربری آماده می‌شود. زمان‌بندی دقیق بعد از جلسه‌ی کشف و مشخص شدن امکانات نسخه‌ی اول قابل ارائه است.
ساخت اپلیکیشن اندروید بدون کدنویسی یا با هوش مصنوعی ممکن است؟
ابزارهای بدون کد و هوش مصنوعی برای نمونه‌ی اولیه و اپ‌های ساده مفیدند، اما برای اپی که باید روی گوشی‌های متنوع روان کار کند، با بک‌اند اختصاصی یکپارچه شود و در چند استور منتشر شود، معمولاً به طراحی و توسعه‌ی حرفه‌ای نیاز است.
اپلیکیشن را اول در کدام استور منتشر کنیم؟
برای بازار داخلی معمولاً کافه‌بازار و مایکت اولویت دارند و گوگل‌پلی به مخاطب و امکان‌پذیری حساب توسعه‌دهنده بستگی دارد. اگر پرداخت درون‌برنامه‌ای دارید، از ابتدا برای هر استور نسخه‌ی جداگانه در نظر بگیرید.
Material Design 3 برای اپ فارسی مناسب است؟
بله. Material از راست‌به‌چپ پشتیبانی می‌کند و کامپوننت‌هایش در Jetpack Compose آماده‌اند؛ کافی است تایپوگرافی فارسی، اعداد و جهت آیکون‌ها با دقت تنظیم و رفتارها حفظ شوند.
اگر در حال برنامه‌ریزی برای طراحی یا بازطراحی اپلیکیشن اندروید هستید، می‌توانید نمونه‌کارهای ما را در پروژه‌های دییر ببینید و برای گفت‌وگو درباره‌ی محصولتان درخواست همکاری بدهید.
