<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های بنفشه ذاکری</title><link>https://virgool.ir/feed/@banafshe.zakeri</link><description>بنفشه ذاکری هستم. طراح محصول، همواره در حال یادگیری و مشتاق کشف لحظه‌ای که طراحی واقعاً برای کاربر معنا پیدا می‌کند.</description><language>fa</language><pubDate>2026-11-11 06:09:25</pubDate><image><url>https://files.virgool.ir/upload/users/887607/avatar/9zAgHv.jpg</url><title>بنفشه ذاکری</title><link>https://virgool.ir/@banafshe.zakeri</link></image><item><title>روایتی از تست کاربردپذیری اولین نسخۀ صندوق فروشگاهی</title><link>https://virgool.ir/@banafshe.zakeri/روایتی-از-تست-کاربردپذیری-اولین-نسخۀ-صندوق-فروشگاهی-cwf5puoc9ulq</link><description>مقدمهپس از آماده شدن نسخۀ اولیۀ صندوق فروشگاهی، تصمیم گرفتیم برای ارزیابی دقیق میزان سهولت و درک‌پذیری فلوهای اصلی محصول، تست کاربردپذیری برگزار کنیم. به دلیل محدودیت زمانی و دشواری هماهنگی با سوپرمارکت‌دارانی که عملاً تمام روز درگیر فعالیت‌های فروشگاهی خود هستند، متاسفانه امکان اجرای تست با کاربران واقعی میسر نبود. در نتیجه، برای انجام این ارزیابی از چند نفر از همکاران درون هلدینگ کمک گرفتیم. چینش کاربران تست به این صورت بود: یک نفر کارشناس تضمین کیفیت (QA) برای سنجش دقیق‌تر فلوها از ابعاد مختلف، یکی از اعضای تیم مالی با دید حسابداری، دو توسعه‌دهنده (Developers) و در نهایت دو نفر از نیروهای خدماتی. همان‌طور که پیش‌بینی می‌شد حضور این دو نفر باعث شد تست به تجربۀ واقعی کاربران هدف نزدیک‌تر شود، چرا که بیش از سایرین با پرسونای اصلی محصول ــ یعنی مالکین سوپرمارکت‌های کوچک و کم‌تجربه از نظر فناوری ــ تطابق داشتند.برگزاری این تست‌ را با همراهی و کمک همکارم خانم مرضیه قربانی از تیم طراحی پیش بردیم تا فرایند مشاهده، تحلیل رفتار کاربر و مستندسازی یافته‌ها با دقت بیشتری انجام شود. در ادامه به مرور روند طراحی و آماده‌سازی جلسه و مهم‌ترین مشاهداتی که به درک عمیق‌تر ما از تجربۀ واقعی کاربران با صندوق فروشگاهی منجر شد، خواهیم پرداختطراحی و آماده‌سازی تست کاربردپذیریهدف اصلی ما از برگزاری این تست ارزیابی میزان کارایی (Efficiency)، یادگیری‌پذیری (Learnability) و وضوح مسیرهای اصلی تعامل (Clarity of Main Flows) در نسخۀ اولیۀ صندوق فروشگاهی بود. تمرکز ویژۀ ما روی بخش‌هایی بود که شامل فلوهای پرتکرار و حیاتی و یا شامل نقاطی باشند که بیشترین احتمال خطا یا سردرگمی در آن‌ها وجود دارد؛ از جمله ثبت کالای جدید در سیستم، ثبت و تست کارتخوان جدید، ایجاد فاکتور فروش و مرجوعی کالا. معیارهای ارزیابیبرای ارزیابی نتایج، مجموعه‌ای از شاخص‌های کمی و کیفی را در نظر گرفتیم:نرخ موفقیت (Task Success Rate)زمان انجام هر وظیفه (Task Completion Time)تعداد خطاها یا نقاط توقف کاربر (Error &amp; Friction Points)بازخورد ذهنی شرکت‌کننده‌ها (Subjective Feedback)در کنار داده‌های رفتاری، یادداشت‌های مشاهده‌گر و برداشت‌های تسهیل‌گر نیز به‌عنوان ورودی‌های کیفی مورد تحلیل قرار گرفتند:لحظاتی که کاربر برای یافتن دکمه یا گزینه‌ای مکث می‌کردواکنش‌های احساسی در مواجهه با واژه‌ها یا آیکون‌هااشتباهات تکرارشونده در میان چند شرکت‌کنندهفرایند اجرا و مشاهدهتست‌ها در بازه‌ای دو روزه و در قالب چند جلسۀ انفرادی در محیط واقعی دفتر و با استفاده از دستگاه اندروید صندوق فروشگاهی برگزار شد. هر جلسه بین 15 تا 30 دقیقه به طول انجامید و شامل سه مرحلۀ اصلی بود: آغاز و توضیح مقدماتی (Briefing)، اجرای سناریوها (Task Execution) و جمع‌بندی و گفت‌وگوی پایانی (Debriefing).نقش‌ها و نحوۀ اجرادر هر جلسه یکی از اعضای تیم طراحی نقش تسهیل‌گر (Facilitator) را بر عهده داشت و وظیفۀ هدایت کاربر، ارائۀ سناریوها و حفظ تمرکز جلسه را انجام می‌داد. هم‌زمان، نفر دوم در نقش ناظر (Observer) حضور داشت و به ثبت رفتار کاربر، لحظات مکث، خطاها، بازخوردهای کلامی و زبان بدن او می‌پرداخت. این تقسیم نقش کمک کرد تا هم تعامل مستقیم با کاربر حفظ شود و هم داده‌های رفتاری با دقت ثبت گردد.در طول اجرای سناریوها، از شرکت‌کنندگان خواسته شد تا بر اساس روش Think-Aloud Protocol افکار و تصمیمات خود را به زبان بیاورند. این رویکرد کمک کرد بتوانیم نقاطی را که باعث سردرگمی یا تردید در ذهن کاربر می‌شدند شناسایی کنیم، حتی زمانی که در ظاهر روند کار بدون خطا پیش می‌رفت.یادداشت‌های هر جلسه بلافاصله پس از پایان تست مرور و در نهایت در قالب یک الگوی واحد در figJam مستند شد. در ادامه، جزئیات هر سناریو و بینش‌هایی که از رفتار کاربران استخراج شد را بررسی می‌کنیم.تسک اول: افزودن کالای جدید در سیستمرفتار کاربران: در لیست ایجاد کالای جدید، فیلدی به نام «نقطۀ سفارش» وجود داشت که برای تمام شرکت‌کنندگان تست مبهم بود. (هدف از وجود این فیلد اختیاری این بود که مشخص شود هر کالا با رسیدن به چه تعدادی نیاز به ارسال نوتیفیکیشن به کاربر برای ثبت سفارش مجدد دارد.) البته فرض ما بر این است که کاربران واقعی محصول که با بیزنس آشنایی بیشتری دارند، احتمالاً این اصطلاح را متوجه خواهند شد؛ در نتیجه تصمیم به بازنگری یا توضیح بیشتر در نسخه‌های بعدی گرفته خواهد شد.یکی از شرکت‌کنندگان برای ثبت کالا به جای منوی «کالاها»، سراغ بخش «انبار» رفت به این دلیل که فکر می‌کرد باید از آنجا کالا را اضافه کند. سه نفر نیز در بخش مربوط به تخفیف کالا مکث داشتند؛ چرا که ترتیب فیلدها (ابتدا مبلغ و سپس درصد تخفیف) با مدل ذهنی آن‌ها (ابتدا درصد و سپس مبلغ تخفیف) مطابقت نداشت.دکمۀ ثبت کالا در پایین صفحه قرار داشت و همواره قابل مشاهده بود که این باعث شد برخی کاربران گمان کنند فرم تکمیل شده و بدون پر کردن تمام فیلدها اقدام به لمس دکمۀ ثبت کنند.نتیجه و شاخص‌ها:نرخ موفقیت: پنج نفر موفق، یک نفر با راهنماییمیانگین زمان تکمیل تسک: ۲:۳۰ دقیقه (طولانی‌ترین زمان در میان سایر تسک‌ها)اصلاحات طراحی مبتنی بر یافته‌ها:اصطلاح «نقطۀ سفارش» در نسخه‌های بعدی یا ساده‌تر خواهد شد یا با توضیح مختصر همراه می‌شود تا برای کاربران واقعی شفاف باشد.ترتیب فیلدها در بخش تخفیف اصلاح شد تا با مدل ذهنی کاربران هماهنگ باشد.دکمۀ «ثبت کالا» از حالت چسبیده به پایین صفحه خارج شد تا کاربر پس از مشاهدۀ کل فرم به آن برسد.تسک دوم: ویرایش کالای موجودرفتار کاربران:در این تسک، پنج نفر توانستند با موفقیت کالای مورد نظر را ویرایش کنند و تنها یک نفر تسک را ناتمام گذاشت. این شرکت‌کننده دکمۀ «ویرایش» پایین فرم را به‌اشتباه به منزلۀ دکمۀ آغاز ویرایش جدید تلقی کرد، در حالی که عملکرد واقعی آن، تأیید تغییرات فعلی بود. سایر شرکت‌کنندگان مسیر را به‌درستی طی کردند اما دو نفر از آن‌ها پیش از زدن دکمه، مکث کوتاهی داشتند که فرضیۀ دوپهلو بودن معنای واژۀ «ویرایش» را تقویت می‌کرد.نتیجه و شاخص‌ها:نرخ موفقیت: پنج نفر موفق، یک نفر ناموفقمیانگین زمان تکمیل تسک: ۳۶ ثانیهاصلاحات طراحی مبتنی بر یافته‌ها:متن دکمۀ «ویرایش» به «ذخیرۀ تغییرات» تغییر یافت تا هدف عملکرد به‌روشنی مشخص شود.در مستند طراحی، تأکید شد که واژه‌های عملکردی (Action Words) باید دقیق و بی‌ابهام انتخاب شوند.تسک سوم: حذف کالا رفتار کاربران: در این تسک، کاربران باید اقدام به حذف همزمان تعدادی کالای مشخص می‌کردند. فلوی طراحی‌شدۀ ساده‌تر برای حذف چند کالا به‌این ترتیب بود که به‌محض انتخاب یک کالا، دکمۀ «حذف گروهی» در قسمت پایین جدول از حالت غیرفعال به فعال تبدیل می‌شد؛ منطقی که بعدها مشخص شد چندان برای شرکت‌کنندگان واضح نبوده‌است؛ طوری که تنها دو نفر از شش نفر به ارتباط بین انتخاب کالا و فعال شدن دکمه پی بردند و از قابلیت حذف گروهی استفاده کردند. سایر کاربران ناچار به حذف تک‌به‌تک کالاها شدند. این رفتار نشان داد که منطق فعال‌سازی مشروط، بدون نشانه‌گذاری بصری کافی، منجر به درک ناقص از قابلیت‌ها می‌شود.نتیجه و شاخص‌ها:نرخ موفقیت: چهار نفر موفق، دو نفر با راهنماییمیانگین زمان تکمیل تسک: ۲۱ ثانیهاصلاحات طراحی مبتنی بر یافته‌ها:پیام راهنمای کوتاهی اضافه شد تا کاربران به‌نحو شفاف‌تری با ویژگی «حذف گروهی کالا» و نحوۀ استفاده از آن آشنا شوند.تسک چهارم: تعریف انبار جدیدرفتار کاربران:تمام شرکت‌کنندگان موفق شدند انبار جدید را بسازند و فلو اصلی بدون مشکل اجرا شد. با این حال، دو نفر درک صحیحی از مفهوم «انبار پیش‌فرض» نداشتند و عملکرد دقیق این گزینه برایشان مبهم بود؛ انتخاب این گزینه به‌منزلۀ قرار دادن انبار موردنظر به‌عنوان مبدا یا مقصد در تمامی فلوهای اصلی صندوق از جمله خرید، فروش، مرجوعی خرید و مرجوعی فروش است.نتیجه و شاخص‌ها:نرخ موفقیت: شش نفر موفقمیانگین زمان تکمیل تسک: 19 ثانیهاصلاحات طراحی مبتنی بر یافته‌ها: واژۀ «انبار پیش‌فرض» به «انبار فروشگاه» تغییر یافت تا برای کاربران شفاف‌تر و قابل‌فهم‌تر باشد.تسک پنجم: انتخاب انبار پیش‌فرض رفتار کاربران:در این تسک، شرکت‌کنندگان باید انبار خواسته‌شده را به‌عنوان انبار پیش‌فرض انتخاب می‌کردند. پنج نفر این کار را بدون مشکل انجام دادند و یک نفر با راهنمایی موفق شد. با وجود اینکه در تسک قبل کاربران با مفهوم «انبار پیش‌فرض» آشنا شده بودند، باز هم ترکیب این مفهوم با وضعیت‌های «فعال/غیرفعال» باعث مکث و گیج‌شدن آن‌ها شد. یکی از کاربران نیز انتظار داشت تغییرات مستقیماً با کلیک روی سلول موردنظر در جدول امکان‌پذیر باشد و به صفحۀ ویرایش منتقل نشود، که نشان‌دهندهٔ تفاوت بین مدل ذهنی کاربر و جریان طراحی است.نتیجه و شاخص‌ها:نرخ موفقیت: پنج نفر موفق، یک نفر با راهنماییمیانگین زمان تکمیل تسک: 8 ثانیهاصلاحات طراحی مبتنی بر یافته‌ها:علاوه بر تغییر واژۀ «پیش‌فرض» که در تسک قبل ذکر شد، به جای اصطلاحات «فعال» و «غیرفعال» از عبارات «قابل فروش» و «غیرقابل فروش» استفاده شد تا وضوح بیشتری ایجاد شود.تسک ششم: ثبت فاکتور فروش  رفتار کاربران: هدف از انجام این تسک، ثبت فاکتور فروش برای چند کالای مختلف بود. متاسفانه در طول اجرای تست با مشکل اتصال بارکدخوان به صندوق مواجه شدیم و کاربران مجبور شدند از مسیر جایگزین (جستجوی کالا و یا انتخاب دستی کالاها از لیست) استفاده کنند. این مسیر با انتظارات ذهنی اغلب شرکت‌کنندگان از عملکرد صندوق تفاوت قابل‌توجهی داشت تا آن‌جا که حتی دو نفر به جای تب «صندوق»، وارد بخش «کالاها» شدند و مسیر اصلی فلو را گم کردند؛ در واقع تجربۀ مشاهده‌شده در این تست بیشتر بازتاب محدودیت‌های محیط تست بود تا بازتاب دقیقی از تجربۀ واقعی فلوی محصول.نتیجه و شاخص‌ها: نرخ موفقیت: چهار نفر موفق، دو نفر با راهنماییمیانگین زمان تکمیل تسک: ۲ دقیقهیادداشت درباره محدودیت تست:در نسخه‌های بعدی، تست با تجهیزات کامل (بارکدخوان متصل) انجام خواهد شد تا ارزیابی واقعی‌تری صورت گیرد.تسک هفتم: ثبت کارتخوان و انجام تست اتصالرفتار کاربران:هدف این تسک، تنظیم و تست دستگاه کارتخوان جهت ایجاد اطمینان از اتصال آن به صندوق فروشگاهی بود. مسیر این کار در طراحی ما از طریق بخش «تنظیمات» انجام می‌شد که در قالب یک آیکون در بالای صفحه قرار گرفته‌بود. این در حالی بود که تمام تسک‌های قبلی از منوی اصلی آغاز می‌شد و ذهنیت کاربران بر این اساس شکل گرفته بود. این شد که همۀ کاربران ابتدا به دنبال گزینۀ کارتخوان در منوی اصلی گشتند و پس از جستجو و ناکامی در یافتن، سرانجام مسیر صحیح یعنی آیکون بالای صفحه را پیدا کردند. علاوه بر این، وجود آیکون ماشین حساب در کنار آیکون تنظیمات، به‌خاطر وجود شباهت بصری با کارتخوان، برخی کاربران را به مسیر اشتباه هدایت کرد.نتیجه و شاخص‌ها:نرخ موفقیت: چهار نفر موفق، دو نفر با راهنماییمیانگین زمان تکمیل تسک: ۵۲ ثانیهاصلاحات طراحی مبتنی بر یافته‌ها:این رفتار کاربران ناشی از سوگیری مدل ذهنی کاربر (User Mental Model Bias) بود؛ آن‌ها انتظار داشتند مسیر تمام تسک‌ها مشابه تسک‌های پیشین از منوی اصلی باشد و همین سوگیری باعث شد ابتدا مسیر اشتباه را دنبال کنند. برای کاهش این سوگیری در تست‌های بعدی، لازم است مسیرهای جدید یا بخش‌های متفاوت محصول قبل از اجرای تست به کاربران معرفی شود یا با یک آموزش کوتاه پیش از شروع تسک، ذهنیت آن‌ها با جریان صحیح هماهنگ گردد.هنگام طراحی و انتخاب آیکون‌ها باید دقت لازم اعمال شود تا مفاهیم مشابه به‌طور کامل از هم قابل تشخیص و تفکیک باشند.جمع‌بندیتجربۀ اجرای تست کاربردپذیری اولین نسخۀ صندوق فروشگاهی، بیش از آنکه صرفاً یک ارزیابی محصول باشد، یادآور این مساله بود که طراحی خوب در جزئیات معنا پیدا می‌کند. واژه‌ای که برای تیم بدیهی است، می‌تواند برای کاربر گیج‌کننده باشد. سوگیری‌های ذهنی کاربران و محدودیت‌های محیط تست نیز می‌توانند مسیر تعامل را به‌طور غیرمنتظره‌ای تحت تاثیر قرار دهند.از همۀ این‌ها مهم‌تر این‌که کاربران واقعی وقت کلنجار رفتن با طراحی ما را ندارند؛ هر مکث و توقف کوچک در محیط فروشگاه، تاثیر مستقیم روی تجربه و کارایی کاربر دارد. </description><category>بنفشه ذاکری</category><author>بنفشه ذاکری</author><pubDate>Sat, 18 Oct 2025 18:37:33 +0330</pubDate></item><item><title>مطالعۀ موردی بازطراحی جستجوی محتوا در اپلیکیشن «بله»</title><link>https://virgool.ir/@banafshe.zakeri/مطالعۀ-موردی-بازطراحی-جستجوی-محتوا-در-اپلیکیشن-بله-bsufy9s6a6jn</link><description>مقدمهجستجوی محتوا در اپلیکیشن «بله» قابلیتی است برای جستجو در میان کانال‌های عمومی موجود در این اپلیکیشن و یافتن محتوای موردنظر توسط کاربر که این محتوا می‌تواند به‌صورت متن، تصویر و یا ویدئو باشد. در واقع این قابلیت با هدف بهبود یافت‌پذیری محتوا و دسترسی آسان و سریع کاربران به محتوای موجود در کانال‌ها توسعه داده‌شده است. در این مقاله قصد داریم گام به گام مسیری که برای بازطراحی این محصول طی شد را به‌همراه نتایج حاصل از آن بررسی کنیم.مسئلهمسئلۀ اصلی از آن‌جا شروع شد که «بله» تصمیم به ایجاد یک اکوسیستم محتوایی مطابق با نیاز کاربرانش گرفت که یکی از ارکان‌ مهم ساخت این اکوسیستم، یافت‌پذیری محتوا بود. ویژگی جستجوی محتوایی به‌عنوان راهکار اصلی این مسئله، پیش از این نیز در «بله» وجود داشت اما به‌علت اهمیت کمتر در برنامه‌های گذشتۀ محصول، چندان فرصت پرداختن به آن فراهم نشده و قدری از مسیر توسعه بازمانده بود؛ بنابراین تصمیم به ایجاد تیمی منحصر به «جستجو» گرفته و در اولین قدم به سراغ شاخص‌های ارزیابی عملکرد تعریف شده برای این محصول در دورۀ گذشته (میانگین تعداد کاربران استفاده‌کننده از جستجو در هفت روز گذشته و همچنین درصد کاربرانی که موفق شدند در این زمان به محتوای موردنظر خود دسترسی پیدا کنند) رفتیم و از مقایسۀ این KPIها با داده‌های موجود متوجه اختلاف معنادار میان آن‌ها شدیم؛ این شد که تصمیم گرفتیم برای بهبود شاخص‌های ارزیابی عملکرد و کمک به اکوسیستم محتوایی به بازطراحی کامل ویژگی جستجو بپردازیم.تحلیل رقبا یا Benchmarkدر گام اول تصمیم گرفتیم برای درک بهتر از سازوکار و الگوی جستجو در میان اپلیکیشن‌های موجود، به بررسی و  تحلیل این قابلیت در آن‌ها بپردازیم. به این منظور سراغ تعدادی از محصولات محبوب‌ و نام‌آشنا رفته و آن‌ها را در دو دستۀ کلی شبکه‌های اجتماعی (مانند WhatsApp, Telegram, Clubhouse, Facebook, Tik Tok, Instagram, Reddit, Product Hunt, ایتا و روبیکا) و اپلیکیشن‌هایی که عرضه‌کنندۀ محصولات در حوزه‌های مختلف هستند، (همچون YouTube, Castbox, Apple Music, Pinterest, Dribbble, Medium, دیجی‌کالا و طاقچه) طبقه‌بندی کرده و به بررسی الگوی جستجو در هر یک از آن‌ها پرداختیم. در هر دو دسته تعدادی از محصولات از الگوی مشابهی تبعیت می‌کردند. بنابراین مطابق تصویر زیر در هر بخش به زیردسته‌هایی رسیدیم:شبکه‌های اجتماعی: ۱. با محوریت پیام‌رسانی  ۲. با محوریت محتوا (شامل دو زیردستۀ با و بدون استفاده از هوش مصنوعی)عرضه‌کنندۀ محصول: ۱. محصول فیزیکی ۲. محصول متنی مثل مقاله ۳.محصول محتوایی مثل موزیکطبقه‌بندی اپلیکیشن‌های حوزۀ «شبکه‌های اجتماعی» به‌همراه الگوی جستجوی استنتاج‌شده از هر زیردستهطبقه‌بندی اپلیکیشن‌های «عرضه‌کنندۀ محصول» به‌همراه الگوی جستجوی استنتاج‌شده از هر زیردستهدر نهایت از ادغام موارد مشابه در میان شش الگوی جستجوی به‌دست آمده از شش زیردستۀ بالا، مطابق تصویر زیر به چهار الگوی متفاوت رسیدیم.ادغام و دسته‌بندی الگوهای جستجوی به‌دست آمده در بنچ‌مارک در چهار دستۀ نهاییدر این میان به منظور ایجاد دیدی بهتر مابین اعضای تیم نسبت به تمام راهکارهای موجود در طراحی، تصمیم گرفتیم دسته‌بندی دیگری براساس چهار گام اصلی تشکیل‌دهندۀ فرآیند جستجو ارائه داده و راهکارهای مربوط به هر گام را مشخص کنیم:۱. صفحۀ اصلی نمایش‌دهندۀ ویژگی جستجو۲. صفحۀ بازشونده بعد از کلیک روی جستجو۳. صفحۀ در حال تایپ عبارت جستجو۴. صفحۀ نمایش نتایج جستجونمایشی از تمام حالات ممکن در چهار گام اصلی فرآیند جستجو مصاحبه با کاربرانبرای رسیدن به راه‌حل نهایی یعنی یافتن الگوی جستجوی مناسب برای «بله» از میان چهار الگوی بالا، لازم دیدیم با تعدادی از کاربران این اپلیکیشن با جنسیت و سطوح دانش فنی متفاوت که حداقل از یک محصول یا اپلیکیشن محتوامحور به‌طور مرتب استفاده می‌کنند، مصاحبه کنیم.هدف مصاحبه: کشف الگوهای رفتاری جستجو، دسته‌بندی الگوهای مشترک متناسب با نوع محصول «بله» و هم‌چنین پیدا کردن انتظارات افراد از جستجوی خوبیافته‌های جلسۀ مصاحبه: یافته‌های این جلسه در سه بخش به‌صورت زیر جمع‌بندی شد: ۱. قبل از جستجواغلب کاربران، علاقه‌مند به پیشنهاد ترندهای روز، کانال‌های پربازدید و … هستند.دوست دارند در مواقع نیاز، دسته‌بندی موردنظر خود را قبل از تایپ عبارت انتخاب کنند.۲. در حین جستجوانتظار دریافت پیشنهاد (پیش‎‌بینی) هنگام تایپ کردن دارند. (در بیشتر مواقع حدس کلمه و دو مورد پیشنهادهای مرتبط)۳. بعد از جستجو (مشاهدۀ نتایچ)از دسته‌بندی‌ها (فیلترها) استفاده می‌کنند.علاقه‌مند به پیشنهاد محتواهای مرتبط هستند.از مرتب‌سازی استفاده می‌کنند.در نهایت از تلفیق نتایج مصاحبه با چهار الگوی جستجوی حاصل از بنچ‌مارک، به الگوی جستجوی محتوای مناسب برای «بله» رسیدیم.الگوی جستجوی محتوای مناسب برای بله شروع فرآیند طراحی رابط کاربریبا شروع فرآیند طراحی وایرفریم و در ادامه رابط کاربری، در جلسات هفتگی منظمی که با مالک محصول و سرپرست تیم طراحی داشتیم، به بررسی جزئیات مختلف طرح، بایدها و نبایدهای جستجو در «بله» و محدودیت‌های زمانی و فنی موجود پرداخته و در نهایت به طرح رابط کاربری نهایی جستجو رسیدیم.بازطراحی‌های اولیهبازطراحی صفحۀ «کلیک روی جستجو»بازطراحی صفحۀ «در حال تایپ» بازطراحی صفحۀ «نمایش نتایج»در ادامه به توضیح چند نمونه از مسائلی که در فرآیند بازطراحی جستجو با آن مواجه بودیم پرداخته و راه‌حل‌های پیشنهادی را بررسی می‌کنیم.مسئله ۱: تصمیم‌گیری راجع به الگوی هایلایت مناسب در قسمت پیشنهاد نتایج به کاربر در حال تایپدر مقاله nngroup با عنوان site search suggestion، گفته شده زمانی که قرار است پیشنهادهای داده‌شده توسط موتور جستجو، به ابتدا و یا انتهای عبارت تایپ‌شده توسط کاربر اضافه شود (فقط به انتهای عبارت اضافه نشود)، بهتر است عبارت تایپ‌شده بولد شود. با درنظر گرفتن این موضوع و با توجه به اینکه در جستجوی «بله» کاربران اغلب در وضعیت در حال تایپ، روی عبارتی که خود تایپ کرده‌اند متمرکزند تا اینکه به دنبال دریافت پیشنهادهای تکمیل‌کننده باشند و از طرفی برای اینکه الگوی هایلایت در هر دو صفحۀ «در حال تایپ» و «نمایش نتایج» همخوانی داشته و منجر به ایجاد حس دوگانگی در کاربر نشود، تصمیم بر این شد که عبارت تایپ‌شده را هایلایت کنیم. به‌طور کلی پیشنهاد عبارت مناسب در زمان تایپ، مزایای زیادی به‌همراه دارد:کاهش interaction cost برای کاربر به‌ علت نیاز به تایپ کمترکاهش خطاهای تایپیو از همه مهم‌تر کاهش mental effort کاربر برای به‌یاد آوردن آن‌چه قصد جستجویش را داشتهمسئله ۲: تصمیم‌گیری راجع به انتخاب نوع محتوای پیشنهادی به کاربر در حال تایپدر اینجا چالش اصلی انتخاب بین پیشنهاد کانال، محتوا و یا ترکیبی از این دو بود. داده‌های ما در این بخش شامل این موارد می‌شد:مطابق نتایج بنچ‌مارک، اغلب اپلیکیشن‌ها همچون Pinterest, Castbox و Apple Music در این بخش ابتدا محصول خود را پیشنهاد می‌دهند که برای «بله» محصول همان کانال است.مدل ذهنی کاربران نیز از نسخۀ قبلی جستجو، بیشتر مطابق با پیشنهاد کانال بود.از طرفی طبق نتایج مصاحبه، هدف ۵۰ درصد کاربران از جستجو، رسیدن به ترکیبی از محتوا و کانال، ۳۳ درصد رسیدن به فقط محتوا و ۱۷ درصد رسیدن به فقط کانال بود.طبق موارد بالا در نهایت تصمیم بر این شد پیشنهاد نتایج در حال تایپ را به پیشنهاد سه کانال و دو محتوا با تقدم کانال اختصاص دهیم.مسئله ۳: نحوۀ طراحی کامپوننت محتوابا توجه به اینکه این کامپوننت در دیزاین سیستم و محصول «بله» کامپوننت جدیدی محسوب می‌شد و تا پیش از این چنین نمایشی در بخش جستجو وجود نداشت، برای ما مهم بود طراحی به‌گونه‌ای باشد که علاوه بر ارائه اطلاعات موردنیاز به کاربر جهت تصمیم‌گیری برای کلیک یا عدم کلیک روی نتیجه، حسی مبنی بر اطمینان نسبت به معتبر بودن محتوا نیز ایجاد کند. به این منظور تغییراتی در طراحی این کامپوننت نسبت به طرح‌های اولیه ایجاد شد:اضافه شدن آواتار و تعداد اعضای کانال برای ایجاد حس اعتماد و تایید اجتماعی (Social Proof) در کاربراضافه شدن تاریخ انتشار محتوا جهت اطمینان از به‌روز بودن آنبزرگ‌تر شدن تصویر برای دادن اطلاعات بیشتر و واضح‌تر به کاربرفرآیند تغییر کامپوننت محتوادر این میان در تعامل با تیم فنی بنا به ملاحظات زمانی موجود و برای رسیدن طرح به نسخۀ پیش‌رو قرار به این شد که ویژگی مرتب‌سازی در صفحۀ «نمایش نتایج جستجو» به نسخه‌های آتی موکول شود.طراحی‌ نهاییطراحی نهایی صفحات «جستجو»تست کاربردپذیریپس از انتشار نسخۀ اولیه تصمیم گرفتیم برای مشاهدۀ نحوۀ استفادۀ کاربران از جستجوی جدید و گرفتن بازخورد، به‌صورت تصادفی با تعدادی از آن‌ها تست کاربردپذیری برگزار کنیم. در این بین فرضیاتی نیز وجود داشت که نیاز به راستی‌آزمایی آن‌ها داشتیم. سناریوی تست: در این تست از کاربران خواستیم وارد تب «جریان» شده و دو موضوع یا عبارت را به دل‌خواه خود جستجو کنند.اهدف تست:پی بردن به میزان توجه کاربران به بخش «برترین‌های روز»پی بردن به میزان توجه کاربران به پیشنهادهای داده شده در حال تایپاستفاده یا عدم استفاده از دکمۀ «مشاهدۀ همۀ نتایج»میزان توجه به سه تب محتوا، تصویر و کانال در مقایسه با همبخشی از یافته‌های تست:۸ درصد از کاربران موفق شدند سناریوی تعریف شده را با موفقیت به اتمام برسند.تنها ۲۵ درصد از کاربران از پیشنهادهای داده شده در حال تایپ استفاده کردند که این رقم با گفتۀ مقالۀ nngroup یعنی ۲۳ درصد تا حد زیادی همخوانی داشت.۲۵ درصد از کاربران متوجه دکمه «مشاهدۀ همۀ نتایج» نشدند.نتایج و دستاوردها پس از توسعۀ محصول، از بررسی و رصد داده‌های موجود پس از حدود یک ماه به کمک تیم داده به نتایج زیر رسیدیم:رشد ۶۷ درصدی تعداد کاربرانی که روی جستجو در تب «جریان» کلیک کردندافزایش ۲۰ درصدی تعداد کاربرانی که بعد از کلیک روی جستجو، وارد فرآیند شده و عبارتی را جستجو کردند (در نسخۀ قبل ۵۰٪ از افراد کلیک‌کننده و در نسخۀ جدید ۷۰٪ از آن‌ها شروع به جستجو کردند.)رشد ۷ درصدی Success Rate (جستجوهای موفق: جستجویی که به کلیک روی یک یا تعدادی از نتایج توسط کاربر منتهی ‌شود.)افزایش چشمگیر ۲.۴ برابری در میانگین تعداد کلیک‌های کاربران در روز</description><category>بنفشه ذاکری</category><author>بنفشه ذاکری</author><pubDate>Sat, 18 May 2024 11:30:49 +0330</pubDate></item></channel></rss>