اگر برای طراحی UI/UX اپلیکیشن موبایل از سه جا قیمت گرفته باشید، احتمالاً سه عدد گرفته‌اید که هیچ شباهتی به هم ندارند. یکی برای «۲۰ صفحه» قیمت داده، یکی ساعتی حساب می‌کند و سومی می‌گوید «بستگی دارد». هیچ‌کدام لزوماً دروغ نمی‌گویند. فقط هر کدام دارند چیز متفاوتی را قیمت می‌دهند.
این مقاله فهرست قیمت نیست. می‌خواهیم توضیح دهیم هزینهٔ طراحی رابط کاربری از چه چیزهایی ساخته میشود، کدام مراحل را نباید حذف کرد تا ارزان‌تر شود، و چه سؤال‌هایی از هر تیم طراحی بپرسید تا پیشنهادهایشان قابل مقایسه شود.
«تعداد صفحه» واحد خوبی برای قیمت نیست
بیشتر پیشنهادها با شمردن صفحهها شروع می‌شوند، چون شمردنش راحت است. مشکل این است که یک صفحه می‌تواند یک فرم ساده باشد یا صفحهٔ صندوق فروش که روزی صدها بار استفاده میشود. واحد بهتر فرایند است: کاری که کاربر از اول تا آخر انجام میدهد، مثل «ثبت سفارش تعمیر» یا «پیدا کردن یک بند از استاندارد».
یک فرایند معمولاً چند صفحه دارد و هر صفحه چند حالت. حالت خالی (هنوز داده‌ای نیست)، حالت بارگذاری، حالت خطا، حالت بدون اینترنت و حالت عادی. پیشنهادی که فقط حالت عادی را طراحی می‌کند ارزان‌تر است، اما بقیه را برنامه‌نویس سر کار حدس می‌زند، و معمولاً همان‌جاهاست که کاربر گیر می‌کند.
هزینه از کجا می‌آید
به تجربهٔ ما این شش عامل بیشترین اثر را روی زمان و در نتیجه هزینهٔ طراحی دارند:
- تعداد فرایندهای اصلی و پیچیدگی هرکدام. اپی با سه فرایند ساده با اپی که سه نقش کاربری متفاوت دارد (مشتری، کارشناس، مدیر) قابل مقایسه نیست.
- دوزبانه بودن. اگر اپ باید فارسی و انگلیسی (یا عربی) داشته باشد، هر صفحه دو بار بررسی میشود. راستچین را نمی‌شود فقط با برعکس کردن چیدمان ساخت: آیکون‌های جهت‌دار، عدد و کد انگلیسی وسط متن فارسی، تاریخ شمسی و قالب اعداد هرکدام جدا تصمیم می‌خواهند. ما دربارهٔ همین مسئله در وب‌سایت در مقالهٔ فنپینو CMS و طراحی راستچین از روز اول نوشته‌ایم.
- خروجی: فایل طراحی یا نمونهٔ کارکردی. فایل Figma ارزان‌تر است. نمونهٔ اولیهٔ قابل کلیک با کد واقعی گران‌تر است، اما بخشی از کار فرانت‌اند را جلو می‌اندازد و چیزی را تأیید می‌کنید که مثل محصول نهایی رفتار می‌کند.
- تست با کاربر واقعی. چند جلسه با کسانی که واقعاً با اپ کار خواهند کرد. این مرحله را معمولاً اول از همه حذف می‌کنند و بعد هزینهاش را در ماه‌های بعد از انتشار می‌دهند.
- دسترس‌پذیری. کنتراست خوانا، اندازهٔ لمس مناسب و پشتیبانی از بزرگ کردن متن. راهنمای اپل پیشنهاد می‌کند کاربر بتواند متن را دست‌کم تا ۲۰۰ درصد بزرگ کند (Apple Human Interface Guidelines، بخش Accessibility)، و این یعنی چیدمان باید با متن بزرگ نشکند.
- وجود یا نبود سیستم طراحی. اگر رنگ، تایپوگرافی و کامپوننت‌ها از قبل تعریف شده باشند، کار سریع‌تر است. اگر نه، ساختن آن بخشی از پروژه است و ارزشش را دارد، چون نسخه‌های بعدی را ارزان می‌کند.
یک مثال فرضی
فرض کنید اپ یک تعمیرگاه موبایل سه فرایند اصلی دارد: پذیرش گوشی پشت پیشخوان، پیگیری وضعیت توسط مشتری و گزارش روزانه برای مدیر. با پنج حالت برای هر صفحه، فرایند پذیرش به‌تنهایی ممکن است بیش از ده نمای جدا داشته باشد. حالا اگر همین اپ دوزبانه باشد و پذیرش باید با یک دست و سریع انجام شود، طراحی پذیرش از دو فرایند دیگر روی هم وقت بیشتری می‌گیرد. پیشنهادی که هر سه را «۱۵ صفحه» حساب کرده، این تفاوت را نمی‌بیند.
این مثال از کار واقعی خود ما می‌آید. در موبایل مستر صفحهٔ صندوق فروش برای سرعت پشت پیشخوان طراحی شد، با ورود صوتی برای صندوق‌دار و یک لینک پیگیری عمومی تا مشتری برای پرسیدن وضعیت گوشی مدام تماس نگیرد. اگر کنجکاوید چرا این تماس‌ها برای تعمیرگاه گران تمام میشود، هزینهٔ واقعی اداره کردن تعمیرگاه با واتساپ و دفترچه را بخوانید. بخش قیمتگذاری تعمیر هم داستان طراحی خودش را داشت: تشخیص با کمک هوش مصنوعی در موبایل مستر.
مراحل کار، و این‌که کدام را نباید حذف کرد
- مشاهدهٔ کار فعلی. کنار کاربر می‌نشینیم یا می‌بینیم امروز کار را با کاغذ، واتساپ یا اکسل چطور انجام میدهد. هدف پیدا کردن چند کاری است که روزی ده‌ها بار تکرار میشود. حذف نکنید.
- نقشهٔ صفحهها و وایرفریم. تغییرشان ارزان است و بیشتر تصمیم‌های مهم همین‌جا گرفته میشود. راهنمای Material هم پیشنهاد می‌کند کارهای مهم بالا یا پایین صفحه، در دسترس، قرار بگیرند (Material Design 3، بخش Structure).
- طراحی بصری و سیستم طراحی. اگر بودجه محدود است، این‌جا میشود سادهتر گرفت.
- نمونهٔ اولیه و تست با کاربر. حذف نکنید. حتی سه یا چهار نفر کافی است تا جاهایی که مکث می‌کنند پیدا شود.
- تحویل به برنامه‌نویس و همراهی در پیاده‌سازی. طراحی‌ای که تیم توسعه بدون سؤال پیاده کند وجود ندارد. بپرسید چند ساعت پاسخ‌گویی در دورهٔ توسعه در قیمت هست.
- سنجش بعد از انتشار. سرعت و رفتار واقعی کاربر. در یکی از صفحه‌های سایت خودمان، یک تصویر PNG حدود هشتصد کیلوبایتی بالای صفحه زمان نمایش بزرگ‌ترین محتوا را در تست موبایل به بیش از نه ثانیه رسانده بود. با استفاده از نسخهٔ WebP همان تصویر به حدود ۲٫۳ ثانیه رسید و امتیاز کارایی Lighthouse از ۰٫۶۷ به ۰٫۹۸.
هشت سؤال برای مقایسهٔ پیشنهادها
- قیمت بر اساس صفحه است یا فرایند؟ فهرست فرایندها را مکتوب بخواهید.
- حالتهای خطا، خالی، بارگذاری و بدون اینترنت طراحی می‌شوند؟
- نسخهٔ راستچین جدا بررسی میشود یا فقط آینه میشود؟
- خروجی فایل طراحی است یا نمونهٔ کارکردی با کد؟
- تست با کاربر واقعی در قیمت هست؟ با چند نفر؟
- چند دور اصلاح در قیمت است و دور بعدی چطور حساب میشود؟
- مالکیت فایل‌ها و سیستم طراحی بعد از پروژه با کیست؟
- بعد از تحویل، چه کسی به سؤال‌های برنامه‌نویس جواب میدهد؟
دو پیشنهاد که به این هشت سؤال جواب یکسان داده باشند، تازه قابل مقایسه‌اند. آن وقت تفاوت قیمت معنی پیدا می‌کند.
ما در خدمات طراحی UI/UX بیشتر روی نرم‌افزارهایی کار می‌کنیم که آدم‌ها کل روز با آن کار می‌کنند، و زمانبندی و قیمت را بعد از بررسی اولین فرایند می‌دهیم، نه قبل از آن.
پرسش‌های متداول
هزینهٔ طراحی UI/UX اپلیکیشن موبایل چقدر است؟
عدد ثابتی وجود ندارد، چون به تعداد و پیچیدگی فرایندها، دوزبانه بودن، نوع خروجی و تست با کاربر بستگی دارد. برای مقایسهٔ منصفانه، از هر تیم بخواهید قیمت را بر اساس فهرست مکتوب فرایندها بدهد، نه تعداد صفحه.
طراحی UI اپلیکیشن چقدر طول میکشد؟
این هم به تعداد فرایندها بستگی دارد. زمانبندی واقعبینانه معمولاً بعد از مشاهدهٔ کار فعلی و بررسی اولین فرایند داده میشود. پیشنهادی که قبل از هر بررسی تاریخ دقیق میدهد، احتمالاً حالتهای خطا و تست را حساب نکرده است.
فرق UI و UX در قیمتگذاری چیست؟
UX یعنی مشاهده، نقشهٔ صفحهها، وایرفریم و تست؛ UI یعنی ظاهر و سیستم طراحی. اگر بودجه محدود است، بخش UI را سادهتر بگیرید، نه بخش UX را. اصلاح یک ظاهر ساده ارزان است، اما اصلاح یک فرایند اشتباه بعد از توسعه گران است.
طراحی راستچین اپلیکیشن هزینهٔ جدا دارد؟
بله، چون هر صفحه باید در حالت راستبهچپ جدا بررسی شود: جهت آیکونها، متن ترکیبی فارسی و انگلیسی، تاریخ شمسی و قالب اعداد. اگر از اول در طراحی دیده شود، هزینهاش خیلی کمتر از اصلاح بعدی است.
