دو پیشنهاد قیمت برای یک محصول گرفته‌اید و عددها با هم فاصله دارند. اما معلوم نیست این اختلاف در هزینه طراحی رابط کاربری از کجا آمده است. جواب کوتاه این است: به‌جای شمردن صفحه‌ها، دامنه طراحی، پیچیدگی مسیرها و خروجی‌های تحویلی را کنار هم بگذارید. پیشنهاد ارزان‌تر شاید اصلاً بخشی از کاری را که لازم دارید پوشش ندهد.
- تعداد قالب‌های مستقل و حالتهای صفحه، از شمار خام صفحات برای برآورد مفیدتر است.
- تحقیق، آزمون، اصلاحات و همراهی توسعه باید ردیف و خروجی مشخص داشته باشند.
- دو قیمت را تنها پس از یکسان‌کردن دامنه و معیار تحویل مقایسه کنید.
- قیمت جاری را از جدول خدمات بخوانید و برای دامنه متفاوت، برآورد جدا بگیرید.
هزینه طراحی رابط کاربری به چه عواملی بستگی دارد؟
چند عامل با هم هزینه طراحی رابط کاربری را می‌سازند. اول حجم کار: تعداد قالب‌های مستقل، حالتهای هر صفحه و مسیرهای کاربر. بعد عمق کار: میزان تحقیق، نسخه‌های موبایل و دسکتاپ، اجزای مشترک و خروجی‌های تحویلی. دورهای اصلاح، آزمون با کاربران و همراهی تیم طراحی هنگام پیاده‌سازی هم باید جدا مشخص شوند. به همین دلیل تعداد صفحه‌ها به‌تنهایی برای مقایسه قیمت کافی نیست.
رابط کاربری (UI) یعنی ظاهر و کنترل‌های محصول؛ از دکمه خرید تا فرم ثبت‌نام. تجربه کاربری (UX) اما به کیفیت مسیری برمی‌گردد که کاربر برای انجام کارش طی می‌کند. مثلاً آیا خریدار شرایط ارسال را پیش از پرداخت می‌فهمد، یا وسط خرید غافلگیر می‌شود؟
یک مرز دیگر را هم باید روشن کرد: طراحی با کدنویسی یکی نیست. طراح ساختار، ظاهر و رفتار موردانتظار را مشخص می‌کند و تیم توسعه همین‌ها را به محصولی قابل استفاده تبدیل می‌کند. پس هزینه طراحی رابط کاربری، اتصال درگاه پرداخت یا ساخت حساب کاربری را خودبه‌خود پوشش نمی‌دهد.
اگر مرز این فعالیت‌ها هنوز برایتان روشن نیست، راهنمای تفاوت رابط و تجربه کاربری برای کسب‌وکار کمک می‌کند. همچنین در درخواست برآورد صریح بنویسید که فقط طراحی می‌خواهید، فقط توسعه، یا هر دو را با قیمت‌گذاری جداگانه.
هزینه طراحی رابط کاربری چگونه محاسبه می‌شود؟
فرمولش ساده است: زمان هر فعالیت توافق‌شده ضرب‌در نرخ همان فعالیت، جمع همه ردیف‌ها، به‌علاوه هزینه‌های مستقیمی که تأیید کرده‌اید. اگر نرخ فعالیت‌ها فرق دارد، هر ردیف را جدا حساب کنید. اما در پیشنهاد قیمت ثابت، مبنای مبلغ دامنه و فرض‌هایی است که روی آن‌ها توافق کرده‌اید.
پس پیش از اینکه عدد بخواهید، ترتیب برآورد را این‌طور روشن کنید:
هدف محصول و مسیر اصلی کاربر را بنویسید.
قالب‌های مستقل را فهرست کنید.
حالت‌ها، دستگاه‌ها و زبان‌ها را مشخص کنید.
فعالیت‌های تحقیق و آزمون را تعیین کنید.
خروجی هر مرحله و معیار پذیرش آن را ثبت کنید.
معیار پذیرش یعنی شرطی که اگر برآورده شود، خروجی را تأیید می‌کنید. جمله «فرم رزرو باید حالت تکمیل ظرفیت و خطای ارتباط را داشته باشد» قابل بررسی است. هر کسی فایل را باز کند، می‌بیند این دو حالت هست یا نه. اما «طراحی باید حرفه‌ای باشد» معیار کافی نیست، چون هر کس برداشت خودش را از حرفه‌ای دارد.
برگه زیر را می‌توانید کپی کنید و هزینه طراحی رابط کاربری را ردیف‌به‌ردیف در آن ثبت کنید. خانه‌های عددی را بعد از توافق با تیم طراحی پر کنید، چون عدد بدون فرض‌های کنارش معنایی ندارد.
فعالیت | واحد یا تعداد | زمان برآوردی | نرخ | مبلغ | فرض‌ها |
|---|---|---|---|---|---|
تحقیق اولیه | دسترسی به کاربران | ||||
طراحی قالب‌ها و حالت‌ها | فهرست دامنه | ||||
اصلاحات | بازخورد تجمیع‌شده | ||||
همراهی توسعه | محدوده بازبینی | ||||
هزینه‌های مستقیم | تأیید پیش از خرید |
یک استثنا هم هست: برای مسیری که هنوز نامعلوم است، عدد قطعی برای هزینه طراحی رابط کاربری نخواهید. اول بررسی اولیه را به چند پرسش و خروجی مشخص محدود کنید و بعد باقی کار را برآورد کنید. همچنین هر تعرفه طراحی رابط کاربری را همراه تاریخ اعتبار، دامنه و تأیید مسئول فروش بخوانید.
صفحه، قالب و حالت چه تفاوتی در برآورد دارند؟
این سه واژه در پیشنهادها زیاد به‌جای هم به کار می‌روند، در حالی که معنایشان فرق دارد. صفحه یک مقصد مشخص است، قالب ساختاری است که بارها تکرار می‌شود و حالت، وضعیت همان صفحه در یک لحظه خاص است. مثلاً صفحه جزئیات یک کالای مشخص مقصد است. ساختار مشترک همه صفحه‌های جزئیات کالا قالب است؛ بارگذاری، خطا یا ناموجودبودن هم حالتهای آن‌اند.
فرض کنید فروشگاهی صدها کالا دارد. ممکن است همه آن‌ها با یک قالب جزئیات محصول نمایش داده شوند، چون عوض‌شدن نام و عکس کالا طراحی مستقل نمی‌خواهد. اما اگر خریدار در بعضی کالاها رنگ، اندازه و زمان تحویل را با هم انتخاب می‌کند، آن صفحه احتمالاً ساختار و رفتار دیگری می‌خواهد.
ملاک من برای جداکردن قالب‌ها ساده است: آیا کاربر در این صفحه تصمیم یا تعامل واقعاً متفاوتی دارد؟ اگر فقط محتوا عوض می‌شود، هزینه طراحی رابط کاربری را با شمردن نشانی‌های سایت برآورد نکنید. ولی اگر چیدمان یا منطق انتخاب تغییر می‌کند، همین تفاوت را صریح در دامنه بنویسید.
بنابراین وقتی قیمت طراحی هر صفحه ui را بررسی می‌کنید، این سؤال‌ها را از تیم بپرسید:
واحد قیمت، صفحه مستقل است یا قالب قابل تکرار؟
حالتهای خالی، خطا و بارگذاری داخل قیمت هستند؟
تکلیف پنجره‌های روی صفحه و پیام‌های تأیید چیست؟
نسخه موبایل بخشی از همان واحد است یا ردیف جدا دارد؟
با این حال، تعداد قالب‌ها را چشم‌بسته در تعداد حالت‌ها و دستگاه‌ها ضرب نکنید. یک پیام خطای مشترک ممکن است در چند مسیر به کار برود و فقط یک بار طراحی شود. از سوی دیگر، تبدیل جدول دسکتاپ به کارت‌های موبایل می‌تواند طراحی مستقلی بخواهد. بخش مشترک را یک بار بشمارید و تفاوت‌ها را جدا توضیح دهید.
پیش از شمردن صفحات، بنویسید کاربر چه کاری را باید کامل کند و کجا ممکن است متوقف شود. این فهرست، حالتهای فراموش‌شده را آشکار می‌کند.
سهم تحقیق، وایرفریم، پروتوتایپ و طراحی نهایی
تحقیق ابهام درباره نیاز و رفتار کاربر را کم می‌کند. وایرفریم (Wireframe) طرح ساده ساختار صفحه است؛ یعنی جای بخش‌ها و اولویت اطلاعات، بدون پرداخت کامل جزئیات بصری. پروتوتایپ (Prototype) نمونه‌ای تعاملی است که حرکت بین صفحه‌ها را نشان می‌دهد تا بشود مسیر را بررسی یا با کاربر آزمود.
در برآورد هزینه طراحی ux، نام فعالیت به کارتان نمی‌آید؛ خروجی قابل استفاده بخواهید. معمولاً اولین سؤالی که درباره ردیف «تحقیق کاربر» می‌پرسم این است: قرار است به کدام پرسش جواب بدهد؟ مثلاً آیا کاربر پیش از انتخاب نوبت باید ارائه‌دهنده‌ها را با هم مقایسه کند؟ جواب همین یک سؤال ممکن است ترتیب کل مسیر رزرو را عوض کند.
تحقیق: پرسش، روش بررسی و یافته‌ای که روی تصمیم طراحی اثر دارد.
وایرفریم: ساختار محتوا، اولویت اطلاعات و مسیر انجام کار.
پروتوتایپ: مسیرهای قابل اجرا و محدوده رفتارهای شبیه‌سازی‌شده.
آزمون: مسئله‌های مشاهده‌شده، اولویت اصلاح و تصمیم بعدی.
سهم تحقیق را هم درصد ثابتی از هزینه طراحی رابط کاربری فرض نکنید. عمق بررسی را اطلاعاتی که از قبل دارید و ریسک مسیر اصلی تعیین می‌کنند. بازطراحی یک فرم تماس آشنا با طراحی مسیر ناشناخته ثبت درخواست مالی یکی نیست. در مسیر مبهم، حذف تحقیق شاید صرفه‌جویی به نظر برسد، ولی ممکن است کار را به بازطراحی ساختار بکشاند.
سؤالی که پیش از طراحی بی‌جواب بماند، اغلب وسط اجرا گران‌تر تمام می‌شود.
در طراحی نهایی، رنگ، تایپوگرافی، فاصله‌ها و وضعیت اجزا قطعی می‌شوند. باید مشخص باشد دکمه غیرفعال، خطای ورودی و گزینه انتخاب‌شده چه رفتاری دارند. همچنین فایل قابل ویرایش و توضیح تعامل‌ها را بخواهید. چند تصویر زیبا برای اجرای دقیق محصول کافی نیست و برنامه‌نویس را مجبور می‌کند جاهای خالی را حدس بزند.
اثر موبایل، راست‌به‌چپ و دیزاین سیستم بر بودجه
طراحی واکنش‌گرا (Responsive) یعنی چیدمان خودش را با اندازه نمایشگر هماهنگ کند. اما موبایل نسخه کوچک‌شده دسکتاپ نیست. روی صفحه باریک ممکن است اولویت محتوا، جای کنترل‌ها و روش نمایش جدول‌ها تغییر کند. همین تفاوت‌ها روی هزینه طراحی رابط کاربری اثر می‌گذارند.
هنگام بررسی قیمت طراحی ui سایت، جدول‌ها، فرم‌های طولانی و منوی موبایل را جدا نگاه کنید؛ معمولاً همین‌ها در موبایل کار تازه می‌خواهند. تعداد اندازه‌های تحویلی و رفتار صفحه بین آن‌ها را هم بنویسید. مثلاً مشخص کنید جدول در نمایشگر باریک پیمایش افقی دارد یا به کارت تبدیل می‌شود.
راست‌به‌چپ هم فقط این نیست که متن از سمت دیگر شروع شود. وقتی فارسی با شماره، ایمیل یا شناسه در یک خط می‌آید، ترتیب خواندن می‌تواند به‌هم بریزد. آینه‌کردن همه نشانه‌ها هم راه‌حل درستی نیست؛ برای مثال فلش بازگشت باید برعکس شود، ولی آیکون پخش ویدیو نه. برای مشخص‌کردن نیازهای چندزبانه، راهنماهای بین‌المللی‌سازی وب مرجع تکمیلی مناسبی هستند.
دسترس‌پذیری هم باید در دامنه روشن باشد؛ یعنی امکان استفاده افراد با توانایی‌ها و ابزارهای متفاوت از محصول. خوانایی متن، تضاد رنگ و نشانه تمرکز صفحه‌کلید (کادری که نشان می‌دهد کاربر با کلید Tab روی کدام بخش است) تصمیم طراحی می‌خواهند. برای تعیین سطح بررسی، راهنمای استانداردهای دسترس‌پذیری وب را ببینید. البته طراحی به‌تنهایی انطباق محصول نهایی را تضمین نمی‌کند، چون بخشی از آن در کد ساخته می‌شود.
دیزاین سیستم (Design system) مجموعه اجزای تکرارپذیر است، همراه قواعدی که می‌گوید هر جزء کجا و چطور به کار برود. یک کتابخانه کوچک از دکمه و فرم با سیستم گسترده یک محصول چندتیمی هم‌دامنه نیست. پیشنهاد من این است: سطح مستندسازی و مسئول نگهداری را پیش از برآورد تعیین کنید، چون سیستم بی‌صاحب به‌مرور از محصول واقعی عقب می‌ماند.
در هزینه طراحی رابط کاربری اپلیکیشن، تفاوت الگوهای تعامل در سیستم‌عامل‌ها و حالت آفلاین هم وارد حساب می‌شوند. با این حال، دو پلتفرم لزوماً دو برابر طراحی نمی‌خواهند؛ معمولاً بخشی از اجزا مشترک می‌ماند و فقط تفاوت‌ها جدا طراحی می‌شوند. برای تعیین تفاوت‌های لازم، راهنمای اصول طراحی رابط و تجربه کاربری اپلیکیشن به تنظیم دامنه کمک می‌کند.
قیمت‌گذاری ساعتی، صفحه‌ای و پروژه‌ای چه تفاوتی دارد؟
مدل ساعتی بر زمان کار تکیه دارد، مدل صفحه‌ای بر واحد طراحی و مدل پروژه‌ای بر دامنه توافق‌شده. کدام برای شما مناسب‌تر است؟ این به میزان قطعیت نیازهایتان بستگی دارد، نه صرفاً به ترجیح تیم اجرا.
مدل | کاربرد مناسب | شرط کنترل بودجه |
|---|---|---|
ساعتی | دامنه متغیر یا بررسی تدریجی | گزارش فعالیت، سقف هزینه و نقطه بازبینی |
صفحه‌ای | قالب‌های هم‌سطح و قابل شمارش | تعریف واحد، حالت‌ها و پیچیدگی |
پروژه‌ای | دامنه روشن و خروجی مشخص | معیار پذیرش و روش مدیریت تغییر |
نرخ ساعتی پایین‌تر لزوماً هزینه طراحی رابط کاربری را در مجموع کم نمی‌کند. زمان لازم، سطح خروجی و میزان بازکاری را هم کنار نرخ ببینید؛ تیمی با نرخ کمتر ممکن است ساعت بیشتری لازم داشته باشد. همچنین در مدل ساعتی مشخص کنید تیم کی نزدیک‌شدن به سقف بودجه را به شما خبر می‌دهد.
قیمت صفحه‌ای برای صفحه‌های مشابه قابل فهم است. با این حال، یک صفحه گزارش تعاملی با فیلتر و نمودار با یک صفحه معرفی متن‌محور هم‌ارز نیست. مدل پروژه‌ای هم به این معنا نیست که هر تغییری بدون بازبینی پذیرفته شود. اگر مسیر اصلی بعد از تأیید عوض شود، باید سازوکار برآورد دوباره از قبل معلوم باشد.
به همین دلیل مدل ترکیبی گاهی انتخاب منطقی‌تری است: اول یک بررسی اولیه محدود، بعد پیشنهاد پروژه‌ای برای دامنه‌ای که روشن شده است. این روش ابهام اولیه را از تعهد به اجرای کل محصول جدا می‌کند.
در مقایسه قیمت طراحی ui ux، مبلغ کل را از برنامه پرداخت جدا کنید. همچنین تحویل مرحله‌ای را روشن کنید: کدام خروجی، با تأیید چه کسی، مبنای ورود به مرحله بعد است؟ پیش‌پرداخت کمتر به‌تنهایی نشانه پیشنهاد بهتر نیست.
سه سناریوی نمونه با دامنه کار مشخص
این سناریوها کاملاً فرضی‌اند و فقط روش نوشتن دامنه را نشان می‌دهند. از روی نام محصول نمی‌شود هزینه طراحی رابط کاربری را رتبه‌بندی کرد. مثلاً فرم یک سایت خدماتی ممکن است از مسیر خرید یک فروشگاه پیچیده‌تر باشد.
سایت معرفی خدمات: دامنه شامل صفحه خانه، فهرست خدمات، جزئیات خدمت و فرم تماس است. طراحی موبایل و دسکتاپ، حالتهای خطا و موفقیت فرم و فایل قابل ویرایش جزو تحویل‌اند. اما تولید محتوا و کدنویسی بیرون از دامنه می‌مانند.
اجزای مشترک: کتابخانه سبک دکمه، ورودی و کارت خدمت.
آزمون: یافتن خدمت مناسب و ارسال فرم تماس.
اصلاحات: ثبت بازخورد تجمیع‌شده روی نسخه مشخص هر قالب.
حالا فرض کنید هر خدمت فرم اختصاصی خودش را دارد؛ مثلاً درخواست مشاوره یک فیلد بارگذاری مدرک می‌خواهد و بقیه نه. آن وقت عبارت «فرم تماس» دیگر دامنه را کامل توصیف نمی‌کند. بنابراین قواعد نمایش فیلدها را پیش از برآورد اضافه کنید.
فروشگاه: دامنه شامل فهرست کالاها، جزئیات کالا، سبد و مسیر خرید مهمان است. حالتهای ناموجود، سبد خالی و پرداخت ناموفق هم لازم‌اند. نمونه تعاملی خرید جزو خروجی است، ولی پنل مدیریت و اتصال پرداخت خارج از دامنه‌اند.
اجزای مشترک: کنترل تعداد، قیمت، کارت کالا و انتخاب ویژگی.
آزمون: خرید مهمان و بازگشت به مسیر پس از پرداخت ناموفق.
اصلاحات: ثبت مسئله‌ها بر اساس مرحله خرید و اولویت اثر بر تکمیل سفارش.
دقت کنید که خرید مهمان با حساب کاربری کامل یکی نیست. سابقه سفارش و مرجوعی هر کدام می‌توانند دامنه مستقلی داشته باشند؛ پس اگر لازمشان دارید، جدا نامشان را بیاورید.
اپلیکیشن رزرو: دامنه شامل جست‌وجو، انتخاب زمان و مدیریت رزرو است. تکمیل ظرفیت، قطع ارتباط و لغو هم باید طراحی داشته باشند. تحقیق روی مسیر رزرو و تفاوت پلتفرم‌ها داخل دامنه‌اند، اما توسعه و پنل ارائه‌دهنده بیرون از آن می‌مانند.
اجزای مشترک: تقویم، زمان قابل انتخاب و وضعیت رزرو.
آزمون: رزرو نوبت و تلاش مجدد پس از قطع ارتباط.
اصلاحات: ثبت تصمیم هر تغییر و اثر آن بر سایر مراحل رزرو.
اصلاحات، تست و هزینه‌های خارج از توافق
دور اصلاح یعنی یک نوبت بازخورد تجمیع‌شده روی یک خروجی مشخص. تعداد دورها تا وقتی خروجی و مسئول جمع‌کردن نظرها تعریف نشده، معنای دقیقی ندارد. صحنه آشنایش این است: مدیر فروش یک نظر می‌دهد، مدیرعامل چند روز بعد نظر دیگری، و مرحله‌ای که تأیید شده بود دوباره باز می‌شود.
همچنین اصلاح مغایرت با توافق را از درخواست تازه جدا کنید. اگر حالت خطایی در دامنه ثبت شده ولی در فایل نیامده، خواستنش درخواست قابلیت جدید نیست. اما اضافه‌کردن ورود با شماره تلفن بعد از تأیید مسیر ورود با ایمیل، ممکن است تغییر دامنه باشد.
آزمون کاربردپذیری یعنی تماشای کاربر وقتی یک کار مشخص را انجام می‌دهد. مثلاً از او می‌خواهید برای آخر هفته نوبت بگیرد و می‌بینید کجا مکث می‌کند. این آزمون با بررسی زیبایی صفحه یا کنترل اجرای کد فرق دارد. پس در پیشنهاد هزینه طراحی رابط کاربری، هدف آزمون، نوع مشارکت‌کنندگان و خروجی گزارش را روشن کنید.
جذب مشارکت‌کننده و هماهنگی جلسه‌ها بر عهده چه کسی است؟
چه کسی متن، تصویر و دارایی‌های خریدنی مثل فونت یا عکس را تأمین می‌کند؟
جلسه‌های اضافه چه شرایطی دارند؟
بازبینی پیاده‌سازی چند مرحله و چه محدوده‌ای را پوشش می‌دهد؟
وقتی دامنه تغییر می‌کند، اول درخواست را مکتوب کنید. تیم باید اثرش را بر هزینه و زمان توضیح دهد و شروع کار به تأیید شما وابسته باشد. با این حال، هر بازخوردی خودبه‌خود هزینه اضافه ندارد. گاهی می‌شود قابلیت تازه را با حذف یک بخش کماولویت جایگزین کرد.
بهترین وقت برای کشیدن مرز تعهدها، پیش از اولین اختلاف است.
زمان‌بندی هم فقط دست تیم طراحی نیست؛ به آماده‌بودن محتوا، دسترسی به کاربران و سرعت پاسخ تصمیم‌گیرنده بستگی دارد. پس موعد بازخورد و اثر تأخیر را ثبت کنید. تأیید ساختار با متن نمونه هم به معنی پذیرش هر حجمی از محتوای بعدی نیست. اگر توضیح هر خدمت از دو خط به دو پاراگراف برسد، چیدمان ممکن است عوض شود.
یک نفر بازخورد ذی‌نفعان را جمع و تعارض‌ها را حل کند. فرستادن نظرهای متناقض به طراح، تصمیم‌گیری داخلی شما را به رفت‌وبرگشت پروژه تبدیل می‌کند.
چگونه دو پیشنهاد قیمت را مقایسه کنیم؟
اول یک دامنه یکسان برای هر دو تیم بفرستید و مبلغ کل را بعد از هم‌سطح‌کردن خروجی‌ها مقایسه کنید. هر مورد نامشخص را «نیازمند توضیح» بنویسید، نه صفر. سکوت یک پیشنهاد درباره نسخه موبایل یعنی ابهام؛ نه رایگان‌بودن آن را نشان می‌دهد، نه حذف قطعی‌اش را.
برای مثال، دو پیشنهاد فرضی را کنار هم بگذارید. اولی فقط نوشته «طراحی صفحات فروشگاه». دومی قالب‌ها، حالتهای خرید، نمونه تعاملی و فایل تحویلی را یکی‌یکی نام برده است. دومی قابل ارزیابی‌تر است، ولی هنوز نمی‌شود درباره ارزش اقتصادی هیچ‌کدام حکم داد.
موضوع مقایسه | پیشنهاد کلی | پیشنهاد ریزشده |
|---|---|---|
قالب‌ها و حالت‌ها | نیازمند توضیح | فهرست قابل تطبیق با دامنه |
تحقیق و آزمون | نیازمند توضیح | فعالیت و خروجی مشخص |
نسخه‌ها و اصلاحات | نیازمند توضیح | دستگاه‌ها و دورهای تعریف‌شده |
تحویل و همراهی توسعه | نیازمند توضیح | نوع فایل و محدوده بازبینی |
اما تفصیل بیشتر هم به‌تنهایی کافی نیست. پیشنهاد مفصل ممکن است فعالیت‌هایی داشته باشد که مرحله فعلی محصول شما لازمشان ندارد. هر ردیف را به هدف پروژه وصل کنید و بپرسید اگر حذف شود، چه چیزی از دست می‌رود. مثلاً سیستم طراحی گسترده برای یک سایت معرفی محدود شاید فقط هزینه نگهداری غیرضروری بسازد.
پیش از انتخاب، تکلیف مالکیت فایل‌ها، سطح دسترسی و امکان ویرایش بعد از پایان همکاری را روشن کنید. مسئول تأیید، موعد بازخورد و معیار پذیرش هم باید مشخص باشند. از نگاه من، فایل طراحی مرتب با نام‌گذاری روشن و توضیح رفتارها به اندازه تصویر نهایی برای تیم توسعه ارزش دارد. در واقع اگر برنامه‌نویس نتواند در فایل پیدا کند دکمه غیرفعال چه شکلی است، بخشی از طراحی تحویل نشده است.
بنابراین برای مقایسه هزینه طراحی رابط کاربری، اول اختلاف دامنه را پیدا کنید و بعد سراغ اختلاف مبلغ بروید. برای ثبت این توافق‌ها، راهنمای ثبت تعهدات در قرارداد طراحی سایت به تنظیم بندهای اجرایی کمک می‌کند.
پکیج‌هایPackages
خروجی این پکیج‌ها فایل طراحی و مستندات است، نه سایت اجراشده. اگر پیاده‌سازی را هم به ما بسپارید، هزینه‌ی این مرحله از قرارداد توسعه کسر می‌شود.
جدول قیمت جاری نیاسا و اطلاعات لازم برای برآورد
قیمت‌های جاری را در جدول قیمت و خدمات طراحی رابط کاربری UI/UX نیاسا ببینید. قیمت هر بسته را همراه فرض‌ها و محدوده همان بسته بخوانید. اما پروژه‌ای که مسیرها، تحقیق یا خروجی‌های متفاوتی دارد، به برآورد جدا نیاز دارد.
اگر همکاری با نیاسا را بررسی می‌کنید، شرح محصول را به فهرستی از کارهای قابل توافق تبدیل کنید. مبلغ فقط بخشی از پیشنهاد است؛ یعنی تحقیق، طراحی، اصلاحات و تحویل هم هر کدام باید دامنه روشنی داشته باشند. الگوی زیر اطلاعات لازم برای درخواست برآورد را یک‌جا جمع می‌کند:
نوع محصول و هدف: سایت، اپلیکیشن یا نرم‌افزار سازمانی؛ کار اصلی که باید آسان‌تر شود.
کاربران و نقش‌ها: چه کسانی از محصول استفاده می‌کنند و چه دسترسی‌هایی دارند؟
مسیرهای مهم: مثل ثبت‌نام، خرید، رزرو یا تأیید درخواست.
قالب‌ها و حالت‌ها: فهرست شناخته‌شده، همراه خطاها و وضعیت‌های خاص.
دستگاه‌ها و زبان‌ها: موبایل، دسکتاپ، پلتفرم‌ها و نیازهای راست‌به‌چپ.
فایل‌های موجود: هویت بصری، محتوای آماده، طراحی قبلی و داده‌های قابل استفاده.
خروجی مطلوب: فایل قابل ویرایش، نمونه تعاملی، اجزای مشترک و همراهی توسعه.
محدودیت‌ها: بازه بودجه، نیاز زمانی و دلیل آن.
هر جا چیزی را نمی‌دانید، همان را صریح بنویسید؛ نبود فهرست کامل مانع شروع گفت‌وگو نیست. برای قدم بعد، همین برگه را آماده کنید و نیازهای ضروری را از گزینه‌هایی که می‌توانند صبر کنند جدا کنید. این تفکیک مبنای روشن‌تری برای برآورد و مذاکره درباره دامنه می‌سازد. دو طرف از همان اول می‌دانند اگر بودجه کم آمد، کدام بخش زودتر کنار می‌رود.
مسیرهای اصلی، دستگاه‌های هدف و فایل‌های موجود را بفرستید تا گفت‌وگو درباره دامنه طراحی و بودجه از اطلاعات مشخص شروع شود.
پرسش‌های پرتکرار
۴آیا تعرفه ثابتی برای طراحی رابط کاربری وجود دارد؟
یک مبلغ واحد بدون تعریف خروجی، معیار قابل اتکایی نیست. تعرفه هر تیم را همراه با فرض‌های آن بخوانید و مشخص کنید تحقیق، نسخه موبایل و اصلاحات در همان مبلغ قرار دارند یا جدا حساب می‌شوند.
قیمت طراحی هر صفحه UI چگونه تعیین می‌شود؟
ابتدا باید روشن شود منظور از صفحه، یک ساختار مستقل است یا نسخه‌ای از یک قالب تکراری. فرم چندمرحله‌ای و صفحه معرفی ساده، حتی با عنوان یک صفحه، حجم کار یکسانی ندارند.
آیا هزینه طراحی UI/UX شامل برنامه‌نویسی هم می‌شود؟
فقط وقتی توسعه صریحاً در پیشنهاد آمده باشد. فایل طراحی و نمونه قابل کلیک، محصول اجرایی نیستند و اتصال داده‌ها یا پرداخت به توافق توسعه نیاز دارد.
چطور بودجه طراحی رابط کاربری را کمتر کنیم؟
مسیرهای ضروری نسخه نخست را نگه دارید و قابلیتهای کماولویت را عقب بیندازید. استفاده دوباره از اجزای مشترک و تجمیع بازخوردها معمولاً از حذف حالتهای خطا یا بررسی مسیر اصلی، انتخاب کمریسکتری است.
