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