چند تصویر خوشرنگ از سایتها و اپلیکیشنها دیدهاید و حالا باید برای طراحی پروژه خودتان مجری انتخاب کنید. بعضی نمونهکارها در نگاه اول بسیار جذاباند، اما معلوم نیست کاربر در آنها چگونه به هدفش میرسد، کدام بخش را همان تیم طراحی کرده و چه چیزی واقعاً اجرا یا آزمایش شده است. انتخاب فقط بر اساس زیبایی صفحه اول، اطلاعات کافی برای این تصمیم نمیدهد.
برای ارزیابی نمونهکار طراحی UI/UX، بهتر است از یک پروژه مشخص شروع کنید و درباره مسئله، تصمیمها و نتیجه آن سؤال بپرسید. لازم نیست همه جزئیات تخصصی طراحی را بلد باشید؛ کافی است بدانید چه شواهدی بخواهید و از کدام تصویر یا ادعا، چه نتیجهای میتوان گرفت.
این راهنما برای کارفرمایی است که میخواهد پیش از شروع همکاری، توانایی مجری را متناسب با پروژه خودش بررسی کند. تعداد نمونهها یا نام مشتریان میتواند به شناخت سابقه کمک کند، اما کیفیت توضیح یک پروژه مرتبط و امکان بررسی مسیرهای آن، برای تصمیم شما کاربرد بیشتری دارد.

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

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