فرض کنید برای اولین بار به شهری سفر کردهاید و فقط یک ساعت و نیم وقت آزاد دارید. گوگلمپ دهها کافه، موزه، پارک و جاذبه گردشگری به شما پیشنهاد میدهد، اما هنوز نمیدانید کدام گزینه واقعا به دردتان میخورد. شاید نزدیکترین مکان چندان جذاب نباشد، محبوبترین گزینه بیش از حد شلوغ باشد یا تا رسیدن به مقصد، بخش زیادی از فرصتتان را از دست بدهید.
در چنین موقعیتی، مشکل کمبود اطلاعات نیست. اتفاقا ممکن است حجم زیاد اطلاعات تصمیمگیری را دشوارتر کرده باشد.
حالا تصور کنید در مصاحبه مدیریت محصول از شما بپرسند:
«چطور تجربه کشف مکان در Google Maps را برای مسافری که تجربه کمی دارد بازطراحی میکنید؟»
این سوال در ظاهر درباره طراحی تجربه کاربری است، اما پاسخ خوب به آن فراتر از پیشنهاد چند قابلیت جدید میرود. مصاحبهکننده میخواهد ببیند آیا میتوانید مسئله واقعی کاربر را شناسایی کنید، بین نیازهای متفاوت اولویت بگذارید، محدودیتهای محصول را در نظر بگیرید و راهکاری پیشنهاد دهید که بتوان اثربخشی آن را سنجید.
اول مشخص کنیم دقیقا چه مشکلی را حل میکنیم
پیش از طراحی هر راهکاری باید بین دو نیاز تفاوت بگذاریم:
- پیدا کردن مکان مشخص: کاربر نام یک رستوران، هتل یا جاذبه را میداند و میخواهد موقعیت آن را پیدا کند.
- کشف مکان مناسب: کاربر هنوز نمیداند کجا برود و انتظار دارد محصول در انتخاب مقصد به او کمک کند.
سوال مصاحبه درباره حالت دوم است.
مسافری که در شهر جدیدی قدم میزند، ممکن است نام خیابانها را نداند، با محلهها آشنا نباشد یا نتواند از روی امتیازها و نظرات کاربران تشخیص دهد کدام مکان برای شرایط فعلی او مناسبتر است.
البته کمتجربه بودن لزوما به معنای ناآشنایی با فناوری نیست. ممکن است فردی در استفاده از اپلیکیشنها مهارت داشته باشد، اما برای اولین بار به کشوری سفر کرده باشد و شناختی از موقعیتهای محلی نداشته باشد.
این تمایز مهم است؛ چون اگر مسئله را اشتباه تعریف کنیم، احتمالا محصولی طراحی خواهیم کرد که به جای کمک به مسافر، فقط روش استفاده از نقشه را به او آموزش میدهد.
برای ادامه تحلیل، یک فرض مشخص در نظر میگیرم: کاربر هدف، مسافری است که با گوشی هوشمند در شهری ناآشنا حضور دارد، زمان محدودی برای گردش دارد و هنوز مقصد مشخصی انتخاب نکرده است. فرض میکنیم بیشتر جابهجاییهای کوتاه او پیاده انجام میشود.
این فقط نقطه شروع تحلیل است، نه توصیف همه مسافران. نیازهای فردی که محدودیت حرکتی دارد، با خانواده سفر میکند یا به اینترنت پایدار دسترسی ندارد، ممکن است متفاوت باشد.
آیا Google Maps واقعا به قابلیت تازهای نیاز دارد؟
پیش از پیشنهاد یک قابلیت، باید محصول موجود را بشناسیم.
Google Maps همین حالا امکان جستجوی مکانهای اطراف، بررسی امتیازها و نظرات، مشاهده اطلاعات مکان و استفاده از بخش Explore برای کشف پیشنهادهای محلی را فراهم میکند.
طبق راهنمای رسمی Google Maps، پیشنهادهای بخش Explore میتوانند براساس موقعیت و زمان روز تغییر کنند. همچنین گوگل توضیح میدهد که رتبهبندی نتایج جستجوی محلی عمدتا از ارتباط نتیجه با جستجو، فاصله و میزان شناختهشدن مکان تاثیر میگیرد.
بنابراین نباید ادعا کنیم که کاربران هیچ راهی برای کشف مکان ندارند.
مسئلهای که ارزش بررسی دارد این است:
آیا امکانات فعلی به مسافری که هنوز نمیداند چه میخواهد کمک میکنند از میان گزینههای موجود، انتخابی متناسب با شرایطش داشته باشد؟
تفاوت بین «نمایش مکانهای مرتبط» و «کمک به انتخاب مکان مناسب» میتواند فرصت واقعی بهبود محصول باشد.
البته باید ابتدا ثابت کنیم که چنین شکافی وجود دارد. شاید در پژوهش متوجه شویم کاربران از امکانات فعلی راضیاند و فقط با محل قرارگیری بعضی کنترلها مشکل دارند.
شناخت کاربر؛ قبل از اینکه راهحل را انتخاب کنیم
من ابتدا کاربران را براساس شرایط و کاری که میخواهند انجام دهند تفکیک میکنم، نه صرفا سن، ملیت یا میزان آشنایی با فناوری.
برای مثال:
مسافر با زمان محدود: میخواهد در فرصت کوتاه خود مکانی نزدیک و مناسب پیدا کند.
مسافر علاقهمند به تجربههای محلی: به دنبال مکانهایی است که با علایقش تناسب داشته باشند، نه لزوما معروفترین جاذبهها.
مسافر با محدودیتهای خاص: ممکن است دسترسیپذیری، هزینه، زبان یا کیفیت اتصال اینترنت برای او اهمیت بیشتری داشته باشد.
قرار نیست در نسخه اول، همه این نیازها را همزمان حل کنیم.
برای گروه اصلی، چند سوال پژوهشی مطرح میکنم:
- کاربران هنگام انتخاب مقصد بیشتر با چه چیزی مشکل دارند: پیدا کردن گزینهها، مقایسه آنها یا اعتماد به اطلاعات؟
- چه اطلاعاتی باعث میشود یک مکان را انتخاب کنند یا از انتخاب آن منصرف شوند؟
- امروز چطور تصمیم میگیرند؟ از جستجوی گوگل، شبکههای اجتماعی، توصیه دوستان یا پرسیدن از افراد محلی کمک میگیرند؟
- آیا مشکل در تمام سفرها تکرار میشود یا فقط در موقعیتهایی مثل کمبود وقت و ناآشنایی با زبان محلی؟
برای پاسخ، ترکیبی از مشاهده کاربران هنگام انجام یک کار واقعی، مصاحبه کوتاه و تحلیل مسیر استفاده از قابلیتهای موجود را انتخاب میکنم.
صرفا نگاه کردن به نرخ کلیک کافی نیست. اگر کاربر پنج مکان را باز کند و در نهایت نتواند تصمیم بگیرد، تعداد بالای تعاملات لزوما به معنی تجربه موفق نیست.
سه مسیر برای بازطراحی تجربه کشف مکان
بعد از شناخت مسئله، دستکم سه مسیر قابل دفاع داریم.
مسیر اول: سادهسازی جستجو و فیلترها
میتوانیم دستهبندیها و فیلترهای موجود را واضحتر کنیم تا کاربران سریعتر به گزینههای مناسب برسند.
مزیت این روش، هزینه اجرایی کمتر و حفظ تجربه آشنای کاربران است.
اما اگر کاربر اساسا نداند دنبال چه نوع مکانی بگردد، سادهتر کردن فیلترها شاید مسئله اصلی او را حل نکند.
مسیر دوم: ساخت یک حالت مخصوص گردشگران
میتوانیم تجربه مستقلی برای مسافران طراحی کنیم؛ با پیشنهادهای گردشگری، برنامهریزی روزانه و راهنمای انتخاب مقصد.
این راهکار امکان پوشش نیازهای بیشتری را دارد، اما هزینه طراحی، توسعه، نگهداری و پیچیدگی محصول را بالا میبرد.
همچنین هنوز نمیدانیم آیا کاربران به تجربهای مستقل نیاز دارند یا ترجیح میدهند از همان Google Maps آشنا استفاده کنند.
مسیر سوم: کمک مرحلهای و اختیاری به انتخاب مقصد
راهکار پیشنهادی من، آزمایش یک مسیر کوتاه برای کشف مکان در بستر قابلیتهای فعلی Google Maps است.
این تجربه میتواند با سوال سادهای شروع شود:
«الان دوست داری چه کاری انجام بدهی؟»
کاربر مثلا یکی از گزینههای گردش کوتاه، استراحت، غذا خوردن یا تجربه فرهنگی را انتخاب میکند. سپس در صورت نیاز، محدودیت زمانی و شیوه جابهجایی را مشخص میکند.
محصول به جای نمایش فهرستی طولانی، چند پیشنهاد مرتبط ارائه میدهد و برای هرکدام به زبان ساده توضیح میدهد چرا ممکن است انتخاب مناسبی باشد:
- تناسب مکان با هدف انتخابشده
- زمان تقریبی رسیدن و محدودیت زمانی کاربر
- اطلاعات موجود درباره ساعات فعالیت
- شواهد قابل مشاهده مانند نظرات و مشخصات مکان
در کنار هر پیشنهاد، امکان مشاهده جزئیات، ذخیره مکان و دریافت مسیر قرار میگیرد.
انتخاب من مسیر سوم است، اما نه بهعنوان پاسخ قطعی؛ بهعنوان فرضیهای که میتوان با هزینه محدود آزمایش کرد.
این طراحی نباید کاربران را مجبور به پاسخ دادن به سوالها کند. گزینه رد کردن راهنما و بازگشت به جستجوی معمولی باید همیشه در دسترس باشد.
چرا تعداد پیشنهادهای کمتر لزوما بهتر نیست؟
در نگاه اول، ارائه سه پیشنهاد به جای سی پیشنهاد تصمیم منطقیتری به نظر میرسد. اما یک خطر مهم وجود دارد: اگر سیستم گزینههای مناسب را اشتباه تشخیص دهد، ممکن است کاربر اصلا آنها را نبیند.
به همین دلیل، کاهش تعداد گزینهها بهتنهایی معیار موفقیت نیست.
پیشنهادها باید بر مبنای نیاز واقعی کاربر مرتب شوند و دلیل پیشنهاد شدنشان قابل فهم باشد. همچنین باید بتوان محدودیتها را تغییر داد و تمام نتایج را مشاهده کرد.
نباید صرفا از روی امتیاز بالای یک مکان نتیجه بگیریم که برای هر مسافری انتخاب مناسبی است.
برای مثال، رستورانی با امتیاز بالا ممکن است خارج از محدوده زمانی کاربر باشد. یا موزهای که در فهرست جاذبههای محبوب قرار دارد، هنگام رسیدن مسافر تعطیل شده باشد.
از طرف دیگر، اطلاعات مکان همیشه کامل یا بهروز نیستند. اطلاعاتی مانند ساعت فعالیت و ویژگیهای مکان ممکن است نیاز به بررسی دوباره داشته باشند. محصول نباید در چنین شرایطی قطعیت ساختگی ایجاد کند.
محدودیت اینترنت هم مهم است. Google Maps قابلیت دانلود نقشه آفلاین دارد، اما طبق مستندات رسمی گوگل، مسیریابی پیاده در حالت آفلاین در دسترس نیست. بنابراین نمیتوانیم صرفا با تکیه بر نقشه دانلودشده، تجربه کامل گردش پیاده آفلاین را وعده بدهیم.
مثال کاربردی: یک تجربه فرضی در محصول نرمافزاری
فرض کنیم تیم محصول Google Maps میخواهد این ایده را برای مسافران کمتجربه آزمایش کند.
کاربر فرضی ما برای اولین بار به لیسبون سفر کرده است. حدود ۹۰ دقیقه وقت آزاد دارد و میخواهد پیش از برگشتن به هتل، یک مکان فرهنگی را ببیند.
در تجربه معمولی، احتمالا عبارتی مثل «جاذبههای نزدیک من» را جستجو میکند، چند نتیجه را باز میکند، عکسها و امتیازها را میبیند و برای مقایسه فاصله و ساعت فعالیت بین صفحات جابهجا میشود.
در نسخه پیشنهادی، کاربر از بخش Explore وارد مسیر اختیاری «وقت آزاد دارم» میشود.
او هدف «تجربه فرهنگی»، بازه زمانی «تا ۹۰ دقیقه» و روش جابهجایی «پیاده» را انتخاب میکند.
سیستم چند گزینه را همراه با زمان تقریبی رسیدن، اطلاعات ساعات فعالیت و دلیل تناسب هر پیشنهاد نمایش میدهد.
کاربر همچنان میتواند همه نتایج را ببیند یا مستقیما از جستجوی معمولی استفاده کند.
این مثال، توصیف یک قابلیت تاییدشده یا آزمایش واقعی گوگل نیست؛ صرفا سناریویی فرضی برای توضیح تصمیم محصول است.
در این پروژه، مدیر محصول مسئله، گروه هدف، نتیجه مطلوب و اولویتها را مشخص میکند. طراح تجربه کاربری جریان انتخاب را طراحی و آزمایش میکند. تیم مهندسی امکان استفاده از دادههای موجود، زمان پاسخگویی و محدودیتهای فنی را بررسی میکند. تحلیلگر محصول نیز به تعریف و ارزیابی معیارها کمک میکند.
اگر برای پیادهسازی از دادههای موقعیت مکانی استفاده شود، باید دسترسی کاربر به اطلاعات مکان با رضایت و کنترل روشن همراه باشد. امکان انتخاب دستی منطقه نیز اهمیت دارد.
موفقیت را با چه معیارهایی میسنجیم؟
اگر هدف کمک به تصمیمگیری است، نباید افزایش تعداد بازدید صفحات مکان را معیار اصلی موفقیت قرار دهیم.
من معیارها را در سه سطح تعریف میکنم.
۱. معیار اصلی: موفقیت در انتخاب مکان مناسب
در آزمایش کاربردپذیری، کاربر باید بتواند در یک سناریوی مشخص و با محدودیتهای تعریفشده، مکانی متناسب با هدف و زمان خود انتخاب کند و توضیح دهد چرا آن گزینه را مناسب میداند.
نرخ موفقیت = تعداد کاربرانی که انتخاب معتبر و متناسب با قیود سناریو انجام دادهاند ÷ تعداد کل کاربران شرکتکننده در همان سناریو
معتبر بودن انتخاب باید پیش از آزمایش تعریف شود؛ مثلا مکان با محدودیت زمانی، روش جابهجایی و اطلاعات در دسترس سازگار باشد.
در محصول واقعی، شروع مسیریابی یا ذخیره مکان میتواند نشانهای از پیشرفت در تصمیمگیری باشد، اما اثبات نمیکند که کاربر واقعا به مقصد رسیده یا از انتخاب خود رضایت داشته است.
۲. معیارهای تشخیصی
زمان لازم برای انتخاب مقصد، تعداد رفتوبرگشتهای غیرضروری بین نتایج، میزان استفاده از راهنمای جدید و دفعات بازگشت به جستجوی معمولی را بررسی میکنم.
این دادهها نشان میدهند کجای جریان جدید به کاربر کمک میکند و کجا مانع او میشود.
۳. معیارهای محافظتی
باید مطمئن شویم سادهتر کردن تجربه به قیمت کاهش کیفیت تصمیم تمام نمیشود.
بنابراین خطاهای مربوط به اطلاعات مکان، انتخاب گزینههای نامتناسب، افت سرعت پاسخگویی، مشکلات حریم خصوصی و افزایش انصراف از فرایند را نیز بررسی میکنیم.
نتایج را در مقایسه با تجربه فعلی و برای گروههای قابل مقایسه میسنجیم. همچنین باید تفاوت کاربران تازهوارد و باتجربه، زبانها و شرایط جغرافیایی را در تحلیل در نظر گرفت.
موفقیت فقط به معنای سریعتر شدن انتخاب نیست؛ انتخاب باید سریعتر، قابل دفاعتر و متناسبتر با شرایط کاربر شود.
اگر در مصاحبه فقط دو هفته زمان داشته باشیم چه میکنیم؟
این یکی از دو سوال تکمیلی موجود در فایل مرجع است.
در چنین شرایطی ساختن یک قابلیت کامل تصمیم مناسبی نیست.
در روزهای اول، مسئله را با چند مشاهده و مصاحبه هدفمند بررسی میکنم. سپس یک نمونه اولیه تعاملی از تجربه انتخاب مقصد میسازیم که از دادهها و قابلیتهای موجود استفاده کند.
نمونه اولیه را با کاربرانی از گروه هدف و در یک سناریوی واقعی یا شبیهسازیشده آزمایش میکنیم.
در پایان دو هفته، انتظار من ارائه یک محصول کامل نیست؛ باید بتوانیم پاسخ دهیم:
آیا کاربران واقعا برای انتخاب مکان به کمک بیشتری نیاز دارند؟ آیا پیشنهادهای هدایتشده تصمیمگیری را بهتر میکنند؟ آیا شواهد برای ادامه سرمایهگذاری کافی است؟
اگر پاسخ منفی باشد، ادامه توسعه صرفا به دلیل جذاب بودن ایده منطقی نیست.
چه شواهدی باعث میشود راهکار پیشنهادی را کنار بگذاریم؟
سوال تکمیلی دوم فایل مرجع دقیقا همین موضوع را بررسی میکند.
اگر پژوهش نشان دهد مسافران کمتجربه با همان جستجو و فیلترهای موجود بهخوبی تصمیم میگیرند، فرض اصلی ما ضعیف میشود.
همچنین اگر آزمایش نشان دهد راهنمای جدید زمان انتخاب را افزایش میدهد، گزینههای مناسب را پنهان میکند یا به دلیل کیفیت پایین دادهها پیشنهادهای نادرست ارائه میدهد، باید در تصمیم تجدیدنظر کنیم.
ممکن است نتیجه پژوهش این باشد که کاربران به پیشنهادهای بیشتر نیاز ندارند و فقط میخواهند اطلاعاتی مانند ساعات فعالیت، فاصله و قابلیت دسترسی را واضحتر ببینند.
در چنین شرایطی، بهبود نمایش اطلاعات مکان احتمالا انتخاب مناسبتری از ساخت یک مسیر جدید برای کشف مقصد است.
توانایی کنار گذاشتن ایدهای که خودمان پیشنهاد دادهایم، بخشی از قضاوت حرفهای مدیر محصول است.
پاسخ پیشنهادی در مصاحبه
اگر بخواهم همین تحلیل را در قالب یک پاسخ طبیعی و کوتاهتر ارائه کنم، چنین میگویم:
«من قبل از اینکه چیزی را در Google Maps تغییر بدهم، مشخص میکنم مسافر کمتجربه دقیقا در کدام مرحله مشکل دارد. چون پیدا کردن آدرس یک مکان با انتخاب مقصد در شهری ناآشنا دو مسئله متفاوت هستند.
فرض اولیه من این است که بعضی مسافران بهخصوص وقتی زمان محدودی دارند، بین گزینههای مختلف سردرگم میشوند.
اول بررسی میکنم کاربران الان چطور مقصدشان را انتخاب میکنند و آیا قابلیتهای موجود واقعا نیازشان را برطرف نمیکند.
اگر این مشکل تایید شود، به جای طراحی یک بخش بزرگ و مستقل برای گردشگران، یک تجربه اختیاری و ساده را در Explore آزمایش میکنم که براساس هدف، زمان و شیوه جابهجایی، چند گزینه مرتبط پیشنهاد بدهد و دلیل هر پیشنهاد را توضیح دهد.
بعد بررسی میکنم آیا کاربران با این روش انتخاب بهتری انجام میدهند یا نه. اگر فقط تعداد کلیکها بیشتر شود یا اطلاعات پیشنهادی قابل اعتماد نباشد، آن را موفقیت نمیدانم و راهکار را اصلاح میکنم.»
اشتباهات رایج در پاسخ به این سوال
شروع با فهرست قابلیتها: پیشنهادهایی مثل هوش مصنوعی، واقعیت افزوده یا حالت گردشگری ممکن است جذاب باشند، اما تا زمانی که ندانیم چه مشکلی را حل میکنند، دلیل کافی برای سرمایهگذاری نداریم.
طراحی برای همه مسافران: نیاز فردی که برای اولین بار سفر میکند با کسی که سفرهای مکرر دارد یکسان نیست. پاسخ خوب باید یک گروه مشخص را اولویتبندی کند.
نادیده گرفتن قابلیتهای موجود: اگر ندانیم Google Maps همین حالا چه امکاناتی دارد، ممکن است چیزی را پیشنهاد کنیم که در محصول وجود دارد یا مسئله واقعی را حل نمیکند.
تکیه بیش از حد بر امتیاز و محبوبیت: مکان پربازدید یا دارای امتیاز بالا لزوما بهترین انتخاب برای زمان، بودجه و هدف یک کاربر مشخص نیست.
اشتباه گرفتن تعامل با موفقیت: افزایش کلیک روی پیشنهادها بهتنهایی نشان نمیدهد کاربر مقصد مناسبی پیدا کرده است.
قطعیت در شرایط مبهم: مدیر محصول باید فرضهایش را روشن کند و توضیح دهد تحت چه شرایطی تصمیم خود را تغییر میدهد.
جمعبندی
برای بازطراحی تجربه کشف مکان در Google Maps، پیشنهاد من اضافه کردن امکانات بیشتر به نقشه نیست؛ ابتدا باید بفهمیم چرا بعضی مسافران با وجود اطلاعات فراوان هنوز در انتخاب مقصد مشکل دارند. اگر این نیاز تایید شود، یک راهنمای کوتاه، اختیاری و متناسب با هدف و محدودیتهای کاربر، نقطه شروع قابل دفاعی است.
با این حال، ارزش راهکار فقط در آزمایش مشخص میشود. اگر پیشنهادهای جدید به انتخابی سریعتر و مناسبتر کمک نکنند یا اعتماد کاربر را کاهش دهند، باید مسیر را تغییر دهیم. مدیر محصول موفق کسی نیست که بیشترین قابلیت را پیشنهاد میدهد؛ کسی است که مسئله درست را انتخاب میکند و برای تصمیمش شواهد قابل سنجش دارد.
منابع
۱. Google Maps Help — Find nearby inspiration in the Explore tab
۲. Google Maps Help — Search for nearby places and explore the area
