اصول طراحی اپلیکیشن؛ تجربهای که کاربر را سردرگم نمیکند.
یک بار برای انجام کاری ساده، اپلیکیشنی را باز کردم و همان اول با سه بنر، دو پنجرهٔ راهنما و درخواست فعال کردن اعلان روبهرو شدم. هنوز نفهمیده بودم محصول چه کمکی میکند، اما پنج تصمیم از من میخواست. صفحهها از نظر بصری حرفهای بودند؛ تجربه شبیه ورود به فروشگاهی بود که چند نفر همزمان جلوی در دربارهٔ پیشنهادهایشان حرف میزنند.
طراحی اپلیکیشن خوب یعنی مهمترین کار کاربر را در زمینهٔ واقعی موبایل—صفحهٔ کوچک، توجه محدود، لمس و حرکت—واضح و قابل انجام کنیم. اپ موبایل نسخهٔ کوچکشدهٔ سایت نیست. نحوهٔ نگه داشتن دستگاه، کیبورد مجازی، قطعی اینترنت، permissionها و جابهجایی سریع میان برنامهها بخشی از مسئلهاند.
با یک هدف روشن شروع کنیم
بسیاری از اپها میخواهند همهٔ قابلیتها را در صفحهٔ اول نشان دهند. نتیجه داشبوردی میشود که کاربر نمیداند از کجا شروع کند. هدف اصلی محصول باید به یک یا چند کار پرتکرار تبدیل شود و صفحهٔ آغاز آنها را جلو بیاورد.
قبل از طراحی میپرسم: اگر کاربر فقط یک دقیقه وقت داشته باشد، مهمترین کاری که باید بتواند انجام دهد چیست؟ اگر جواب روشن نیست، مشکل با چیدمان حل نمیشود.
سادگی به معنی خالی کردن صفحه نیست. اپ بانکی باید اطلاعات و کنترل بیشتری از اپ هواشناسی نشان دهد. سادگی یعنی چیزی که الان لازم است نزدیک باشد و جزئیات ثانویه بدون گم شدن در دسترس بماند.
ناوبری باید با مدل ذهنی کاربر هماهنگ باشد
منوی خوب قرار نیست خلاقیت طراح را ثابت کند. کاربر باید بداند کجاست، چه بخشهایی وجود دارد و چگونه برمیگردد. الگوهای آشنای پلتفرم، هزینهٔ یادگیری را کم میکنند.
برای بخشهای اصلی و پرتکرار، نوار پایین انتخاب مناسبی است؛ به شرطی که تعداد گزینهها محدود و برچسبها روشن باشند. محتواهای سلسلهمراتبی نیاز به مسیر بازگشت قابل پیشبینی دارند. gesture میتواند میانبُر باشد، اما نباید تنها راه انجام یک کار مهم شود.
راهنمای اپل هم توصیه میکند از رفتارهای آشنای سیستم استفاده کنیم و کنترلهای مهم را با نحوهٔ نگه داشتن تلفن هماهنگ کنیم. نوآوری وقتی ارزش دارد که مسئله را بهتر حل کند، نه وقتی ناوبری معمول را به معما تبدیل کند.
لمس با کلیک فرق دارد
ماوس دقیق است؛ انگشت نه. کنترل کوچک، گزینههای نزدیک و لینک ظریف در موبایل باعث لمس اشتباه میشوند. اپل اندازهٔ پیشفرض ۴۴ در ۴۴ پوینت را برای کنترلهای iOS پیشنهاد میکند و روی فاصلهٔ کافی میان عناصر هم تأکید دارد.
مهمترین اقدامها را در ناحیهای قرار دهید که با یک دست دسترسپذیرتر است، اما به فرض ثابت دربارهٔ همهٔ کاربران تکیه نکنید. راستدست، چپدست، اندازهٔ دستگاه و محدودیت حرکتی متفاوتاند.
فقط خود آیکن را بزرگ نکنید؛ محدودهٔ لمس میتواند بزرگتر از ظاهر باشد. وضعیت فشرده شدن هم باید سریع دیده شود تا کاربر بداند تعامل ثبت شده است.
محتوای واقعی، طراحی واقعی میسازد
نام کوتاه و عکس کامل در ماکاپ، بسیاری از مشکلها را پنهان میکند. اپ باید با نام بلند، تصویر خراب، عدد بزرگ، متن فارسی و انگلیسی، تاریخ و دادهٔ خالی درست رفتار کند.
در طراحی فارسی، راستبهچپ بودن فقط تراز متن نیست. جهت آیکنهای حرکتی، ترتیب اطلاعات، نمایش اعداد و ترکیب زبانها باید آزموده شود. ترجمهٔ مستقیم متن انگلیسی هم ممکن است طول و لحن نامناسب بسازد.
من نمونهها را زود با محتوای نزدیک به واقعیت پر میکنم. وقتی کارت با عنوان بلند میشکند، بهتر است در فیگما بفهمیم تا در نسخهٔ منتشرشده.
فرم موبایل را کوتاه و بخشنده طراحی کنیم
تایپ روی موبایل پرهزینه است. فقط اطلاعاتی را بپرسید که در همان مرحله لازماند. نوع کیبورد را با داده هماهنگ کنید، فرمت را قبل از خطا نشان دهید و تا جای ممکن از اطلاعات مجاز دستگاه یا انتخابهای ساده استفاده کنید.
خطا باید کنار همان فیلد، با زبان قابل اصلاح و بدون پاک کردن داده نشان داده شود. «ورودی نامعتبر» کمک نمیکند؛ «شماره باید ۱۱ رقم باشد» قدم بعدی را روشن میکند.
در جریان طولانی، پیشرفت و امکان ذخیره مهماند. قطع تماس، خاموش شدن صفحه یا رفتن به اپ دیگر اتفاق عجیبی نیست. بازگشت کاربر نباید به شروع دوباره منجر شود.
permission را وقتی بخواهیم که ارزشش روشن است
درخواست موقعیت، دوربین یا اعلان در اولین ثانیه، قبل از شکل گرفتن اعتماد، معمولاً رد میشود. permission را در لحظهای بخواهید که کاربر قصد استفاده از قابلیت مرتبط را دارد و توضیح دهید چرا لازم است.
اگر کاربر رد کرد، محصول نباید به بنبست نامفهوم برسد. راه جایگزین یا مسیر فعال کردن دوباره را نشان دهید. شفافیت دربارهٔ داده بخشی از تجربه و مسئولیت محصول است.
بازخورد و بازیابی از خطا
هر اقدام باید نتیجهٔ قابل مشاهده داشته باشد. هنگام درخواست شبکه loading نشان دهید؛ بعد از ذخیره تأیید کنید؛ اگر شکست خورد دلیل و راه تلاش دوباره را بگویید. skeleton یا spinner باید متناسب با زمان و ساختار باشد، نه صرفاً تزئین.
برای اقدام حساس پیشگیری و امکان برگشت طراحی کنید. Undo برای حذف سبک، تأیید برای عملیات پرریسک و نگه داشتن پیشنویس، آزادی بیشتری به کاربر میدهد. پیام خطا نباید او را سرزنش کند.
حالت آفلاین و اینترنت ضعیف در بسیاری از موقعیتهای ایران واقعیت روزمرهاند. معلوم کنید چه چیزی ذخیره شده، چه چیزی منتظر ارسال است و آیا خروج امن است.
عملکرد بخشی از UX است
انیمیشن سنگین و تصویر بزرگ ممکن است در نمونه زیبا باشد، اما روی دستگاه متوسط و شبکهٔ کند تجربه را خراب کند. تیم طراحی باید زود با توسعه دربارهٔ هزینهٔ اجرا حرف بزند.
حس سرعت فقط عدد فنی نیست. نمایش سریع ساختار، اولویت دادن به محتوای ضروری و پاسخ فوری به لمس، انتظار را قابل فهمتر میکند. وعدهٔ رابط باید با توان سیستم هماهنگ باشد.
دسترسپذیری را از ابتدا وارد کنیم
کنتراست، Dynamic Type، برچسب برای screen reader، اندازهٔ کنترل و عدم اتکا به رنگ برای پیام، پایهاند. تعامل باید با روشهای مختلف ممکن باشد و حرکت شدید گزینهٔ کاهش داشته باشد.
دسترسپذیری به کاربران خاص محدود نیست. صفحهٔ خوانا زیر نور، هدف لمسی مناسب در حرکت و زبان روشن برای همه بهتر است. وقتی آن را آخر پروژه اضافه میکنیم، اصلاح معماری پرهزینه میشود.
تست روی دستگاه واقعی
دیدن فریم روی مانیتور حس موبایل را نمیدهد. نمونه را روی دستگاه باز کنید، با یک دست کار کنید، کیبورد را بالا بیاورید، متن را بزرگ کنید و اینترنت را کند کنید. روی اندازههای مختلف و هر دو سیستمعامل هدف بررسی کنید.
سپس به کاربر هدف بدهید و مشاهده کنید. آیا اقدام اصلی را پیدا میکند؟ از نتیجه مطمئن است؟ کجا مکث میکند؟ تست کوتاه خیلی زودتر از گزارش پس از انتشار، مشکل ناوبری را پیدا میکند.
چکلیست طراحی اپلیکیشن
- ارزش و کار اصلی در شروع واضح است؟
- ناوبری با الگوی پلتفرم و مدل ذهنی هماهنگ است؟
- کنترلها اندازه و فاصلهٔ مناسب دارند؟
- حالت خالی، خطا، loading، آفلاین و دسترسی ردشده طراحی شده؟
- متن فارسی و دادهٔ بلند رابط را نمیشکند؟
- فرم کمترین ورودی لازم را میگیرد؟
- permission در زمینهٔ درست درخواست میشود؟
- کاربر میتواند از اشتباه برگردد؟
- تجربه روی دستگاه واقعی و با کاربر تست شده؟
پرسشهای متداول
طراحی اپلیکیشن را از UI شروع کنیم یا جریان؟
از هدف، محتوا و جریان شروع کنید؛ سپس UI آن را قابل فهم و جذاب میکند. شروع از ظاهر میتواند مسئلههای ساختاری را پنهان کند.
طراحی iOS و Android باید یکسان باشد؟
هویت و منطق محصول میتواند مشترک باشد، اما الگوهای پلتفرم، ناوبری، permission و اجزای سیستمی تفاوت دارند. برابری پیکسلی همیشه تجربهٔ یکسان نمیسازد.
چند صفحه برای یک اپ لازم است؟
عدد ثابتی وجود ندارد. از حداقل جریانهایی شروع کنید که ارزش اصلی و حالتهای ضروری را پوشش دهند. تعداد صفحه معیار کیفیت نیست.
جمعبندی من
من محمد عبدی هستم و طراحی اپلیکیشن را چیدن صفحههای کوچک نمیبینم. اپ در دست آدمی استفاده میشود که شاید عجله دارد، اینترنتش قطع شود یا فقط یک دست آزاد داشته باشد. تصمیم خوب این زمینه را وارد طراحی میکند.
اگر هدف اصلی روشن، ناوبری آشنا، لمس آسان، بازخورد دقیق و راه برگشت وجود داشته باشد، رابط آرام میشود. کاربر لازم نیست طراحی را تحسین کند؛ کافی است بدون سردرگمی کارش را انجام دهد و به محصول اعتماد کند.
نوشتهٔ محمد عبدی، طراح محصول و تجربهٔ کاربری.