دقیقه
26 مهر 1405برای طراحی یک سایت یا اپلیکیشن، دو پیشنهاد دریافت کرده‌اید که هر دو عنوان «طراحی UI/UX» دارند، اما مبلغشان متفاوت است. یکی فقط ظاهر چند صفحه را تحویل می‌دهد؛ دیگری شناخت نیاز، بررسی رقبا، طراحی مسیرها، پروتوتایپ تعاملی و نسخه موبایل و دسکتاپ را هم در محدوده کار دارد. تا وقتی این تفاوت‌ها روشن نشده‌اند، مقایسه دو مبلغ تصویر دقیقی از ارزش پیشنهادها نمی‌دهد.
هزینه طراحی UI/UX بر اساس حجم و پیچیدگی کار، میزان شناخت مسئله و خروجی‌هایی که باید تحویل شوند برآورد می‌شود. تعداد صفحه یکی از ورودی‌های این برآورد است، اما نقش کاربران، حالت‌های هر صفحه، سطح تعامل و روش تأیید طرح هم روی آن اثر می‌گذارند. یک فرم چندمرحله‌ای می‌تواند از چند صفحه معرفی ساده، بررسی و طراحی بیشتری بخواهد.
در این راهنما می‌بینیم چه چیزهایی قیمت طراحی رابط و تجربه کاربری را تغییر می‌دهند، چه اطلاعاتی برای برآورد لازم است و چگونه هزینه را با حفظ بخش‌های ضروری مدیریت کنیم. هدف، رسیدن به پیشنهاد قابل‌مقایسه برای پروژه شماست؛ مبلغ نهایی باید پس از مشخص‌شدن محدوده، زمان و شرایط همکاری اعلام شود.
هزینه طراحی UI/UX دقیقاً مربوط به چه کاری است؟
طراحی تجربه کاربری یا UX به شناخت نیازها، ساختار اطلاعات و مسیر انجام کار کمک می‌کند؛ طراحی رابط کاربری یا UI ظاهر و اجزایی را شکل می‌دهد که کاربر با آن‌ها تعامل دارد. در پروژه واقعی این فعالیت‌ها به هم مرتبط‌اند، اما ممکن است یک پیشنهاد فقط بخشی از آن‌ها را پوشش دهد. بنابراین پیش از پرسیدن مبلغ، باید معلوم شود تیم طراحی از چه نقطه‌ای شروع می‌کند و در چه نقطه‌ای مسئولیتش تمام می‌شود.
تفاوت هزینه طراحی با هزینه اجرای سایت یا اپلیکیشن
فایل طراحی و پروتوتایپ، سامانه عملیاتی نیستند. می‌توان در فیگما میان صفحات حرکت کرد و یک سناریو را نمایش داد، اما ذخیره اطلاعات، پرداخت واقعی، اتصال به نرم‌افزار دیگر و منطق سمت سرور به توسعه نیاز دارند. اگر پیشنهاد، طراحی و پیاده‌سازی را یکجا ارائه می‌کند، سهم و محدوده هر بخش باید جداگانه توضیح داده شود.
همین تفکیک درباره تولید متن، عکاسی، طراحی هویت بصری، خرید فونت و تصویر، ورود محتوا یا آزمون دسترس‌پذیری تخصصی هم لازم است. وجود این موارد در پروژه مفید است، اما نباید صرفاً از عنوان UI/UX نتیجه گرفت که همه آن‌ها در قیمت آمده‌اند. برای بودجه کل راه‌اندازی سایت، مقاله زیر زاویه گسترده‌تری دارد.
چرا قیمت هر صفحه به‌تنهایی کافی نیست؟
«صفحه» می‌تواند به یک نشانی وب، یک الگوی مستقل یا یک فریم در فایل طراحی اشاره کند. برای مثال، ده صفحه خدمات با ساختار مشترک با ده صفحه دارای رفتار و چیدمان متفاوت یکسان نیستند. در مقابل، یک صفحه رزرو ممکن است حالت انتخاب زمان، ظرفیت تکمیل، خطای پرداخت و تأیید نهایی داشته باشد که در شمارش ساده صفحات دیده نمی‌شوند.
از مجری بخواهید واحد شمارش را تعریف کند: کدام صفحات الگوی مشترک دارند، کدام حالت‌ها جدا طراحی می‌شوند و نسخه موبایل چگونه محاسبه می‌شود؟ قیمت صفحه‌ای می‌تواند روش قراردادی قابل‌استفاده‌ای باشد، به شرط آنکه این تعریف‌ها و خروجی هر واحد روشن باشند.
چه عواملی مبلغ طراحی رابط و تجربه کاربری را تغییر می‌دهند؟
برای فهم اختلاف قیمت، باید پیشنهاد را به فعالیت و خروجی تبدیل کرد. بعضی عوامل حجم طراحی را بیشتر می‌کنند، بعضی ابهام مسئله را کاهش می‌دهند و بعضی برای هماهنگی با تیم توسعه لازم‌اند. اثر هر عامل به پروژه بستگی دارد؛ هیچ ضریب ثابتی برای تبدیل تعداد صفحه به هزینه همه پروژه‌ها وجود ندارد.
تحقیق، شناخت کسب‌وکار و دسترسی به اطلاعات
پروژه‌ای که مخاطب، هدف و فرایندهایش مستند شده‌اند، با پروژه‌ای که هنوز مدل خدمتش روشن نیست نقطه شروع یکسانی ندارد. مصاحبه با کارفرما، بررسی داده‌های موجود، مطالعه رقبا و در صورت نیاز پژوهش با کاربران، فعالیت‌های متفاوتی هستند. درخواست «تحقیق کامل» بدون مشخص‌کردن سؤال تحقیق، روش و خروجی، برآورد دقیقی ایجاد نمی‌کند.
بررسی رقبا می‌تواند الگوهای رایج و شیوه ارائه خدمت را نشان دهد، اما جای شناخت کاربران خود پروژه را نمی‌گیرد. اگر مصاحبه یا آزمون با کاربران در محدوده است، هزینه هماهنگی، جذب مشارکت‌کننده و تحلیل نتیجه نیز باید معلوم شود. انتخاب روش باید از سؤال‌های واقعی پروژه بیاید، نه از اضافه‌کردن نام چند روش تحقیق به پیشنهاد.
تعداد نقش‌ها، مسیرها و حالت‌های ضروری
یک سایت معرفی با یک فرم تماس معمولاً مسیرهای متفاوتی از یک سامانه چندنقشی دارد. در سامانه رزرو، مشتری، ارائه‌دهنده خدمت و مدیر ممکن است به اطلاعات و اختیارات متفاوت نیاز داشته باشند. طراحی هر نقش فقط تغییر منو نیست؛ باید تصمیم‌ها، دسترسی‌ها و مسیرهای کاری آن بررسی شوند.
حالت خالی، بارگذاری، خطا، موفقیت و محدودیت دسترسی نیز بخشی از تجربه‌اند. برای نمونه، طراحی فهرست سفارش‌ها بدون حالت «هنوز سفارشی ثبت نشده» یا «دریافت اطلاعات ناموفق بود» بخشی از تصمیم‌های لازم را به زمان توسعه منتقل می‌کند. در برآورد باید مشخص شود کدام حالت‌ها برای مسیرهای مهم تحویل می‌شوند.
نسخه موبایل، دسکتاپ و سطح پروتوتایپ
طراحی موبایل فقط کوچک‌کردن نسخه دسکتاپ نیست. جدول، منو، فرم و اولویت نمایش محتوا ممکن است به راه‌حل متفاوتی نیاز داشته باشند. اگر کاربران بیشتر با موبایل وارد می‌شوند، این موضوع می‌تواند اولویت شروع طراحی را تعیین کند؛ با این حال محدوده نسخه‌های لازم باید مستقل از ترتیب شروع، مشخص باشد.
پروتوتایپ نیز سطح‌های مختلف دارد: اتصال ساده چند صفحه با نمایش مسیرهای اصلی، یا شبیه‌سازی دقیق‌تر تعامل‌ها و حالت‌ها. تعداد فریم‌ها به‌تنهایی نشان نمی‌دهد چه سناریوهایی قابل بررسی‌اند. پیش از قیمت‌گذاری، سناریوهای مورد توافق و میزان جزئیات مورد نیاز برای ارائه به کارفرما و توسعه را تعیین کنید.
هویت بصری، اجزای مشترک و آمادگی برای توسعه
داشتن هویت بصری مشخص می‌تواند بعضی تصمیم‌های اولیه را روشن کند، اما تطبیق آن با رابط دیجیتال همچنان به طراحی نیاز دارد. وضعیت رنگ‌ها، تایپوگرافی، خوانایی و اجزای تعاملی باید بررسی شود. اگر هویت بصری هم باید از ابتدا ساخته شود، بهتر است این خدمت و هزینه آن جدا از طراحی محصول تعریف شود.
اجزای مشترک مانند دکمه، ورودی فرم و کارت، از تکرار بی‌دلیل تصمیم‌ها جلوگیری می‌کنند. دامنه کتابخانه اجزا، حالت‌های آن‌ها و مستندات استفاده باید متناسب با محصول باشد. طراحی یک مجموعه اجزای پایه با تدوین دیزاین سیستم گسترده برای چند محصول برابر نیست؛ نه حذف کامل این کار منطقی است و نه تحمیل یک ساختار بزرگ به هر پروژه کوچک.
برآورد پروژه چگونه به یک پیشنهاد قابل بررسی تبدیل می‌شود؟
برای تصمیم‌گیری، یک عدد نهایی کافی نیست. پیشنهاد باید نشان دهد چه فعالیت‌هایی انجام می‌شوند، چه خروجی‌هایی دارید و چه فرض‌هایی مبنای برآورد بوده‌اند. مدل ساده بررسی این است: تلاش لازم برای شناخت مسئله، طراحی، بازبینی و تحویل را کنار هزینه‌های جانبی توافق‌شده بگذارید؛ سپس ببینید مبلغ پیشنهادی چه محدوده‌ای را پوشش می‌دهد.
مبلغ ثابت، محاسبه زمانی یا همکاری مرحله‌ای
مبلغ ثابت برای محدوده‌ای که به‌اندازه کافی روشن شده قابل‌بررسی‌تر است؛ باید معلوم باشد تغییر نیاز چگونه بر زمان و هزینه اثر می‌گذارد. در همکاری زمانی، لازم است نرخ، شیوه ثبت فعالیت و سقف یا نقاط کنترل بودجه مشخص شوند. هیچ‌کدام به‌تنهایی تضمین ارزان‌ترشدن یا کیفیت بهتر نیستند.
وقتی ابهام زیاد است، می‌توان ابتدا مرحله شناخت و تعریف محدوده را جدا قرارداد کرد و برآورد ادامه را پس از آن انجام داد. در این حالت، خروجی مرحله اول باید برای کارفرما قابل استفاده باشد؛ مثلاً شرح نیاز، مسیرهای اصلی و فهرست صفحات و حالت‌ها. اگر ادامه همکاری اختیاری است، شرایط تحویل همین خروجی‌ها نیز روشن شود.
اصلاحات و تغییر نیاز را چگونه تعریف کنیم؟
اصلاح طرح در چارچوب هدف و محدوده مصوب با اضافه‌کردن نقش کاربری یا فرایند تازه یکسان نیست. برای مثال، تغییر چیدمان فرم توافق‌شده با تبدیل همان فرم به فرایند چندمرحله‌ای احراز هویت، کار متفاوتی ایجاد می‌کند. عبارت «چند نوبت اصلاح» بدون تعریف نحوه جمع‌آوری بازخورد و حدود آن، ابهام را برطرف نمی‌کند.
بهتر است هر مرحله، مسئول تأیید و مهلت اعلام بازخورد داشته باشد و نظرهای تیم کارفرما به‌صورت تجمیعی ارائه شوند. درباره بازگشت به مرحله تأییدشده، تغییر محتوا یا افزودن صفحه نیز از ابتدا توافق کنید. هدف محدودکردن گفت‌وگو نیست؛ باید اثر تصمیم جدید بر طراحی و برنامه پروژه قابل پیگیری باشد.
| محور | توضیح قابل بررسی | ابهام پرهزینه |
|---|---|---|
| شناخت و تحقیق | سؤال‌ها، روش‌ها و خروجی مرحله شناخت | عبارت کلی «تحقیق کامل» |
| دامنه طراحی | نقش‌ها، نوع صفحات، مسیرها و حالت‌های مهم | فقط تعداد نامشخص صفحه |
| دستگاه‌ها | نسخه موبایل و دسکتاپ و حدود طراحی واکنش‌گرا | فرض خودکار درباره نسخه دوم |
| تعامل | سناریوهای قابل نمایش در پروتوتایپ | استفاده مبهم از واژه «کامل» |
| اصلاح و تحویل | نقاط تأیید، فایل قابل ویرایش و همراهی با توسعه | پشتیبانی و اصلاحات بدون حدود روشن |
چطور پیشنهاد دو تیم طراحی را منصفانه مقایسه کنیم؟
مقایسه باید با شرح نیاز مشترک شروع شود. اگر یک تیم مسئله را «طراحی ظاهر» و تیم دیگر آن را «بازطراحی مسیر خرید» فهمیده باشد، اختلاف مبلغ ممکن است ناشی از اختلاف برداشت باشد. ابتدا هدف، کاربران اصلی و خروجی مورد انتظار را یکسان توضیح دهید؛ سپس تفاوت روش، شواهد و مسئولیت‌ها را بررسی کنید.
یک مثال فرضی از دو پیشنهاد با تعداد صفحه یکسان
فرض کنید برای یک سامانه نوبت‌دهی، هر دو پیشنهاد نام هشت صفحه را دارند. پیشنهاد اول تصاویر نهایی دسکتاپ را تحویل می‌دهد؛ پیشنهاد دوم علاوه بر آن، مسیر لغو نوبت، نبود ظرفیت، انتخاب زمان در موبایل و پروتوتایپ مسیر اصلی را پوشش می‌دهد. عدد هشت در این دو پیشنهاد به خروجی هم‌ارز اشاره نمی‌کند.
برای مقایسه، از هر تیم بخواهید همین موارد را در جدول محدوده مشخص کند. اگر بعضی قابلیت‌ها لازم نیستند، آگاهانه حذفشان کنید و دوباره قیمت بگیرید. اگر لازم‌اند، پیشنهاد ارزان‌تر باید با اضافه‌شدن آن‌ها ارزیابی شود. مبلغ بالاتر بدون شواهد کافی برتری را ثابت نمی‌کند؛ مبلغ پایین‌تر هم به‌تنهایی نشانه ضعف نیست.
به‌جای تعداد فایل، قابلیت استفاده از خروجی را بررسی کنید
فایل پر از فریم لزوماً تحویل کامل‌تری نیست. تیم توسعه باید بتواند ساختار، اجزا، حالت‌ها و رفتارهای توافق‌شده را بفهمد و کارفرما نیز باید به نسخه قابل ویرایش و مرجع نهایی دسترسی داشته باشد. حدود پاسخ‌گویی طراح به سؤال‌های توسعه و بازبینی تطابق اجرا را در پیشنهاد بخوانید.
در عین حال، طراحی خوب به‌تنهایی مسئول همه نتیجه‌های کسب‌وکار نیست. فروش، ثبت‌نام یا استفاده از محصول به عوامل دیگری هم وابسته‌اند. ادعای افزایش قطعی فروش یا تضمین درصد مشخص، بدون داده و روش سنجش روشن، مبنای مناسبی برای توجیه هزینه طراحی نیست.
چگونه بودجه UI/UX را بدون حذف نیازهای ضروری مدیریت کنیم؟
مدیریت هزینه با کوچک‌کردن آگاهانه دامنه شروع می‌شود. حذف نسخه موبایل در محصولی با کاربران عمدتاً موبایلی، یا حذف حالت خطای یک مسیر حیاتی، فقط هزینه تصمیم‌گیری را به زمان دیگری منتقل می‌کند. ابتدا مشخص کنید کاربر در نسخه نخست باید چه کار اصلی را با موفقیت انجام دهد و طراحی همان مسیر چه چیزهایی لازم دارد.
امکانات کم‌اولویت را جدا کنید، مسیر اصلی را کامل نگه دارید
برای نمونه، می‌توان گزارش‌های پیشرفته یا شخصی‌سازی گسترده را به مرحله بعد موکول کرد، در حالی که ثبت درخواست، مشاهده وضعیت و مدیریت خطا در نسخه اول کامل طراحی شوند. اگر همه بخش‌ها به‌صورت ناقص شروع شوند، تحویل قابل استفاده دشوارتر می‌شود. اولویت‌ها باید بر اساس نیاز محصول و ریسک مسیرها تعیین شوند، نه فقط جذابیت بصری هر بخش.
در محصول تازه، ممکن است هنوز بعضی فرض‌ها نیاز به بررسی داشته باشند. طراحی جزئیات زیاد پیش از روشن‌شدن آن فرض‌ها می‌تواند بازکاری ایجاد کند. مقاله انتخاب امکانات نسخه نخست، برای تفکیک نیاز ضروری از قابلیت قابل تعویق مفید است.
اطلاعات و تصمیم‌های کارفرما را به‌موقع آماده کنید
نمونه محتوا، محدودیت‌های فنی، هویت بصری موجود، بازخورد کاربران و معرفی تصمیم‌گیرنده اصلی، ورودی‌های مفیدی هستند. لازم نیست کارفرما به‌جای طراح راه‌حل نهایی بسازد؛ باید مسئله، واقعیت‌های کسب‌وکار و محدودیت‌ها را روشن کند. اگر نمونه‌ای را می‌پسندید، توضیح دهید کدام ویژگی آن برای مخاطب شما مناسب است.
محتوای واقعی نیز روی تصمیم طراحی اثر می‌گذارد. تغییر چند کلمه با جایگزینی یک تیتر کوتاه با توضیح طولانی برابر نیست. درباره مسئول تهیه محتوا و زمان تثبیت آن توافق کنید؛ استفاده موقت از متن نمونه باید به‌عنوان فرض پروژه مشخص باشد، نه اینکه در روز تحویل باعث بازطراحی پیش‌بینی‌نشده شود.
برای دریافت برآورد طراحی UI/UX چه اطلاعاتی بفرستیم؟
برای شروع لازم نیست سند پیچیده‌ای بنویسید. یک توضیح روشن از محصول، مخاطب، مسئله اصلی و امکانات ضروری، از فهرستی طولانی از سلیقه‌های ظاهری مفیدتر است. اگر اطلاعاتی هنوز قطعی نیست، همان ابهام را اعلام کنید تا در پیشنهاد به‌صورت فرض یا فعالیت مرحله شناخت دیده شود.
- محصول چیست و کاربر اصلی باید چه کاری در آن انجام دهد؟
- چه نقش‌ها، مسیرها و نوع صفحه‌هایی در نسخه نخست لازم‌اند؟
- سایت یا اپلیکیشن موجود است؟ داده و بازخورد قابل استفاده دارید؟
- نسخه‌های موبایل و دسکتاپ، زبان‌ها و محدودیت‌های فنی کدام‌اند؟
- هویت بصری و محتوا آماده‌اند و چه کسی طرح را تأیید می‌کند؟
- محدودیت بودجه و زمان و نیاز به همراهی طراح در توسعه چیست؟
در آژانس خلاقیت امین، فرایند از مصاحبه با کارفرما، استخراج نیازها و شناخت رقبا آغاز می‌شود. پس از بررسی و جمع‌بندی، وایرفریم با جزئیات بالا و تعامل‌های مورد توافق در فیگما آماده و ارائه می‌شود. با دریافت بازخورد و تأیید این مرحله، طراحی نهایی رابط برای موبایل و دسکتاپ، با رعایت هویت بصری و اجزای مشترک، انجام می‌شود و سپس طرح تأییدشده به پیاده‌سازی می‌رود.
برای برآورد پروژه خود، خدمات طراحی رابط و تجربه کاربری آژانس خلاقیت امین را ببینید و هدف محصول، مسیرهای ضروری و محدودیت‌های خود را توضیح دهید. مبلغ قابل اتکا زمانی به دست می‌آید که بدانیم چه مسئله‌ای را با چه خروجی و مسئولیتی قرار است حل کنیم.