دکمه سبز شد، تیک موفقیت پخش شد و کاربر صفحه را بست؛ اما درخواست در سرور شکست خورده بود. این فقط یک انیمیشن بد نیست: قرارداد نادرستی میان وضعیت واقعی سیستم و چیزی است که رابط به کاربر وعده میدهد. نتیجه میتواند سفارش تکراری، پرداخت نامعلوم، فرم گمشده یا بیاعتمادی باشد.
میکرواینتراکشن خوب از «افکت جذاب» شروع نمیشود. ابتدا Task، State، منبع حقیقت، خطا و اقدام بعدی را مشخص میکند؛ سپس Feedback متنی، بصری، لمسی یا حرکتی را به آن میافزاید. در این راهنما، تعامل خرد را از Trigger تا State machine، Accessibility، Motion، Performance، سنجش و تحویل به Design system طراحی میکنیم—با مثالهای فروشگاه، فرم، OTP و پرداخت برای کاربر ایرانی.
میکرواینتراکشن چیست و چه چیزی نیست؟
Microinteraction لحظهای محدود در رابط است که یک Trigger را میگیرد، طبق Rule وضعیت را تغییر میدهد، نتیجه را بازخورد میدهد و رفتار تکرار یا حالتهای بعدی را مدیریت میکند. واحد طراحی آن «یک Task کوچک با Outcome روشن» است، نه تعداد Keyframeها.
| مفهوم | نقش | مثال |
|---|---|---|
| Microinteraction | چرخه کامل Trigger→State→Feedback→Recovery | ذخیره آدرس با Pending، Success و Error |
| Animation | نمایش تغییر در طول زمان | Fade پیام یا حرکت Progress |
| Transition | رابط بصری میان دو State | باز و بستهشدن Accordion |
| Feedback | اطلاع از دریافت، وضعیت یا نتیجه | «سفارش ثبت شد» یا «اتصال قطع است» |
| Affordance | سرنخ اینکه کنترل چه کاری میکند | ظاهر و Label دکمه «پرداخت» |
| Component | واحد قابلاستفاده مجدد UI | Button، Switch، Toast یا Progress |
Hover زیبا بهتنهایی Microinteraction کامل نیست؛ چون روی Touch وجود ندارد، ممکن است State یا Outcome نداشته باشد و برای Keyboard نیز دیده نشود. در مقابل، یک پیام ثابت «ذخیره شد» بدون Motion میتواند تعامل خرد بسیار مؤثری باشد.
کالبد میکرواینتراکشن؛ از چهار جزء تا State machine
مدل کلاسیک Trigger، Rules، Feedback و Loops/Modes نقطه شروع خوبی است؛ برای محصول واقعی باید Source of truth، Failure و Recovery را نیز صریح کنیم.
| بخش | پرسش طراحی | خروجی لازم |
|---|---|---|
| Trigger | کاربر، سیستم، زمان یا Event آغازگر است؟ | Click/Enter/Change/Network/Timer |
| Precondition | چه شرطی باید برقرار باشد؟ | مجوز، داده معتبر، اتصال یا موجودی |
| Rules | کدام Transition مجاز است؟ | State diagram و Guard |
| Source of truth | Client، Server یا Provider نتیجه را تأیید میکند؟ | Acknowledgement contract |
| Feedback | کاربر چه چیزی را چه زمانی بفهمد؟ | Copy، Icon، Motion، Sound/Haptic |
| Failure | Timeout، Offline، Conflict یا خطای Validation چه میشود؟ | Error state قابلتشخیص |
| Recovery | Retry، Undo، Edit، Resume یا Support کدام است؟ | اقدام بعدی بدون بنبست |
| Loops/Modes | تکرار، Preference یا Context رفتار را عوض میکند؟ | Rate limit، persistence و reset |
State را پیش از Motion بنویسید
Idle → Ready → Pressed → Pending
Pending → Success
Pending → ValidationError | NetworkError | Timeout | Conflict
Error → Edit | Retry | Cancel
Success → Undo (اگر عمل برگشتپذیر است)Hover، Focus و Pressed حالتهای ورودیاند؛ Pending، Success و Error وضعیت عملیاتاند. آنها را یکی نکنید. تغییر رنگ در لحظه Click فقط میگوید کنترل فعال شد، نه اینکه سرور نتیجه را پذیرفت.
Feedback contract؛ رابط دقیقاً چه وعدهای میدهد؟
برای هر Transition یک قرارداد قابلآزمون بنویسید. Feedback باید سه پرسش را جواب دهد: «درخواست من دریافت شد؟»، «اکنون چه وضعیتی دارد؟» و «بعد چه کنم؟»
| State | پیام درست | کنترل | خطای رایج |
|---|---|---|---|
| Pressed | بازخورد فوری فشردن | Focus حفظ شود | نمایش Success زودهنگام |
| Pending | «در حال ثبت…» | جلوگیری منطقی از Duplicate؛ Cancel اگر ممکن | Spinner بیمتن و بینهایت |
| Success | Outcome و شناسه قابلاستناد | Next step یا Undo | Toast دوثانیهای تنها |
| Validation error | محل، علت و روش اصلاح | Focus/summary مناسب | فقط کادر قرمز |
| Network/timeout | وضعیت معلوم یا نامعلوم | Retry امن، حفظ ورودی | «ناموفق» با پاککردن فرم |
| Conflict | چه چیزی تغییر کرده است؟ | Review/Merge/Reload | Overwrite خاموش |
Success را به Acknowledgement معتبر وصل کنید. در عملیات چندمرحلهای، «درخواست دریافت شد» را از «پردازش کامل شد» جدا کنید. این تمایز در پرداخت، ارسال فایل، ثبت سفارش و صدور گزارش حیاتی است.
اولویت ارزش؛ وضوح و کنترل پیش از Delight
- Correctness: نمایش وضعیت واقعی و جلوگیری از اثر تکراری؛
- Comprehension: فهم اینکه چه اتفاقی افتاده؛
- Recovery: خروج از خطا بدون از دستدادن کار؛
- Orientation: حفظ جای کاربر و رابطه علت/معلول؛
- Efficiency: کاهش انتظار ادراکی یا گام اضافه؛
- Brand/Delight: شخصیت و لذت، مشروط به پنج مورد قبل.
دکمهای که برای جلب توجه مدام میلرزد ممکن است Conversion کوتاهمدت بسازد، اما کنترل کاربر و توجه او را میگیرد. اصول گستردهتر انتخاب اخلاقی در راهنمای طراحی اخلاقی و حذف Dark pattern بررسی شده است.
الگوهای مهم و Acceptance آنها
ارسال فرم، ورود و OTP
- Validation را در زمان مناسب انجام دهید؛ خطا قبل از تعامل کاربر فریاد نزند.
- هنگام Submit، Label به «در حال ارسال…» تغییر کند و مقدارها حفظ شوند.
- Disabled ظاهری جای Idempotency یا کنترل سمت سرور را نمیگیرد.
- خطا با متن، محل و پیشنهاد اصلاح بیاید؛ Color تنها کانال نباشد.
- برای OTP، امکان Paste/Autofill، ارسال مجدد پس از Countdown واقعی و تغییر شماره وجود داشته باشد.
- تأخیر SMS یا شبکه ایران به «کد اشتباه است» ترجمه نشود.
برای طراحی Message، Field، Error summary و آزمایش Outcome، راهنمای لندینگ، فرم و A/B test مکمل این بخش است.
سبد خرید و موجودی
افزودن خوشبینانه کالا میتواند رابط را سریع نشان دهد، اما Price، Stock و Variant باید با پاسخ سرور Reconcile شوند. اگر موجودی تغییر کرد، کالا را بیصدا حذف نکنید؛ تفاوت را توضیح دهید و گزینه جایگزین یا بازگشت بدهید. Animation پرواز تصویر به سبد، جای شمارنده متنی و وضعیت قابلخواندن را نمیگیرد.
پرداخت و Redirect
«بازگشت از درگاه» لزوماً Success نیست. رابط باید Pending verification، Paid، Failed، Cancelled و Unknown را جدا نمایش دهد. اگر Callback دیر رسید، شناسه سفارش و مسیر «بررسی دوباره وضعیت» بدهید؛ پرداخت مجدد را تا روشنشدن Idempotency و وضعیت تراکنش تحریک نکنید.
آپلود و پردازش طولانی
Spinner فقط وجود فعالیت را نشان میدهد. اگر اندازه کار معلوم است، Progress واقعی، مقدار ارسالشده و زمان تقریبی محتاطانه بهتر است. Upload از Server processing جداست؛ Cancel/Resume، Retry بخش شکستخورده و حفظ فایل انتخابشده را طراحی کنید.
Toggle، Switch و Preference
State باید بدون اتکا به رنگ فهمیده و با Keyboard تغییر کند. الگوی Button در WAI-ARIA APG تفاوت Button معمولی و Toggle با aria-pressed را توضیح میدهد. برای Preference ذخیرهشونده، تغییر Control از تأیید ذخیره Server جدا باشد؛ اگر ذخیره شکست خورد State را Revert یا خطا را روشن کنید.
حذف، Undo و عملیات پرریسک
Confirm برای هر عمل، اصطکاک میسازد و کاربر به آن عادت میکند. عمل برگشتپذیر را میتوان با Undo پایدار طراحی کرد؛ عمل مالی، حقوقی یا غیرقابلبازگشت به Review روشن نیاز دارد. Toast کوتاهی که تنها مسیر Undo است برای کاربر Keyboard، Screen reader یا فردی با توجه تقسیمشده قابلاعتماد نیست.
Optimistic UI یا Pessimistic UI؟
| رویکرد | تناسب | شرط ایمنی |
|---|---|---|
| Optimistic | Like، Preference کمریسک، تغییر محلی سریع | Rollback/Reconcile، نرخ خطای پایین، اثر قابلبازگشت |
| Pessimistic | پرداخت، حذف حساس، تغییر دسترسی | Pending روشن و Timeout/Recovery |
| Staged | آپلود، سفارش، گزارش | Received→Processing→Completed با State مستقل |
انتخاب را با Risk×Latency×Reversibility انجام دهید. Optimistic UI برای عملیات مالی فقط «حس سریع» نمیسازد؛ ممکن است واقعیت نادرست بسازد. همچنین Double-click باید در Client کنترل شود، اما تضمین عدم اثر تکراری در API و Transaction است.
دسترسپذیری؛ Feedback برای همه کانالها
WCAG 2.2 الزامات مرتبطی برای Keyboard، Focus، Color، Motion، Target، Error و Status دارد. Compliance با افزودن ARIA بعد از طراحی حاصل نمیشود؛ HTML بومی، State درست و آزمون با فناوری کمکی مقدماند.
| ریسک | Requirement طراحی | نمونه آزمون |
|---|---|---|
| Keyboard | عملکرد با Tab/Enter/Space و Focus قابلدیدن | مسیر کامل بدون Mouse |
| Screen reader | Name/Role/State و تغییر مهم قابلاعلان | NVDA/VoiceOver روی Success/Error |
| Color/vision | State با متن/شکل، Contrast کافی | بدون رنگ نیز قابلتشخیص |
| Touch/motor | Target و فاصله مناسب، جایگزین Drag | Touch با Zoom و یک انگشت |
| Cognition | Copy ثابت، زمان کافی، History/Recovery | Resume پس از وقفه |
| Motion sensitivity | Reduced motion و حذف حرکت غیرضروری | تنظیم OS روی Reduce |
WCAG ۲.۲ در معیار ۲.۵.۸ حداقل Target را با استثناهای مشخص ۲۴×۲۴ CSS pixel میداند؛ ۴۴×۴۴ مربوط به معیار Enhanced سطح AAA است. عدد را از Context، تراکم و کاربران جدا نکنید. پوشش جامعتر در راهنمای طراحی فراگیر و WCAG آمده است.
Status message و Live region
راهنمای W3C برای Status Messages میگوید تغییرهایی مثل Success، Waiting، Progress یا Error باید بدون جابهجایی Focus برای فناوری کمکی قابلتشخیص باشند. role="status" برای اطلاع کمفوریت مناسب است؛ Alert برای وضعیت فوری و مهم است، نه هر Toast.
- پیام را پیشاپیش در Live region قابلشناسایی قرار دهید و محتوایش را تغییر دهید؛
- هر تغییر شمارنده یا کاراکتر را Announce نکنید؛ Noise نیز مانع است؛
- Focus را برای Toast ندزدید؛ برای Dialog یا خطای بلوکهکننده، الگوی Focus جدا لازم است؛
- اطلاعات حساس مثل OTP، شماره کارت یا متن خصوصی را بیدلیل Announce نکنید؛
- پیام ناپدیدشونده تنها مدرک Success یا تنها مسیر Action نباشد.
Focus، Name، Role و State
از <button> برای Action و از Link برای Navigation استفاده کنید. Focus پس از بازشدن Dialog، حذف Item یا تغییر Context باید به مقصد منطقی برود. aria-expanded، aria-pressed، aria-selected و aria-busy باید واقعیت را بازتاب دهند؛ ARIA جای Event handling، Keyboard behavior یا HTML سالم را نمیگیرد.
Motion با معنا؛ نه زمانبندی جادویی
هیچ Duration جهانی برای همه کنترلها، دستگاهها و فاصلهها وجود ندارد. Motion token را براساس نوع تغییر، Distance، Complexity و امکان Interrupt تعریف کنید و با کاربران و دستگاه واقعی بسنجید.
| ویژگی | پرسش | Guardrail |
|---|---|---|
| Purpose | رابطه مکانی، تغییر State یا تأکید؟ | اگر حذف شد، Meaning از بین میرود؟ |
| Duration | تغییر کوچک است یا انتقال Context؟ | Action را بیدلیل Block نکند |
| Easing | ورود، خروج یا جابهجایی؟ | شتاب ناگهانی و Bounce بیهدف حذف |
| Distance/scale | چه میزان میدان دید حرکت میکند؟ | حرکت بزرگ Vestibular risk بیشتری دارد |
| Interrupt | کاربر وسط Motion چه میکند؟ | State نهایی قطعی و Input گم نشود |
| Reduced | نسخه کمحرکت چیست؟ | Meaning با متن/Opacity/Instant state حفظ |
prefers-reduced-motion یک Variant محصول است
ویژگی prefers-reduced-motion در MDN Preference سیستمعامل برای کمکردن حرکت غیرضروری را آشکار میکند. «Reduce» لزوماً به معنی خاموشکردن کور همه Transitionها نیست؛ حرکت بزرگ/Scale/Parallax را میتوان با تغییر فوری، Dissolve یا Feedback متنی جایگزین کرد.
.feedback {
transition: opacity 160ms ease, transform 160ms ease;
}
@media (prefers-reduced-motion: reduce) {
.feedback {
transition: opacity 80ms linear;
transform: none;
}
}معیار ۲.۳.۳ WCAG برای Motion ناشی از Interaction امکان Disable را مطرح میکند مگر Essential باشد. همچنین Pause, Stop, Hide برای Motion یا Auto-update خودکار و ماندگار شرطهای جدا دارد. Flash سریع میتواند خطر جسمی داشته باشد و با «دکمه توقف بعدی» جبران نمیشود.
میکرواینتراکشن فارسی و RTL
RTL فقط Flip کردن CSS نیست. جهت حرکت باید معنای Information architecture را دنبال کند: Back/Forward، Previous/Next و ورود Pane را با ساختار واقعی و الگوی پلتفرم تست کنید. Icon جهتدار، Chevron، Progress step و Swipe به بازبینی نیاز دارند؛ Iconهای غیرجهتی مثل Play یا Download لزوماً Mirror نمیشوند.
- متن فارسی با عدد، درصد، کد رهگیری، URL و مبلغ Mixed-direction را در Toast و Button آزمون کنید؛
- «۱۲۵٬۰۰۰ تومان» و «۱۲۵٬۰۰۰ ریال» را با Label کامل، نه صرفاً رنگ، متمایز کنید؛
- ی/ک عربی و فارسی، نیمفاصله و ارقام را در Validation بیدلیل خطا نگیرید؛
- پیام کوتاه را مبهم نکنید: «انجام شد» کمتر از «آدرس ذخیره شد» اطلاع میدهد؛
- روی فونت فارسی، Line-height، Zoom و شکستن متن Button/Toast تست کنید؛
- شبکه کند، VPN، قطعووصل، درگاه و تأخیر پیامک را سناریوی اصلی بدانید، نه Edge case.
برای قرارداد Bidi، متن، عدد، فونت و QA محلی، به راهنمای طراحی سایت فارسی و RTL رجوع کنید.
Performance؛ Motion روان فقط FPS نیست
Animation میتواند Main thread را با Style/Layout/Paint درگیر و پاسخ به Input را کند کند. راهنمای انیمیشن پربازده در web.dev توصیه میکند پیش از Animate کردن Propertyهای دیگر، اثر آنها بر Pipeline سنجیده شود و در صورت امکان از transform و opacity استفاده شود. این یک تضمین جهانی نیست؛ Layer، Memory، اندازه Element و Device مهماند و will-change نیز نباید سراسری و دائمی شود.
بودجه و آزمون Performance
- Input-to-visual feedback و INP مسیر را روی دستگاه میانرده/ضعیف اندازه بگیرید؛
- Long task، Layout/Paint، dropped frame و Memory/GPU layer را ثبت کنید؛
- Animation همزمان با Fetch، Validation، Hydration و List update آزموده شود؛
- State نهایی با قطع Animation، Background tab یا navigation درست بماند؛
- Low-power، Data saver، Zoom، RTL و Reduced motion در ماتریس QA باشند؛
- Skeleton باید شکل محتوا را صادقانه نشان دهد و Layout shift نسازد.
راهنمای سرعت سایت، UX و تبدیل مدل گستردهتری برای Performance budget و سنجش Journey دارد.
میکرواینتراکشن و SEO؛ ادعای مستقیم نسازید
گوگل «انیمیشن لایک» یا کاهش Bounce در Analytics شما را بهعنوان میانبر رتبه تضمین نمیکند. راهنمای رسمی Page Experience گوگل میگوید Core Web Vitals در سیستمهای رتبهبندی استفاده میشوند، اما امتیاز خوب تضمین رتبه نیست و Page experience نیز یک Signal واحد ندارد.
پس Microinteraction را برای Task success و وضوح بسازید. اثر SEO محتمل، غیرمستقیم و مشروط است: اگر JavaScript سنگین INP را خراب کند، محتوا را پنهان نگه دارد، Link را به Button جعلی تبدیل کند یا Layout shift بسازد، تجربه و Eligibility آسیب میبینند. Dwell time و Bounce را بدون طراحی علّی به «سیگنال رتبه» تبدیل نکنید.
امنیت و اخلاق؛ UI کنترل امنیتی نیست
| ریسک | ظاهر فریبنده | کنترل واقعی |
|---|---|---|
| Double submit | Disable دکمه | Idempotency/Transaction سمت سرور |
| Permission | مخفیکردن Control | Authorization سمت سرور |
| Password | نوار سبز Strength | Policy، breached-password check، MFA و storage امن |
| Payment | تیک پس از Redirect | Verification و reconciliation سرور |
| Consent | Animation پررنگ Accept | انتخاب همسطح، informed و قابللغو |
| Delete | Toast «حذف شد» | Policy، audit، retention و restore/undo |
Confetti، vibration، streak و Variable reward میتوانند برای بعضی محصولات مناسب باشند، اما نباید Shame، Urgency جعلی، Consent نامتوازن یا استفاده اجباری بسازند. Motion brand asset است، نه مجوز دستکاری.
Interaction spec قابلتحویل
بهجای تحویل ویدیوی زیبا، Specification زیر را برای هر Pattern ثبت کنید:
| فیلد | نمونه برای «ذخیره آدرس» |
|---|---|
| User job | ثبت آدرس بدون ورود دوباره |
| Trigger/input | Button، Enter؛ داده معتبر |
| States | Idle/Invalid/Pending/Saved/Error/Conflict |
| Source of truth | پاسخ API با version |
| Copy | «در حال ذخیره…»، «آدرس ذخیره شد» |
| Semantics | Button بومی، status کمفوریت، Error مرتبط |
| Focus | پس از Success روی Button؛ در Error به summary/field منطقی |
| Motion | Fade کوچک؛ Variant کمحرکت |
| Failure/recovery | ورودی حفظ، Retry/Edit، Conflict review |
| Telemetry | submit_received/saved/failed/retry بدون PII |
| Acceptance | Keyboard/AT/RTL/offline/slow/reduced/performance |
برای وصلکردن Task، Acceptance و QA کل صفحه، راهنمای طراحی کاربرپسند از Task تا Usability را ببینید.
Motion و Feedback در Design system
Token فقط Duration و Easing نیست. System باید State، Semantic، Copy، Motion variant، Focus، reduced-motion behavior و Event telemetry را به Component وصل کند.
- Primitive: duration، easing، distance، opacity؛
- Semantic: enter، exit، emphasis، state-change، reduced؛
- Component: button-pending، toast-success، dialog-enter، progress؛
- Pattern: submit، upload، delete/undo، payment verification؛
- Governance: Owner، version، evidence، deprecation و regression.
Component نباید Business state را حدس بزند. API باید Pending/Success/Error/Conflict را قابلتفکیک کند و Product copy باید از Error code فنی جدا باشد.
سنجش؛ Engagement بیشتر الزاماً موفقیت نیست
| لایه | Metric | تفسیر |
|---|---|---|
| Outcome | Task success، completion، correct state | آیا کار واقعاً انجام شد؟ |
| Efficiency | Time/steps، duplicate action | آیا ابهام کم شد؟ |
| Recovery | Error recovery، retry success، abandonment | آیا خطا بنبست ساخت؟ |
| Accessibility | Keyboard/AT completion، reduced-motion defects | چه کسی حذف شده است؟ |
| Performance | INP، long task، dropped frame | آیا Feedback خودش مانع است؟ |
| Trust | unknown state، support contact، complaint | آیا وعده رابط با واقعیت یکی است؟ |
Like count یا Hover event معیار ارزش عمومی نیست. Eventها را به State transition و Outcome وصل کنید و داده حساس را در متن Status/Telemetry نریزید. برای Production monitoring، راهنمای Observability وبسایت مسیر Signal تا SLO و Incident را توضیح میدهد.
پشته آزمون میکرواینتراکشن
- State/unit: Transitionهای مجاز، Timeout، Retry و Race؛
- Component: Name/Role/State، Keyboard، Focus و Reduced motion؛
- Integration: API error، offline، duplicate، stale response و conflict؛
- Visual/motion: RTL، Zoom، font load، frame و interruption؛
- Assistive technology: Screen reader، high contrast و switch/keyboard؛
- Usability: فهم State، confidence، recovery و زمان Task؛
- Production: outcome/error/retry/performance با Alert و rollback.
ماتریس سناریوهای شکست
| سناریو | انتظار |
|---|---|
| Double-click/Enter | یک Outcome؛ Feedback پایدار |
| پاسخ دیر و خارج ترتیب | State جدید با پاسخ قدیمی Overwrite نشود |
| Offline وسط کار | وضعیت معلوم، ورودی حفظ، Retry امن |
| Navigation/refresh | عملیات حساس قابلبازیابی یا هشدار روشن |
| Reduced motion | Meaning و State بدون حرکت کامل |
| Screen reader | یک Announcement مفید، بدون Noise |
| RTL + متن بلند | جهت/Wrap/Focus/Target سالم |
| Low-end device | Input responsive و State قطعی |
مصاحبه و تست نباید فقط بپرسد «انیمیشن را دوست داشتید؟». از کاربر بخواهید نتیجه را توضیح دهد، خطا را بازیابی کند و وضعیت را پس از وقفه پیدا کند. پروتکل کامل در راهنمای تست کاربردپذیری آمده است.
Workflow تیم از Inventory تا Rollout
| مرحله | کار | خروجی |
|---|---|---|
| ۱. Inventory | ثبت Action، Toast، Loader، Toggle و Motion | Interaction registry |
| ۲. Risk | مالی/داده/دسترسپذیری/خطا/تکرار | اولویت Critical journey |
| ۳. Contract | State، source، copy، recovery و semantic | Interaction spec |
| ۴. Prototype | Default/Reduced/RTL/Error/Slow | Prototype قابلآزمون |
| ۵. Build | Native semantics، API contract و tokens | Component/Pattern |
| ۶. Verify | Automated + manual + AT + usability + performance | Evidence pack |
| ۷. Release | Canary، telemetry، alert و rollback | Production evidence |
| ۸. Govern | Regression، version و deprecation | Design-system lifecycle |
چکلیست طراحی میکرواینتراکشن
- Task و Outcome با یک جمله روشناند؛
- Trigger، Precondition و Source of truth ثبت شدهاند؛
- Idle/Focus/Pressed/Pending/Success/Error/Disabled طراحی شدهاند؛
- Success فقط پس از تأیید معتبر نمایش داده میشود؛
- Unknown/Timeout/Offline از Failed قطعی جداست؛
- Duplicate action در Client و Server کنترل میشود؛
- ورودی در خطا حفظ و Recovery روشن است؛
- Feedback متنی است و فقط به Color/Icon/Motion متکی نیست؛
- Name/Role/State و Keyboard interaction درستاند؛
- Focus پس از تغییر Context مقصد منطقی دارد؛
- Status مهم برای فناوری کمکی قابلتشخیص است؛
- Live region Noise یا افشای داده حساس نمیسازد؛
- Reduced-motion variant معنای کامل دارد؛
- Auto-motion، Flash، timeout و pause کنترل شدهاند؛
- Target، فاصله، Touch و جایگزین Drag آزموده شدهاند؛
- RTL، متن فارسی، عدد/تومان و Wrap سالماند؛
- Network کند، VPN، OTP و درگاه در سناریوها هستند؛
- Layout/Paint/Long task/INP روی دستگاه واقعی سنجیده شدهاند؛
- Telemetry به Outcome وصل است، نه Vanity engagement؛
- Pattern در Design system Owner و Regression دارد.
جمعبندی؛ یک سیستم کوچک، نه یک افکت کوچک
میکرواینتراکشن موفق رابط را «زندهتر» نمیکند؛ آن را صادقتر، قابلفهمتر و بازیابیپذیرتر میکند. Trigger و State machine، منبع حقیقت، Feedback، Semantic، Motion variant و Recovery باید یک قرارداد واحد باشند. اگر تیک Success پیش از Server میآید، Toast برای Screen reader نامرئی است یا Animation روی دستگاه ضعیف Input را Block میکند، زیبایی خروجی مسئله را حل نمیکند.
از Critical journey شروع کنید: پرداخت، Submit، Upload، Delete یا تغییر Preference. Stateها را بنویسید، خطا و شبکه ایران را شبیهسازی کنید، Default و Reduced motion را کنار هم بسازید و Outcome را در Production بسنجید. Delight وقتی ارزش دارد که Correctness، Accessibility و Control پیش از آن حل شده باشند.
سؤالات متداول میکرواینتراکشن
تفاوت میکرواینتراکشن و انیمیشن چیست؟
میکرواینتراکشن چرخه کامل یک Task یا تغییر State شامل Trigger، Rule، Feedback، Failure و Recovery است. Animation فقط یکی از روشهای نمایش تغییر در طول زمان است. یک پیام متنی بدون حرکت میتواند Microinteraction کامل باشد و یک انیمیشن زیبا بدون State واقعی صرفاً تزئین باشد.
مدت مناسب انیمیشن میکرواینتراکشن چند میلیثانیه است؟
عدد جهانی وجود ندارد. Duration به فاصله، پیچیدگی، نوع Transition، Device و امکان Interrupt بستگی دارد. برای تغییر کوچک کوتاهتر و برای تغییر Context زمان توضیحی بیشتری لازم است؛ اما Action نباید بیدلیل Block شود. Token بسازید و آن را با Performance و Task comprehension روی دستگاه واقعی آزمون کنید.
آیا باید تمام انیمیشنها را در prefers-reduced-motion خاموش کنیم؟
نه لزوماً. هدف حذف یا جایگزینی Motion غیرضروری و آزاردهنده با State فوری، Opacity ملایم یا Feedback متنی است، در حالی که Meaning حفظ میشود. حرکت Essential باید دقیق توجیه شود. Default و Reduced را دو Variant محصول بدانید و هر دو را تست کنید.
برای اعلام «به سبد اضافه شد» از Toast استفاده کنیم؟
Toast میتواند کانال مکمل باشد، اما شمارنده و State سبد نیز باید بهروز و برای فناوری کمکی قابلتشخیص شوند. پیام نباید تنها مسیر Undo باشد یا پیش از تأیید Server Success نشان دهد. اگر Stock/Price تغییر کرد، Reconciliation و اقدام بعدی روشن لازم است.
آیا میکرواینتراکشن باعث بهبود رتبه سئو میشود؟
اثر مستقیم و تضمینشدهای برای یک Animation وجود ندارد. Microinteraction میتواند Task و تجربه را بهتر کند، اما JavaScript سنگین، INP بد، Layout shift یا محتوای پنهان میتواند آسیب بزند. آن را برای کاربر و Outcome طراحی کنید و Performance/Core Web Vitals را اندازه بگیرید؛ Bounce یا Dwell را میانبر رتبه فرض نکنید.
