فرض کنید مسافری که از ویلچر استفاده می‌کند، اقامتگاهی را با ویژگی «ورودی بدون پله» رزرو کرده است. وقتی به مقصد می‌رسد، متوجه می‌شود در ورودی اتاق خواب آن‌قدر باریک است که ویلچرش از آن عبور نمی‌کند. در ظاهر، جست‌وجو و رزرو موفق بوده، اما محصول در مهم‌ترین بخش وظیفه‌اش شکست خورده است.
این یک سناریوی فرضی است، ولی مسئله‌ای واقعی در طراحی محصولات رزرو اقامتگاه را نشان می‌دهد: پیدا کردن اقامتگاهی که چند ویژگی دسترس‌پذیری دارد، با پیدا کردن اقامتگاهی که واقعا با نیازهای یک مسافر سازگار است، تفاوت دارد.
در نهمین سؤال از مجموعه هزار سؤال مصاحبه مدیر محصول، باید به این مسئله پاسخ بدهیم:
«چطور تجربه رزرو Airbnb را برای مهمانی که نیازهای حرکتی دارد طراحی می‌کنید؟»
این سؤال فقط درباره طراحی رابط کاربری یا اضافه کردن چند فیلتر نیست. مصاحبه‌کننده می‌خواهد ببیند چقدر می‌توانیم مسئله واقعی کاربر را بشناسیم، بین نیازهای متفاوت اولویت بگذاریم، راهکار قابل‌آزمایش پیشنهاد کنیم و برای تصمیم خودمان معیار موفقیت داشته باشیم.
این سؤال در مجموعه مرجع به‌عنوان یک تمرین طراحی محصول مرتبط با Airbnb معرفی شده است، نه یک سؤال رسمی تأییدشده از مصاحبه‌های این شرکت.
مسئله را درست تعریف کنیم
اولین اشتباه این است که تصور کنیم همه افرادی که محدودیت حرکتی دارند، نیازهای مشابهی هم دارند.
فردی که از ویلچر دستی استفاده می‌کند، ممکن است به عرض مشخصی برای درها نیاز داشته باشد. فردی که با واکر حرکت می‌کند، شاید بیشتر نگران پله‌ها و سطح زمین باشد. مسافر دیگری ممکن است بتواند چند پله را طی کند، اما استفاده از حمام بدون دستگیره کمکی برایش دشوار باشد.
بنابراین قبل از طراحی راهکار، باید چند موضوع مشخص شود:
- کدام گروه از کاربران را در اولویت قرار می‌دهیم؟
- در کدام مرحله، از جست‌وجو تا رسیدن به اقامتگاه، بیشترین مشکل را دارند؟
- چه اطلاعاتی برای تصمیم‌گیری آن‌ها ضروری است؟
- چه محدودیت‌هایی از نظر زمان توسعه، داده‌های اقامتگاه و همکاری میزبان وجود دارد؟
برای ادامه پاسخ، یک فرض مشخص انتخاب می‌کنیم:
کاربر هدف ما مسافری است که از ویلچر استفاده می‌کند، می‌خواهد با استقلال بیشتری سفر کند و قبل از پرداخت باید مطمئن شود مسیر ورود، اتاق خواب و حمام اقامتگاه با نیازهای حرکتی او سازگار است.
این فرض به معنای یکسان بودن نیازهای همه کاربران ویلچر نیست. حتی ابعاد ویلچر، میزان توانایی جابه‌جایی و نیاز به تجهیزات کمکی نیز متفاوت است.
هدف محصول را هم این‌طور تعریف می‌کنیم:
کمک به مسافر برای پیدا کردن، ارزیابی و رزرو اقامتگاهی که با نیازهای ضروری او سازگار باشد، بدون اینکه مجبور شود برای فهمیدن جزئیات اولیه با چندین میزبان تماس بگیرد یا اطلاعات شخصی غیرضروری ارائه کند.
این هدف از «افزایش تعداد رزرو» دقیق‌تر است، چون کیفیت و نتیجه رزرو را هم در نظر می‌گیرد.
پیش از طراحی، باید بدانیم Airbnb چه امکاناتی دارد
یکی از نشانه‌های پاسخ حرفه‌ای در مصاحبه این است که محصول موجود را بشناسیم و قابلیت‌هایی را که از قبل وجود دارند، دوباره به‌عنوان ایده جدید معرفی نکنیم.
Airbnb در حال حاضر امکان جست‌وجو با فیلترهای دسترس‌پذیری را فراهم می‌کند. کاربران می‌توانند ویژگی‌هایی مانند ورودی بدون پله، در ورودی عریض، دسترسی بدون پله به اتاق خواب، دستگیره کمکی حمام و دوش بدون پله را جست‌وجو کنند.
Airbnb همچنین اعلام می‌کند ویژگی‌های دسترس‌پذیری ثبت‌شده توسط میزبانان اقامتگاه را با بررسی تصاویر ارزیابی می‌کند و مسافران می‌توانند برای دریافت جزئیات بیشتر با میزبان ارتباط بگیرند.
پس پیشنهاد «اضافه کردن فیلتر مخصوص افراد دارای معلولیت» به‌تنهایی پاسخ مناسبی نیست؛ چون بخش مهمی از آن همین حالا وجود دارد.
مسئله‌ای که باید بررسی کنیم این است:
آیا امکانات موجود به مسافر کمک می‌کنند با اطمینان کافی تشخیص دهد که یک اقامتگاه برای نیازهای خاص او مناسب است؟
برای پاسخ دادن، به داده‌های واقعی کاربران، کیفیت اطلاعات اقامتگاه‌ها و رفتار مسافران در مسیر رزرو نیاز داریم. بدون این شواهد نباید ادعا کنیم که تجربه فعلی Airbnb شکست خورده یا بهبود پیشنهادی ما حتما بهتر است.
مسیر تصمیم‌گیری: از شناخت نیاز تا انتخاب راهکار
۱. نیازهای ضروری را از ترجیحات جدا کنیم
در یک تجربه معمول رزرو، داشتن بالکن، منظره بهتر یا فاصله کمتر از مرکز شهر می‌تواند یک ترجیح باشد.
اما برای مسافری که با ویلچر حرکت می‌کند، عبور ویلچر از در ورودی ممکن است شرط ضروری رزرو باشد.
این تفاوت در طراحی سیستم جست‌وجو اهمیت زیادی دارد.
من نیازهای کاربر را به دو گروه تقسیم می‌کنم:
نیازهای ضروری: ویژگی‌هایی که نبودشان اقامتگاه را عملا غیرقابل‌استفاده می‌کند؛ مثلا مسیر بدون پله تا اتاق خواب.
ترجیحات: ویژگی‌هایی که مطلوب‌اند، اما کاربر ممکن است در صورت نبودشان گزینه دیگری را انتخاب کند؛ مثلا نزدیکی به یک جاذبه گردشگری.
این تفکیک باید توسط خود مسافر انجام شود، نه اینکه سیستم صرفا براساس استفاده او از ویلچر همه نیازهایش را حدس بزند.
اطلاعات هر ویژگی نیز باید وضعیت مشخصی داشته باشد: وجود آن مستند شده، وجود ندارد یا اطلاعات کافی درباره‌اش ثبت نشده است.
«اطلاعات نامشخص» نباید معادل «مناسب» تلقی شود.
۲. به‌جای انبوه فیلترها، تطبیق قابل‌اعتماد ایجاد کنیم
می‌توانیم امکانات بیشتری به فیلترها اضافه کنیم، اما تعداد بیشتر فیلتر لزوما تصمیم‌گیری را آسان‌تر نمی‌کند.
پیشنهاد من طراحی یک مسیر اختیاری است که مسافر در ابتدای جست‌وجو نیازهای ضروری خودش را مشخص کند. سپس سیستم اقامتگاه‌ها را براساس اطلاعات موجود و میزان انطباق با همان نیازها نمایش دهد.
برای هر نتیجه، باید روشن باشد کدام نیازها با شواهد موجود پوشش داده شده‌اند و کدام موارد هنوز به بررسی نیاز دارند.
مثلا اگر اقامتگاهی ورودی بدون پله دارد، اما درباره عرض در حمام اطلاعاتی ثبت نشده، نباید آن را بدون توضیح به‌عنوان گزینه کاملا مناسب نمایش دهیم.
از طرف دیگر، سخت‌گیری بیش از حد ممکن است تعداد نتایج را به‌شدت کاهش دهد؛ به‌خصوص در شهرهایی که اقامتگاه‌های دارای اطلاعات کامل کم هستند.
در این شرایط، سیستم می‌تواند با اجازه کاربر گزینه‌هایی را با اطلاعات ناقص نمایش دهد، پیشنهاد تغییر تاریخ یا محدوده جست‌وجو بدهد و امکان پرسیدن سؤال مشخص از میزبان را فراهم کند.
تفاوت مهم این است که سیستم نباید برای افزایش تعداد نتایج، از نیازهای ضروری کاربر چشم‌پوشی کند.
۳. اطلاعات اقامتگاه باید مسیر حرکت را توضیح دهند
داشتن یک ویژگی دسترس‌پذیری، لزوما به معنای قابل‌استفاده بودن تمام اقامتگاه نیست.
ممکن است ورودی ساختمان بدون پله باشد، اما مسیر رسیدن به اتاق خواب پله داشته باشد. شاید در حمام عریض باشد، اما فضای کافی برای چرخش ویلچر وجود نداشته باشد.
بنابراین صفحه جزئیات اقامتگاه باید به مسافر کمک کند مسیر استفاده واقعی از فضا را ارزیابی کند:
از محل ورود تا اتاق خواب، از اتاق خواب تا حمام و از مسیرهای داخلی تا امکانات ضروری.
اطلاعاتی مانند عرض در، وجود پله، وضعیت آسانسور و تصاویر روشن از مسیرها می‌توانند مفید باشند؛ البته تنها زمانی که واقعا در دسترس و قابل‌اعتماد باشند.
Airbnb در راهنمای رسمی عکاسی از امکانات دسترس‌پذیری، به نمایش اندازه درها، عکس‌برداری از زوایای مختلف و مشخص کردن اتاق‌هایی که ویژگی‌های خاص دارند اشاره می‌کند.
پیشنهاد تکمیلی من این است که کنار هر ویژگی، منبع اطلاعات و وضعیت بررسی آن شفاف باشد. مثلا مشخص شود ویژگی براساس تصاویر بررسی‌شده ثبت شده یا هنوز جزئیات کافی درباره آن وجود ندارد.
این پیشنهاد به معنای تضمین مناسب بودن اقامتگاه برای تمام کاربران نیست. تصمیم نهایی باید براساس نیازهای خود مسافر و اطلاعات قابل‌اتکا گرفته شود.
۴. ابهام‌های مهم را پیش از پرداخت برطرف کنیم
یکی از موقعیت‌های پرریسک در این تجربه، رزرو اقامتگاهی است که هنوز درباره یک نیاز ضروری اطلاعات کافی ندارد.
برای حل مسئله، می‌توانیم مرحله‌ای سبک پیش از نهایی کردن رزرو طراحی کنیم که نیازهای ضروری انتخاب‌شده را مرور کند.
اگر اطلاعات کافی وجود داشته باشد، کاربر با دید روشن‌تری ادامه می‌دهد. اگر اطلاعات ناقص باشد، سیستم همان ابهام مشخص را نشان می‌دهد و امکان پرسیدن سؤال از میزبان را فراهم می‌کند.
مثلا به‌جای پیام عمومی «با میزبان تماس بگیرید»، پرسش مرتبط‌تری پیشنهاد شود:
«عرض مفید در حمام، در حالت کاملا باز، چقدر است؟»
پاسخ میزبان نیز نباید بدون بررسی لازم به یک تضمین قطعی تبدیل شود.
همچنین لازم است مسیر پشتیبانی و سیاست‌های لغو رزرو به‌صورت شفاف در دسترس باشند. نباید بدون پشتوانه عملیاتی یا سیاست رسمی، به کاربر وعده بازپرداخت ویژه یا تضمین دسترس‌پذیری بدهیم.
۵. خود فرایند رزرو هم باید دسترس‌پذیر باشد
تا اینجا بیشتر درباره ویژگی‌های فیزیکی اقامتگاه صحبت کردیم، اما مسئله به همین‌جا ختم نمی‌شود.
خود محصول دیجیتال هم باید برای استفاده با روش‌های مختلف تعامل مناسب باشد.
کاربر باید بتواند با صفحه‌کلید بین فیلترها حرکت کند، گزینه‌ها را انتخاب کند، وضعیت هر گزینه را تشخیص دهد و فرایند پرداخت را کامل کند.
دکمه‌ها و ورودی‌ها باید برچسب قابل‌فهم داشته باشند و پیام‌های خطا صرفا با رنگ نمایش داده نشوند.
استانداردهای WCAG از W3C مبنای مناسبی برای ارزیابی این بخش‌اند.
بااین‌حال، رعایت دسترس‌پذیری دیجیتال به‌تنهایی به معنای مناسب بودن اقامتگاه نیست. محصول باید هم قابل‌استفاده باشد و هم اطلاعات قابل‌اعتماد برای انتخاب محل اقامت ارائه کند.
بین راهکارهای مختلف کدام را انتخاب کنیم؟
در مصاحبه ممکن است چند پیشنهاد اولیه مطرح شود.
راهکار اول: افزودن فیلترها و نشان‌های بیشتر. اجرای آن در برخی بخش‌ها ساده‌تر است و ممکن است پیدا کردن اقامتگاه را سریع‌تر کند، اما اگر اطلاعات ناقص یا نادرست باشند، فقط احساس اطمینان بیشتری ایجاد می‌کند، نه اطمینان واقعی.
راهکار دوم: طراحی یک تجربه جامع و کاملا شخصی‌سازی‌شده. می‌تواند نیازهای متنوع‌تری را پوشش دهد، اما به داده‌های ساختاریافته، همکاری میزبانان، طراحی پیچیده‌تر و هزینه نگهداری بیشتری نیاز دارد.
راهکار سوم: بهبود تدریجی تطبیق نیازها با اطلاعات مستند. ابتدا روی چند نیاز ضروری و پرتکرار تمرکز می‌کنیم، شکاف اطلاعاتی را شفاف نشان می‌دهیم و مسیر رفع ابهام را کوتاه می‌کنیم.
من راهکار سوم را برای شروع انتخاب می‌کنم.
دلیلش این نیست که لزوما کامل‌ترین تجربه را ارائه می‌دهد. مزیت آن این است که می‌توانیم با دامنه محدود، ارزش واقعی آن را آزمایش کنیم و پیش از گسترش، مشکلات داده و اعتماد را بشناسیم.
البته اگر تحقیقات نشان دهند مسئله اصلی کمبود اقامتگاه مناسب است، نه دشواری ارزیابی آن‌ها، باید اولویت را از بازطراحی جست‌وجو به افزایش پوشش و کیفیت اطلاعات عرضه تغییر دهیم.
مثال عملی در یک محصول نرم‌افزاری
سناریوی فرضی
فرض کنیم یک پلتفرم رزرو اقامتگاه شبیه Airbnb داریم. تیم محصول متوجه شده برخی کاربران پس از استفاده از فیلترهای دسترس‌پذیری، چند صفحه جزئیات را باز می‌کنند، اما رزرو را کامل نمی‌کنند.
از این داده به‌تنهایی نمی‌توان نتیجه گرفت که علت، نبود اعتماد است. شاید قیمت بالا باشد، اقامتگاه مناسب وجود نداشته باشد یا کاربر صرفا در حال مقایسه گزینه‌ها باشد.
مدیر محصول همراه پژوهشگر تجربه کاربری با تعدادی از مسافران مصاحبه می‌کند و هم‌زمان کیفیت اطلاعات اقامتگاه‌های موجود را بررسی می‌کنند.
فرض کنیم در این بررسی مشخص شود یکی از ابهام‌های تکرارشونده، نبود اطلاعات روشن درباره مسیر ورود تا حمام است.
تیم دو مسیر را مقایسه می‌کند:
- اضافه کردن نشان عمومی «مناسب ویلچر».
- نمایش جداگانه وضعیت مسیر ورود، اتاق خواب و حمام، همراه با عکس و مشخص کردن اطلاعات ناقص.
انتخاب اولیه مسیر دوم است، چون اطلاعات قابل‌بررسی‌تری به کاربر می‌دهد و کمتر به یک برچسب کلی وابسته است.
طراح محصول نمونه اولیه را می‌سازد، تیم فنی کیفیت و ساختار داده‌ها را بررسی می‌کند، تیم عملیات و پشتیبانی امکان دریافت و اصلاح اطلاعات میزبانان را می‌سنجد و مدیر محصول معیارهای آزمایش را مشخص می‌کند.
آزمایش ابتدا روی مجموعه محدودی از اقامتگاه‌هایی اجرا می‌شود که اطلاعاتشان بررسی شده است.
اگر کاربران بتوانند مناسب بودن اقامتگاه را دقیق‌تر تشخیص دهند، بدون اینکه خطاهای جدی یا ابهام‌های تازه ایجاد شود، گسترش راهکار منطقی‌تر خواهد بود.
اما اگر کاربران همچنان برای فهمیدن اطلاعات ضروری مجبور باشند بارها با میزبان تماس بگیرند، طراحی جدید هنوز مسئله اصلی را حل نکرده است.
تمام این مثال فرضی است و نتیجه واقعی آزمایش یا گزارشی از عملکرد Airbnb محسوب نمی‌شود.
موفقیت را چگونه اندازه بگیریم؟
در چنین محصولی، نرخ تبدیل رزرو مهم است، اما به‌تنهایی کافی نیست.
ممکن است طراحی جدید باعث افزایش رزرو شود، درحالی‌که تعداد بیشتری از مسافران پس از رسیدن متوجه شوند اقامتگاه با نیازهایشان سازگار نیست.
بنابراین سه سطح شاخص تعریف می‌کنم.
۱. شاخص نتیجه اصلی
نسبت رزروهایی که نیازهای ضروری اعلام‌شده مسافر را هنگام ورود واقعا برآورده کرده‌اند.
برای سنجش آن می‌توان از بازخورد اختیاری پس از ورود و داده‌های مشکلات ثبت‌شده استفاده کرد. مخرج این شاخص باید روشن باشد؛ مثلا تعداد رزروهای گروه آزمایشی که ارزیابی معتبر پس از ورود دارند. باید مراقب سوگیری ناشی از پاسخ ندادن برخی مسافران هم باشیم.
۲. شاخص‌های تشخیصی
نرخ پیدا کردن حداقل یک گزینه منطبق با نیازهای ضروری، زمان لازم برای ارزیابی مناسب بودن اقامتگاه، تعداد پرسش‌های ضروری باقی‌مانده پیش از رزرو و نرخ تکمیل رزرو پس از انتخاب نیازهای دسترس‌پذیری.
این شاخص‌ها را هم به‌صورت مرحله‌ای در قیف جست‌وجو بررسی می‌کنیم و هم در کل جلسات جست‌وجوی واجد شرایط، تا کمبود گزینه‌ها پشت آمار تبدیل پنهان نشود.
۳. شاخص‌های محافظ
نرخ لغو یا شکایت به دلیل مغایرت ویژگی‌های دسترس‌پذیری، تعداد مواردی که اقامتگاه به‌اشتباه مناسب تشخیص داده شده، فشار پاسخ‌گویی بر میزبانان و تأثیر تغییرات بر تجربه سایر کاربران.
دوره بررسی را از قبل تعیین می‌کنیم: ابتدا آزمون کاربردپذیری و ارزیابی کیفیت داده، سپس یک اجرای محدود که بازخورد بعد از ورود مسافران را نیز پوشش دهد.
نباید فقط به بهبود کلیک یا رزرو اولیه اکتفا کنیم.
ریسک‌ها و ملاحظات اجرایی
مهم‌ترین ریسک این راهکار ایجاد اطمینان کاذب است.
برچسبی مانند «مناسب برای ویلچر» ممکن است برای مسافری کافی نباشد، چون نیازهای کاربران یکسان نیست.
ریسک دوم، ناقص بودن اطلاعات اقامتگاه‌هاست. اگر برای همه ویژگی‌ها داده ساختاریافته بخواهیم، ممکن است بسیاری از میزبانان نتوانند اطلاعات لازم را به‌سرعت ثبت کنند.
ریسک سوم، حریم خصوصی است. برای ارائه این تجربه لازم نیست از کاربر تشخیص پزشکی یا جزئیات شخصی حساس بخواهیم. ویژگی‌های موردنیاز برای اقامت باید به شکل اختیاری انتخاب شوند.
از طرف دیگر، میزبان باید بتواند درباره امکانات واقعی اقامتگاه اطلاعات دقیق ارائه کند، نه اینکه درباره توانایی یا مناسب بودن سفر برای شخص تصمیم بگیرد.
در اینجا مدیر محصول مسئول روشن کردن مسئله، انتخاب اولویت و ارزیابی نتیجه است. طراح، پژوهشگر، مهندس و تیم عملیات نیز هرکدام در کشف نیاز، اجرای تجربه و قابل‌اعتماد شدن اطلاعات نقش دارند.
پاسخ پیشنهادی در جلسه مصاحبه
نمونه پاسخ گفتاری یک داوطلب:
«من قبل از اینکه سراغ طراحی برم، اول مشخص می‌کنم منظورمون از نیاز حرکتی چیه؛ چون کسی که از ویلچر استفاده می‌کنه، لزوما نیازهای مشابه فردی که با واکر راه می‌ره نداره.
برای شروع، فرض می‌کنم می‌خوایم به کاربران ویلچر کمک کنیم اقامتگاهی پیدا کنن که مسیر ورود، اتاق خواب و حمامش واقعا با نیازهاشون سازگار باشه.
اول تجربه فعلی Airbnb و داده‌های استفاده از فیلترها رو بررسی می‌کنم. با چند کاربر هم مصاحبه می‌کنم تا بفهمم مشکل اصلی پیدا نکردن اقامتگاهه، ناقص بودن اطلاعاته یا نداشتن اطمینان قبل از رزرو.
به‌جای اینکه صرفا فیلترهای بیشتری اضافه کنم، ترجیح می‌دم ابتدا نیازهای ضروری کاربر رو از ترجیحاتش جدا کنیم و وضعیت هر نیاز رو در نتایج و صفحه اقامتگاه شفاف نشون بدیم.
بعد این تغییر رو با یک نمونه اولیه و روی اقامتگاه‌هایی که اطلاعات قابل‌بررسی دارن آزمایش می‌کنم.
معیار موفقیتم فقط افزایش رزرو نیست؛ می‌خوام ببینم چند نفر تونستن اقامتگاهی پیدا کنن که در زمان ورود واقعا با نیازهای ضروری‌شون سازگار بوده.
اگر متوجه بشم مشکل اصلی کمبود اقامتگاه مناسب یا اطلاعات معتبره، اولویت رو تغییر می‌دم و به‌جای پیچیده‌تر کردن رابط کاربری، روی کیفیت داده‌ها و همکاری میزبان‌ها تمرکز می‌کنم.»
سؤال‌های تکمیلی مصاحبه
اگر فقط دو هفته برای بررسی مسئله فرصت داشته باشید چه می‌کنید؟
این پرسش در فایل مرجع آمده و توانایی ما را در محدود کردن دامنه مسئله و انتخاب روش یادگیری می‌سنجد.
در دو هفته قرار نیست یک سامانه کامل دسترس‌پذیری بسازیم.
ابتدا گروه هدف را مشخص می‌کنیم و با تعدادی از مسافران دارای نیازهای حرکتی گفت‌وگو می‌کنیم. مسیر فعلی جست‌وجو و رزرو آن‌ها را مشاهده می‌کنیم و نمونه‌ای از اقامتگاه‌ها را از نظر کامل بودن اطلاعات بررسی می‌کنیم.
سپس یک نمونه اولیه ساده از نمایش نیازهای ضروری و وضعیت تطبیق می‌سازیم و آن را با کاربران آزمایش می‌کنیم.
در پایان دو هفته باید بدانیم کدام ابهام بیشترین اثر را دارد، آیا راهکار پیشنهادی درک کاربران را بهتر می‌کند و مهم‌ترین مانع اجرایی چیست.
خروجی مطلوب یک تصمیم مستدل درباره آزمایش بعدی است، نه ادعای حل کامل مسئله.
چه شواهدی باعث می‌شود راهکار پیشنهادی خودتان را رد کنید؟
این هم دومین پرسش تکمیلی منبع اصلی است.
اگر بررسی‌ها نشان دهند کاربران اطلاعات لازم را به‌خوبی پیدا می‌کنند، اما اقامتگاه مناسب با قیمت و موقعیت قابل‌قبول وجود ندارد، بهتر کردن نمایش اطلاعات احتمالا اولویت اول نیست.
اگر داده‌های میزبانان بیش از حد ناقص یا غیرقابل‌اعتماد باشند، سیستم تطبیق می‌تواند نتیجه گمراه‌کننده تولید کند.
همچنین اگر آزمون‌های کاربردپذیری نشان دهند کاربران برداشت اشتباهی از وضعیت تأیید ویژگی‌ها دارند، یا بررسی پس از اقامت مغایرت‌های بیشتری نشان دهد، باید طراحی را اصلاح یا آزمایش را متوقف کنیم.
پایبند بودن به هدف کاربر مهم‌تر از دفاع کردن از اولین راهکاری است که پیشنهاد داده‌ایم.
اگر این تجربه تعداد رزروها را کاهش دهد چه می‌کنید؟
این پرسش، تکمیلی پیشنهادی برای تمرین بیشتر است و در دو سؤال تکمیلی فایل مرجع وجود ندارد.
ابتدا بررسی می‌کنم کاهش رزرو از کجا آمده است.
اگر کاربران به‌دلیل دریافت اطلاعات دقیق‌تر، از رزرو اقامتگاه‌های نامناسب منصرف شده‌اند، کاهش تبدیل لزوما نشانه شکست نیست.
اما اگر طراحی پیچیده شده یا اقامتگاه‌های مناسب به‌اشتباه حذف شده‌اند، باید راهکار را اصلاح کنیم.
تصمیم نهایی به کیفیت رزرو، رضایت واقعی مسافر، هزینه پشتیبانی و آثار تجاری بلندمدت بستگی دارد؛ نه یک عدد تبدیل به‌تنهایی.
پاسخ‌های ضعیف و اشتباهات رایج
پاسخ «یک فیلتر مخصوص افراد دارای معلولیت اضافه می‌کنم» بیش از حد کلی است. نه نیاز مشخصی را توضیح می‌دهد، نه امکانات فعلی Airbnb را در نظر می‌گیرد.
پاسخ «همه اقامتگاه‌های دسترس‌پذیر را اول نتایج می‌گذارم» هم بدون تعریف معیار دسترس‌پذیری ارزش چندانی ندارد. یک اقامتگاه ممکن است برای یک کاربر مناسب و برای دیگری نامناسب باشد.
پیشنهاد «با هوش مصنوعی از روی عکس‌ها تشخیص می‌دهیم کدام اقامتگاه مناسب است» نیز بدون بررسی دقت داده‌ها و پیامدهای خطا، تصمیم قابل‌دفاعی نیست. تشخیص خودکار شاید ابزار کمکی باشد، اما نمی‌توان بر اساس یک حدس تصویری به مسافر اطمینان قطعی داد.
در نهایت، پاسخ‌هایی که فقط نرخ تبدیل را معیار موفقیت می‌گیرند، پیامدهای واقعی تجربه اقامت را نادیده می‌گیرند.
در این سؤال، مصاحبه‌کننده بیشتر از تعداد قابلیت‌های پیشنهادی، به کیفیت تعریف مسئله، اولویت‌بندی و قدرت دفاع از تصمیم توجه می‌کند.
جمع‌بندی
برای طراحی تجربه بهتر رزرو Airbnb برای مسافران دارای نیازهای حرکتی، از اضافه کردن چند فیلتر شروع نمی‌کنم. ابتدا گروه مشخصی از کاربران را انتخاب می‌کنم، نیازهای ضروری آن‌ها را می‌شناسم و بررسی می‌کنم در کدام بخش مسیر رزرو، اطلاعات یا اطمینان کافی ندارند.
راهکار اولیه من، تطبیق شفاف نیازهای ضروری با اطلاعات مستند اقامتگاه، نمایش ابهام‌ها و ساده کردن مسیر رفع آن‌ها پیش از پرداخت است. این راهکار باید با کاربران واقعی و اطلاعات قابل‌اعتماد آزمایش شود و موفقیت آن را با نتیجه واقعی اقامت بسنجیم.
اگر شواهد نشان دهند مسئله اصلی کمبود اقامتگاه مناسب، ضعف داده‌های میزبانان یا حتی پیچیدگی تجربه پیشنهادی ماست، باید مسیر را تغییر دهیم. طراحی خوب در چنین مسئله‌ای فقط به معنای آسان کردن رزرو نیست؛ به معنای کمک به مسافر برای گرفتن تصمیمی آگاهانه و قابل‌اعتماد است.
