جست‌وجوی صوتی می‌تواند راه دیگری برای وارد کردن پرسش باشد، اما با اضافه کردن تصویر میکروفون کامل نمی‌شود. کاربر باید بداند چه زمانی صدا دریافت می‌شود، چه متنی تشخیص داده شده و چگونه آن را اصلاح کند. همچنین قابلیت صوتی نباید تنها مسیر جست‌وجو باشد. محیط شلوغ، محدودیت دستگاه یا ترجیح شخصی ممکن است استفاده از صدا را نامناسب کند. طراحی باید امکان انتخاب و برگشت به ورودی متنی را حفظ کند.
دو موضوع را جدا ببینید: جست‌وجوی صوتی داخل سایت و پیدا شدن محتوای سایت از طریق دستیار یا موتور بیرونی. اولی به دریافت صدا، تبدیل به متن و نمایش نتیجه مربوط است؛ دومی به قابلیت‌ها و سیاست‌های سرویس بیرونی وابسته است. داشتن Schema یا بخش FAQ تضمین نمی‌کند یک دستیار پاسخ شما را انتخاب کند. آمار عمومی درباره سهم جست‌وجوی صوتی نیز بدون منبع، تاریخ و تعریف جامعه، مبنای تصمیم محصول نیست.
نیاز کاربر را پیش از انتخاب فناوری بررسی کنید
برای مثال فرضی، فروشگاه کتابی را در نظر بگیرید که کاربرانش عنوان را با گوشی جست‌وجو می‌کنند. بعضی عنوان‌ها طولانی‌اند و ورود صوتی ممکن است کمک کند، اما نام نویسنده یا واژه خارجی نیز احتمال تشخیص نادرست دارد. ابتدا ببینید مشکل اصلی واقعاً تایپ است یا کیفیت نتیجه و فیلتر. اضافه کردن صوت به موتور جست‌وجوی ضعیف، لزوماً پیدا کردن کتاب را بهتر نمی‌کند. هدف باید به وظیفه مشخص وصل باشد.
موقعیت استفاده مهم است. کاربر در فضای عمومی شاید نخواهد عنوان یا پرسش شخصی را بلند بگوید. فرد دارای محدودیت گفتار نیز ممکن است مسیر دیگری لازم داشته باشد. قابلیت صوتی می‌تواند برای بعضی کاربران مفید و برای دیگری نامناسب باشد. تعریف مسئله و مشاهده استفاده در این تصمیم مرتبط است. به جای فرض اینکه همه تجربه صوتی می‌خواهند، نیاز و محدودیت گروه هدف را بررسی کنید.
Speech Recognition با خواندن متن فرق دارد
MDN درباره Web Speech API دو بخش SpeechRecognition و SpeechSynthesis را از هم جدا می‌کند. اولی برای تشخیص گفتار و دومی برای تبدیل متن به صداست. پشتیبانی یکی، پشتیبانی کامل دیگری را ثابت نمی‌کند. در طراحی سایت نیز دریافت پرسش صوتی با پاسخ صوتی یک قابلیت یکسان نیست. ممکن است فقط ورود صدا لازم باشد و نتیجه به شکل متن و پیوند نمایش داده شود.
مستندات SpeechRecognition محدود بودن دسترسی مرورگری و احتمال پردازش مبتنی بر سرویس در بعضی پیاده‌سازی‌ها را بیان می‌کند. قابلیت را برای مرورگر، زبان و دستگاه هدف بررسی کنید. وجود نام API به معنای دسترسی یکسان یا کارکرد آفلاین همگانی نیست. اگر مسیر محلی یا خدمت ثالث انتخاب می‌شود، محدودیت و مسئولیت داده آن باید جدا روشن شود و به کاربر وعده نادرست داده نشود.
درخواست دسترسی باید در زمینه روشن باشد
کاربر پس از انتخاب آگاهانه دکمه صوتی باید بفهمد چرا میکروفون لازم است. درخواست بی‌مقدمه هنگام ورود به صفحه می‌تواند نامرتبط و نگران‌کننده باشد. پیش از شروع، توضیح کوتاه درباره دریافت صدا و روش توقف بدهید. مجوز مرورگر جای توضیح محصول را نمی‌گیرد. اگر کاربر اجازه نداد، مسیر متن باید همچنان کار کند و پیام خطا او را سرزنش نکند. رد مجوز یک انتخاب معتبر است، نه خطایی که با اصرار تکراری باید تغییر کند.
برای داده صوتی، مشخص کنید پردازش کجا انجام می‌شود و چه چیزی نگهداری می‌شود. سیاست واقعی خدمت باید با متن رابط سازگار باشد. عبارت «فقط روی دستگاه» را بدون اطمینان از مسیر اجرا ننویسید. اگر صدا به ارائه‌دهنده دیگری می‌رود، مسئولیت و محدودیت را بررسی کنید. این مقاله حکم حقوقی عمومی نمی‌دهد؛ کشور، نوع داده و استفاده می‌توانند الزام‌های متفاوتی داشته باشند. طراحی باید پرسش‌های حریم خصوصی را پیش از انتشار روشن کند.
وضعیت دریافت و توقف را قابل فهم کنید
حالت آماده، در حال شنیدن، در حال پردازش و پایان باید از هم جدا باشند. فقط موج متحرک یا رنگ کافی نیست؛ متن وضعیت و نام کنترل لازم است. دکمه توقف باید در دسترس بماند و کاربر نباید برای قطع دریافت دنبال گزینه مخفی بگردد. اگر زمان دریافت محدود است، آن را با رفتار روشن نشان دهید. پایان خودکار نباید کاربر را نامطمئن بگذارد که آیا هنوز صدا دریافت می‌شود یا نه.
برای صفحه‌خوان و صفحه‌کلید، کنترل‌ها باید نام و وضعیت مناسب داشته باشند. صدا تنها راه اعلام نتیجه نباشد. راهنمای اعلان فرم W3C WAI درباره پیام موفقیت و خطای روشن مفید است. در کاربرد صوتی، پیام‌ها باید به اقدام بعدی وصل شوند؛ مثلاً بگویند متن تشخیص داده نشد و می‌توان دوباره تلاش یا تایپ کرد. وضعیت مبهم، کاربر را به تکرار ناخواسته می‌کشاند.
متن تشخیص‌داده‌شده را قابل اصلاح نگه دارید
در مثال کتاب، نام نویسنده ممکن است اشتباه شنیده شود. متن را پیش از اجرای جست‌وجو یا در کنار نتیجه نشان دهید و اجازه اصلاح بدهید. اگر ارسال خودکار انتخاب شده، رفتار آن باید روشن و قابل برگشت باشد. برای پرسش حساس یا اقدام دارای پیامد، تأیید جدا می‌تواند لازم شود. جست‌وجو با ثبت سفارش یا حذف داده یک ریسک یکسان ندارد؛ نباید همان الگوی تأیید را برای همه کارها فرض کرد.
در فارسی، عدد، نیم‌فاصله، واژه خارجی و شکل نوشتاری نام‌ها می‌توانند نتیجه را تغییر دهند. موتور جست‌وجو باید تا حد نیاز، شکل‌های مرتبط را مدیریت کند، اما متن اصلی کاربر را بی‌دلیل عوض نکنید. نوشتار فارسی در رابط و تجربه فرم مرتبط‌اند. دقت تشخیص را با نمونه واقعی زبان و محیط هدف بررسی کنید، نه فقط یک جمله کوتاه در فضای آرام.
خطا و نبود نتیجه را به مسیر جایگزین وصل کنید
مجوز ردشده، نبود میکروفون، قطع ارتباط و نامفهوم بودن صدا وضعیت‌های متفاوت‌اند. پیام باید تا حد اطلاعات موجود علت را روشن کند. همه آن‌ها را با «مشکلی رخ داد» نشان ندهید. اگر پردازش به شبکه وابسته است، قطع ارتباط نباید مانند سکوت کاربر تفسیر شود. مسیر تایپ و تلاش دوباره را حفظ کنید و از شروع خودکار پی‌درپی دریافت صدا جلوگیری کنید.
اگر نتیجه پیدا نشد، عبارت جست‌وجو و گزینه اصلاح را نشان دهید. پیشنهاد مرتبط می‌تواند کمک کند، اما نباید نتیجه نامربوط را با اطمینان به کاربر تحمیل کند. طراحی وضعیت خالی برای این مرحله مفید است. کیفیت تجربه از زنجیره دریافت، اصلاح و پیدا کردن نتیجه می‌آید؛ دقت تبدیل صدا فقط یکی از بخش‌هاست و به‌تنهایی موفقیت کاربر را نشان نمی‌دهد.
محدوده قابلیت را صادقانه معرفی کنید
اگر سرویس فقط بعضی زبان‌ها یا مرورگرها را پوشش می‌دهد، همان را در راهنما توضیح دهید و در محیط ناسازگار مسیر دیگری نشان دهید. پنهان کردن دکمه بدون توضیح ممکن است کاربر را درباره تفاوت دستگاه‌ها سردرگم کند. نسخه آزمایشی را با وعده دسترسی عمومی یکسان معرفی نکنید. راهنمای پشتیبانی باید بداند کدام محدودیت شناخته‌شده است و چه اطلاعات غیرحساسی برای بررسی مشکل لازم دارد.
سئو را با وعده نتیجه صوتی جایگزین نکنید
محتوای روشن، عنوان درست و اطلاعات واقعی به فهم صفحه کمک می‌کنند، اما نشانه‌گذاری خاص را ضمانت انتخاب در دستیار ندانید. طبق به‌روزرسانی رسمی Google Search، نمایش FAQ rich result از ۷ مه ۲۰۲۶ پایان یافته و مستندات آن در ژوئن حذف شده است. بنابراین توصیه قدیمی درباره افزودن FAQ برای گرفتن این نمایش، مبنای فعلی مناسبی نیست. پرسش‌وپاسخ را اگر به نیاز مخاطب کمک می‌کند نگه دارید.
برای سنجش قابلیت داخلی، موفقیت جست‌وجو، اصلاح متن، خطای دریافت و انتخاب مسیر جایگزین را بررسی کنید. داده لازم را با حفظ حریم خصوصی جمع کنید. تعریف KPI مرتبط است. قابلیت را به گروه و محیطی محدود شروع کنید که نیاز مشخص دارد و سپس با شواهد تصمیم بگیرید. اضافه شدن میکروفون باید انجام کار را آسان‌تر کند و نه اینکه مسیر اصلی جست‌وجو را به فناوری نامطمئن وابسته سازد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!