وقتی برای طراحی UI/UX قیمت می‌گیرید، ممکن است با عددهایی روبه‌رو شوید که تفاوت زیادی با هم دارند.
یک طراح براساس تعداد صفحه قیمت می‌دهد، یک تیم قیمت پروژه‌ای اعلام می‌کند و مجموعه دیگری با نرخ ساعتی یا Retainer کار می‌کند.
این اختلاف فقط به «گران یا ارزان بودن» طراح مربوط نیست. مشکل اصلی این است که عنوان طراحی UI/UX می‌تواند Scopeهای کاملاً متفاوتی را پوشش دهد.
طراحی یک Landing Page با چند Section با طراحی یک Dashboard چندنقشی، اپلیکیشن رزرو یا محصول SaaS قابل مقایسه نیست. حتی دو پروژه با تعداد Screen یکسان هم ممکن است از نظر Research، User Flow، Prototype، Component، State و Responsive Design تفاوت زیادی داشته باشند.
برای مقایسه قیمت UI/UX، اول باید بفهمید دقیقاً چه چیزی قرار است طراحی شود؛ بعد عددها را کنار هم بگذارید.
درباره تصویر این مقاله: مبالغ دلاری روی کاور صرفاً نمونه تصویری برای نمایش سه مدل قیمت‌گذاری هستند و تعرفه یا پیشنهاد قیمت ویرینو محسوب نمی‌شوند.
هزینه طراحی UI/UX به چه چیزهایی بستگی دارد؟
قیمت طراحی رابط و تجربه کاربری معمولاً از ترکیب چند عامل ساخته می‌شود.
مهم‌ترین عوامل عبارت‌اند از:
- نوع محصول؛ سایت، اپلیکیشن، Dashboard، SaaS یا Web App
- تعداد Screen یا Template یکتا
- پیچیدگی User Flow
- نیاز به UX Research
- وجود یا نبود Wireframe
- سطح Fidelity طراحی
- تعداد Stateها و حالت‌های مختلف هر Screen
- نسخه Mobile، Tablet و Desktop
- Prototype و Interaction Design
- Design System یا Component Library
- تعداد Revisionها
- نیاز به تست کاربر
- تحویل Design Handoff برای Developer
به همین دلیل عددی مثل «هر صفحه ۲ میلیون تومان» بدون تعریف صفحه اطلاعات کاملی نمی‌دهد.
یک صفحه ساده About Us با یک Dashboard که Table، Filter، Empty State، Error State، Permission و Interactionهای مختلف دارد یک واحد طراحی یکسان نیست.
مدل‌های رایج قیمت‌گذاری UI/UX
سه مدل اصلی بیشتر دیده می‌شوند: قیمت صفحه‌ای، قیمت پروژه‌ای و قیمت ساعتی.
قیمت‌گذاری صفحه‌ای
در این مدل هزینه براساس تعداد Screen یا Page محاسبه می‌شود.
مزیتش این است که برای پروژه‌های ساده قابل فهم است. اگر Scope مشخص باشد، کارفرما سریع‌تر می‌تواند Budget را تخمین بزند.
اما مشکل از جایی شروع می‌شود که «صفحه» تعریف نشده باشد.
مثلاً Home، Product Detail و Checkout از نظر پیچیدگی یکسان نیستند.
همچنین باید مشخص شود Stateهای مختلف یک Screen جدا حساب می‌شوند یا داخل همان Scope هستند.
قیمت‌گذاری صفحه‌ای برای سایت‌های Marketing، Landing Pageها و پروژه‌هایی با Templateهای محدود معمولاً قابل استفاده‌تر است.
قیمت‌گذاری پروژه‌ای
در مدل پروژه‌ای، کل Scope بررسی می‌شود و یک قیمت برای مجموعه کار اعلام می‌شود.
این مدل برای پروژه‌ای که Deliverableهایش از قبل مشخص‌اند معمولاً مناسب‌تر است.
مثلاً:
- User Flow
- Wireframe
- UI Design
- Responsive Version
- Prototype
- Component Library
- Handoff
در این حالت کارفرما به‌جای شمردن Screenها، خروجی کل پروژه را مقایسه می‌کند.
قیمت‌گذاری ساعتی
مدل ساعتی زمانی منطقی‌تر است که Scope از ابتدا کاملاً ثابت نیست.
مثلاً یک تیم Product ممکن است هر هفته Feature جدید داشته باشد و Designer داخل Sprintهای مداوم کار کند.
در چنین پروژه‌ای تعیین قیمت ثابت برای شش ماه آینده می‌تواند غیرواقعی باشد.
مدل ساعتی یا Retainer برای Product Design، UX Consulting و تیم‌هایی که Roadmap دائماً تغییر می‌کند انعطاف بیشتری دارد.
بازه قیمت UI/UX در بازار ۱۴۰۵ چقدر است؟
یک «نرخ رسمی واحد» برای کل بازار وجود ندارد و نمونه‌های عمومی سال ۱۴۰۵ فاصله زیادی با هم دارند.
نمونه‌های عمومی سنجاق در بررسی ۱۹ مهر ۱۴۰۵، طراحی UI/UX پروژه‌ای را در دسته طراحی گرافیک حدود ۳٫۵ تا ۱۰ میلیون تومان و در دسته ساخت اپلیکیشن حدود ۱۲٫۵ تا ۲۵ میلیون تومان نشان می‌دهند. نرخ ساعتی طراحی رابط وب‌اپ و نرم‌افزار دسکتاپ حدود ۵۰۰ هزار تا ۱٫۵ میلیون تومان، وب‌سایت واکنش‌گرا حدود ۵۰۰ هزار تا ۱٫۷۵ میلیون تومان و اپلیکیشن حدود ۱ تا ۲ میلیون تومان است.
این اعداد نمونه‌های اعلام‌شده توسط یک پلتفرم خدماتی در تاریخ بررسی‌اند؛ دامنه کار و سطح خروجی آن‌ها یکسان نیست و قیمت نهایی به نیاز پروژه و توافق طرفین بستگی دارد.
این اختلاف نشان می‌دهد مقایسه صرف عددها می‌تواند گمراه‌کننده باشد.
یک Marketplace ممکن است سفارش‌های کوچک و Freelancer-based را کنار هم جمع کند، درحالی‌که آژانس قیمت پروژه‌ای شامل Research، Management، Design System، QA و Handoff بدهد.
بنابراین این عددها را باید نمونه بازار دید، نه «تعرفه استاندارد UI/UX».
آیا قیمت براساس تعداد صفحه منصفانه است؟
گاهی بله؛ همیشه نه.
اگر پروژه یک سایت شرکتی با ۸ Template مشخص باشد، قیمت‌گذاری صفحه‌ای می‌تواند ساده و شفاف باشد.
اما در Product Design تعداد Screen به‌تنهایی Metric خوبی نیست.
فرض کنید یک اپ فقط ۶ Screen اصلی دارد، اما هر Screen چند حالت دارد:
- Loading
- Empty
- Error
- Success
- Permission Denied
- First-time User
- Returning User
در ظاهر هنوز «۶ صفحه» داریم، ولی طراحی واقعی بسیار بیشتر از شش Frame است.
به همین دلیل بهتر است در Proposal علاوه بر تعداد Screen، Complexity Level و Stateها هم مشخص شوند.
UI ارزان‌تر است یا UX؟
این سؤال کمی گمراه‌کننده است، چون UI و UX دو Package کاملاً جدا نیستند.
در مقاله UI و UX چیست؟ توضیح داده‌ایم که UI بیشتر به Interface و Visual Layer مربوط است، درحالی‌که UX روی Flow، ساختار، رفتار و تجربه استفاده تمرکز دارد.
اگر پروژه فقط «ظاهر چند Screen» را می‌خواهد، Scope کوچک‌تر است.
اما اگر تیم باید این کارها را هم انجام دهد:
- Interview
- User Research
- Competitor Review
- Journey Mapping
- Information Architecture
- User Flow
- Wireframe
- Usability Testing
طبیعتاً زمان و هزینه بیشتر می‌شود.
در واقع چیزی که گاهی به‌عنوان «طراحی UI ارزان» فروخته می‌شود ممکن است فقط Visual Design باشد، نه فرایند کامل UI/UX.
سه سناریوی نمونه برای برآورد هزینه
سناریو اول: Landing Page
نیاز:
- یک صفحه
- Responsive
- Hero
- Feature Section
- Social Proof
- FAQ
- CTA
اگر Content و Brand Direction از قبل آماده باشند، این پروژه معمولاً Scope محدودی دارد و مدل صفحه‌ای یا پروژه‌ای برای آن منطقی است.
اما اگر قبل از UI نیاز به Positioning، Content Structure، Wireframe و CRO Analysis داشته باشد، Scope بزرگ‌تر می‌شود.
سناریو دوم: سایت شرکتی
فرض کنید سایت ۱۰ تا ۱۵ صفحه دارد، اما فقط ۵ Template یکتا:
- Home
- Service
- Blog Listing
- Article
- Contact
در اینجا نباید لزوماً برای ۱۵ صفحه «طراحی یکتا» قیمت بگیرید.
اگر بعضی صفحات از یک Template استفاده می‌کنند، Scope باید براساس Template و Component واقعی محاسبه شود.
سناریو سوم: Dashboard یا SaaS
اینجا تعداد Screen معمولاً معیار ضعیف‌تری است.
Dashboard ممکن است:
- چند Role داشته باشد.
- Permission متفاوت داشته باشد.
- Table و Filter پیچیده داشته باشد.
- Chart و KPI داشته باشد.
- Bulk Action داشته باشد.
- Stateهای متعدد داشته باشد.
برای این نوع پروژه، قیمت پروژه‌ای یا ساعتی معمولاً تصویر واقعی‌تری از Scope می‌دهد.
Design System چقدر روی قیمت اثر دارد؟
اگر پروژه کوچک باشد، ممکن است یک Component Library سبک کافی باشد.
اما برای محصولی که قرار است رشد کند، Design System می‌تواند Scope مستقل داشته باشد.
Design System فقط ساخت Button و Input نیست.
ممکن است شامل این موارد باشد:
- Color Tokens
- Typography Scale
- Spacing Rules
- Grid
- Component Variants
- Stateها
- Accessibility Rules
- Documentation
ساخت این سیستم در ابتدا هزینه دارد، اما برای Product Team می‌تواند سرعت طراحی و توسعه Featureهای بعدی را بالا ببرد.
اگر پروژه واقعاً به این سطح از سیستم نیاز ندارد، ساخت Design System سنگین فقط هزینه اضافی ایجاد می‌کند.
چطور Proposalهای UI/UX را مقایسه کنیم؟
عدد نهایی را آخر مقایسه کنید.
اول این سؤال‌ها را کنار هم بگذارید:
- Research داخل Scope هست یا نه؟
- Wireframe تحویل داده می‌شود؟
- چند Screen یکتا طراحی می‌شود؟
- Stateهای مختلف داخل قیمت هستند؟
- Responsive Version شامل چه Deviceهایی است؟
- Prototype ساخته می‌شود؟
- Design System یا Component Library وجود دارد؟
- چند Revision تعریف شده است؟
- Source File تحویل داده می‌شود؟
- Developer Handoff داخل Scope است؟
- QA بعد از Development وجود دارد؟
- UX Testing داخل قرارداد است یا Add-on؟
وقتی پاسخ این سؤال‌ها روشن شود، ممکن است متوجه شوید دو Proposal که یکی دو برابر دیگری قیمت دارد در واقع دو Scope متفاوت را می‌فروشند.
برای بودجه محدود چه چیزی را حذف نکنیم؟
وقتی Budget محدود است، اولین واکنش معمولاً حذف UX و شروع مستقیم UI است.
این تصمیم همیشه اقتصادی نیست.
در بعضی پروژه‌ها می‌توان Scope را کوچک کرد بدون اینکه Foundation حذف شود.
مثلاً:
- Research سبک‌تر
- تمرکز روی Critical Flowها
- Design System کوچک‌تر
- Prototype فقط برای Flowهای پرریسک
- طراحی Templateهای اصلی به‌جای تمام صفحات
اما حذف کامل User Flow، Information Architecture یا Responsive Thinking می‌تواند بعداً هزینه Development را بالا ببرد.
هدف باید کم کردن Scope باشد، نه حذف تصمیم‌های بنیادی.
قیمت UI/UX در ویرینو چطور باید بررسی شود؟
برای پروژه UI/UX بهتر است برآورد از Scope شروع شود.
در خدمات طراحی UI/UX ویرینو نوع پروژه، تعداد Template یا Screen، Complexity، Responsive Design، Research، Prototype و Design System باید قبل از اعلام قیمت نهایی بررسی شوند.
به همین دلیل این مقاله یک قیمت ثابت برای همه پروژه‌ها اعلام نمی‌کند.
قیمت صفحه‌ای برای بعضی پروژه‌ها مناسب است، قیمت پروژه‌ای برای بعضی دیگر و در Product Design مستمر ممکن است مدل ساعتی یا Retainer منطقی‌تر باشد.
اگر UI/UX بخشی از پروژه Website است، مقاله هزینه طراحی سایت در ۱۴۰۵ کمک می‌کند سهم Design را در Scope کلی پروژه بهتر ببینید.
جمع‌بندی
هزینه طراحی UI/UX در ۱۴۰۵ یک عدد ثابت ندارد.
تعداد Screen مهم است، اما به‌تنهایی کافی نیست. Research، User Flow، Stateها، Responsive Design، Prototype، Design System و نوع محصول می‌توانند Scope را چند برابر تغییر دهند.
برای پروژه ساده، قیمت صفحه‌ای می‌تواند شفاف باشد. برای پروژه با Scope مشخص، مدل پروژه‌ای قابل پیش‌بینی‌تر است. برای Product Design مداوم، قیمت ساعتی یا Retainer انعطاف بیشتری دارد.
نمونه‌های عمومی بازار ۱۴۰۵ هم فاصله زیادی با هم دارند؛ از پروژه‌های چندمیلیونی تا قراردادهای چند ده میلیونی. دلیل اصلی همین تفاوت Scope است.
قبل از اینکه بپرسید «هر صفحه UI چند است؟» بپرسید «این صفحه دقیقاً چند تصمیم، State و Interaction دارد؟»
