فرض کنید وارد کشوری شده‌اید که زبانش را خوب بلد نیستید. می‌خواهید نزدیک‌ترین داروخانه باز را پیدا کنید. گوشی را باز می‌کنید و در بخش جست‌وجوی مکان می‌نویسید «داروخانه نزدیک من».
نتایج ظاهر می‌شوند، اما اسم مکان‌ها به زبان محلی است. توضیحات را درست متوجه نمی‌شوید و حتی مطمئن نیستید نتیجه‌ای که انتخاب کرده‌اید واقعا همان چیزی است که دنبالش بودید.
از نظر فنی، موتور جست‌وجو کارش را انجام داده و چند نتیجه برگردانده است. اما آیا کاربر هم توانسته کارش را انجام دهد؟
اینجا دقیقا همان مسئله‌ای است که در سوال دوم مصاحبه مدیر محصول با آن روبه‌رو می‌شویم:
«چطور تجربه جست‌وجوی محلی را برای کاربری که زبان رابط کاربری را خوب نمی‌داند، بهبود می‌دهید؟»
این سوال در دسته Product Sense & Design قرار می‌گیرد و هدفش سنجش توانایی ما در شناخت مسئله، انتخاب گروه هدف، اولویت‌بندی راه‌حل‌ها و طراحی یک آزمایش قابل‌اندازه‌گیری است.
مسئله واقعا زبان رابط کاربری است؟
اولین واکنش احتمالی ما این است که قابلیت تغییر زبان یا ترجمه خودکار را به محصول اضافه کنیم.
راه‌حل بدی نیست، اما هنوز نمی‌دانیم مشکل اصلی چیست.
ممکن است کاربر نتواند عبارت موردنظرش را به زبان محلی بنویسد. ممکن است جست‌وجو را به زبان خودش انجام دهد، اما نتایج مناسبی نگیرد. شاید نتایج درست باشند، ولی توضیحات آن‌ها را متوجه نشود. حتی ممکن است مکان مناسب را پیدا کند، اما نتواند اسم آن را با تابلوی واقعی محل تطبیق دهد.
این‌ها چهار مشکل متفاوت هستند و لزوما با یک راه‌حل برطرف نمی‌شوند.
برای همین، قبل از پیشنهاد قابلیت جدید، باید سه موضوع را روشن کنیم:
- کاربر چه کسی است و در چه موقعیتی جست‌وجو می‌کند؟
- دقیقا در کدام مرحله نمی‌تواند کارش را ادامه دهد؟
- از کجا می‌فهمیم مشکلش برطرف شده است؟
نکته مهم این است که زبان ورودی کاربر، زبان رابط محصول و زبان رایج در محل جست‌وجو ممکن است سه زبان متفاوت باشند.
اگر این تفاوت را نادیده بگیریم، احتمالا مسئله را بیش از حد ساده کرده‌ایم.
برای چه کسانی محصول را بهتر می‌کنیم؟
در این سناریو چند گروه کاربری داریم.
گردشگری که برای چند روز به کشور دیگری سفر کرده، مهاجری که به‌تازگی وارد کشور شده، دانشجوی بین‌المللی یا حتی فردی که سال‌ها در یک کشور زندگی کرده اما هنوز با زبان محلی راحت نیست.
هرکدام نیازهای متفاوتی دارند.
گردشگر ممکن است بیشتر دنبال رستوران، حمل‌ونقل و مکان‌های دیدنی باشد. مهاجر احتمالا نیازهای پرتکرارتری مثل خدمات درمانی، بانکی و اداری دارد.
در مصاحبه قرار نیست برای همه این گروه‌ها هم‌زمان راه‌حل طراحی کنیم.
من برای شروع، مسافرانی را انتخاب می‌کنم که آشنایی محدودی با زبان مقصد دارند و می‌خواهند خدمات ضروری نزدیک خود را پیدا کنند.
چرا این گروه؟
چون در بعضی از موقعیت‌های این گروه، اشتباه در انتخاب مکان می‌تواند هزینه زمانی یا عملی قابل‌توجهی داشته باشد. ضمن اینکه می‌توانیم وظایف مشخصی برای آزمایش تعریف کنیم.
البته این انتخاب یک فرض اولیه است، نه نتیجه قطعی تحقیقات. اگر داده‌ها نشان دهند مشکل برای مهاجران پرتکرارتر و شدیدتر است، اولویت را تغییر می‌دهیم.
اول بفهمیم کاربر کجا متوقف می‌شود
فرض کنیم می‌خواهیم تجربه جست‌وجوی یک اپلیکیشن نقشه را بهبود دهیم.
به‌جای شروع طراحی، ابتدا مسیر کاربر را بررسی می‌کنیم:
شروع جست‌وجو ← وارد کردن عبارت ← مشاهده نتایج ← بررسی گزینه‌ها ← انتخاب مکان ← رسیدن به مقصد
برای هر مرحله یک سوال داریم.
آیا کاربر عبارت موردنظرش را وارد می‌کند؟ آیا نتیجه مرتبط پیدا می‌شود؟ آیا عنوان و اطلاعات نتیجه قابل‌فهم هستند؟ آیا کاربر می‌تواند گزینه درست را تشخیص دهد؟ آیا مکان انتخابی با نیاز واقعی او مطابقت دارد؟
برای پاسخ، دو نوع شواهد را کنار هم قرار می‌دهیم.
از داده‌های رفتاری می‌توانیم جست‌وجوهای بدون نتیجه، تغییر مکرر عبارت، بازگشت سریع از صفحه مکان و توقف در مراحل مختلف را بررسی کنیم.
در کنار آن، با تعدادی از کاربران هدف مصاحبه و آزمون کاربردپذیری انجام می‌دهیم تا متوجه شویم چرا چنین رفتاری دارند.
مثلا اگر کاربری یک عبارت را سه بار به زبان‌های مختلف جست‌وجو کرده، نباید بلافاصله نتیجه بگیریم موتور جست‌وجو ضعیف است. شاید نتیجه مناسب از همان ابتدا وجود داشته، اما کاربر نمی‌توانسته آن را تشخیص دهد.
داده رفتاری به ما می‌گوید کجا باید دقیق‌تر بررسی کنیم؛ مشاهده و گفت‌وگو کمک می‌کند علت احتمالی را بفهمیم.
چه راه‌حل‌هایی داریم؟
بعد از شناسایی مسئله، چند مسیر قابل‌بررسی داریم.
مسیر اول: ترجمه رابط کاربری
منوها، دسته‌بندی‌ها، پیام‌ها و اطلاعات قابل‌ترجمه را به زبان کاربر نمایش دهیم.
این کار می‌تواند فهم رابط را آسان‌تر کند، اما به‌تنهایی مشکل تطبیق عبارت جست‌وجو با نام محلی مکان را حل نمی‌کند.
مسیر دوم: جست‌وجوی چندزبانه
به کاربر اجازه دهیم نیازش را به زبان خودش بنویسد و سیستم تلاش کند مکان‌های مرتبط را با وجود تفاوت زبانی پیدا کند.
مثلا عبارت «داروخانه» بتواند با دسته‌بندی محلی مرتبط شود، بدون اینکه کاربر مجبور باشد معادل آلمانی آن را بداند.
برای این کار می‌توانیم از نگاشت دسته‌بندی‌ها، معادل‌های زبانی و قابلیت‌های موجود موتور جست‌وجو استفاده کنیم.
مسیر سوم: کمک به تشخیص نتیجه درست
در کنار نام اصلی مکان، اطلاعات قابل‌فهمی مثل نوع خدمت، موقعیت، فاصله و وضعیت ساعات کاری را نمایش دهیم.
در این رویکرد لازم نیست همه نام‌های محلی را ترجمه کنیم. اتفاقا حفظ نام اصلی مکان اهمیت دارد، چون کاربر باید بتواند آن را روی تابلو، بلیت یا نشانی واقعی تشخیص دهد.
مسیر چهارم: جست‌وجو بر اساس نیاز، نه واژه
می‌توانیم برای نیازهای پرتکرار، مسیرهای ساده‌تری طراحی کنیم.
مثلا کاربر بدون دانستن نام محلی «داروخانه»، دسته‌بندی آن را از میان گزینه‌های قابل‌فهم انتخاب کند و جست‌وجو را ادامه دهد.
اما نباید تصور کنیم اضافه کردن چند آیکون، تمام مشکل زبانی را حل می‌کند.
کدام راه‌حل را انتخاب می‌کنیم؟
اگر قرار باشد برای نسخه اولیه تصمیم بگیرم، تمام این قابلیت‌ها را هم‌زمان توسعه نمی‌دهم.
پیشنهاد من ترکیب دو تغییر محدود است:
اول، امکان پیدا کردن دسته‌بندی‌های ضروری با عبارت‌های زبان کاربر. دوم، نمایش اطلاعات کلیدی نتیجه به شکلی که بتواند آن را با مکان واقعی تطبیق دهد.
این انتخاب یک مزیت مهم دارد: به‌جای بازطراحی کامل محصول، روی دو نقطه اثرگذار در مسیر انجام کار تمرکز می‌کنیم.
البته هزینه و ریسک هم دارد.
جست‌وجوی چندزبانه ممکن است نتیجه نامرتبط برگرداند. ترجمه خودکار ممکن است نام مکان یا نوع خدمت را اشتباه منتقل کند. اطلاعات ساعات کاری هم همیشه کامل یا به‌روز نیست.
برای همین، نام رسمی مکان را حفظ می‌کنم، بین اطلاعات تاییدشده و نامطمئن تفاوت می‌گذارم و اجازه می‌دهم کاربر در صورت نیاز نتیجه اصلی را مشاهده کند.
از طرف دیگر، اگر داده‌ها نشان دهند مشکل اصلی کاربران در فهم نتایج است، نه پیدا کردن آن‌ها، ممکن است بهبود نمایش نتایج را زودتر از جست‌وجوی چندزبانه اجرا کنیم.
اولویت باید از شواهد بیاید، نه از جذابیت فنی یک قابلیت.
یک مثال واقعی‌نما از طراحی محصول
فرض کنیم یک کاربر فارسی‌زبان در برلین می‌خواهد داروخانه‌ای پیدا کند که در زمان مراجعه باز باشد.
در تجربه اولیه، عبارت فارسی او ممکن است نتیجه مناسبی ندهد یا نتیجه‌ای برگرداند که کاربر از نام و توضیحات آلمانی آن چیزی متوجه نشود.
در نسخه پیشنهادی، کاربر عبارت «داروخانه باز نزدیک من» را وارد می‌کند.
سیستم ابتدا نیاز به داروخانه و محدوده مکانی را تشخیص می‌دهد. سپس نتایج مرتبط را همراه با نام اصلی آلمانی، دسته‌بندی قابل‌فهم، فاصله و اطلاعات ساعات کاری موجود نمایش می‌دهد.
اگر وضعیت باز بودن مکان قابل‌اطمینان نباشد، محصول نباید با قطعیت آن را باز معرفی کند.
کاربر می‌تواند پیش از حرکت، جزئیات نتیجه را بررسی کند و در مقصد نیز نام اصلی مکان را با تابلوی آن تطبیق دهد.
این یک سناریوی فرضی است و قرار نیست ادعا کنیم چنین قابلیتی با همین جزئیات در محصول مشخصی پیاده‌سازی شده است.
ارزش این طراحی در تعداد قابلیت‌هایش نیست؛ در این است که فاصله بین نیاز کاربر و انجام موفق کار را کمتر می‌کند.
موفقیت را چطور اندازه می‌گیریم؟
یکی از اشتباه‌های رایج در سوالات طراحی محصول این است که راه‌حل پیشنهاد می‌دهیم، اما مشخص نمی‌کنیم چطور درباره موفقیت آن قضاوت خواهیم کرد.
برای این مسئله، صرف افزایش تعداد جست‌وجوها معیار مناسبی نیست. حتی ممکن است نشانه این باشد که کاربر چند بار تلاش می‌کند و موفق نمی‌شود.
من سه دسته شاخص تعریف می‌کنم.
شاخص نتیجه: درصد کاربرانی که می‌توانند در یک سناریوی مشخص، مکان مناسب نیازشان را بدون کمک پیدا کنند.
شاخص تشخیصی: زمان لازم برای پیدا کردن نتیجه درست، تعداد تغییر عبارت جست‌وجو و دفعات انتخاب نتیجه نامرتبط.
شاخص محافظتی: نرخ انتخاب مکان اشتباه، خطاهای مربوط به اطلاعات مکانی و مواردی که ترجمه یا دسته‌بندی نادرست باعث گمراهی کاربر شده است.
در آزمون کنترل‌شده می‌توانیم درست بودن انتخاب را با پاسخ مرجع بسنجیم. اما در محصول واقعی، کلیک روی مسیریابی یا مشاهده صفحه مکان به‌تنهایی اثبات نمی‌کند کاربر به مقصد مناسب رسیده است.
بنابراین باید بین رفتار قابل‌اندازه‌گیری و موفقیت واقعی کاربر تفاوت بگذاریم.
پیش از آزمایش، وضعیت فعلی و معیار تصمیم‌گیری را ثبت می‌کنیم تا بعدا فقط بهبود شاخص‌های دلخواه را گزارش ندهیم.
اگر مصاحبه‌کننده بپرسد فقط دو هفته فرصت دارید؟
در این شرایط دنبال ساخت یک سامانه کامل ترجمه و جست‌وجوی چندزبانه نمی‌روم.
در چند روز اول، داده‌های موجود را بررسی می‌کنم و چند وظیفه پرتکرار را با کاربران هدف آزمایش می‌کنم.
بعد یکی از موانع اصلی را انتخاب می‌کنم و یک نمونه اولیه محدود می‌سازم؛ مثلا جست‌وجوی چندزبانه برای چند دسته خدمت ضروری در یک شهر مشخص.
در ادامه، همان وظایف را با تجربه فعلی و نمونه جدید مقایسه می‌کنم.
اگر آزمایش نشان دهد کاربران نتیجه درست را راحت‌تر پیدا می‌کنند و خطاهای مهم افزایش پیدا نکرده، برای توسعه محدودتر و آزمایش در مقیاس واقعی برنامه می‌ریزیم.
هدف این دو هفته تحویل تمام قابلیت‌ها نیست؛ به دست آوردن شواهد کافی برای یک تصمیم بهتر است.
چه شواهدی باعث می‌شود راه‌حل خودمان را کنار بگذاریم؟
این یکی از مهم‌ترین سوالات تکمیلی مصاحبه است.
اگر کاربران همچنان نتوانند نتیجه درست را تشخیص دهند، جست‌وجوی چندزبانه به‌تنهایی کافی نبوده است.
اگر مشکل اصلی به نبود اطلاعات دقیق مکان‌ها مربوط باشد، بهتر کردن ترجمه اولویت اصلی نیست.
اگر کاربران با دسته‌بندی‌های تصویری موجود به‌راحتی کارشان را انجام دهند، شاید توسعه یک قابلیت پیچیده ارزش سرمایه‌گذاری نداشته باشد.
و اگر تعداد نتایج اشتباه افزایش پیدا کند، حتی در صورت کاهش زمان جست‌وجو، ممکن است مجبور شویم راه‌حل را اصلاح یا متوقف کنیم.
یک مدیر محصول نباید صرفا دنبال تایید ایده خودش باشد. باید از ابتدا بداند چه شواهدی می‌تواند تصمیمش را تغییر دهد.
در مصاحبه چطور جواب بدهیم؟
اگر بخواهم این سوال را به شکل طبیعی در یک مصاحبه پاسخ بدهم، می‌گویم:
«قبل از پیشنهاد راه‌حل، می‌خواهم مشخص کنم مشکل اصلی کاربر در نوشتن عبارت جست‌وجو است، در فهم نتایج یا در تشخیص مکان درست.
برای شروع روی مسافرانی تمرکز می‌کنم که زبان محلی را خوب نمی‌دانند و دنبال خدمات ضروری هستند.
با بررسی داده‌های جست‌وجو و مشاهده رفتار چند کاربر، مرحله‌ای را که بیشترین مشکل را ایجاد می‌کند پیدا می‌کنم.
اگر مشکل اصلی در پیدا کردن و فهم نتایج باشد، ابتدا جست‌وجوی محدود چندزبانه و نمایش اطلاعات کلیدی به زبان قابل‌فهم را آزمایش می‌کنم، بدون اینکه نام اصلی مکان حذف شود.
موفقیت را هم با توانایی کاربر در انتخاب مکان درست، زمان انجام کار و نرخ خطا می‌سنجم. اگر نتیجه مثبت نباشد یا خطاهای مهم بیشتر شوند، راه‌حل را بازنگری می‌کنم.»
این پاسخ به‌جای فهرست کردن قابلیت‌ها، مسیر تصمیم‌گیری را نشان می‌دهد.
پاسخ‌های ضعیف چه ویژگی‌هایی دارند؟
گفتن اینکه «کل برنامه را چندزبانه می‌کنم» بدون شناخت محل مشکل، پاسخ کاملی نیست.
اینکه «با هوش مصنوعی همه اطلاعات را ترجمه می‌کنم» هم تا وقتی درباره دقت، هزینه، نام‌های محلی و خطاها صحبت نکرده‌ایم، بیشتر یک پیشنهاد فنی است تا تصمیم محصولی.
پاسخ «تجربه را برای همه کاربران بهتر می‌کنم» نیز اولویت مشخصی ندارد.
مصاحبه‌کننده می‌خواهد ببیند آیا می‌توانیم از میان چند مسئله و چند راه‌حل، انتخابی قابل‌دفاع داشته باشیم یا نه.
جمع‌بندی
برای بهتر کردن جست‌وجوی محلی کاربران ناآشنا با زبان رابط، ابتدا باید مشخص کنیم مشکل در کدام مرحله رخ می‌دهد: نوشتن عبارت، پیدا شدن نتایج، فهم اطلاعات یا انتخاب مکان درست. سپس برای یک گروه مشخص، راه‌حلی محدود و قابل‌آزمایش انتخاب کنیم.
در سناریوی مطرح‌شده، نقطه شروع پیشنهادی من جست‌وجوی چندزبانه برای نیازهای ضروری و نمایش اطلاعات قابل‌فهم در کنار نام اصلی مکان است. این تصمیم را به این دلیل انتخاب می‌کنم که مستقیما به انجام کار کاربر کمک می‌کند و می‌توان اثرش را بدون بازطراحی کامل محصول آزمایش کرد.
البته این انتخاب قطعی نیست. اگر تحقیقات نشان دهند مانع اصلی جای دیگری است، باید اولویت را تغییر دهیم. پاسخ قوی در مصاحبه مدیر محصول، پاسخی نیست که بیشترین قابلیت را پیشنهاد می‌دهد؛ پاسخی است که روشن می‌کند چه مسئله‌ای را برای چه کسی حل می‌کنیم، چرا این مسیر را انتخاب کرده‌ایم و چه شواهدی می‌تواند نظرمان را عوض کند.
منابع
- مستندات Google Places Autocomplete درباره زبان نتایج، نام‌های جایگزین و محدودسازی مکانی:
https://developers.google.com/maps/documentation/places/web-service/place-autocomplete
- راهنمای W3C برای نوشتن رابط‌های قابل‌فهم و پیام‌های روشن:
https://www.w3.org/WAI/tips/writing/
- راهنمای WCAG 2.2 درباره تشخیص زبان بخش‌های مختلف رابط:
https://www.w3.org/WAI/WCAG22/Understanding/language-of-parts.html
