طراحی UX برای WebXR؛ AR/VR دسترس‌پذیر، امن و سریع

تجربه XR خوب از لحظه‌ای شروع می‌شود که محصول جرئت می‌کند XR را اجرا نکند. اگر کاربر فقط می‌خواهد ببیند یک مبل در اتاق جا می‌شود، ویدئوی ۳۶۰ درجه، مدل سه‌بعدی Inline یا اندازه‌های دقیق شاید سریع‌تر از درخواست دوربین و ورود اجباری به AR او را به تصمیم برساند. WebXR یک مقصد طراحی نیست؛ یکی از مسیرهای انجام کار است.

در طراحی تجربه کاربری برای AR و VR وب، صفحه به فضا گسترش می‌یابد و ورودی می‌تواند لمس، نگاه، کنترلر، دست، صدا یا حرکت بدن باشد. در عوض، عدم قطعیت ردیابی، محدودیت مرورگر و دستگاه، بیماری حرکت، ایمنی فیزیکی، حریم خصوصی محیط و دسترس‌پذیری وارد قرارداد محصول می‌شوند. این راهنما فرایندی برای انتخاب Use case، طراحی تعامل، Performance، Privacy، Accessibility، تست و Pilot می‌دهد؛ نه فهرستی از جلوه‌های سه‌بعدی.

WebXR چیست و وضعیت آن چه معنایی برای محصول دارد؟

WebXR مجموعه‌ای از APIها برای ارائه تجربه واقعیت مجازی و افزوده روی وب و دسترسی کنترل‌شده به Pose، View، Reference space و ورودی‌های XR است. WebXR Device API در W3C در زمان بازبینی این مقاله Candidate Recommendation Draft است؛ خود سند تصریح می‌کند که کار در حال تکامل است. همچنین MDN WebXR Device API آن را Limited availability و نیازمند Secure context معرفی می‌کند.

نتیجه عملی این دو واقعیت:

• Browser/Device support را در لحظه اجرا Feature-detect کنید، نه با User-Agent و فهرست ثابت.
• قابلیت‌های اختیاری مثل Hit test، Hand input، Depth یا DOM overlay را جدا تشخیص دهید.
• تجربه ۲D/۳D Inline را محصول درجه‌دو نسازید؛ مسیر اصلی کار باید در آن کامل باشد.
• تغییر API، Runtime و Browser را در Regression matrix نگه دارید.

const support = {
  webxr: "xr" in navigator,
  immersiveAR: false,
  immersiveVR: false
};

if (support.webxr) {
  support.immersiveAR = await navigator.xr.isSessionSupported("immersive-ar");
  support.immersiveVR = await navigator.xr.isSessionSupported("immersive-vr");
}

renderBestAvailablePath(support);

این نمونه فقط Capability gate را نشان می‌دهد؛ Error، Permission، Session lifecycle و قابلیت‌های اختیاری باید جدا مدیریت شوند.

AR، VR، Inline 3D و ۳۶۰ درجه را یکی نکنید

«Magic window» روی گوشی الزاماً WebXR immersive نیست. نام فنی را فقط وقتی به کاربر نشان دهید که برای تصمیم یا راهنما مفید است؛ CTA بهتر می‌تواند «دیدن مبل در اتاق من» باشد.

پیش از Prototype، Use case gate بسازید

XR باید عدم قطعیت مشخصی را بهتر از مسیر ساده‌تر کاهش دهد. برای فروشگاه، این عدم قطعیت ممکن است Scale/fit/style-in-context باشد؛ برای آموزش، Spatial sequence یا تمرین کم‌خطر؛ برای ملک، Orientation و رابطه فضاها.

برای فروشگاهی که می‌خواهد AR را با Return و Conversion بسنجد، راهنمای واقعیت افزوده در فروشگاه اینترنتی Business case و Pilot را تکمیل می‌کند.

Journey را پیش، حین و پس از Immersion طراحی کنید

کاربر را با Permission prompt شروع نکنید. ابتدا ارزش و دلیل را در DOM معمولی توضیح دهید، سپس پس از اقدام صریح او Session بخواهید. سند WebXR نیز ایجاد Session immersive را به User activation و رضایت متصل می‌کند.

Progressive enhancement: یک کار، چند مسیر

Capability ladder را از ساده به غنی طراحی کنید:

1. متن، تصویر، ابعاد و ویدئوی دسترس‌پذیر؛
2. مدل سه‌بعدی Inline با Keyboard/Touch/Mouse؛
3. نمای ۳۶۰ یا Device orientation اختیاری؛
4. AR دستی روی دستگاه واجد شرایط؛
5. VR immersive با ورودی و مرز مناسب.

State را میان مسیرها حفظ کنید. اگر کاربر رنگ/مدل را در DOM انتخاب کرده، AR باید همان Variant را باز کند؛ بعد از خروج، Snapshot و انتخاب در صفحه معمولی باقی بماند. این Handoff مانع بن‌بست و تکرار می‌شود.

Spatial UI: عمق فقط محور Z نیست

در XR، UI باید نسبت خود را با بدن، View، محیط و Object روشن کند. هر عنصر را در یکی از این فضاها تعریف کنید:

• World-locked: به مکان/شیء محیط متصل؛ برای Label یا نشانه مکانی؛
• Body/view-relative: همراه کاربر؛ برای وضعیت ضروری یا Safe exit با احتیاط؛
• Object-attached: بخشی از ابزار یا محصول؛ برای Control زمینه‌دار؛
• DOM overlay: UI وب روی تجربه immersive، فقط وقتی Runtime پشتیبانی می‌کند.

پنل دائماً چسبیده به صورت می‌تواند مزاحم و خسته‌کننده باشد؛ پنل دور یا پشت Object ممکن است گم شود. Distance، Angular size، Occlusion، Contrast و Background complexity را روی دستگاه واقعی بسنجید. «در هدست من خواناست» شاهد کافی نیست.

قواعد متن و اطلاعات

• جمله کوتاه، hierarchy روشن و line length محدود؛
• Scale براساس زاویه دید و فاصله، نه pixel ثابت؛
• Contrast در پس‌زمینه روشن/تاریک و Passthrough متغیر؛
• اطلاعات بحرانی با متن/صدا/شکل و نه فقط رنگ؛
• Billboarding فقط وقتی Orientation ثابت‌تر به خوانایی کمک می‌کند؛
• Zoom/size/contrast قابل تنظیم و Reset آسان.

Affordance و Feedback در محیط سه‌بعدی

کاربر باید پیش از عمل بداند چه چیزی Select، Grab، Drag، Rotate یا Place می‌شود. Hover ممکن است روی Touch/Hand وجود نداشته باشد؛ Cursor یا highlight باید ورودی‌های مختلف را پوشش دهد.

ورودی چندگانه؛ Gesture طبیعی همیشه قابل‌استفاده نیست

Gesture «طبیعی» ممکن است برای فرهنگ، توان حرکتی، فضای عمومی، نور یا ردیابی دستگاه نامناسب باشد. یک عمل بحرانی را به Pinch خاص، نگه‌داشتن دست در هوا یا فرمان صوتی تنها وابسته نکنید.

• Controller، Hand، Gaze+confirm، Touch، Keyboard و Switch را براساس Platform پوشش دهید.
• Rebinding، handedness، sensitivity، dwell selection و timeout قابل تنظیم باشند.
• Targetها margin فضایی و امکان اصلاح پیش از Commit داشته باشند.
• Drag مسیر جایگزین داشته باشد؛ WCAG ۲.۲ برای Dragging movement و Target size معیار دارد.
• Voice مکمل باشد و در محیط شلوغ/خصوصی مسیر دیگری وجود داشته باشد.

WCAG 2.2 برای Keyboard، Pointer gesture، Motion actuation، Dragging، Target size، Focus و Animation معیارهای پایه می‌دهد؛ XR نیازهای فراتر از صفحه را نیز اضافه می‌کند.

راحتی و بیماری حرکت: به‌جای نسخه واحد، اختیار بدهید

بیماری حرکت می‌تواند از ناهماهنگی حس دیداری و وستیبولار، Latency، حرکت دوربین، شتاب، Rotation، Scale غلط، Flicker یا افت Frame ناشی شود. حتی Teleport برای بعضی کاربران آزاردهنده است؛ پس یک روش را «Comfortable برای همه» ننامید.

Comfort contract

• حرکت فیزیکی کاربر دوربین را کنترل کند؛ دوربین را بدون درخواست جابه‌جا نکنید.
• گزینه Stationary، Teleport، Snap turn و Smooth با سرعت قابل تنظیم ارائه دهید.
• Vignette/field-of-view reduction اختیاری باشد، نه جای حل Performance.
• Horizon/reference ثابت، Pause فوری، Recenter و Safe exit در دسترس باشد.
• شروع کوتاه، افزایش تدریجی و یادآوری استراحت برای Session طولانی؛
• Flash و Motion شدید را حذف یا Reduced-motion mode بدهید.
• کاربر نشسته، ایستاده و با فضای محدود را جدا تست کنید.

XR Accessibility User Requirements در W3C نیاز به جایگزین برای محرک بیماری حرکت/تشنج، کنترل چندوجهی، Safe harbor، زمان، Orientation، Caption و جایگزین صوت فضایی را مطرح می‌کند. این سند Working Group Note و فهرست نیازهاست، نه Checklist کامل Conformance؛ آن را همراه WCAG و تست با کاربران به‌کار ببرید.

ایمنی فیزیکی را داخل Interface بیاورید

کاربر AR ممکن است به صفحه نگاه کند و مانع، پله، ترافیک یا فرد دیگری را نبیند؛ کاربر VR ممکن است از مرز امن خارج شود. طراحی نباید کاربر را به عقب‌رفتن، چرخش ناگهانی یا رسیدن دور وادار کند مگر محیط برای آن آماده و تأیید شده باشد.

WebAR: Placement باید عدم قطعیت را نشان دهد

Plane detection، Hit test، نور، Scale و Occlusion کامل نیستند. Object مجازی ممکن است شناور، داخل دیوار یا با اندازه غلط دیده شود. به‌جای پنهان‌کردن خطا، Confidence و روش اصلاح را در UX نشان دهید.

1. حرکت موردنیاز برای Scan را کوتاه و بصری آموزش دهید.
2. سطح پیدا‌شده را با Grid/reticle نشان دهید.
3. پیش از Place، Scale و Variant را تأیید کنید.
4. پس از Place، Nudge/Rotate/Reset/Undo و اندازه مرجع بدهید.
5. هشدار دهید نمایش تقریبی است و برای Fit حساس، اندازه واقعی را بررسی کند.
6. Snapshot را با Label مدل/رنگ/ابعاد ذخیره کنید، نه تصویر بی‌زمینه.

در Try-on پوشاک/آرایش یا جای‌گذاری محصول، تفاوت دوربین، نور، بدن و Calibration می‌تواند نتیجه را تغییر دهد. Claim «کاملاً واقعی» یا «اندازه قطعی» ندهید مگر Validation متناسب دارید.

Accessibility: تجربه جایگزین باید نتیجه هم‌ارز بدهد

دسترس‌پذیری XR فقط Caption نیست. حرکت، دید، شنوایی، گفتار، شناخت، تعادل، قد/Reach و توان استفاده از یک یا دو دست فرق می‌کند. نیاز را در Research و Acceptance criteria وارد کنید.

مسیر DOM معمولی باید Semantic، Keyboard-operable و Screen-reader compatible باشد. «تجربه کامل فقط در هدست» را با نتیجه کسب‌وکار توجیه نکنید. فرایند پایه Research/Prototype/Test در راهنمای جامع تجربه کاربری قابل استفاده است، اما Recruitment باید تنوع توان و دستگاه را هم پوشش دهد.

حریم خصوصی و Permission: محیط خانه داده است

Pose، حرکت، دوربین، میکروفون، نقشه محیط، Anchor و الگوی تعامل می‌توانند حساس باشند. برای هر Feature بنویسید چه داده‌ای در Device پردازش، چه چیزی ارسال، ذخیره یا با شخص ثالث به اشتراک گذاشته می‌شود. «برای بهترشدن تجربه» Purpose کافی نیست.

Permission flow قابل اعتماد

1. Preview و ارزش را بدون Permission نشان دهید.
2. در لحظه نیاز، دلیل دوربین/حرکت و استفاده/Retention را Plain language بگویید.
3. درخواست را پس از User action بدهید؛ Deny مسیر ۲D را باز نگه دارد.
4. حین Session نشانه فعال‌بودن و Control توقف واضح باشد.
5. پس از خروج، State و گزینه حذف Snapshot/Anchor را نشان دهید.

راهنمای Permission و Security در MDN به Secure context، User intent و کنترل‌های Permission/Policy اشاره می‌کند. اگر تجربه در iframe است، `Permissions-Policy` و Originهای مجاز را حداقلی تنظیم کنید.

Permissions-Policy: xr-spatial-tracking=(self "https://trusted-xr.example")

data_inventory:
  pose_stream: device-only, session lifetime
  snapshot: user initiated, delete control
  analytics: aggregate events, no raw camera frame
  support_recording: off by default, explicit consent

Camera frame یا نقشه محیط را فقط چون SDK اجازه می‌دهد ذخیره نکنید. Third-party asset/analytics SDK را در Data flow و CSP ثبت و دامنه‌های آن را محدود کنید. راهنمای سیاست امنیتی محتوا برای Rollout امن منابع وب مکمل است.

Performance: نرخ فریم ثابت مهم است، عدد جادویی نه

هدف Render باید با Refresh و Runtime دستگاه هماهنگ باشد. «همیشه بالای ۹۰ FPS» برای همه تلفن‌ها، هدست‌ها و حالت‌ها قاعده عمومی نیست. Missed frame، Frame-time p95/p99، Thermal throttling، CPU/GPU، Memory، Battery، Network و Time-to-first-interaction را روی ماتریس واقعی بسنجید.

• مدل را با LOD و Draco/mesh compression متناسب با Runtime آماده کنید.
• Texture را در ابعاد مصرف و فرمت مناسب Device تحویل دهید.
• نور/سایه Real-time را محدود و Bake را با AR lighting نیازسنجی کنید.
• Object خارج View را Cull و Resource حذف‌شده را Dispose کنید.
• Quality tier را قابل کاهش و از Stutter بهتر کنید؛ تغییر ناگهانی را تست کنید.

Web Performance عمومی و Journey را نیز فراموش نکنید؛ قبل از XR، صفحه ورود باید روی موبایل سریع و قابل‌استفاده باشد. راهنمای سرعت سایت و تجربه کاربر Baseline و Field evidence را پوشش می‌دهد.

Asset pipeline بخشی از UX است

هر مدل باید Source، License، واحد اندازه، محور، Origin/pivot، Material، Variant، Collision، LOD، Alt/description، Performance budget و Owner داشته باشد. خطای سانتی‌متر/متر یا pivot بد مستقیماً Placement را خراب می‌کند.

asset_contract = {
  "sku": "chair-204",
  "source_unit": "centimeter",
  "runtime_unit": "meter",
  "real_dimensions_cm": [78, 82, 91],
  "pivot": "floor-center",
  "variants": ["walnut", "black"],
  "lod": [0, 1, 2],
  "license": "owned-product-scan",
  "accessibility_description": "صندلی چوبی دسته‌دار...",
  "owner": "3d-commerce"
}

Preview رندرشده را با محصول واقعی و اندازه مرجع مقایسه کنید. Update محصول، رنگ، قیمت یا موجودی باید Versioning و Invalidating Snapshot قدیمی داشته باشد.

Navigation و Wayfinding در VR

فضای ۳۶۰ درجه مرز صفحه ندارد؛ کاربر باید Location، مقصد و راه برگشت را بفهمد. Landmark متمایز، مسیر دیداری/صوتی، Map اختیاری، Breadcrumb فضایی، Orientation reset و «بازگشت به نقطه امن» کمک می‌کنند.

• هدف را پشت کاربر بدون Cue رها نکنید.
• Teleport destination را پیش از Commit با جهت نهایی نشان دهید.
• ناحیه غیرقابل دسترس و دلیل آن مشخص باشد.
• پس از Recenter/Tracking reset، Context کاربر حفظ شود.
• Pause و خروج نباید در منوی عمیق پنهان باشد.

خطا و Recovery: Tracking همیشه کامل نیست

تست WebXR: Lab کافی نیست

Prototype را با همان کاربران، فضاها و دستگاه‌های هدف آزمایش کنید. فیلم‌برداری محیط یا بدن فقط با رضایت و Masking انجام شود. Moderator باید نشانه ناراحتی را جدی بگیرد و کاربر بدون توضیح بتواند Session را متوقف کند.

ماتریس آزمون

• حالت: 2D، Inline 3D، AR، VR؛
• دستگاه/مرورگر/نسخه و Capability؛
• ورودی: Touch، Keyboard، Controller، Hand، Gaze/Switch در Scope؛
• توان: دید، شنوایی، حرکت، تعادل، شناخت و seated/standing؛
• محیط: نور، فضای کوچک، سطح بازتابی/بی‌بافت، صدای عمومی؛
• شبکه: cache cold، قطع/وصل و bandwidth پایین؛
• Failure: Deny، tracking loss، low memory، orientation change و resume؛

در مطالعه، Task success، error/recovery، کمک، زمان تا نتیجه، comfort report، decision confidence و Outcome بعدی را ثبت کنید. فقط «جذاب بود؟» Novelty bias را اندازه می‌گیرد. طراحی و اجرای مطالعه در راهنمای تست کاربردپذیری آمده است.

سنجش محصول: زمان Session هدف نیست

Eligible population را از کل Session جدا کنید؛ اگر فقط کاربران قوی‌ترین دستگاه وارد Pilot می‌شوند، نتیجه را به کل بازار تعمیم ندهید. طراحی Measurement و Decision cadence در UX داده‌آگاه تکمیل می‌شود.

Dark pattern در XR خطرناک‌تر است

Immersion، توجه و محیط خصوصی قدرت بیشتری به رابط می‌دهند. Permission مبهم، دکمه خروج پنهان، هدایت نگاه اجباری، Countdown، صدای ناگهانی، Manipulation فضایی و ثبت پیش‌فرض تصویر می‌توانند آسیب‌زا باشند. رضایت باید قابل فهم، هدف‌مند و قابل پس‌گرفتن باشد.

برای ممیزی اختیار، Assent، توقف و پیامد، راهنمای طراحی اخلاقی و دارک‌پترن را روی Journey immersive اعمال کنید.

نسخه اجرایی برای ایران

• سهم Device/browser/OS را از داده واقعی محصول و Feature probe بگیرید؛ حدس بازار کافی نیست.
• روی Android میان‌رده، WebView پیام‌رسان و چند اپراتور/ISP تست کنید.
• Asset اولیه را کوچک، Progressive و قابل Resume بسازید؛ CDN/Origin خارجی را با مسیر واقعی بسنجید.
• فونت فارسی، RTL/Bidi، اعداد، تومان/ریال و Label دوبعدی/فضایی را روی Texture و DOM تست کنید.
• راهنمای حرکتی را با تصویر/متن ساده فارسی و مسیر بدون صدا ارائه دهید.
• ابزار/SDK خارجی را از نظر دسترسی، License، پرداخت، Telemetry، Export و Fallback ارزیابی کنید.
• دوربین محیط خانه/محل کار را داده حساس فرض و Raw frame را حداقل کنید.
• برای پشتیبانی، Screenshot/diagnostic را با رضایت و Redaction بگیرید.

مسیر ورودی باید روی موبایل معمولی هم سالم باشد؛ راهنمای موبایل‌فرندلی و تست تجربه موبایل را پیش از لایه immersive اجرا کنید.

برنامه ۹۰ روزه Pilot

روز ۱ تا ۳۰: Fit و قرارداد

• یک Decision job، Population، Outcome و Guardrail انتخاب کنید.
• Capability/accessibility/privacy/safety threat model و fallback تعریف کنید.
• یک Asset contract و Performance budget واقعی بسازید.

روز ۳۱ تا ۶۰: Prototype عمودی

• Journey کامل 2D→permission→calibration→task→exit→handoff را بسازید.
• ورودی دوم، reduced-motion/seated و Failure recovery را پیاده کنید.
• ماتریس Device/browser/network/ability را با User test اجرا کنید.

روز ۶۱ تا ۹۰: Pilot و تصمیم

• Eligible cohort و مسیر fallback را جدا اندازه بگیرید.
• Task/comfort/business/economics و Guardrail را پیش‌ثبت کنید.
• Scale فقط با بهبود Outcome و عبور Safety/accessibility/technical gate؛ Hold برای داده ناکافی و Rollback برای آسیب یا شکست مسیر اصلی.

سؤال‌های متداول

آیا WebAR و WebVR روی همه مرورگرها اجرا می‌شوند؟

خیر. WebXR و Moduleهای آن پشتیبانی یکسانی در همه مرورگرها و دستگاه‌ها ندارند. در Runtime با `isSessionSupported()` و Capabilityهای لازم Feature-detect کنید و مسیر 2D/Inline 3D هم‌ارز ارائه دهید؛ فهرست ثابت مرورگر به‌سرعت منقضی می‌شود.

برای WebXR حتماً هدست لازم است؟

برای VR immersive معمولاً دستگاه سازگار لازم است، اما Inline 3D، ویدئو/تصویر ۳۶۰ و بعضی تجربه‌های AR روی نمایشگر دستی اجرا می‌شوند. نیاز سخت‌افزار به Mode و Feature بستگی دارد؛ CTA باید قبل از شروع نیازمندی را روشن کند.

آیا ۹۰ FPS حداقل اجباری WebXR است؟

عدد واحدی برای همه Runtimeها وجود ندارد. هدف این است که Frame loop با Refresh دستگاه پایدار بماند و Missed frame/Latency ناراحت‌کننده نسازد. Frame-time p95/p99، Thermal و Session طولانی را روی دستگاه واقعی بسنجید و Quality tier داشته باشید.

چگونه بیماری حرکت در VR را حذف کنیم؟

حذف کامل برای همه قابل تضمین نیست. کنترل دوربین را به کاربر بدهید، روش‌های Stationary/Teleport/Snap/Smooth قابل تنظیم، Pause/Recenter/Exit، Reduced motion و Session کوتاه فراهم کنید و با کاربران دارای حساسیت‌های متفاوت تست کنید.

Fallback دسترس‌پذیر برای تجربه XR چیست؟

مسیر جایگزین باید Outcome اصلی را با DOM معنایی، Keyboard/Touch و محتوای متن/تصویر/ویدئو در دسترس بدهد؛ نه صرفاً پیام «دستگاه شما پشتیبانی نمی‌شود». انتخاب Variant، اطلاعات، Save/Cart یا تکمیل آموزش باید حفظ شود.

جمع‌بندی

طراحی UX برای AR و VR وب، طراحی یک Canvas سه‌بعدی نیست؛ طراحی Capability، بدن، فضا، Permission، Failure و خروج است. از Job فضایی معتبر شروع کنید، Progressive enhancement و نتیجه هم‌ارز را بسازید، حرکت و ورودی را قابل تنظیم کنید، محیط را داده حساس بدانید و Performance را روی Runtime واقعی بسنجید. یک Pilot کوچک که Task را بهتر و امن‌تر می‌کند از تجربه پرزرق‌وبرقی که فقط روی دستگاه تیم اجرا می‌شود ارزشمندتر است.

منابع فنی و دسترس‌پذیری منتخب

• W3C — WebXR Device API
• MDN — WebXR Device API and browser support
• W3C — XR Accessibility User Requirements
• W3C — Web Content Accessibility Guidelines 2.2
• MDN — WebXR permissions and security