گذاشتن آیکون میکروفون کنار جستوجو، یک رابط صوتی خوب نمیسازد. اگر کاربر مجبور شود نام محصول فارسی را سه بار تکرار کند، نداند صدایش کجا پردازش میشود یا برای اصلاح یک عدد دوباره از ابتدا حرف بزند، صدا بهجای کاهش اصطکاک، یک مانع تازه است. VUI زمانی ارزش دارد که برای یک کار مشخص، در یک محیط مشخص، سریعتر یا دسترسپذیرتر از لمس و تایپ باشد.
این راهنما طراحی رابط کاربری صوتی یا Voice User Interface را برای وب فارسی از انتخاب Use case تا Prototype، معماری ASR/NLU/TTS، حریم خصوصی، دسترسیپذیری و Pilot توضیح میدهد. رابط صوتی داخل وب، دستیار سیستمعامل و سئوی جستوجوی صوتی را از هم جدا میکنیم تا تصمیم فنی و بازاریابی با هم مخلوط نشوند. وضعیت APIها و منابع در ۱۵ مرداد ۱۴۰۵ / ۶ اوت ۲۰۲۶ بازبینی شده است؛ پشتیبانی Browser، زبان و Provider را پیش از Production روی Deviceهای هدف دوباره آزمایش کنید.
پاسخ کوتاه: آیا وبسایت شما به VUI نیاز دارد؟
اگر یک کار پرتکرار و کوتاه مانند جستوجوی محصول، ثبت یادداشت، فیلترکردن یا پیگیری سفارش دارید و کاربر در موبایل، حین حرکت یا با محدودیت حرکتی از تایپ دشوار استفاده میکند، Voice input ارزش Pilot دارد. اگر کار شامل مقایسهٔ متراکم، ورود رمز، تصمیم مالی، محیط عمومی یا دادهٔ حساس است، GUI/Text باید مسیر اصلی یا دستکم جایگزین کامل بماند.
| شرایط | نامزد مناسب | نامزد ضعیف | شاهد لازم |
|---|---|---|---|
| دستها مشغول یا تایپ موبایل دشوار | Dictation و جستوجوی کوتاه | فرم چندمرحلهای حساس | Task time و Error کمتر از Text |
| واژگان محدود و دامنه مشخص | فرمان کنترلشده | گفتوگوی «هرچه خواستی بپرس» | Intent/Slot accuracy و Recovery |
| محتوای بصری روی صفحه | Multimodal: صدا + گزینهٔ قابللمس | Voice-only برای جدول و مقایسه | Task completion و Recall |
| محیط شلوغ یا خصوصی | Text/Keyboard fallback | اجبار به گفتن آدرس یا کد ملی | آزمون Context واقعی |
| عمل پرریسک | Voice برای شروع + تأیید دیداری و Re-auth | خرید/حذف فقط با جملهٔ صوتی | Threat model و Abuse test |
VUI را Feature آیندهنگر ندانید؛ یک فرضیهٔ UX است. آن را با اصول طراحی تجربهٔ کاربری و Journey صورتبندی کنید و اگر Voice در Pilot از مسیر موجود بهتر نشد، حذفش کنید.
چهار Scope متفاوت که معمولاً VUI نامیده میشوند
| Scope | تعریف | نمونه | مالک فنی |
|---|---|---|---|
| Speech input در وب | تبدیل گفتار به متن در یک کنترل | جستوجوی صوتی داخل فروشگاه | Frontend + ASR |
| Voice command | نگاشت جمله به Intent/Action محدود | «سفارشهای باز را نشان بده» | ASR + NLU + Policy + API |
| Conversational assistant | گفتوگوی چندنوبتی با State | پشتیبانی یا راهنمای انتخاب | Dialog manager/LLM + Tools |
| Speech output | تبدیل متن به صدا | خواندن خلاصه یا تأیید | TTS + Content design |
| Voice search بیرون سایت | پرسوجو در موتور/دستیار شخص ثالث | جستوجوی وب با صدا | Search platform؛ نه VUI سایت |
| IVR/تماس تلفنی | تعامل صوتی روی شبکه تلفن | مرکز تماس خودکار | Telephony stack |
ممکن است سایت فقط Dictation لازم داشته باشد، نه دستیار مکالمهای. افزودن LLM به جستوجوی دهدستهای هزینه، تأخیر و سطح حمله را بیدلیل بالا میبرد. در مقابل، پشتیبانی چندمرحلهای بدون مدیریت State و Handoff انسانی با یک میکروفون حل نمیشود.
Snapshot پلتفرم در ۲۰۲۶
Web Speech API
Web Speech API دو بخش اصلی Speech Recognition و Speech Synthesis دارد، اما میزان پشتیبانی، Prefix، زبان، پردازش محلی/راهدور و رفتار Permission در Browserها یکسان نیست. مستند Web Speech API در MDN را با جدول Compatibility همان تاریخ بررسی کنید؛ Feature detection و Fallback ضروری است.
ویژگی SpeechRecognition.processLocally برای الزام پردازش روی Device معرفی شده، اما در مستند جاری MDN Experimental است و ممکن است به Language pack نصبشده نیاز داشته باشد. نبود آن را به معنی «صدا حتماً محلی است» یا وجود آن را به معنی «فارسی حتماً پشتیبانی میشود» تفسیر نکنید.
Microphone capture و Permission
برای گرفتن جریان خام میکروفون، getUserMedia() در Secure Context و با اجازهٔ کاربر کار میکند. مشخصات Media Capture and Streams در W3C گرفتن رضایت صریح، امکان قطع Track و نمایش دسترسی/ضبط را در مدل Browser لحاظ میکند. از کاربر در Load صفحه اجازه نخواهید؛ ابتدا ارزش و مقصد پردازش را توضیح دهید، سپس با اقدام روشن مانند «برای گفتن عبارت نگه دارید» درخواست کنید.
پلتفرم دستیار با API وب یکی نیست
معماری را به قابلیت قدیمی یک Vendor گره نزنید. برای نمونه، Google Conversational Actions در ۱۳ ژوئن ۲۰۲۳ تعطیل شد، هرچند مسیرهای دیگری مانند App Actions و Smart Home جدا بودند. هر Skill/Action را با وضعیت انتشار، زبان، منطقه، Store policy، Export و برنامهٔ خروج همان روز ارزیابی کنید.
Use case خوب و بد برای صدای وب
| Use case | چرا ممکن است مناسب باشد؟ | ریسک | Fallback |
|---|---|---|---|
| جستوجوی محصول/مقاله | عبارت طولانی و تایپ موبایل | نام خاص، برند لاتین و نویز | نمایش Transcript و ویرایش Text |
| پرکردن یادداشت آزاد | سرعت Dictation | نقطهگذاری و دادهٔ حساس | Text area قابلویرایش |
| فیلتر محدود | «رنگ مشکی زیر دو میلیون» | واحد، Range و ابهام | Chipهای دیداری تأییدشده |
| پیگیری سفارش | Intent روشن | افشای وضعیت در محیط عمومی | نمایش امن پس از Login |
| راهنمای Step-by-step | دستهای مشغول | قطع/Repeat و بار حافظه | متن، تصویر و کنترل Pause |
| خرید یا انتقال حساس | شروع سریع | Spoof، اشتباه مبلغ و Repudiation | Review دیداری + Re-auth + Confirm |
| مقایسهٔ چند محصول | پرسش مقدماتی | اطلاعات متراکم شنیداری | جدول/کارت قابلاسکن |
قانون ساده: اگر کاربر برای ارزیابی پاسخ باید چند مقدار را همزمان به خاطر بسپارد، Screen را شریک صدا کنید. Voice output طولانی، متن را دسترسپذیرتر نمیکند؛ بار حافظهٔ شنیداری میتواند نتیجه را بدتر کند.
Voice UX brief پیش از طراحی
- کاربر: زبان، لهجه، سن، توانایی، Device و سواد دیجیتال.
- Context: خانه، خیابان، خودرو، محل کار، نویز و حضور دیگران.
- Job: کاری که Voice باید سریعتر/ممکنتر کند.
- Risk: پیامد تشخیص اشتباه، افشای صدا یا اجرای ناخواسته.
- Corpus: عبارتهای واقعی، نه فقط جملههای طراح.
- Fallback: Text، Touch، Keyboard، Human handoff یا Cancel.
- Outcome: Task success، Error، Time، رضایت یا دسترسی.
- Stop rule: چه نتیجهای Pilot را متوقف میکند؟
عبارتهای نمونه را با مصاحبه و Log جستوجوی داخلی جمع کنید. صدای کاربر را بدون Consent و Purpose روشن به Dataset تبدیل نکنید.
معماری مرجع رابط صوتی
یک مسیر متداول:
User action → Microphone/Audio → VAD/Endpointing → ASR → Normalization → Intent/Entity یا LLM → Policy/Authorization → Tool/API → Response composer → Screen + TTS
| لایه | وظیفه | شکست مهم | Telemetry |
|---|---|---|---|
| Capture | گرفتن صدا با رضایت | Permission denied، Mic unavailable | permission_result بدون Fingerprint اضافی |
| VAD/Endpointing | تشخیص آغاز/پایان گفتار | قطع زودهنگام یا انتظار طولانی | speech_duration، endpoint_latency |
| ASR | صدا به Transcript | نام خاص/لهجه/نویز | confidence، WER/CER در Test set |
| Normalization | عدد، تاریخ، فاصله و واحد | «دو تومن» در برابر «دو میلیون» | normalized fields + reason |
| NLU/LLM | Intent و Entity یا پاسخ | ابهام، Hallucination، Prompt injection | intent، slots، confidence، model version |
| Policy | محدودکردن Action و نیاز به تأیید | اجرای فرمان خارج Scope | decision، rule، actor |
| Tool/API | خواندن/نوشتن در سیستم | Timeout، Retry و Duplicate action | tool، idempotency، result class |
| Response | پاسخ کوتاه دیداری/شنیداری | افشای حساس یا خروجی طولانی | response type، TTS latency |
در Use case محدود، Grammar/Intent طبقهبندیشده اغلب قابلکنترلتر از LLM آزاد است. LLM را فقط وقتی اضافه کنید که Variation زبان ارزشش را داشته باشد و Policy مستقل اجازهٔ Action بدهد.
پردازش محلی، Server یا Hybrid؟
| گزینه | مزیت | هزینه/ریسک | مناسب برای |
|---|---|---|---|
| Browser/OS API | راهاندازی سریع | Support و محل پردازش متغیر | Prototype با Fallback |
| On-device model | کاهش ارسال Audio و امکان Offline | Model size، RAM، Battery و زبان | واژگان محدود/Device مشخص |
| Server/Cloud streaming | Model قویتر و مدیریت متمرکز | Latency، هزینه، Residency و انتقال داده | محصول با Consent و DPA |
| Hybrid | فرمان ساده محلی، سؤال پیچیده Remote | پیچیدگی Routing و UX | Risk tierهای متفاوت |
برای کاربران ایران، فقط میانگین سرعت دفتر تهران را نسنجید. Mobile data، Packet loss، VPN، ISP، Device ضعیف و زمان دانلود Language/model pack را در Test matrix بگذارید. Local همیشه سریعتر نیست؛ Model بزرگ و Warm-up میتواند تجربه را کند کند.
طراحی و ارزیابی ASR فارسی
یک Demo با فارسی رسمی نمایندهٔ بازار نیست. Corpus باید تنوع واقعی داشته باشد:
- فارسی رسمی و محاورهای: «میخواهم»، «میخوام»، «میخام» در Transcript؛
- لهجه و گویش، بدون برچسبزدن تحقیرآمیز به کاربر؛
- Code-switch: برند و مدل لاتین در جملهٔ فارسی؛
- اعداد: رقم فارسی/لاتین، «یک و نیم»، «دو تومن»، کد سفارش و تلفن؛
- تاریخ شمسی، ساعت و بازه؛
- آدرسهای ایران، نام خیابان/شهر و نام خانوادگی؛
- نیمفاصله، ی/ک فارسی و عربی و علائم؛
- صدای آرام، سریع، مکث، لکنت و گفتار نامعمول؛
- نویز خیابان، تلویزیون، خودرو، Echo و میکروفون ارزان.
Normalization بدون تغییر معنا
دو خروجی نگه دارید: Transcript خام برای Debug محدود و امن، و مقدار Normalized برای Business logic. تبدیل عدد/واحد باید Explainable باشد. اگر «دو تومن» ممکن است دو تومان یا دو میلیون تومان باشد، حدس نزنید؛ سؤال Clarification بسازید. برای Search، Variantها را به Index نگاشت کنید؛ برای تراکنش، مقدار را دیداری نمایش و تأیید کنید.
WER کافی نیست
WER = (Substitution + Deletion + Insertion) / تعداد واژههای مرجع
در فارسی، فاصله و نیمفاصله WER را حساس میکند؛ CER و نسخهٔ Normalized نیز گزارش شوند. اما Product metric مهمتر Task success است. شاید ASR یک واژه را غلط بنویسد ولی Intent و محصول درست انتخاب شوند؛ یا متن ظاهراً درست باشد اما عدد مالی اشتباه Normalized شود.
مدل مکالمه: Intent، Entity، State و Repair
برای هر قابلیت یک Contract بنویسید:
| فیلد | نمونهٔ جستوجوی فروشگاه |
|---|---|
| Intent | search_product |
| نمونه عبارت | «کفش پیادهروی مشکی زیر سه میلیون» |
| Entity/Slot | category=کفش، use=پیادهروی، color=مشکی، max_price=۳٬۰۰۰٬۰۰۰ تومان |
| Required slot | حداقل category یا query |
| Ambiguity | سه میلیون ریال یا تومان؟ |
| Confirmation | Chip دیداری «تا ۳ میلیون تومان» |
| Action | فقط Search read-only |
| Fallback | Transcript قابلویرایش و Search معمولی |
پنج نوع شکست و پاسخ مناسب
- No input: «صدایی نرسید؛ دوباره بگویید یا تایپ کنید.»
- No match: بهجای «نفهمیدم»، Scope را بگویید: «نام محصول یا دسته را بگویید.»
- Ambiguous: دو گزینهٔ کوتاه نشان دهید؛ سؤال باز و طولانی نپرسید.
- Partial match: Slotهای مطمئن را حفظ و فقط مورد نامطمئن را سؤال کنید.
- System failure: مسئولیت را به کاربر ندهید؛ Text fallback و Retry امن بدهید.
پس از دو Repair ناموفق، Mode را عوض کنید یا Handoff بدهید. تکرار همان Prompt با صدای بلندتر طراحی مکالمه نیست.
Multimodal؛ صدا باید روی صفحه قابلدیدن باشد
- هنگام Listening، وضعیت واضح، کنترل Stop و زمان محدود نشان دهید.
- Transcript را زنده اما با امکان اصلاح نمایش دهید.
- Entityهای استخراجشده را به Chip یا فیلد قابلویرایش تبدیل کنید.
- نتیجهٔ طولانی را بهجای خواندن کامل، خلاصه و روی Screen نمایش دهید.
- فرمان حساس را با Summary دیداری، مبلغ/مقصد و دکمهٔ تأیید تکمیل کنید.
- Focus، Screen reader announcement و Keyboard order را حفظ کنید.
- کاربر بتواند بیهزینه از Voice به Text و برعکس برود.
Persona صوتی قرار نیست انسان را تقلید کند. کوتاهی، وضوح، Consistency و اعلام محدودیت مهمتر از شوخی یا لحن نمایشی است. صدا را با برند هماهنگ کنید، اما هرگز وانمود نکنید انسان یا متخصص واقعی پاسخ میدهد.
VUI خودکار دسترسپذیر نیست
Voice input میتواند برای بعضی کاربران دارای محدودیت حرکتی، تایپ یا بینایی مفید باشد؛ در عین حال برای فرد ناشنوا، کمشنوا، دارای اختلال گفتار، کاربر غیرکلامی یا محیطی که صحبتکردن ممکن نیست، مانع است. راهنمای W3C دربارهٔ موانع گفتار بر روش جایگزین مانند Text تأکید میکند.
چکلیست دسترسی
- تمام کارها با Keyboard/Touch/Text نیز کامل شوند.
- دکمهٔ میکروفون Name، Role، State و Label دیداری درست داشته باشد.
- Listening/Processing/Error به Screen reader اعلام شود، بدون تکرار آزاردهنده.
- Transcript و پاسخ صوتی، معادل Text داشته باشند.
- Auto-play صدا رخ ندهد؛ Pause، Stop و Volume در اختیار کاربر باشد.
- Timeout برای گفتار آهسته قابلتنظیم یا قابلتمدید باشد.
- رنگ تنها Signal ضبط یا خطا نباشد.
- با Speech input خود سیستمعامل و Screen reader تعارض ایجاد نشود.
WCAG 2.2 معیار پایهٔ وب است؛ داشتن Voice قابلیتهای Keyboard، Focus، Label، Error identification و Accessible authentication را حذف نمیکند. VUI را با کاربران دارای نیازهای متفاوت تست کنید، نه فقط تیم سازنده.
حریم خصوصی: میکروفون، Audio و Transcript
پیش از توسعه، Data map بسازید:
| داده | آیا لازم است؟ | Retention نمونه | کنترل |
|---|---|---|---|
| Raw audio | اغلب برای عملیات روزمره لازم نیست | پیشفرض صفر؛ Dataset فقط با Consent جدا | Encryption، محدودیت دسترسی، حذف |
| Transcript | برای نتیجه/Debug کمینه | کوتاه و Purpose-bound | Redaction و دسترسی نقشمحور |
| Intent/Entity | برای Task و Analytics | بر اساس نیاز محصول | Pseudonymization و Minimize |
| Account/Order | فقط پس از Login و ضرورت | طبق رکورد عملیاتی | Authorization و Audit |
| Failure sample | برای بهبود مدل با نمونه محدود | Window مشخص | Opt-in، Review و حذف PII |
در UI بگویید چه چیزی ضبط میشود، کجا/توسط چه Providerی پردازش میشود، آیا برای آموزش مدل استفاده میشود و چگونه حذف میشود. Consent عملیات Voice را با رضایت اختیاری آموزش مدل یکی نکنید. مسیر Privacy را با بودجه و برنامهٔ عملی حریم خصوصی داده هماهنگ کنید.
امنیت Voice و فرمانهای حساس
صدا یک Secret قابلاتکا نیست. فایل ضبطشده، پخش از بلندگو، Deepfake، صدای فرد دیگر، Transcript آلوده و Prompt injection میتوانند سیستم را فریب دهند. حتی تشخیص Speaker، احراز هویت قطعی یا Consent تراکنش نیست.
- Voice را برای Action حساس تنها عامل تأیید نکنید.
- خواندن اطلاعات حساس را در محیط عمومی کمینه کنید.
- برای خرید، حذف، تغییر حساب یا افشای داده Re-auth و تأیید دیداری لازم کنید.
- Toolهای LLM را Allowlist و Scope کنید؛ Model اجازهٔ مستقیم همهٔ APIها نداشته باشد.
- Argumentها را Server-side اعتبارسنجی و Action نوشتنی را Idempotent کنید.
- Prompt، Content بازیابیشده و صدای کاربر را دادهٔ غیرقابلاعتماد بدانید.
- Log امنِ Actor، Intent، Policy decision، Tool و نتیجه داشته باشید.
- Kill switch و Feature flag برای Incident فراهم کنید.
اگر VUI به حساب، سفارش یا CRM متصل است، مرز Authorization و Tool API را با راهنمای امنیت API و کنترل دسترسی طراحی کنید.
LLM در رابط صوتی؛ فهم زبان با مجوز عمل فرق دارد
LLM میتواند عبارتهای متنوع را بهتر Parse یا پاسخ را طبیعیتر کند، اما Confidence زبانی، مجوز اجرای Action نیست. معماری امن سه خروجی جدا دارد:
- Interpretation: Intent، Entity و ابهام با Schema محدود.
- Policy: Rule مستقل تصمیم میگیرد Read، Clarify، Confirm، Re-auth یا Deny.
- Execution: Tool محدود با Validation، Idempotency و Audit اجرا میشود.
پاسخ آزاد مدل برای موجودی، قیمت، وضعیت سفارش یا سیاست مرجوعی Source of truth نیست؛ Tool/API معتبر داده را میدهد و Response composer آن را خلاصه میکند. اگر داده موجود نیست، «نمیدانم/اجازه ندارم» بهتر از پاسخ محتمل است.
Latency و عملکرد ادراکشده
Latency Voice جمع چند مرحله است:
Permission + Capture start + Endpointing + Upload/ASR + NLU/LLM + Tool + Response + TTS start
فقط زمان API را گزارش نکنید. زمان از Tap تا اولین Feedback، تا Transcript، تا نتیجهٔ دیداری و تا شروع TTS را در p50/p95 بسنجید. Streaming میتواند Transcript و پاسخ را زودتر نشان دهد، اما Partial result نباید Action حساس را اجرا کند.
- Feedback Listening در کمتر از حس «دکمه کار نکرد» ظاهر شود.
- Endpointing را برای مکث طبیعی فارسی تنظیم و تست کنید.
- Model/Language pack بزرگ را بیخبر روی Mobile data دانلود نکنید.
- Timeout و Retry با Text fallback داشته باشید.
- بار JS، Audio library و Widget را در Performance budget قرار دهید.
اثر Script و Model روی LCP/INP را با راهنمای Core Web Vitals و RUM پایش کنید.
Metricهای VUI از ASR تا Outcome
| لایه | Metric | برش ضروری |
|---|---|---|
| دسترسی | Permission accept/deny، Feature available | Browser/OS/Device بدون Fingerprinting اضافی |
| ASR | WER، CER، Named entity/number error | لهجه، نویز، جنس صدا فقط با طرح اخلاقی، Device |
| NLU | Intent accuracy، Slot precision/recall/F1 | Intent و Risk tier |
| Dialog | No-input، No-match، Clarification، Turn count | Use case و Step |
| UX | Task success، Time، Correction، Mode switch | Voice/Text و Context |
| عملکرد | Latency p50/p95 هر مرحله | ISP، شبکه، Device |
| Outcome | Search success، Ticket deflection سالم، Conversion | Control مشابه |
| Guardrail | Wrong action، privacy complaint، unsafe disclosure | Severity و Root cause |
هر Error class Owner داشته باشد. Average accuracy میتواند شکست یک لهجه یا Device را پنهان کند. Dataset ارزیابی را از Training جدا و نسخهدار نگه دارید. برای Event taxonomy و تحلیل Funnel از راهنمای UX دادهآگاه استفاده کنید.
Prototype پیش از ASR واقعی
با Wizard-of-Oz آغاز کنید: کاربر صحبت میکند، پژوهشگر پشت صحنه پاسخ سیستم را طبق Script انتخاب میکند. این روش بدون ساخت مدل نشان میدهد Use case، Prompt و Repair اصولاً قابلفهم هستند یا نه.
- Top task و Context را انتخاب کنید.
- Happy path، No-match، Ambiguity، Timeout و Cancel را بنویسید.
- ۱۰ تا ۲۰ عبارت واقعی برای هر Intent جمع کنید؛ این عدد Benchmark مدل نیست، شروع طراحی است.
- پاسخ صوتی کوتاه و معادل دیداری بسازید.
- Prototype را با صدای پژوهشگر یا TTS، Screen و دکمهٔ واقعی تست کنید.
- رفتار را مشاهده کنید: کاربر چه میگوید، کجا مکث و چگونه اصلاح میکند؟
- سپس Provider/API را روی Corpus واقعی Benchmark کنید.
پروتکل جذب، سناریو، رضایت ضبط و تحلیل Severity را با راهنمای تست کاربردپذیری تنظیم کنید.
Scorecard انتخاب ASR/TTS یا پلتفرم
| معیار | وزن نمونه | شاهد |
|---|---|---|
| دقت فارسی در Corpus شما | ۲۰٪ | Benchmark blind با WER/CER و Task success |
| Latency و Streaming | ۱۵٪ | p50/p95 روی شبکهٔ ایران |
| Privacy/Residency/Training | ۱۵٪ | DPA، Retention، Subprocessor و Opt-out |
| Browser/Device coverage | ۱۰٪ | ماتریس واقعی، نه لیست Marketing |
| Customization | ۱۰٪ | Vocabulary، Hint، normalization و Export |
| Security | ۱۰٪ | Auth، Isolation، Encryption، Audit و Incident |
| عملیات | ۱۰٪ | SLA، Status، Quota، Support و Rollback |
| TCO و Exit | ۱۰٪ | Audio minute، Egress، Model، Migration و Data export |
Demo انگلیسی یا فارسی استودیویی را امتیاز ندهید. Corpus Blind با عبارتهای نام خاص، عدد، نویز و لهجهٔ بازار شما معیار است. Gate رد: استفادهٔ مبهم از Audio برای Training، نبود حذف، شکست Action حساس یا نداشتن Text fallback.
ماتریس تست Production
| بعد | سناریوها | انتظار |
|---|---|---|
| Browser/OS | Android/iOS/Windows/macOS و Browserهای هدف | Feature detection و Fallback |
| Permission | Allow، Deny، Block دائم، Revocation | بدون بنبست و درخواست تکراری آزاردهنده |
| Audio | Mic ضعیف، Bluetooth، قطع Track، تماس ورودی | State درست و Recovery |
| شبکه | Slow، Loss، Offline، VPN، تغییر Network | Timeout، Cancel و Text مسیر امن |
| فارسی | لهجه، Code-switch، عدد، تاریخ، آدرس، نام برند | Metric برشخورده و Clarification |
| Accessibility | Keyboard، Screen reader، Speech disability | Task کامل بدون Voice |
| Privacy | Indicator، Stop، Delete، Retention | رفتار مطابق Notice/Consent |
| Security | Replay، صدای پسزمینه، Prompt injection، Tool abuse | Deny/Confirm/Re-auth و Audit |
| Action | Duplicate utterance، Retry، Timeout API | Idempotency و نتیجهٔ واحد |
| Performance | Cold/Warm model، Long utterance، concurrent users | Budget p95 و Graceful degradation |
VUI و سئوی جستوجوی صوتی؛ ادعاها را جدا کنیم
اضافهکردن میکروفون به جستوجوی داخلی، سیگنال رتبهبندی مستقیم اثباتشدهای برای گوگل نیست. موتور جستوجو Query صوتی را بهعنوان درخواست کاربر پردازش میکند؛ سایت همچنان باید پاسخ مفید، Crawlable، سریع و قابلاعتماد ارائه کند. محتوای محاورهای فقط وقتی مفید است که نیت واقعی را بهتر پاسخ دهد، نه چون تعداد سؤال یا Long-tail را زیاد میکند.
- سؤال واقعی کاربر را با پاسخ کوتاه و سپس جزئیات عمیق پوشش دهید.
- عنوان، H1، URL، لینک داخلی و Structured data مرتبط را صحیح نگه دارید.
- FAQ برای کاربر مفید است، اما نمایش Rich result برای همهٔ سایتها تضمین نیست.
speakableرا نسخهٔ عمومی «سئوی صوتی فارسی» ندانید؛ مستند جاری Google برای Speakable آن را Beta و برای محتوای خبری انگلیسی در آمریکا روی دستگاههای مشخص توصیف میکند.- Voice query را در Search Console بهطور عمومی به Segment قابلاعتماد و مستقل تبدیل نمیکنید؛ از ادعای سهم دقیق بدون داده بپرهیزید.
برای بهینهسازی خود صفحه، چکلیست سئوی داخلی را اجرا کنید. هدف، پاسخ بهتر است؛ نه تولید انبوه FAQ برای شکار جستوجوی صوتی.
Pilot ششهفتهای VUI فارسی
- هفتهٔ ۱: Voice UX brief، Top task، Context، Risk و Baseline مسیر Text.
- هفتهٔ ۲: Corpus، Intent/Slot، State، Repair، Data map و Threat model.
- هفتهٔ ۳: Wizard-of-Oz و تست کاربردپذیری با گروه متنوع.
- هفتهٔ ۴: Benchmark دو گزینهٔ ASR/TTS روی Corpus Blind و شبکه/Device ایران.
- هفتهٔ ۵: Prototype واقعی با Feature flag، Fallback، Telemetry و سقف Action read-only.
- هفتهٔ ۶: آزمایش کنترلشده و تصمیم Go/Iterate/Stop بر اساس Task success و Guardrail.
برای Pilot اول، Action نوشتنی حساس انتخاب نکنید. جستوجوی Read-only با Transcript قابلویرایش، Scope کوچک و دادهٔ قابلاندازهگیری دارد. پس از اثبات Fit، پیچیدگی گفتوگو و ابزارها را مرحلهای اضافه کنید.
چکلیست پیش از انتشار رابط صوتی
- Use case و دلیل برتری Voice نسبت به Text مستند است.
- Scope میان Dictation، Command، Assistant، TTS و Voice search روشن است.
- Feature detection، Browser matrix و Text fallback کامل است.
- Corpus فارسی شامل لهجه، Code-switch، عدد، نام و نویز بازار است.
- ASR/NLU با WER/CER/Intent/Slot و Task success ارزیابی شدهاند.
- Listening، Transcript، Stop، Repair و Mode switch واضحاند.
- Keyboard، Screen reader و کاربر دارای اختلال گفتار در تست پوشش داده شدهاند.
- Raw audio، Transcript، Retention، Training و حذف در Data map مشخصاند.
- Action حساس به Voice تنها متکی نیست و Policy/Re-auth مستقل دارد.
- LLM به Toolهای Allowlist با Validation و Audit محدود است.
- Latency p50/p95 و اثر روی Core Web Vitals در شبکهٔ ایران اندازهگیری شده است.
- Feature flag، Kill switch، Incident owner و Stop rule وجود دارد.
سؤالات متداول طراحی رابط کاربری صوتی
رابط کاربری صوتی یا VUI چیست؟
رابطی است که بخشی از تعامل را با گفتار ورودی یا صدای خروجی انجام میدهد. VUI میتواند Dictation ساده، فرمان محدود یا مکالمهٔ چندنوبتی باشد. جستوجوی صوتی در موتور جستوجو و IVR تلفنی Scopeهای جدا هستند و معماری یکسان ندارند.
آیا Speech Recognition در همهٔ مرورگرها کار میکند؟
خیر؛ پشتیبانی، Prefix، زبان، Permission و محلی/راهدور بودن پردازش متفاوت و در حال تغییر است. Web Speech API را Feature-detect کنید، Browser/OSهای واقعی را بسنجید و کنترل Text/Keyboard کامل داشته باشید. قابلیت آزمایشی processLocally نیز تضمین پشتیبانی فارسی نیست.
آیا افزودن صدا سایت را دسترسپذیر میکند؟
برای بعضی کاربران میتواند مانع تایپ یا حرکت را کم کند، اما برای کاربر دارای اختلال گفتار، ناشنوا/کمشنوا یا محیطی که صحبت ممکن نیست مانع میشود. Voice باید یک Mode اختیاری با Text، Keyboard، Transcript، Focus و Error accessible باشد؛ نه تنها راه انجام کار.
آیا جستوجوی صوتی داخل سایت رتبهٔ گوگل را بهتر میکند؟
اثر مستقیم اثباتشدهای ندارد. اگر قابلیت Voice واقعاً تجربه و یافتن محتوا را بهتر کند، ارزش محصولی دارد؛ اما رتبه به کیفیت، ارتباط، Crawlability و سیگنالهای متعدد وابسته است. FAQ یا Speakable نیز رتبه و Rich result را تضمین نمیکنند.
اولین Pilot مناسب برای VUI فارسی چیست؟
یک جستوجوی Read-only و محدود با Push-to-talk، نمایش Transcript و امکان ویرایش. نام محصول، برند لاتین، عدد، لهجه و نویز را روی Corpus واقعی آزمایش کنید. اگر Task success و زمان از Search متنی بهتر نشد یا شکایت حریم خصوصی بالا بود، Scope را اصلاح یا Feature را متوقف کنید.
جمعبندی
VUI آیندهٔ اجتنابناپذیر همهٔ صفحات نیست؛ یک Mode تعاملی برای Task و Context مناسب است. طراحی موفق از Corpus فارسی، مکالمهٔ محدود، Repair روشن، رابط Multimodal، حریم خصوصی و مسیر جایگزین آغاز میشود. Browser API یا LLM را پیش از اثبات مسئله انتخاب نکنید. ابتدا با Wizard-of-Oz نشان دهید Voice کار را بهتر میکند، سپس ASR را روی لهجه و شبکهٔ واقعی Benchmark و فقط Actionهای کمریسک را Pilot کنید.
