شرکتی را انتخاب کنید که بتواند برای هر نمونهکارش مسئله، نقش تیم و نتیجه را توضیح بدهد، پیش از طراحی از کاربران و کسبوکار شما بپرسد، و خروجیها و مالکیت فایلها را در قرارداد روشن بنویسد. زیبایی نمونهکار و قیمت پایین، معیار تصمیم نیستند.
این راهنما برای صاحب کسبوکار یا مدیر محصولی است که چند شرکت را در دست مقایسه دارد و میخواهد پیش از امضا بداند چه چیزی را بسنجد، چه چیزی را در پیشنهاد مکتوب ببیند و کجا باید متوقف شود. در پایان یک چکلیست بله/خیر با قاعدهٔ حذف دارید که میتوانید همان روز روی پیشنهادهای رسیده اجرا کنید.
چرا نمونهکارِ زیبا و قیمتِ پایین شما را به شرکت درست نمیرساند
همه میگویند پیش از انتخاب، نمونهکارها را ببینید. توصیه بدی نیست، اما ناقص است و در عمل گمراه میکند. نمونهکار خروجیِ نهایی را نشان میدهد، نه تصمیمهایی که به آن خروجی رسیدهاند. و UX درست در همان تصمیمها اتفاق میافتد.
نمونهکار چه چیزی را نشان میدهد و چه چیزی را پنهان میکند
یک اسلاید صیقلی نشان میدهد که تیم سلیقهٔ بصری دارد. نشان نمیدهد مسئله چه بوده، چه کسی تصمیم گرفته، کاربر در کدام نقطه سردرگم میشده و طرح بعد از آزمون چه تغییری کرده است. در عمل دیدهایم که کارفرما از ظاهر یک پروژه راضی میشود و سه ماه بعد، وقتی کاربران واقعی سفارش را نیمهکاره رها میکنند، میفهمد زیبایی و کاربردپذیری دو چیز جدا بودهاند.
یک نکتهٔ تفکیکی هم لازم است. هویت بصری برند با طراحی رابط کاربری یکی نیست؛ اگر هنوز مرز این دو برایتان روشن نیست، توضیح هویت بصری برند و تفاوتش با رابط کاربری را بخوانید تا نمونهکار لوگو و پالت رنگ را بهجای نمونهکار UX نخرید.
آزمون سهسؤاله برای هر نمونهکار
موضع ما صریح است: نمونهکار زیبا مدرک نیست؛ توضیحِ مسئله و نقش مدرک است. برای هر نمونهکاری که شرکت نشانتان میدهد سه سؤال بپرسید:
- مسئلهٔ این پروژه دقیقاً چه بود؟ (پاسخ «طراحی یک اپلیکیشن» مسئله نیست؛ مسئله مثلاً ریزش کاربر در مرحلهٔ ثبت سفارش است.)
- نقش شما در آن چه بود؟ کدام بخش را خود شما طراحی کردید و کدام را مشتری یا شرکت دیگری انجام داد؟
- چه چیزی در اثر یافتهها عوض شد؟ کدام فرضِ اولیه غلط درآمد و طرح چطور اصلاح شد؟
اگر شرکت به هر سه پاسخ روشن میدهد و میتواند مدارکش را نشان بدهد، نمونهکار برایتان ارزش دارد. اگر فقط تصویر دارد و جملههای کلی، آن نمونهکار را در ارزیابی صفر حساب کنید.
چرا تعداد پروژه و سابقه، بهتنهایی معیار نیست
شرکتی که چند ده پروژه تحویل داده، ممکن است هر بار همان فرایند سطحی را تکرار کرده باشد. سابقه فقط وقتی ارزش دارد که از دلش فرایندی قابلتوضیح بیرون آمده باشد. به همین دلیل «چند سال و چند پروژه» را سؤال اول نکنید؛ سؤال اول این است که «در پروژهٔ آخر، کدام تصمیم را بعد از آزمون با کاربر عوض کردید؟».
یک قاعدهٔ دیگر: هر شرکتی که بدون شواهد، افزایش فروش یا نرخ تبدیل را وعده بدهد، همانجا از فهرست خط بخورد. طراحی یکی از عوامل نتیجه است، نه ضامنِ آن. اگر در انتخاب شرکتها در حوزههای دیگر هم میخواهید همین منطق را به کار ببرید، راهنمای انتخاب شرکتها چارچوب عمومیتری میدهد.
معیارهای انتخاب شرکت UI/UX به ترتیب اهمیت
همهٔ معیارها هموزن نیستند. بعضی تصمیمسازند و نبودنشان یعنی حذف؛ بعضی خوباند و در دعوای دو شرکتِ نزدیک به هم کفهٔ ترازو را میچرخانند؛ بعضی هم مطلوباند ولی نباید تصمیم را به دست بگیرند. جدول زیر ده معیار را با همین سه وزن میآورد.
| معیار | وزن | پرسش کلیدی |
|---|---|---|
| نمونهکارِ قابلتوضیح | حیاتی | مسئله، نقش و نتیجهٔ هر نمونه را میتوانید مستند بگویید؟ |
| فرایند طراحی | حیاتی | پیش از طراحی، تحقیق و مسیر کاربر دارید یا مستقیم سراغ صفحهها میروید؟ |
| ترکیب تیم و نقطهٔ پاسخگویی | حیاتی | چه کسانی روی پروژه کار میکنند و چه کسی پاسخگوی من است؟ |
| قرارداد، خروجیها و مالکیت | حیاتی | خروجیها، دامنه، دورهای بازبینی و مالکیت فایلها کجا نوشته شده؟ |
| آزمون کاربردپذیری | مهم | طرح با چه کسانی و چگونه آزمایش میشود و یافتهها چطور اعمال میشود؟ |
| همکاری با تیم توسعه | مهم | تحویل به توسعهدهنده و پاسخ به پرسشهای اجرایی در قرارداد هست؟ |
| دسترسپذیری و طراحی واکنشگرا | مهم | اندازههای مختلف صفحه و کاربران با نیازهای متفاوت دیده شدهاند؟ |
| مشارکت کارفرما | مهم | نقطههای بررسی مشخصاند و بازخورد مستند میشود؟ |
| ارتباط و تناسب | مهم | پرسش دقیق میپرسند یا فقط سلیقهٔ بصری پیشنهاد میدهند؟ |
| تجربهٔ صنعت مشابه | مطلوب | مخاطب و پیچیدگی محصول شبیه کار من است؟ |
معیارهای حیاتی: فرایند، تیم، قرارداد و مالکیت
چهار معیارِ اول تصمیمساز هستند. شرکتی که فرایندش را نمیتواند توضیح بدهد، یا قرارداد مبهم میدهد، با هر نمونهکار درخشانی کنار گذاشته میشود.
فرایند یعنی ترتیبی مشخص: شناخت کسبوکار و کاربر، ساخت پرسونا و مسیر کاربر، وایرفریم، پروتوتایپ و آزمون. لازم نیست هر پروژه همهٔ این مراحل را با عمق یکسان طی کند، اما شرکت باید بگوید کدام را برای پروژهٔ شما حذف میکند و چرا.
دربارهٔ تیم، فقط «تیم مجرب داریم» کافی نیست. بپرسید طراح UX کیست، طراح UI کیست، پژوهشگری هست یا نه، و مدیر پروژه چه کسی است. مهمتر از همه: وقتی چیزی خراب شد، با چه کسی حرف میزنید؟ خروجیها و مالکیت فایلها (فایلهای Figma، راهنمای رابط و سیستم طراحی) هم باید پیش از شروع نوشته شده باشد، نه بعد از تحویل.
معیارهای مهم: آزمون کاربردپذیری، همکاری با تیم توسعه، دسترسپذیری
اینها کیفیت نتیجه را بالا میبرند ولی در پروژههای کوچک ممکن است با دامنهٔ محدود تعدیل شوند. آزمون کاربردپذیری را مبهم نپذیرید؛ بپرسید طرح با چند کاربر و با چه سناریویی دیده میشود و گزارشش چه شکلی است. همکاری با توسعه یعنی تحویل مرتب (Developer Handoff) و پاسخگویی به پرسشهای اجرایی، چون بسیاری از طرحهای خوب در همین مرحله خراب میشوند. دسترسپذیری یعنی طرح برای صفحههای مختلف و کاربران متنوع فکر شده باشد، نه فقط برای نمایشگر طراح.
مشارکت کارفرما و ارتباط و تناسب هم در همین دستهاند. شرکت خوب از همان جلسهٔ اول سؤال میپرسد: کاربر شما کیست، مهمترین کاری که باید بتواند انجام بدهد چیست. شرکتی که با «چه رنگی دوست دارید» شروع میکند، راهکار را از سلیقه میسازد نه از مسئله.
معیارهای مطلوب ولی نه تعیینکننده: تجربه صنعت مشابه، ابزارها، اندازه شرکت
تجربه در صنعت شما خوب است چون زمان یادگیریِ دامنه را کم میکند. ولی شرکتی با فرایند قوی و صنعت متفاوت معمولاً از شرکتی با صنعت مشابه و فرایند ضعیف بهتر عمل میکند. ابزار هم همینطور؛ شرکتها تقریباً همه از ابزارهای شناختهشده استفاده میکنند و اسم ابزار نباید معیار شود. اندازهٔ شرکت هم فقط وقتی مهم است که پروژه ظرفیت و پایداری تیم را بطلبد.
بدهبستانها: هر انتخابی چیزی را از شما میگیرد
هیچ گزینهای بیهزینه نیست. مهم این است که بدانید چه چیزی را کنار میگذارید.
شرکت تخصصی UI/UX در برابر آژانس خدمات کامل
شرکت تخصصی معمولاً در پژوهش و آزمون عمیقتر است ولی هماهنگی با توسعه و بازاریابی را باید خودتان یا تیم دیگری انجام دهد. آژانس خدمات کامل همهچیز را زیر یک سقف میآورد، ولی اغلب UX در آن یکی از خدمات جانبی است و عمق پژوهش کمتر. برای مرور شرکتهای متخصص، دستهٔ خدمات طراحی UI/UX را ببینید؛ اگر محصول شما کل تجربهٔ دیجیتال را میطلبد، شرکتهای طراحی محصول دیجیتال گزینههای گستردهتری دارند.
تیم متخصص صنعت شما در برابر تیم با فرایند قوی
تیم متخصص صنعت سریعتر شروع میکند، اما ممکن است همان الگوهای رایج بازار را تکرار کند. تیم با فرایند قوی کندتر وارد میشود، ولی فرضیهها را با کاربر میسنجد. اگر محصولتان در صنعتی با قواعد خاص (مثلاً مالی یا پزشکی) است، تجربه وزن بیشتری میگیرد. در غیر این صورت فرایند مقدم است.
پروژه با قیمت ثابت در برابر همکاری ساعتی یا ماهانه
قیمت ثابت قابلپیشبینی است، ولی فقط وقتی دامنه دقیق نوشته شده باشد؛ هر تغییر میشود درخواست تغییر پروژه (Change Request) و قیمت جدید. همکاری ساعتی یا ماهانه انعطاف میدهد و برای محصولی که مدام تغییر میکند مناسبتر است، اما بدون کنترل، بودجه میتواند از دستتان در برود.
فریلنسر هم وقتی کافی است که کار محدود و مشخص است (مثلاً بازطراحی چند صفحه) و خودتان میتوانید تحقیق و تحویل را مدیریت کنید. ریسکش وقتی بالا میرود که پروژه تحقیق، آزمون و همراهی با توسعه میخواهد و همهچیز به یک نفر وابسته است.
بودجه طراحی UI/UX به تومان: چه چیزی قیمت را تغییر میدهد
ما در این مقاله بازهٔ عددی نمیدهیم، چون هزینهٔ این کار به دامنه، تیم و عمق پژوهش وابسته است و عدد کلی، گمراهکننده میشود. قیمت دقیق فقط از پیشنهاد مکتوب شرکتها به تومان به دست میآید. آنچه میتوانیم بگوییم، عواملی است که قیمت را بالا و پایین میکنند.
عواملی که هزینه را بالا و پایین میکنند
- تعداد صفحهها و جریانهای کاربری (ثبتنام، پرداخت، پیگیری سفارش و مانند آن)
- عمق تحقیق کاربر و تعداد مصاحبهها یا جلسههای مشاهده
- انجام یا حذف آزمون کاربردپذیری با کاربر واقعی
- تعداد دورهای بازبینی که در قرارداد پوشش داده شده
- مستندات و تحویل به توسعهدهنده
- ساخت سیستم طراحی و راهنمای رابط، و شرایط مالکیت فایلها
چرا دو پیشنهاد با دو قیمت قابل مقایسه نیستند
تصور کنید صاحب یک فروشگاه اینترنتی در تهران برای اپلیکیشن موبایلش دو پیشنهاد میگیرد. اولی ارزانتر است و فقط طرح نهایی صفحهها را تحویل میدهد. دومی گرانتر است و تحقیق، پروتوتایپ، آزمون و تحویل به تیم توسعه را هم شامل میشود. اگر این دو را فقط با رقم مقایسه کند، ارزانتر برنده میشود. اما بعد از تحویل، تیم برنامهنویسی پرسشهایی دارد که کسی جواب نمیدهد، کاربران جایی گیر میکنند که هیچکس آزمایش نکرده، و صاحب کسبوکار ناچار است بخشی از کار را دوباره بخرد. پیشنهاد ارزانتر در واقع قیمتِ بخشی از کار بود.
هزینههای پنهان معمولاً از سه جا میآیند: دور بازبینی اضافه، تغییر دامنه، و پشتیبانی پس از تحویل. هر سه را باید پیش از امضا در متن پیشنهاد ببینید.
فهرست کوتاه و پرسشهایی که پیش از قرارداد باید بپرسید
مقایسهٔ بیش از چند شرکت، وقت را هدر میدهد. ساخت فهرست کوتاه سه مرحله دارد.
سه مرحله ساخت فهرست کوتاه
- غربال از دایرکتوری. از میان شرکتهای دسته، سراغ پروفایلهای تأییدشده بروید و نظرهای راستیآزماییشده را بخوانید. روش امتیازدهی ما در متدولوژی رتبهبندی وانوریکس و نحوهٔ بررسی نظرها در سیاست بررسی نظرها آمده است؛ رتبه بدون دانستن معیارش کاری از پیش نمیبرد.
- آزمون سهسؤاله. از هر شرکت برای دو یا سه نمونهکار مسئله، نقش و نتیجه را بخواهید و پاسخهای مبهم را حذف کنید.
- درخواست پیشنهاد مکتوب. از شرکتهای باقیمانده یک پیشنهاد فنی-مالی با شرح دامنه بگیرید. اگر RFP کوتاهی نوشتهاید، همهٔ شرکتها را با همان مقایسه کنید.
پرسشها و پاسخهایی که باید در پیشنهاد یا قرارداد ببینید
اینها را شفاهی نپذیرید؛ باید مکتوب باشند.
- خروجیها دقیقاً کداماند: وایرفریم، پروتوتایپ، طرح نهایی، فایلهای طراحی، راهنمای رابط، مستندات توسعهدهنده؟
- چند دور بازبینی در قیمت هست و بعد از آن چه میشود؟
- مالکیت فایلهای طراحی با کیست و فایلهای قابلویرایش تحویل میشوند یا فقط خروجی تصویری؟
- تغییر دامنه چگونه ثبت و قیمتگذاری میشود؟
- آیا تیم طراحی در تحویل به توسعهدهندگان و پاسخ به پرسشهای بعدی همراهی میکند؟
- آزمون کاربردپذیری با چه کاربرانی انجام میشود و گزارشش چه شکلی است؟
اگر در مرحلهٔ دریافت پیشنهاد به کمک نیاز داشتید، میتوانید از صفحهٔ تماس با ما راهنمایی بخواهید.
چکلیست بله/خیر با امتیازدهی
برای هر شرکت به این گزارهها پاسخ بله یا خیر بدهید. معیارهای حیاتی را با وزن بیشتر حساب کنید.
| گزاره | وزن | بله/خیر |
|---|---|---|
| برای هر نمونهکار مسئله، نقش و نتیجه را مستند توضیح داد | حیاتی | |
| فرایند مشخص با مرحلهٔ شناخت کاربر ارائه کرد | حیاتی | |
| اعضای تیم و نقطهٔ پاسخگویی معلوم است | حیاتی | |
| خروجیها، دورهای بازبینی و مالکیت فایلها مکتوب است | حیاتی | |
| برنامهٔ آزمون با کاربر دارد | مهم | |
| همراهی با تیم توسعه را در قرارداد آورده | مهم | |
| دسترسپذیری و طراحی واکنشگرا را پوشش میدهد | مهم | |
| نقطههای بررسی و مستندسازی بازخورد مشخص است | مهم | |
| سؤالهایش دربارهٔ مسئله بود، نه سلیقهٔ بصری | مهم | |
| تجربهٔ صنعت مشابه دارد | مطلوب |
قاعدهٔ توقف ساده است: هر «خیر» در یک معیار حیاتی یعنی حذف، حتی اگر بقیهٔ ردیفها «بله» باشند. شرکتهایی که از این صافی رد شدند را بر اساس تعداد «بله» در معیارهای مهم و مطلوب مرتب کنید. اگر هماهنگی طراحی با توسعه برایتان مهم است، شرکتهایی را هم ببینید که کار توسعه را در طراحی محصول دیجیتال کنار طراحی ارائه میکنند.
پرچمهای قرمز و گرانترین اشتباه در این مسیر
نشانههایی که باید از آنها فاصله بگیرید
- وعدهٔ تضمین. هر شرکتی که فروش یا نرخ تبدیل را تضمین میکند و برایش مستند ندارد، وعدهٔ توخالی میدهد.
- قیمتگذاری مبهم. رقمی بدون شرح دامنه، تعداد صفحه و خروجیها قابل مقایسه نیست.
- ناتوانی در توضیح فرایند. اگر نمیتوانند بگویند هفتهٔ اول چه میکنند، هفتهٔ دهم هم نمیدانند.
- نمونهکار بدون شرح. تصویر بدون مسئله و نقش، مدرک نیست.
- طراحی بدون هیچ مرحلهٔ شناخت کاربر. یعنی فرضها بدون آزمایش به صفحه تبدیل میشوند.
گرانترین اشتباه: امضای قرارداد بدون دامنه و مالکیت روشن
پرهزینهترین خطا، انتخاب بر پایهٔ زیبایی و قیمت است و کشف مشکل بعد از تحویل. در آن لحظه دیگر قدرت چانهزنی ندارید: خروجیهایی که فرض میکردید شامل قیمت بودهاند، مجزا حساب میشوند؛ فایلهای قابلویرایش در اختیار شما نیست؛ تیم توسعه بدون راهنما کار میکند و تغییرات هزینهٔ تازه میآورد.
راه دوری ساده و پیش از شروع است: خروجیها، دورهای بازبینی، تغییر دامنه و مالکیت فایلها را بنویسید و قبل از پرداخت اول بررسی کنید. انتخاب مناسب در نهایت به نوع پروژه، بودجه و شیوهٔ همکاری موردنیاز شما بستگی دارد؛ چکلیست بالا جای آن را نمیگیرد، فقط کمک میکند تصمیمتان بر مدرک استوار باشد.
پرسشهای متداول
پیشنهاد مکتوب شرکت UI/UX را چطور با پیشنهاد شرکت دیگر به تومان مقایسه کنم؟
آیا میتوانم از شرکت UI/UX بخواهم قبل از قرارداد یک بخش از کار را نمونه طراحی کند؟
اگر تیم طراحی و تیم برنامهنویسی دو شرکت جدا باشند، چه چیزی را باید در قرارداد طراحی بنویسم؟
پرداخت به شرکت UI/UX را چطور مرحلهبندی کنم که ریسکم کم شود؟
چطور بفهمم نظرهای ثبتشده برای یک شرکت UI/UX در وانوریکس قابلاعتماد است؟
به این مقاله امتیاز دهید
اولین نفری باشید که امتیاز میدهد
درباره نویسنده




