معرفی
فرایند مصاحبه برای موقعیت‌های طراحی رابط کاربری و تجربه کاربری میان شرکتها یکسان نیست. حتی عنوان‌هایی مانند UI Designer ،UX Designer ،Product Designer و UI/UX Designer نیز دامنه مسئولیت ثابت و استانداردی ندارند. در یک شرکت، این نقش ممکن است عمدتاً بر طراحی رابط و تعامل متمرکز باشد اما در شرکتی دیگر، پژوهش کاربر، آزمون کاربردپذیری، طراحی سیستم طراحی یا همکاری نزدیک با تیم محصول نیز بخشی از مسئولیت‌های آن باشد.
به همین دلیل، پیش از مصاحبه شرح شغل را با دقت بخوانید و مشخص کنید کارفرما از این موقعیت چه خروجی‌هایی و چه سطحی از مسئولیت را انتظار دارد. سؤال‌ها و شایستگی‌های مطرح‌شده در این راهنما، مجموعه‌ای از موارد رایج در مصاحبه‌ها هستند و لزوماً همه آن‌ها در هر فرایند استخدامی ارزیابی نمی‌شوند.
آماده‌سازی رزومه و نمونه‌کار
در بسیاری از موقعیت‌ها، پیش از برگزاری مصاحبه تخصصی، رزومه و نمونه‌کار شما بررسی می‌شود. نمونه‌کار مناسب نباید فقط مجموعه‌ای از خروجی‌های بصری باشد، بلکه باید نشان دهد چگونه مسئله را فهمیده‌اید، چه سهمی در پروژه داشته‌اید، چه گزینه‌هایی را بررسی کردهاید، با چه محدودیت‌هایی روبه‌رو بوده‌اید و تصمیم‌های طراحی خود را بر چه مبنایی گرفته‌اید.
اگر در پروژه از داده یا پژوهش واقعی استفاده نکرده‌اید، فرضهای خود را شفاف بیان کنید و نتیجه‌ای ساختگی به پروژه نسبت ندهید. صداقت درباره محدودیتهای پروژه، از ادعای دستاوردهایی که قابل اثبات نیستند ارزشمندتر است.
ممکن است کارفرما در مراحل بعدی بخواهد Prototype یا بخشی از فایل Figma را مشاهده کند. در این شرایط، فقط فایل‌هایی را ارائه دهید که مجوز نمایش آن‌ها را دارید. اگر پروژه تحت تعهد محرمانگی است، می‌توانید فرایند و تصمیم‌های قابل‌اشتراک را با یک Case Study ناشناس یا نمونه‌ای دیگر توضیح دهید بدون آنکه اطلاعات داخلی سازمان قبلی را افشا کنید.
شناخت مراحل مصاحبه و موضوعات ارزیابی
گفتوگوی اولیه ممکن است با مسئول جذب، مدیر محصول، مدیر طراحی یا یکی دیگر از اعضای تیم انجام شود. در این مرحله معمولاً درباره سابقه کاری، نوع محصولاتی که روی آن‌ها کار کردهاید، سطح موقعیت شغلی، شیوه همکاری و محدوده مسئولیت‌ها صحبت می‌شود.
در مرحله تخصصی، توانایی شما در توضیح فرایند تصمیم‌گیری اهمیت زیادی دارد. برای هر پروژه آماده باشید به این پرسش‌ها پاسخ دهید:
مسئله اصلی پروژه چه بود؟
چه شواهد، داده‌ها یا اطلاعاتی در اختیار داشتید؟
چه راه‌حل‌ها و گزینه‌هایی را بررسی کردید؟
چه محدودیت‌هایی بر تصمیم‌های طراحی اثر گذاشتند؟
چرا در نهایت یک راه‌حل را انتخاب کردید؟
چه بازخوردی دریافت کردید و بر اساس آن چه تغییراتی در طرح ایجاد شد؟
هدف این گفت‌وگو صرفاً سنجش توانایی شما در طراحی یک رابط زیبا نیست؛ کارفرما میخواهد بداند چگونه مسئله را تحلیل میکنید، درباره انتخاب‌های خود چطور استدلال می‌آورید و در مواجهه با محدودیت‌ها به چه نحوی تصمیم می‌گیرید.
آمادگی برای تمرین‌های عملی طراحی
برخی کارفرمایان از روش‌هایی مانند Design Exercise، نقد یک رابط کاربری، Whiteboarding یا حل یک مسئله طراحی محدود استفاده می‌کنند. هدف چنین تمرین‌هایی باید ارزیابی مهارت‌های مرتبط با همان موقعیت و بررسی شیوه تفکر شما باشد.
پیش از شروع تمرین، درباره زمان مورد انتظار، نوع خروجی، معیارهای ارزیابی و نحوه ارائه نتیجه سؤال کنید. این اطلاعات کمک می‌کنند زمان خود را متناسب با انتظارات کارفرما مدیریت کنید و به‌جای تمرکز صرف بر ظاهر خروجی، فرایند حل مسئله را نیز به‌خوبی نشان دهید.
مرور دسترس‌پذیری و همکاری با تیم توسعه
در موضوع دسترس‌پذیری، صرفاً به بررسی کنتراست رنگ‌ها اکتفا نکنید. در طراحی وب، موارد دیگری نیز اهمیت دارند که ازجمله آن‌ها می‌توانیم به موارد زیر اشاره کنیم:
وضعیت و ترتیب Focus هنگام پیمایش با صفحه‌کلید
امکان دسترسی به عناصر تعاملی بدون استفاده از ماوس
وجود Label مناسب برای فیلدهای فرم
قابل مشاهده ماندن عنصری که Focus را دریافت کرده است.
اندازه و فاصله مناسب اهداف تعاملی
پیش‌بینی جایگزین برای تعامل‌هایی مانند Drag and Drop
اجرای فنی همه این موارد لزوماً بر عهده طراح نیست اما طراح باید بتواند نیازهای دسترس‌پذیری را تشخیص دهد، آن‌ها را در طراحی لحاظ کند و برای پیادهسازی با تیم توسعه هماهنگ شود.
در همکاری با مدیر محصول و توسعه‌دهندگان نیز بهتر است به‌جای ارائه یک مرزبندی ثابت برای مسئولیت‌ها، توضیح دهید چگونه نقش‌ها و انتظارات را در یک تیم واقعی روشن میکنید. طراح باید در فهم مسئله و ارتقای کیفیت تجربه کاربر مشارکت داشته باشد اما مالکیت تصمیم‌های محصول، پژوهش، سیستم طراحی و پیادهسازی ممکن است در شرکت‌های مختلف میان نقش‌های متفاوت تقسیم شده باشد.
انتخاب مسیر مناسب برای ادامه آمادگی
اگر هنوز در مهارت‌هایی مانند پژوهش کاربر، طراحی تعامل یا ساخت نمونه‌کار اولیه شکاف جدی دارید، بهتر است ابتدا نقشه راه یادگیری این شغل را مرور کنید. اما اگر مهارت‌های اصلی را کسب کردهاید و مسئله شما سنجش آمادگی برای ارسال درخواست شغلی و آماده‌سازی مدارک است، راهنمای ورود به این شغل مسیر مناسب‌تری برای ادامه خواهد بود.
شایستگی‌های مورد سنجش
برای آشنایی بهتر با این راهنما، توجه به موارد زیر می‌تواند مفید باشد.
-
تحلیل مسئله کاربر و محصول
توانایی تبدیل یک درخواست مبهم مانند «صفحه پرداخت را بهتر کنید» به مسئله، کاربر هدف، سناریو، محدودیت و معیار قابل بررسی.
-
طراحی جریان و معماری اطلاعات
توانایی توضیح مسیر کاربر، ترتیب اطلاعات، نقاط تصمیم، مسیرهای جایگزین و وضعیت‌های خطا یا خالی در یک جریان واقعی.
-
طراحی رابط کاربری
تسلط بر سلسله‌مراتب بصری، فاصله‌گذاری، تایپوگرافی، رنگ، حالت‌های اجزا و یکدستی رابط؛ نه صرفاً ساخت صفحه‌های زیبا.
-
نمونه‌سازی و کار با Figma
توانایی ساخت فایل منظم، استفاده درست از کامپوننت و واریانت، طراحی حالت‌های تعاملی و ساخت پروتوتایپ برای سناریوهای مهم.
-
استدلال پشت تصمیم‌های طراحی
توانایی دفاع از تصمیم با شواهد کاربر، نیاز محصول، محدودیت فنی یا اصول کاربردپذیری، همراه با پذیرش امکان اصلاح تصمیم.
-
آزمون کاربردپذیری و استفاده از بازخورد
توانایی تعریف سناریوی آزمون، مشاهده رفتار کاربر، تفکیک نظر از شواهد و اولویتبندی اصلاحهای طراحی.
-
همکاری با مدیر محصول و توسعهدهنده
توانایی روشن‌کردن رفتار اجزا، نسخه واکنشگرا، حالت بارگذاری، خطا و داده خالی و مذاکره درباره محدودیتهای پیادهسازی.
-
سیستم طراحی و مستندسازی
درک تفاوت میان کامپوننت، الگو و صفحه؛ و توانایی ایجاد یا نگهداری قواعدی که رابط را در چند جریان یکدست نگه می‌دارند.
-
دسترس‌پذیری و طراحی واکنشگرا
شناخت نیازهای پایه مانند کنتراست، وضعیت فوکوس، اندازه هدف لمس، متن جایگزین و تفاوت چیدمان در موبایل و وب.
برنامه آماده‌سازی
در ادامه، مهم‌ترین موارد این بخش به تفکیک معرفی شده‌اند.
-
ارائه نمونه‌کار به شکل مطالعه موردی
برای دو پروژه، روایت کوتاه و قابل دفاع آماده کنید: مسئله چه بود، کاربر چه کسی بود، چه شواهدی داشتید، چه گزینه‌هایی بررسی شد، تصمیم نهایی چه بود و چه چیزی پس از بازخورد اصلاح شد. اگر پروژه شخصی است، صریح بگویید کدام بخش فرضی بوده و داده واقعی نداشته‌اید.
صفحه نهایی را نقطه شروع ارائه نکنید. ابتدا جریان، محدودیت و تصمیم مهم را نشان دهید. سپس، با نمایش چند فریم کلیدی در Figma، جزئیات رابط را توضیح دهید.
-
مرور جریان‌های کاربر و حالت‌های غیرعادی
یک جریان پرکاربرد مانند ثبت‌نام، ورود، جست‌وجو، پرداخت یا تکمیل فرم را انتخاب کنید. برای آن مسیر اصلی، اعتبارسنجی ورودی، خطای سرویس، قطع اتصال، بارگذاری، داده خالی، لغو عملیات و بازگشت کاربر را مرور کنید.
در مصاحبه، فقط گفتن «حالت خطا طراحی می‌کنم» کافی نیست. بتوانید توضیح دهید پیام خطا چه زمانی نمایش داده می‌شود، کاربر چه اقدامی می‌تواند انجام دهد و چگونه از حذف یا تکرار ناخواسته داده جلوگیری میکنید.
-
Figma و کیفیت فایل تحویلی
یک فایل نمونه را پاک‌سازی کنید: نام صفحه‌ها و فریمها روشن باشد، کامپوننت‌های تکراری به‌جای نسخه‌های پراکنده استفاده شوند و واریانت‌ها برای حالت‌های معمول مانند پیش‌فرض، غیرفعال، خطا و بارگذاری قابل تشخیص باشند.
پروتوتایپ را با یک سناریوی مشخص آزمایش کنید. مصاحبهگر ممکن است درباره دلیل ساختار فایل، نحوه تحویل به توسعهدهنده یا تفاوت کامپوننت و صفحه سؤال کند.
-
پژوهش کاربر و آزمون کاربردپذیری
برای یک مسئله، هدف پژوهش، گروه کاربر، پرسش‌های مصاحبه و سناریوی آزمون کاربردپذیری آماده کنید. میان گفته کاربر، رفتار مشاهده‌شده و برداشت شخصی خود تفاوت بگذارید.
یک نمونه از تغییر طراحی بر پایه مشاهده کاربر آماده داشته باشید. برای مثال، کاربر نتوانسته فیلتر را پیدا کند و شما جایگاه، برچسب یا ترتیب گزینه‌ها را تغییر داده‌اید.
-
سیستم طراحی و یکدستی رابط
تفاوت توکن طراحی، کامپوننت، واریانت و الگوی صفحه را مرور کنید. بتوانید توضیح دهید چه زمانی ساخت کامپوننت جدید منطقی است و چه زمانی افزودن یک واریانت یا استفاده از الگوی موجود، از پراکندگی جلوگیری میکند.
برای یک دکمه یا فیلد فرم، حالت‌های لازم مانند قرارگیری نشانگر روی جزء، فوکوس، غیرفعال، بارگذاری و خطا را در ذهن داشته باشید؛ نیاز دقیق هر پلتفرم ممکن است متفاوت باشد.
-
همکاری با تیم فنی
برای یک صفحه طراحی‌شده، مشخصات تحویل را مرور کنید: رفتار واکنشگرا، ترتیب اجزا در عرض‌های مختلف، متن‌های طولانی، وضعیت بدون داده و محدودیتهای تصویر یا محتوا. لازم نیست برنامه‌نویس باشید، اما باید طرح قابل پیادهسازی تحویل دهید.
یک نمونه از زمانی آماده کنید که محدودیت فنی باعث تغییر طرح شد و شما چگونه تجربه اصلی کاربر را حفظ کردید.
چک‌لیست آماده‌سازی
پیش از ادامه، فهرست زیر را مرور کنید و مطمئن شوید همه موارد را پوشش داده‌اید:
- لینک نمونه‌کار و دسترسی مشاهده به فایل‌های Figma را پیش از مصاحبه آزمایش کرده‌ام.
- برای دو پروژه، مسئله، کاربر، محدودیت، تصمیم و نتیجه را آماده توضیح دارم.
- یک جریان کاربر را همراه با حالت بارگذاری، خطا و داده خالی مرور کرده‌ام.
- پروتوتایپ پروژه اصلی را از ابتدا تا انتهای سناریو بررسی کرده‌ام.
- فایل Figma پروژه اصلی نام‌گذاری و ساختار قابل فهمی دارد.
- می‌توانم تفاوت وایرفریم، طرح نهایی و نمونه تعاملی را توضیح دهم.
- برای یک تصمیم طراحی، شواهد کاربر یا محدودیت محصولی مشخص دارم.
- یک نمونه از اصلاح طرح پس از بازخورد کاربر یا توسعهدهنده آماده کرده‌ام.
- حالت‌های اصلی اجزای رابط پروژه‌ام را بررسی کرده‌ام.
- نسخه موبایل یا رفتار واکنش‌گرای پروژه‌ام را آماده توضیح دارم.
- درباره محصول، کاربران احتمالی و تیم طراحی شرکت تحقیق اولیه کرده‌ام.
- پرسش‌های مشخصی درباره فرایند طراحی و تحویل به توسعه آماده کرده‌ام.
سئوالاتی که از شما می‌پرسند
-
نمونه‌کار
یکی از پروژه‌های نمونه‌کارتان را از مسئله اولیه تا طرح نهایی توضیح دهید.
توانایی روایت فرایند طراحی، تشخیص مسئله، سهم واقعی شما و ارتباط تصمیم‌های رابط با نیاز کاربر و محصول سنجیده می‌شود.
راهنمای پاسخ و نمونه پاسخ
پروژه‌ای را انتخاب کنید که در آن نقش شما روشن باشد. مسئله، کاربر هدف، محدودیت مهم، جریان انتخاب‌شده و تصمیمی را بگویید که بیشترین اثر را داشته است. مشخص کنید کدام بخش بر پایه داده، بازخورد یا فرض طراحی شده و چه چیزی پس از آزمون یا بازبینی تغییر کرده است.
در پروژه طراحی فرایند ثبت‌نام یک سرویس آموزشی، مسئله اصلی رها کردن فرم در مرحله اطلاعات تکمیلی بود. ابتدا مسیر موجود و پیام‌های پشتیبانی را مرور کردم و دیدم کاربران درباره دلیل درخواست بعضی اطلاعات ابهام دارند. فرم را به دو مرحله تقسیم کردم، دلیل نیاز به اطلاعات را کنار فیلدها آوردیم و اعتبارسنجی را در همان مرحله نمایش دادیم. در بازبینی نمونه تعاملی، ترتیب یک فیلد برای کاربران مبهم بود. بنابراین، آن را به مرحله دوم منتقل کردم. خروجی نهایی فقط صفحه فرم نبود. پس، مسیر خطا، بارگذاری و بازگشت کاربر نیز مشخص شد.
-
فنی
برای طراحی یک فرم ثبت‌نام، چه حالت‌هایی را علاوه بر حالت عادی در نظر می‌گیرید؟
دقت شما در طراحی وضعیت‌های واقعی رابط و درک او از خطا، بازخورد، بارگذاری و دسترس‌پذیری بررسی می‌شود.
راهنمای پاسخ و نمونه پاسخ
به حالت فوکوس، ورود داده، اعتبارسنجی، خطای هر فیلد، ارسال موفق، ارسال ناموفق، غیرفعال‌بودن دکمه و بارگذاری اشاره کنید. توضیح دهید خطا باید نزدیک فیلد، قابل فهم و همراه با راه اصلاح باشد. اگر ثبت‌نام به پیامک یا ایمیل وابسته است، مسیر تأخیر دریافت کد، ارسال مجدد و تغییر شماره نیز اهمیت دارد.
برای هر فیلد، حالت پیش‌فرض، فوکوس، مقدار واردشده و خطا را طراحی می‌کنم. در ارسال فرم، دکمه باید وضعیت بارگذاری داشته باشد تا کاربر چندبار آن را نزند. اگر سرویس خطا داد، پیام کلی مانند «خطا رخ داد» کافی نیست، باید تا حد ممکن بگوید کاربر چه اقدامی انجام دهد. برای رمز عبور نیز راهنمای حداقل شرایط و امکان نمایش یا پنهان کردن رمز را بررسی می‌کنم. در نسخه موبایل، اندازه ناحیه لمس و نمایش مناسب صفحه‌کلید را هم در نظر می‌گیرم.
-
موقعیتی
مدیر محصول میخواهد چند قابلیت جدید در صفحه اصلی اضافه شود، اما شما نگران شلوغی و افت اولویت‌های کاربر هستید. چه میکنید؟
توانایی مدیریت تعارض محصولی، اولویتبندی محتوا و تبدیل اختلاف نظر به فرض قابل بررسی سنجیده می‌شود.
راهنمای پاسخ و نمونه پاسخ
ابتدا هدف هر قابلیت و کاربر هدف آن را روشن کنید. میان اقدام اصلی صفحه و قابلیت‌های پشتیبان تمایز بگذارید. گزینه‌هایی مانند اولویتبندی بصری، نمایش تدریجی، بخش‌بندی محتوا یا آزمایش محدود را پیشنهاد دهید. مخالفت را به سلیقه شخصی تقلیل ندهید و اثر آن بر تکمیل وظیفه کاربر و فهم صفحه را توضیح دهید.
ابتدا از مدیر محصول می‌پرسم هر قابلیت برای چه کاربر و چه هدفی اضافه می‌شود. سپس جریان اصلی صفحه را مشخص می‌کنم. برای مثال، اگر بیشتر کاربران برای ادامه خرید وارد می‌شوند، اقدام خرید باید همچنان واضح بماند. یک نسخه با اولویتبندی مشخص و یک نسخه با نمایش تدریجی قابلیت‌های کم‌اهمیت‌تر آماده می‌کنم. اگر امکان داده‌گیری وجود داشته باشد، معیارهایی مانند نرخ شروع اقدام اصلی و تعامل با بخش جدید را پیشنهاد می‌دهم تا تصمیم فقط بر پایه ترجیح شخصی نباشد.
-
فنی
چه زمانی یک الگوی جدید را به سیستم طراحی اضافه میکنید و چه زمانی از الگوی موجود استفاده میکنید؟
درک شما از تعادل میان یکدستی، انعطاف‌پذیری، هزینه نگهداری و نیاز واقعی محصول بررسی می‌شود.
راهنمای پاسخ و نمونه پاسخ
توضیح دهید چطور ابتدا هدف، رفتار و تفاوت واقعی نیاز جدید را با الگوهای موجود مقایسه میکنید. تغییر ظاهری کوچک معمولاً با واریانت یا توکن حل می‌شود، نه ساخت کامپوننت مستقل. الگوی جدید زمانی توجیه دارد که رفتار، ساختار یا زمینه استفاده متفاوت و تکرارشونده باشد و قواعد استفاده‌اش مستند شود.
اگر یک دکمه فقط رنگ متفاوتی برای یک وضعیت معتبر دارد، ابتدا بررسی می‌کنم آیا با واریانت و توکن موجود قابل حل است. کامپوننت مستقل زمانی می‌سازم که ساختار یا رفتار آن با دکمه‌های فعلی متفاوت باشد و در چند جریان تکرار شود. پیش از افزودن، نام، کاربرد مجاز، حالت‌ها و نمونه استفاده را مشخص می‌کنم زیرا در غیر این صورت، سیستم طراحی به مجموعه‌ای از اجزای مشابه و نامشخص تبدیل می‌شود.
-
نمونه‌کار
در یکی از پروژه‌ها، چه بازخوردی باعث شد تصمیم طراحی خود را تغییر دهید؟
مصاحبهگر میخواهد ببیند شما بازخورد را چگونه به شواهد قابل اقدام تبدیل میکند و آیا به طرح اولیه وابستگی افراطی دارد.
راهنمای پاسخ و نمونه پاسخ
یک بازخورد مشخص از کاربر، پشتیبانی، مدیر محصول یا توسعهدهنده انتخاب کنید. بگویید چه چیزی مشاهده یا گزارش شد، چرا آن را مهم دانستید، چه فرضی تغییر کرد و اصلاح چه اثری بر جریان یا رابط گذاشت. میان یک درخواست سلیقه‌ای و بازخورد تکرارشونده یا مرتبط با وظیفه کاربر تفاوت بگذارید.
در یکی از پروژه‌ها، برای فرایند ثبت سفارش یک فروشگاه اینترنتی، ابتدا اطلاعات ارسال را در یک فرم نسبتاً طولانی قرار داده بودم. در تست پروتوتایپ متوجه شدم چند کاربر هنگام رسیدن به بخش انتخاب روش ارسال مکث می‌کنند و بعضی از آن‌ها تصور می‌کنند باید قبل از دیدن هزینه ارسال، همه اطلاعات را کامل کنند.
این بازخورد باعث شد فرض اولیه‌ام را که «نمایش همه اطلاعات در یک صفحه فرایند را سریع‌تر میکند» دوباره بررسی کنم. جریان را به دو بخش مشخص‌تر تقسیم کردم و هزینه و گزینه‌های ارسال را در زمانی نمایش دادم که کاربر اطلاعات لازم برای محاسبه آن را وارد کرده بود.
بعد از این تغییر، مسیر برای کاربران آزمایشی قابل‌فهم‌تر شد و سؤال‌های کمتری درباره مرحله بعد داشتند. این تجربه به من یاد داد هر بازخوردی را مستقیماً به تغییر طراحی تبدیل نکنم؛ ابتدا بررسی کنم آیا به انجام وظیفه اصلی کاربر مربوط است و آیا در رفتار چند کاربر یا شواهد دیگر نیز دیده می‌شود.
-
رفتاری
توسعهدهنده گفته طرح شما در زمان انتشار قابل پیادهسازی نیست. چگونه موضوع را پیش می‌برید؟
شیوه همکاری شما با تیم فنی، درک محدودیت پیادهسازی و توانایی حفظ هدف تجربه کاربر در شرایط واقعی بررسی می‌شود.
راهنمای پاسخ و نمونه پاسخ
توضیح دهید ابتدا محدودیت را دقیق می‌پرسید: زمان، معماری، داده، عملکرد یا وابستگی به سرویس. سپس هدف تجربه کاربر را از شکل فعلی طرح جدا میکنید و گزینه‌های ساده‌تر را بررسی میکنید. خروجی گفت‌وگو باید شامل تصمیم روشن، حالت‌های اثرپذیر و به‌روزرسانی فایل طراحی باشد.
ابتدا نمی‌پرسم «چرا نمی‌شود؟». بلکه می‌پرسم کدام بخش و به چه دلیل پرهزینه است. در یک پروژه، نمایش هم‌زمان چند وضعیت در کارت‌ها به داده‌ای نیاز داشت که در نسخه نخست موجود نبود. هدف من این بود که کاربر وضعیت سفارش را بفهمد، نه الزاماً همان چیدمان اولیه را ببیند. با توسعهدهنده توافق کردیم در نسخه اول وضعیت‌ها ساده‌تر باشند و جزئیات در صفحه سفارش نمایش داده شود. سپس فریمها و متن‌های رابط را مطابق تصمیم جدید به‌روزرسانی کردم.
-
فنی
برای واکنش‌گراکردن یک صفحه، چه چیزهایی را بررسی میکنید؟
توانایی طراحی برای عرض‌های مختلف و شناخت تغییرات ساختاری، خوانایی و تعامل در موبایل و وب سنجیده می‌شود.
راهنمای پاسخ و نمونه پاسخ
صرفاً کوچک‌کردن اجزا را مطرح نکنید. اولویت محتوا، تغییر تعداد ستون‌ها، ترتیب اطلاعات، اندازه هدف لمس، متن‌های بلند، تصاویر، نوارهای ثابت و رفتار جدول‌ها یا فیلترها را توضیح دهید. بگویید برای عرض‌های مختلف، تصمیم را با سناریوی استفاده و نه فقط ابعاد یک دستگاه می‌گیرید.
در صفحه فهرست محصول، ابتدا مشخص می‌کنم اقدام اصلی کاربر چیست. در دسکتاپ ممکن است فیلتر کنار فهرست باشد، اما در موبایل آن را به پنل جداگانه منتقل می‌کنم تا فضای محتوا حفظ شود. کارت‌ها از چند ستون به یک ستون یا دو ستون تغییر می‌کنند و اطلاعات کم‌اهمیت‌تر خلاصه می‌شود. متن دکمه‌ها و نام محصول را با محتوای بلند بررسی می‌کنم و مطمئن می‌شوم ناحیه لمس و فاصله اجزا برای موبایل مناسب است.
-
موقعیتی
پس از انتشار یک جریان جدید، کاربران در مرحله‌ای غیرمنتظره رها می‌کنند. چگونه بررسی را شروع میکنید؟
توانایی ترکیب داده محصول، مشاهده رفتار کاربر، فرضیه‌سازی و اولویتبندی اصلاح‌ها در یک مسئله واقعی سنجیده می‌شود.
راهنمای پاسخ و نمونه پاسخ
مرحله دقیق رها کردن، نوع کاربر، دستگاه و تغییرات هم‌زمان را مشخص کنید. سپس فرضیه‌هایی مانند ابهام در محتوا، خطای فنی، هزینه پنهان، پیچیدگی فرم یا اعتماد ناکافی بسازید. توضیح دهید برای هر فرضیه چه شواهدی می‌خواهید و قبل از بازطراحی گسترده، چگونه مسئله را اعتبارسنجی میکنید.
ابتدا بررسی می‌کنم رهاکردن در کدام گام و برای چه گروهی بیشتر رخ می‌دهد. برای مثال، این مسئله فقط برای کاربران موبایل یا کاربران جدید رخ می‌دهد. سپس تغییرات اخیر، خطاهای فنی و بازخورد پشتیبانی را مرور می‌کنم. اگر رهاکردن در ورود اطلاعات پرداخت باشد، فرضیه‌هایی مانند ابهام در مبلغ نهایی یا خطای اعتبارسنجی می‌سازم. با مشاهده چند کاربر یا بررسی جلسه‌های پشتیبانی، مسئله را محدود می‌کنم. بعد، اصلاح کم‌ریسک مانند شفاف کردن مبلغ یا تغییر متن خطا را اولویت می‌دهم و اثر آن را پس از انتشار بررسی می‌کنم.
-
فرهنگی
در همکاری با مدیر محصول، چه زمانی با اولویت پیشنهادی او مخالفت میکنید؟
توانایی گفتوگوی حرفه‌ای درباره تصمیم محصول، مرزبندی مسئولیت طراحی و حفظ همکاری در اختلاف نظر بررسی می‌شود.
راهنمای پاسخ و نمونه پاسخ
پاسخ را بر موقعیتی بنا کنید که اولویت پیشنهادی، انجام وظیفه اصلی کاربر، فهم محتوا یا اعتماد کاربر را آسیب می‌زند. توضیح دهید مخالفت را با مسئله، شواهد و گزینه جایگزین مطرح میکنید. بپذیرید که تصمیم نهایی ممکن است محصولی یا تجاری باشد، اما اثر آن باید روشن و ثبت‌شده باشد.
در یکی از پروژه‌ها، مدیر محصول پیشنهاد داد یک بنر تبلیغاتی و دو قابلیت فرعی در بالای صفحه اصلی قرار بگیرند، چون از نظر تجاری اهمیت بالایی داشتند. مسئله این بود که داده‌های استفاده نشان می‌داد بیشتر کاربران وارد این صفحه می‌شوند تا سریع به سفارش‌های فعال خود دسترسی پیدا کنند و این تغییر، اقدام اصلی آن‌ها را به پایین صفحه منتقل می‌کرد.
به‌جای مخالفت مستقیم، ابتدا هدف تجاری هر بخش را مشخص کردم و بعد تأثیر آن را روی مسیر اصلی کاربر توضیح دادم. پیشنهاد کردم یکی از قابلیت‌ها در همان صفحه باقی بماند، اما موارد کم‌اولویت‌تر در بخش دیگری نمایش داده شوند و بنر نیز طوری طراحی شود که با اقدام اصلی رقابت بصری نداشته باشد.
در نهایت، اولویت تجاری حفظ شد اما ساختار صفحه طوری تغییر کرد که دسترسی به سفارش‌ها همچنان واضح بماند. اگر تیم تصمیم دیگری می‌گرفت، آن را می‌پذیرفتم، اما تلاش می‌کردم اثر احتمالی تصمیم بر تجربه کاربر و شاخص‌های مرتبط ثبت و بعد از انتشار بررسی شود.
برای من مخالفت با مدیر محصول زمانی منطقی است که بتوانم نشان دهم یک اولویت پیشنهادی احتمالاً به انجام وظیفه اصلی کاربر، فهم محتوا یا اعتماد او آسیب می‌زند. مخالفت را بر پایه مسئله و شواهد مطرح می‌کنم و در کنار آن گزینه جایگزین هم ارائه می‌دهم.
-
نمونه‌کار
اگر پروژه نمونه‌کار شما واقعی نبوده، چگونه اعتبار تصمیم‌های طراحی را توضیح میدهید؟
صداقت داوطلب، توانایی مدیریت فرض‌ها و درک محدودیت پروژه‌های تمرینی بررسی می‌شود.
راهنمای پاسخ و نمونه پاسخ
واقعی نبودن پروژه را پنهان نکنید. مسئله فرضی، مخاطب فرضی و محدودیتهای انتخاب‌شده را مشخص کنید. نشان دهید برای کاهش حدس، از بررسی محصولات مشابه، گفتوگوی محدود با کاربران بالقوه یا آزمون نمونه تعاملی استفاده کردهاید. ادعای نتیجه تجاری یا داده واقعی نکنید، مگر واقعاً در اختیار داشته‌اید.
این پروژه برای نمونه‌کار شخصی بود و به داده داخلی محصول دسترسی نداشتم. فرض کردم کاربر هدف، فردی است که برای نخستین بار میخواهد نوبت آنلاین بگیرد. برای شناخت الگوها، چند سرویس مشابه را بررسی کردم و با سه کاربر بالقوه درباره مسیر فعلی‌شان گفت‌وگو کردم. نتیجه را به‌عنوان پژوهش جامع ارائه نمی‌کنم، اما از آن برای تعیین ابهام‌های اصلی و ساخت نمونه تعاملی استفاده کردم. پس از مشاهده استفاده آزمایشی، مرحله انتخاب زمان را ساده‌تر کردم.
-
فنی
دسترس‌پذیری را در طراحی یک رابط وب چگونه در نظر می‌گیرید؟
شناخت پایه شما از ملاحظات دسترس‌پذیری و توانایی تبدیل آن به تصمیم‌های قابل تحویل به تیم فنی بررسی می‌شود.
راهنمای پاسخ و نمونه پاسخ
به کنتراست رنگ، اتکا نکردن صرف به رنگ برای انتقال خطا یا وضعیت، حالت فوکوس، ترتیب منطقی حرکت با صفحه‌کلید، برچسب‌گذاری فرم و اندازه مناسب هدف‌های تعاملی اشاره کنید. توضیح دهید دسترس‌پذیری فقط چک کردن رنگ نیست و باید در جریان، محتوا و اجزای سیستم طراحی دیده شود.
در فرم‌ها، خطا را فقط با قرمز نشان نمی‌دهم و متن راهنما نیز می‌گذارم. برای دکمه‌ها و لینک‌ها، حالت فوکوس واضح در نظر می‌گیرم تا استفاده با صفحه‌کلید ممکن باشد. در نمودار یا وضعیت سفارش، رنگ را با آیکون یا متن همراه می‌کنم. همچنین بررسی می‌کنم کنتراست متن و پس‌زمینه مناسب باشد و برچسب فیلدها فقط به placeholder وابسته نباشند. این موارد را در کامپوننت‌ها مشخص می‌کنم تا در صفحه‌های بعدی نیز تکرار شوند.
-
رفتاری
نمونه‌ای از زمانی بگویید که زمان کافی برای پژوهش کامل نداشتید.
توانایی تصمیم‌گیری در محدودیت زمانی، تشخیص ریسک و انتخاب روش‌های سبک‌تر اعتبارسنجی بررسی می‌شود.
راهنمای پاسخ و نمونه پاسخ
موقعیتی را انتخاب کنید که زمان انتشار یا وابستگی محصولی روشن بوده است. بگویید چه پرسش پژوهشی را ضروری دانستید، چه روش سبک‌تری انتخاب کردید و چه فرضی برای بررسی پس از انتشار باقی ماند. نشان دهید کمبود زمان را معادل حذف کامل شناخت کاربر نگرفته‌اید.
در یکی از پروژه‌ها، فقط چند روز تا انتشار نسخه اولیه باقی مانده بود و زمان کافی برای اجرای پژوهش کامل نداشتیم. مسئله اصلی ما این بود که مطمئن شویم کاربران مسیر ثبت درخواست را می‌فهمند و در انتخاب مرحله بعد دچار ابهام نمی‌شوند.
به‌جای حذف کامل پژوهش، چند گفتوگوی کوتاه با کاربران بالقوه انجام دادم و پروتوتایپ را با چند سناریوی اصلی بررسی کردم. همچنین، پیام‌های پشتیبانی و بازخوردهای قبلی را مرور کردم تا ببینم کدام بخش‌های فرایند بیشتر باعث سردرگمی شده‌اند.
نتیجه این بررسی سریع باعث شد قبل از انتشار، متن یکی از مراحل و ترتیب دو فیلد را تغییر دهیم. بااین‌حال، بعضی فرض‌ها مانند مناسب‌بودن کل ساختار جریان را قطعی در نظر نگرفتیم و آن‌ها را برای بررسی بعد از انتشار ثبت کردیم.
بعد از انتشار نیز قرار بود رفتار کاربران و بازخوردهای جدید را بررسی کنیم تا اگر همان نقاط اصطکاک تکرار شدند، پژوهش عمیق‌تری انجام دهیم. در چنین شرایطی سعی می‌کنم محدودیت زمان را بپذیرم، اما شناخت کاربر را به‌طور کامل حذف نکنم و مشخص کنم کدام تصمیمها هنوز بر پایه فرض هستند.
-
موقعیتی
از شما خواسته می‌شود یک صفحه موجود را «مدرن‌تر» کنید. پیش از شروع طراحی چه پرسش‌هایی می‌پرسید؟
توانایی تبدیل درخواست مبهم به هدف طراحی و پرهیز از بازطراحی صرفاً ظاهری سنجیده می‌شود.
راهنمای پاسخ و نمونه پاسخ
درباره هدف کسب‌وکار، کاربر اصلی، وظیفه مهم صفحه، مشکل فعلی، بازخوردهای موجود، محدودیت برند و محدودیت فنی سؤال کنید. مشخص کنید «مدرن‌تر» می‌تواند به معنی یکدستی بصری، خوانایی، ساده‌سازی جریان یا به‌روزرسانی سیستم طراحی باشد و بدون معیار، قابل سنجش نیست.
ابتدا می‌پرسم مشکل فعلی از نگاه کاربر یا کسب‌وکار چیست و آیا داده یا بازخوردی درباره آن داریم. سپس می‌پرسم اقدام اصلی صفحه چیست، چه کسانی بیشتر از آن استفاده می‌کنند و آیا محدودیت برند یا سیستم طراحی وجود دارد. ممکن است منظور از مدرن‌تر فقط رنگ و ظاهر باشد، اما شاید مسئله واقعی شلوغی محتوا یا دشواری پیدا کردن اقدام اصلی باشد. قبل از طراحی، این برداشت را با مدیر محصول هماهنگ می‌کنم.
-
فرهنگی
به نظر شما مرز مسئولیت طراح UI/UX و مدیر محصول در تصمیم‌های محصولی کجاست؟
درک شما از همکاری بین‌رشته‌ای، مسئولیت‌پذیری در تجربه کاربر و پرهیز از مالکیت‌طلبی بر تصمیم‌های محصول بررسی می‌شود.
راهنمای پاسخ و نمونه پاسخ
توضیح دهید مدیر محصول معمولاً مسئله، اولویت و محدودیتهای کسب‌وکار را هدایت میکند و طراح مسئولیت شکل دادن به تجربه، جریان و کیفیت تعامل را دارد. با این حال، طراح باید در تعریف مسئله و سنجش اثر راه‌حل مشارکت کند، نه اینکه فقط سفارش صفحه دریافت کند. تصمیم‌های مهم باید با گفت‌وگو و شواهد مشترک گرفته شوند.
مدیر محصول را مسئول تصمیم‌گیری تنها نمی‌دانم و طراح را هم صرفاً مجری صفحه نمی‌بینم. مدیر محصول معمولاً هدف کسب‌وکار، اولویت‌ها، محدودیت زمان و شاخص موفقیت را روشن میکند. من مسئول طراحی جریان، فهم موانع کاربر، کیفیت تعامل و بیان پیامدهای تجربه کاربر هستم. در تعریف مسئله و انتخاب راه‌حل باید با هم کار کنیم. اگر درباره یک تصمیم اختلاف داشته باشیم، ابتدا فرض‌ها و شواهد هر دو طرف را روشن می‌کنم، گزینه‌های ممکن را با اثرشان بر کاربر و محصول مقایسه می‌کنیم و در صورت امکان با داده، آزمون محدود یا بازخورد کاربر تصمیم می‌گیریم. حتی اگر تصمیم نهایی تجاری باشد، اثر آن بر تجربه کاربر باید شفاف و ثبت‌شده بماند.
-
نمونه‌کار
چگونه مطمئن می‌شوید طرحی که تحویل داده‌اید در محصول نهایی درست پیادهسازی شده است؟
مسئولیت‌پذیری شما تا مرحله انتشار، کیفیت تحویل طراحی به تیم توسعه و توانایی تشخیص تفاوت‌های مؤثر بر تجربه کاربر سنجیده می‌شود.
راهنمای پاسخ و نمونه پاسخ
به مرور طراحی با توسعهدهنده پیش از شروع، مستندسازی رفتارهای مهم، پاسخ‌گویی هنگام پیادهسازی و بازبینی نسخه آزمایشی اشاره کنید. تفاوت‌های جزئی بصری را از تفاوت‌هایی که مسیر، متن، حالت خطا یا دسترس‌پذیری را تغییر میدهند جدا کنید. بگویید چگونه اصلاح‌ها را ثبت و اولویتبندی میکنید.
پیش از توسعه، جریان و حالت‌های مهم را با توسعهدهنده مرور می‌کنم و فقط لینک فریمها را تحویل نمی‌دهم. در فایل، وضعیت‌های خطا، بارگذاری و رفتار واکنشگرا را مشخص می‌کنم. پس از آماده‌شدن نسخه آزمایشی، سناریوی اصلی را روی محیط واقعی بررسی می‌کنم. اگر تفاوتی فقط چند پیکسل باشد، با توجه به اثر آن اولویت می‌دهم، اما اگر متن خطا، ترتیب فیلدها یا رفتار دکمه تغییر کرده باشد، آن را مسئله تجربه کاربر می‌دانم و برای اصلاح پیگیری می‌کنم.
پرسش‌های شما از پنل مصاحبه
-
این نقش در تیم شما بیشتر بر طراحی رابط تمرکز دارد یا پژوهش کاربر، طراحی جریان و آزمون کاربردپذیری نیز در مسئولیت آن است؟
عنوان UI/UX در شرکت‌های مختلف دامنه متفاوتی دارد و پاسخ، تناسب واقعی نقش با تجربه و هدف شغلی شما را روشن میکند.
-
پیش از شروع طراحی یک قابلیت، طراح به چه نوع داده، بازخورد کاربر یا گفت‌وگو با ذی‌نفعان دسترسی دارد؟
این پرسش نشان می‌دهد تصمیم‌های طراحی بر چه شواهدی تکیه می‌کنند و طراح فقط دریافت‌کننده سفارش صفحه نیست.
-
فرایند بازبینی طراحی با مدیر محصول و توسعه‌دهندگان چگونه است و چه کسی تصمیم نهایی را ثبت میکند؟
کیفیت همکاری و احتمال تغییرهای مبهم یا دیرهنگام را آشکار میکند.
-
آیا سیستم طراحی فعال دارید؟ اگر دارید، مسئول نگهداری و تعیین قواعد استفاده از کامپوننت‌ها چه کسی است؟
دامنه کار طراحی و میزان پراکندگی احتمالی در فایل‌ها و رابط محصول را روشن میکند.
-
طراح پس از انتشار قابلیت، چگونه بازخورد کاربران و تفاوت طرح با پیادهسازی را بررسی میکند؟
پاسخ نشان می‌دهد تیم طراحی را تا مرحله انتشار و یادگیری از محصول همراه می‌داند یا نه.
-
برای این موقعیت، مهم‌ترین جریان یا مسئله‌ای که انتظار دارید فرد در ماه‌های نخست روی آن کار کند چیست؟
به شما کمک میکند پیچیدگی مسئله، نوع محصول و انتظار عملی از این نقش را ارزیابی کنید.
-
در تصمیم‌های طراحی، چه محدودیت‌هایی بیشترین اثر را دارند: زمان انتشار، فناوری موجود، مقررات محصول یا یکپارچگی برند؟
شناخت محدودیتهای واقعی، تصویر دقیق‌تری از نوع مسئله‌های روزمره این موقعیت می‌دهد.
اشتباه‌های رایج
در ادامه تعدادی از اشتباهاتی که اغلب افراد در مصاحبه شغل «طراح رابط کاربری و تجربه کاربری» انجام میدهند، آمده است. پرهیز از انجام این اشتباهات، می‌تواند شانس شما را برای پذیرفته شدن از مصاحبه و استخدام نهایی بیشتر کند.
-
نمایش صفحه‌های نهایی بدون توضیح مسئله
برای هر پروژه، مسئله، کاربر، جریان، محدودیت و دلیل تصمیم‌های مهم را آماده کنید. زیبایی رابط را جایگزین منطق طراحی نکنید.
-
ادعای پژوهش یا نتیجه‌ای که واقعی نبوده است
پروژه شخصی و فرضهای آن را شفاف بیان کنید. اگر آزمون محدود یا گفتوگوی غیررسمی داشته‌اید، دامنه آن را بزرگ‌نمایی نکنید.
-
نادیده گرفتن حالت خطا، بارگذاری و داده خالی
برای جریان‌های نمونه‌کار، دست‌کم یک وضعیت غیرعادی را نشان دهید و توضیح دهید کاربر در آن وضعیت چه می‌بیند و چه اقدامی می‌تواند انجام دهد.
-
دفاع سلیقه‌ای از تصمیم طراحی
به‌جای عبارت‌هایی مانند «به نظرم بهتر بود»، تصمیم را به هدف کاربر، سلسله‌مراتب محتوا، بازخورد، محدودیت یا اصل کاربردپذیری پیوند دهید.
-
برخورد تقابلی با بازخورد توسعهدهنده
محدودیت فنی را دقیق بفهمید و هدف تجربه کاربر را حفظ کنید. گزینه جایگزین طراحی کنید و تصمیم نهایی را در فایل به‌روزرسانی کنید.
-
فایل Figma نامنظم و غیرقابل ارائه
پیش از جلسه، نام فریمها، ساختار صفحه‌ها، کامپوننت‌ها و مسیر پروتوتایپ را مرتب کنید تا مصاحبهگر بتواند منطق فایل را دنبال کند.
-
تمرکز صرف بر Figma به‌عنوان مهارت اصلی
کار با ابزار را در کنار پژوهش کاربر، معماری اطلاعات، طراحی تعامل و آزمون کاربردپذیری توضیح دهید. ابزار باید در خدمت حل مسئله باشد.
-
پذیرفتن تمرین طراحی گسترده بدون توافق روشن
پیش از شروع، زمان، مسئله، خروجی، مخاطب ارائه و نحوه استفاده از نتیجه را بپرسید. تمرین کوتاه و مشخص را از پروژه عملیاتی بزرگ جدا کنید.
پس از مصاحبه
تا یک روز کاری پس از مصاحبه، اگر راه ارتباطی مستقیم دارید، پیام کوتاهی بفرستید. از زمان مصاحبه تشکر کنید و فقط یک نکته مرتبط را یادآوری کنید. برای مثال، می‌توانید به علاقه خود به مسئله‌ای که تیم درباره آن صحبت کرد یا لینک نمونه‌کاری که قرار بود ارسال شود، اشاره کنید. پیام تشکر نباید به تکرار کامل رزومه یا پیگیری روزانه تبدیل شود.
بلافاصله پس از جلسه، پرسش‌هایی را که پاسخشان ضعیف بود ثبت کنید. بررسی کنید آیا مشکل از شناخت ناکافی یک مفهوم مانند سیستم طراحی یا دسترس‌پذیری بوده، یا از ناتوانی در توضیح پروژه. سپس همان پروژه را با تمرکز بر نقطه ضعف تمرین کنید. برای نمونه، حالت‌های خطا را کامل کنید یا منطق تصمیم خود را به شواهد مشخص پیوند دهید.
نکات مهم در زمان بررسی پیشنهاد همکاری
هنگام بررسی پیشنهاد همکاری، فقط عنوان شغلی را ملاک قرار ندهید. دامنه واقعی نقش، دسترسی به بازخورد کاربر، شیوه همکاری با محصول و توسعه، مالکیت سیستم طراحی، نوع قرارداد و انتظار از تحویل را دوباره بررسی کنید. ممکن است دو موقعیت با عنوان یکسان، یکی بیشتر طراحی بصری و دیگری طراحی محصولی گسترده باشد.
اگر پاسخ منفی دریافت کردید، در صورت امکان یک پرسش کوتاه و محترمانه درباره مهم‌ترین شکاف مطرح کنید. این بازخورد را قطعی یا کامل فرض نکنید، اما اگر با ارزیابی خودتان هم‌خوان است، آن را به برنامه تمرین تبدیل کنید. برای تقویت پیش‌نیازهای تخصصی، نقشه راه این شغل را مرور کنید و اگر مسئله اصلی رسیدن به فرصت‌های مناسب است، راهنمای ورود این شغل را ببینید.
پرسش‌های پرتکرار
اگر درباره این راهنما پرسشی دارید، ممکن است پاسخ آن را در میان موارد زیر پیدا کنید.
در مصاحبه طراح UI/UX باید فایل Figma را هم نشان بدهم؟
اغلب بله، اگر مصاحبهگر بخواهد فرایند و جزئیات کار را بررسی کند. دسترسی مشاهده، ساختار مرتب فریمها و یک پروتوتایپ قابل اجرا آماده داشته باشید. فقط نمایش فایل کافی نیست و باید منطق جریان و تصمیمها را توضیح دهید.
اگر تجربه کاری ندارم، در مصاحبه UI/UX چه چیزی ارائه کنم؟
پروژه شخصی یا تمرینی قابل دفاع ارائه کنید و فرضیبودن آن را شفاف بگویید. مسئله، کاربر هدف، بررسی نمونههای مشابه، جریان، نمونه تعاملی و اصلاحهای خود را نشان دهید. درباره معیار آمادگی برای نخستین درخواست، راهنمای ورود این شغل را بخوانید.
آیا در مصاحبه UI/UX تمرین طراحی میدهند؟
بعضی شرکتها تمرین کوتاه در جلسه یا تمرین زماندار میدهند. هدف معمولاً دیدن شیوه فهم مسئله، اولویتبندی و توضیح تصمیمهاست. پیش از شروع، زمان، خروجی و مخاطب تمرین را روشن کنید.
برای پاسخ به پرسش درباره پژوهش کاربر، اگر داده واقعی ندارم چه بگویم؟
داده یا نتیجه ساختگی ارائه نکنید. فرضهای پروژه را مشخص کنید و توضیح دهید برای کاهش ابهام چه کار کردهاید؛ مانند بررسی محصولات مشابه، گفتوگوی محدود با کاربران بالقوه یا آزمون پروتوتایپ.
در مصاحبه، تسلط بر Figma مهمتر است یا تفکر UX؟
هر دو مهماند، اما Figma ابزار است. مصاحبهگر معمولاً میخواهد ببیند چگونه مسئله کاربر را میفهمید، جریان طراحی میکنید، تصمیم را توضیح میدهید و طرح را با محدودیتهای واقعی هماهنگ میکنید.
اگر با نظر مدیر محصول یا توسعهدهنده مخالف باشم، چه پاسخی مناسب است؟
اختلاف را به مسئله کاربر و هدف محصول برگردانید. محدودیت و شواهد را روشن کنید، گزینه جایگزین پیشنهاد دهید و نشان دهید تصمیم نهایی را به‌صورت همکاری بین‌رشته‌ای دنبال میکنید، نه رقابت شخصی.
آیا باید برنامهنویسی را در مصاحبه UI/UX بلد باشم؟
معمولاً لازم نیست کدنویسی کنید، اما باید محدودیتهای پایه وب یا موبایل، طراحی واکنشگرا و جزئیات تحویل به توسعهدهنده را بفهمید. این شناخت به ارائه طرح قابل پیادهسازی کمک میکند.
