جستجوی محتوا در اپلیکیشن «بله» قابلیتی است برای جستجو در میان کانال‌های عمومی موجود در این اپلیکیشن و یافتن محتوای موردنظر توسط کاربر که این محتوا می‌تواند به‌صورت متن، تصویر و یا ویدئو باشد. در واقع این قابلیت با هدف بهبود یافت‌پذیری محتوا و دسترسی آسان و سریع کاربران به محتوای موجود در کانال‌ها توسعه داده‌شده است. در این مقاله قصد داریم گام به گام مسیری که برای بازطراحی این محصول طی شد را به‌همراه نتایج حاصل از آن بررسی کنیم.
مسئلۀ اصلی از آن‌جا شروع شد که «بله» تصمیم به ایجاد یک اکوسیستم محتوایی مطابق با نیاز کاربرانش گرفت که یکی از ارکان مهم ساخت این اکوسیستم، یافت‌پذیری محتوا بود. ویژگی جستجوی محتوایی به‌عنوان راهکار اصلی این مسئله، پیش از این نیز در «بله» وجود داشت اما به‌علت اهمیت کمتر در برنامه‌های گذشتۀ محصول، چندان فرصت پرداختن به آن فراهم نشده و قدری از مسیر توسعه بازمانده بود؛ بنابراین تصمیم به ایجاد تیمی منحصر به «جستجو» گرفته و در اولین قدم به سراغ شاخص‌های ارزیابی عملکرد تعریف شده برای این محصول در دورۀ گذشته (میانگین تعداد کاربران استفاده‌کننده از جستجو در هفت روز گذشته و همچنین درصد کاربرانی که موفق شدند در این زمان به محتوای موردنظر خود دسترسی پیدا کنند) رفتیم و از مقایسۀ این KPIها با داده‌های موجود متوجه اختلاف معنادار میان آن‌ها شدیم؛ این شد که تصمیم گرفتیم برای بهبود شاخص‌های ارزیابی عملکرد و کمک به اکوسیستم محتوایی به بازطراحی کامل ویژگی جستجو بپردازیم.
در گام اول تصمیم گرفتیم برای درک بهتر از سازوکار و الگوی جستجو در میان اپلیکیشن‌های موجود، به بررسی و تحلیل این قابلیت در آن‌ها بپردازیم. به این منظور سراغ تعدادی از محصولات محبوب و نام‌آشنا رفته و آن‌ها را در دو دستۀ کلی شبکه‌های اجتماعی (مانند WhatsApp, Telegram, Clubhouse, Facebook, Tik Tok, Instagram, Reddit, Product Hunt, ایتا و روبیکا) و اپلیکیشن‌هایی که عرضه‌کنندۀ محصولات در حوزه‌های مختلف هستند، (همچون YouTube, Castbox, Apple Music, Pinterest, Dribbble, Medium, دیجی‌کالا و طاقچه) طبقه‌بندی کرده و به بررسی الگوی جستجو در هر یک از آن‌ها پرداختیم.
در هر دو دسته تعدادی از محصولات از الگوی مشابهی تبعیت می‌کردند. بنابراین مطابق تصویر زیر در هر بخش به زیردسته‌هایی رسیدیم:
در نهایت از ادغام موارد مشابه در میان شش الگوی جستجوی به‌دست آمده از شش زیردستۀ بالا، مطابق تصویر زیر به چهار الگوی متفاوت رسیدیم.
در این میان به منظور ایجاد دیدی بهتر مابین اعضای تیم نسبت به تمام راهکارهای موجود در طراحی، تصمیم گرفتیم دسته‌بندی دیگری براساس چهار گام اصلی تشکیل‌دهندۀ فرآیند جستجو ارائه داده و راهکارهای مربوط به هر گام را مشخص کنیم:
۱. صفحۀ اصلی نمایش‌دهندۀ ویژگی جستجو
۲. صفحۀ بازشونده بعد از کلیک روی جستجو
۳. صفحۀ در حال تایپ عبارت جستجو
۴. صفحۀ نمایش نتایج جستجو
برای رسیدن به راه‌حل نهایی یعنی یافتن الگوی جستجوی مناسب برای «بله» از میان چهار الگوی بالا، لازم دیدیم با تعدادی از کاربران این اپلیکیشن با جنسیت و سطوح دانش فنی متفاوت که حداقل از یک محصول یا اپلیکیشن محتوامحور به‌طور مرتب استفاده می‌کنند، مصاحبه کنیم.
هدف مصاحبه: کشف الگوهای رفتاری جستجو، دسته‌بندی الگوهای مشترک متناسب با نوع محصول «بله» و همچنین پیدا کردن انتظارات افراد از جستجوی خوب
یافته‌های جلسۀ مصاحبه: یافته‌های این جلسه در سه بخش به‌صورت زیر جمع‌بندی شد:
۱. قبل از جستجو
۲. در حین جستجو
۳. بعد از جستجو (مشاهدۀ نتایچ)
در نهایت از تلفیق نتایج مصاحبه با چهار الگوی جستجوی حاصل از بنچ‌مارک، به الگوی جستجوی محتوای مناسب برای «بله» رسیدیم.
با شروع فرآیند طراحی وایرفریم و در ادامه رابط کاربری، در جلسات هفتگی منظمی که با مالک محصول و سرپرست تیم طراحی داشتیم، به بررسی جزئیات مختلف طرح، بایدها و نبایدهای جستجو در «بله» و محدودیت‌های زمانی و فنی موجود پرداخته و در نهایت به طرح رابط کاربری نهایی جستجو رسیدیم.
در ادامه به توضیح چند نمونه از مسائلی که در فرآیند بازطراحی جستجو با آن مواجه بودیم پرداخته و راه‌حل‌های پیشنهادی را بررسی می‌کنیم.
مسئله ۱: تصمیم‌گیری راجع به الگوی هایلایت مناسب در قسمت پیشنهاد نتایج به کاربر در حال تایپ
در مقاله nngroup با عنوان site search suggestion، گفته شده زمانی که قرار است پیشنهادهای داده‌شده توسط موتور جستجو، به ابتدا و یا انتهای عبارت تایپ‌شده توسط کاربر اضافه شود (فقط به انتهای عبارت اضافه نشود)، بهتر است عبارت تایپ‌شده بولد شود. با درنظر گرفتن این موضوع و با توجه به اینکه در جستجوی «بله» کاربران اغلب در وضعیت در حال تایپ، روی عبارتی که خود تایپ کرده‌اند متمرکزند تا اینکه به دنبال دریافت پیشنهادهای تکمیل‌کننده باشند و از طرفی برای اینکه الگوی هایلایت در هر دو صفحۀ «در حال تایپ» و «نمایش نتایج» همخوانی داشته و منجر به ایجاد حس دوگانگی در کاربر نشود، تصمیم بر این شد که عبارت تایپ‌شده را هایلایت کنیم. به‌طور کلی پیشنهاد عبارت مناسب در زمان تایپ، مزایای زیادی به‌همراه دارد:
مسئله ۲: تصمیم‌گیری راجع به انتخاب نوع محتوای پیشنهادی به کاربر در حال تایپ
در اینجا چالش اصلی انتخاب بین پیشنهاد کانال، محتوا و یا ترکیبی از این دو بود. داده‌های ما در این بخش شامل این موارد می‌شد:
طبق موارد بالا در نهایت تصمیم بر این شد پیشنهاد نتایج در حال تایپ را به پیشنهاد سه کانال و دو محتوا با تقدم کانال اختصاص دهیم.
مسئله ۳: نحوۀ طراحی کامپوننت محتوا
با توجه به اینکه این کامپوننت در دیزاین سیستم و محصول «بله» کامپوننت جدیدی محسوب می‌شد و تا پیش از این چنین نمایشی در بخش جستجو وجود نداشت، برای ما مهم بود طراحی به‌گونه‌ای باشد که علاوه بر ارائه اطلاعات موردنیاز به کاربر جهت تصمیم‌گیری برای کلیک یا عدم کلیک روی نتیجه، حسی مبنی بر اطمینان نسبت به معتبر بودن محتوا نیز ایجاد کند. به این منظور تغییراتی در طراحی این کامپوننت نسبت به طرح‌های اولیه ایجاد شد:
در این میان در تعامل با تیم فنی بنا به ملاحظات زمانی موجود و برای رسیدن طرح به نسخۀ پیش‌رو قرار به این شد که ویژگی مرتب‌سازی در صفحۀ «نمایش نتایج جستجو» به نسخه‌های آتی موکول شود.
پس از انتشار نسخۀ اولیه تصمیم گرفتیم برای مشاهدۀ نحوۀ استفادۀ کاربران از جستجوی جدید و گرفتن بازخورد، به‌صورت تصادفی با تعدادی از آن‌ها تست کاربردپذیری برگزار کنیم. در این بین فرضیاتی نیز وجود داشت که نیاز به راستی‌آزمایی آن‌ها داشتیم.
سناریوی تست:
در این تست از کاربران خواستیم وارد تب «جریان» شده و دو موضوع یا عبارت را به دل‌خواه خود جستجو کنند.
اهدف تست:
بخشی از یافته‌های تست:
پس از توسعۀ محصول، از بررسی و رصد داده‌های موجود پس از حدود یک ماه به کمک تیم داده به نتایج زیر رسیدیم:
