طراحی بد همیشه زشت نیست. ممکن است صفحه چشمنواز باشد، اما کاربر نداند این خدمت برای اوست یا نه؛ دکمه خرید زیر نوار چسبان پنهان شود؛ فرم پس از خطا همه دادهها را پاک کند؛ یا سفارش موفق باشد و پیام نتیجه برای Screen reader اعلام نشود. اینها اختلاف سلیقه نیستند؛ شکست Task هستند.
اشتباهات رایج طراحی سایت را باید با سفر واقعی، شواهد و معیار پذیرش پیدا کرد. «کاربر گیج میشود» یک Observation قابلاقدام نیست؛ «۴ نفر از ۶ نفر در موبایل دکمه ادامه را ندیدند چون Keyboard و Sticky bar آن را پوشاند» هم علت محتمل دارد و هم Test اصلاح.
پاسخ کوتاه: رایجترین اشتباهات طراحی سایت چیست؟
- طراحی بدون مخاطب، Job و Outcome روشن؛
- شروع از ظاهر پیش از محتوا و جریان؛
- پیام و ارزش پیشنهادی مبهم یا اغراقآمیز؛
- سلسلهمراتب دیداری ضعیف و CTAهای هموزن؛
- Homepage شلوغ و Navigation براساس چارت سازمانی؛
- طراحی Mobile بهعنوان نسخه کوچکشده Desktop؛
- دسترسپذیری بهعنوان مرحله آخر؛
- فرم طولانی، Label و Error message ضعیف؛
- اعتمادسازی با Badge، آمار یا رضایتنامه بیمدرک؛
- استفاده از Dark pattern برای Conversion؛
- ندیدن Loading، Empty، Error، Offline و Permission state؛
- تصمیم بر Click و سلیقه، بدون Task success و Outcome؛
- Redesign بزرگ بدون Baseline، Pilot و Rollback؛
- نداشتن مالک، QA و نگهداری پس از انتشار.
اشتباه طراحی را با Failure قابل مشاهده تعریف کنید
| لایه | پرسش | شاهد |
|---|---|---|
| Outcome | کاربر و کسبوکار چه نتیجهای میخواهند؟ | Task/Business metric |
| Journey | از کجا وارد و به کجا باید برسد؟ | Path/step map |
| Friction | کجا کند، متوقف یا اشتباه میکند؟ | Observation/error/event |
| Cause | چه فرضیهای Failure را توضیح میدهد؟ | Evidence triangle |
| Fix | کوچکترین تغییر مؤثر چیست؟ | Prototype/Pilot |
| Acceptance | از کجا میفهمیم اصلاح شد؟ | Outcome + guardrail |
ظاهر، فقط یکی از ورودیهاست. یک UI میتواند از نظر Brand دقیق باشد و هنوز برای Keyboard، شبکه کند، خطای پرداخت یا کاربر کمبینا شکست بخورد.
Opinion را از Evidence جدا کنید
| جمله ضعیف | صورت قابل بررسی |
|---|---|
| منو شلوغ است | ۴۰٪ Taskها مسیر اشتباه رفتند؛ پنج Label همپوشان بود |
| رنگ دکمه بد است | Contrast/State ناقص و عنصر شبیه متن غیرقابل کلیک است |
| فرم طولانی است | Drop در مرحله کدپستی و ۳ فیلد بدون نیاز عملیاتی است |
| سایت کند است | LCP موبایل ایران P75 برابر X و خروج در همان Template بالاست |
| کاربر اعتماد ندارد | در مصاحبه درباره قیمت، بازگشت یا هویت سؤال تکرار شد |
واحد ممیزی «Task در Context» است
صفحه را جدا از سفر بررسی نکنید. Task «خرید» ممکن است از تبلیغ و صفحه محصول آغاز شود، با انتخاب Variant و آدرس ادامه یابد، به درگاه خارج از سایت برود و با Callback یا پیگیری سفارش تمام شود. شکست هر مرحله میتواند بهاشتباه «طراحی Checkout» یا «کیفیت ترافیک» نام بگیرد.
| Context | نمونه | ریسک پنهان |
|---|---|---|
| User | تازهکار، برگشتی، کمبینا | مدل ذهنی/نیاز متفاوت |
| Goal | یادگیری، مقایسه، خرید، پشتیبانی | CTA نامتناسب |
| Device/input | موبایل، Keyboard، Voice | Focus/Target/keyboard |
| Network | کند یا ناپایدار | Timeout/partial load |
| Locale | فارسی، RTL، عدد/کد لاتین | Bidi و Validation |
| State | مهمان، واردشده، خطا، موجودی صفر | مسیر بدون طراحی |
| Risk | مالی، پزشکی، حقوقی، داده شخصی | نیاز به تأیید و Trust |
Service Standard دولت بریتانیا از شناخت کاربر و نیاز، حل کل مسئله، تجربه پیوسته میان کانالها، استفاده ساده برای همه، امنیت/حریم خصوصی، تعریف موفقیت و عملیات قابلاعتماد شروع میکند. این ترتیب یادآوری میکند که «صفحه زیبا» معادل «خدمت سالم» نیست.
شدت را پیش از زیبایی اولویت دهید
یک مدل ترتیبی برای Ranking—نه فرمول علمی دقیق:
Priority = (Task criticality × Severity × Frequency × Evidence confidence) ÷ (Effort × Change risk)
| Severity | تعریف | نمونه | واکنش |
|---|---|---|---|
| Critical | Task یا داده/پول از دست میرود | پرداخت موفق و سفارش ثبتنشده | Incident/stop rollout |
| High | بخش بزرگی متوقف میشود | فرم با Keyboard ارسال نمیشود | رفع فوری/Pilot |
| Medium | Task سخت یا کند میشود | فیلتر وضعیتش را نشان نمیدهد | Backlog نزدیک |
| Low | اصطکاک محدود یا ظاهری | Spacing ناهماهنگ بدون اثر Task | Design-system maintenance |
قانون، امنیت، Accessibility blocker و از دسترفتن داده را صرفاً با حجم کم عقب نیندازید. Frequency پایین میتواند ناشی از این باشد که کاربر پیش از رسیدن به مانع، مسیر را ترک کرده است.
اشتباه ۱: طراحی بدون کاربر، Job و نتیجه
Persona فقط «مرد ۳۰ تا ۴۰ ساله علاقهمند به تکنولوژی» تصمیم طراحی نمیسازد. تیم باید بداند کاربر در چه موقعیت، با چه محرک و محدودیتی، چه نتیجهای میخواهد و موفقیت را چگونه تشخیص میدهد.
| فیلد | نمونه فروشگاه ایرانی |
|---|---|
| Trigger | گوشی فعلی خراب شده |
| Job | تا سقف بودجه، مدل قابلاعتماد انتخاب کند |
| Constraint | موجودی/قیمت نوسانی، تحویل شهرستان |
| Evidence need | گارانتی، موجودی واقعی، مقایسه |
| Success | انتخاب درست و Promise تحویل روشن |
| Business outcome | سفارش تحویلشده و نگهداشتهشده |
Task را با مصاحبه، Ticket پشتیبانی، Search داخلی، داده فروش و مشاهده واقعی بسازید. خواسته Stakeholder یک Input است، نه نماینده قطعی کاربر.
اشتباه ۲: شروع از رنگ و Component پیش از محتوا
وقتی Message، Object، Action و State مشخص نیست، Wireframe به ظرف Lorem ipsum تبدیل میشود. ابتدا Content model و جریان تصمیم را بسازید:
- کاربر چه Entity یا گزینههایی میبیند؟
- برای تصمیم چه Attribute و Evidence لازم است؟
- Primary action و Secondary action چیست؟
- در Empty، Error، Loading، Permission و Success چه میشود؟
- مالک بهروزرسانی داده چه کسی است؟
Design system پس از این قرارداد، Componentهای تکرارپذیر میدهد؛ قرار نیست مسئله محصول را بهجای تیم حل کند.
اشتباه ۳: پیام مبهم یا وعده اغراقآمیز
تیترهایی مانند «آینده کسبوکار شما را میسازیم» یا «بهترین تجربه دیجیتال» مخاطب، مسئله، خروجی و مرز خدمت را پنهان میکنند.
| عنصر | سؤال | ضدالگو |
|---|---|---|
| Audience | برای چه کسی؟ | همه کسبوکارها |
| Problem/job | چه نیاز مشخصی؟ | رشد و موفقیت |
| Outcome | چه خروجی قابل فهمی؟ | تحول بینظیر |
| Mechanism | چطور/با چه Scope؟ | راهکار جامع |
| Evidence | چرا باورپذیر؟ | Badge یا عدد بیمنبع |
| Next step | اکنون چه کند؟ | CTA عمومی «بیشتر» |
صفحه اصلی محل شرح همه جزئیات نیست؛ باید Orientation، مسیر و Evidence کافی بدهد. چارچوب Message، Navigation و Conversion در راهنمای طراحی صفحه اصلی کامل شده است.
اشتباه ۴: سلسلهمراتب دیداری بدون سلسلهمراتب تصمیم
فونت بزرگتر الزاماً عنصر مهمتر برای Task نیست. Contrast، اندازه، Position، Whitespace، Grouping و ترتیب DOM باید به سؤالهای کاربر پاسخ دهند: کجا هستم؟ چه چیزی مهم است؟ وضعیت چیست؟ چه اقدامی ممکن است؟
| علامت | Failure | اصلاح |
|---|---|---|
| سه CTA همرنگ و هماندازه | Primary action نامعلوم | Action hierarchy |
| Cardهای شبیه تبلیغ | Banner blindness | Content/label واقعی |
| Text خاکستری کمرنگ | خوانایی/Contrast | Token و WCAG test |
| Spacing نامنظم | رابطه گروهها مبهم | Layout/spacing scale |
| Status فقط با رنگ | معنا برای همه منتقل نمیشود | Text/icon/semantics |
اشتباه ۵: CTA بیشتر را معادل Conversion بیشتر دانستن
تعداد ثابت «یک CTA» یا «سه CTA» نداریم. یک Primary action میتواند در طول صفحه تکرار شود و Secondary action برای کاربر ناآماده وجود داشته باشد؛ مشکل وقتی است که Actionها هدف متفاوت، پیام ناسازگار یا وزن یکسان دارند.
قرارداد CTA
- Label نتیجه را بگوید: «دریافت پیشفاکتور»، نه «ارسال».
- پس از کلیک، Destination و Commitment مطابق انتظار باشد.
- Disabled state علت و راه رفع داشته باشد؛ کنترل لازم بیدلیل غیرفعال نشود.
- Loading از Double submit جلوگیری و Progress را اعلام کند.
- Success نتیجه، Reference و قدم بعدی را نشان دهد.
- Cancel/Back داده را ناخواسته نابود نکند.
اشتباه ۶: صفحه اصلی را انبار همه درخواستها کردن
Carousel چندپیامی، Logo wall طولانی، همه خدمتها، آخرین خبر، همه آمار و چند فرم میتوانند Orientation را از بین ببرند. هر Module باید Job، Audience، Owner و Metric داشته باشد. چیزی که فقط بهدلیل فشار داخلی اضافه شده، باید از Task test عبور کند.
اشتباه ۷: Navigation براساس ساختار سازمانی
کاربر نام واحدهای داخلی، Product line تاریخی یا اصطلاحات فروش را لزوماً نمیشناسد. Label باید به زبان مخاطب و مقصد قابل پیشبینی باشد.
| کنترل | آزمون | Acceptance |
|---|---|---|
| Label | First-click/Tree test | مسیر درست و Confidence |
| Keyboard | Tab/Shift+Tab/Enter/Escape | Order، focus، close سالم |
| Mobile menu | Touch/zoom/orientation | Target و state روشن |
| Current location | Breadcrumb/active state | Orientation |
| Deep link | ورود مستقیم | Context بدون Homepage |
| Failure | 404/no result | Recovery path |
اشتباه ۸: Search و Filter بدون State و Recovery
Search فقط Input و آیکن ذرهبین نیست. Query normalization، Typo، Synonym، فارسی/عربی «ی/ک»، نیمفاصله، رقم، Finglish برند، Loading، Zero result، Facet، Sort، URL state و Back navigation بخشی از تجربهاند.
| State | باید نشان دهد | نباید |
|---|---|---|
| Loading | Progress و حفظ Context | صفحه سفید |
| Results | Query، count و Active filter | نتیجه بدون علت |
| Zero | اصلاح Query/حذف Filter/مسیر جایگزین | «یافت نشد» بنبست |
| Error | مشکل Service و Retry امن | سرزنش Query |
| No inventory | وضعیت واقعی و alternative | محصول ناموجود شبیه موجود |
اشتباه ۹: موبایل را نسخه کوچکشده Desktop دانستن
Responsive بودن Layout بهتنهایی Task را Mobile-friendly نمیکند. صفحهکلید مجازی، ورودی لمسی، شبکه، Orientation، Safe area، Sticky element، Zoom، دوربین/آپلود و انتقال به درگاه باید در Context واقعی تست شوند.
| Failure موبایل | نشانه | اصلاح |
|---|---|---|
| Target کوچک/فشرده | Tap اشتباه | اندازه و فاصله کافی |
| Keyboard نامناسب | تغییر مداوم صفحهکلید | Input type/mode درست |
| Sticky overlap | CTA/Focus/Error پنهان | Viewport/scroll test |
| Table overflow | ستون ضروری خارج دید | Responsive table/priority |
| Modal تمامصفحه | Back/close نامعلوم | Focus/escape/history contract |
| Upload سنگین | Timeout یا مصرف داده | Limit/compress/progress/retry |
WCAG ۲.۲ معیار AA حداقل Target را با قاعده ۲۴×۲۴ CSS pixel و استثناهای مشخص تعریف میکند؛ این عدد را با توصیههای بزرگتر Touch target در Design system خود اشتباه نگیرید. مسیر کامل Device/Viewport/Input/Content/Performance/SEO در راهنمای طراحی و تست Mobile-friendly آمده است.
اشتباه ۱۰: دسترسپذیری را افزونه یا Audit آخر کار دانستن
WCAG 2.2 چهار اصل Perceivable، Operable، Understandable و Robust و معیارهای آزمونپذیر A/AA/AAA دارد. انطباق فقط Contrast نیست؛ Structure، Keyboard، Focus، Text alternative، Reflow، Label، Error، Status message و سازگاری Assistive technology را شامل میشود.
| اصل | خطای رایج | نمونه Acceptance |
|---|---|---|
| Perceivable | تصویر/ویدئو بدون جایگزین | Alt/Caption متناسب با هدف |
| Operable | منو/Modal فقط Mouse | Keyboard order، focus و close |
| Understandable | Label/Error مبهم | نام، Hint و Recovery مشخص |
| Robust | Custom control بدون Name/Role/Value | Semantic/AT test |
از معیارهای افزوده WCAG ۲.۲ میتوان به Focus Not Obscured، Dragging alternatives، Target Size Minimum، Consistent Help، Redundant Entry و Accessible Authentication اشاره کرد. برای نمونه، Focus keyboard نباید کاملاً زیر Header/Popup پنهان شود و داده قبلاً واردشده در همان Process باید—جز استثناها—Auto-populate یا قابل انتخاب باشد.
ابزار خودکار کافی نیست
W3C در راهنمای ارزیابی Accessibility میگوید هیچ ابزار منفردی نمیتواند انطباق سایت را تعیین کند و ارزیابی انسانی آگاه لازم است. ترکیب کنید:
- Lint/automated scan در CI برای Failureهای قابلتشخیص؛
- Keyboard-only و Zoom/Reflow دستی؛
- Screen reader روی Flowهای نماینده؛
- Contrast و Focus state در همه Stateها؛
- تست با کاربران دارای معلولیت و فناوری کمکی؛
- Template sampling و Retest پس از اصلاح.
Scope، نمونهگیری، WCAG-EM، Severity و Remediation در راهنمای ممیزی دسترسپذیری وب پوشش داده شده است.
اشتباه ۱۱: فرم را مجموعهای از Inputها دیدن
فرم یک مکالمه و Transaction state machine است: شروع، ورود داده، Validation، Review، Submit، Processing، Success، Failure، Retry و Resume.
| جزء | قرارداد | خطا |
|---|---|---|
| Question | چرا لازم و چگونه پاسخ داده شود؟ | فیلد بدون دلیل |
| Label | دائمی و Programmatic | Placeholder بهجای Label |
| Format | مثال و Input mode | حدسزدن فرمت |
| Required | پیش از Submit روشن | ستاره بدون توضیح |
| Validation | زمان مناسب، Client+Server | خطا فقط پس از پایان |
| Review | اطلاعات حساس/مالی قابل بررسی | Submit غیرقابل بازگشت |
| Status | Processing/Success programmatic | Spinner بیپایان |
| Recovery | داده حفظ، retry امن | پاکشدن یا Double submit |
آموزش Form در W3C WAI بر کوتاهی، پرسیدن فقط داده لازم، Label، Fieldset/Legend، Instruction، Validation، Undo/Confirm، Notification و Progress در فرم چندمرحلهای تأکید میکند.
فرم ایرانی را با داده واقعی ایران تست کنید
- نام فارسی، فاصله و نیمفاصله را بیدلیل رد نکنید.
- موبایل و کدپستی با رقم فارسی/لاتین را Normalization کنید؛ Raw value و معنای تبدیل را مدیریت کنید.
- شماره تلفن را با Country/format policy روشن بگیرید، نه Regex شکننده عمومی.
- آدرس را بر نیاز تحویل ساختیافته کنید؛ نقطه نقشه جای نشانی پستی را نمیگیرد.
- Amount تومان/ریال، Separator و واحد را کنار مقدار صریح کنید.
- OTP، CAPTCHA، درگاه و بازگشت به سایت را با Keyboard، Screen reader و Network failure تست کنید.
اشتباه ۱۲: Error message کاربر را سرزنش میکند
«مقدار نامعتبر است» نمیگوید کدام مقدار، چرا و چگونه اصلاح شود. خطا باید نزدیک Field، در Summary، با زبان Label و راه رفع نوشته شود؛ Color تنها حامل معنا نباشد.
| بد | بهتر | چرا |
|---|---|---|
| خطا ۴۲۲ | شماره موبایل را با ۱۱ رقم وارد کنید | Field و Action روشن |
| مقدار اشتباه | تاریخ پایان باید بعد از تاریخ شروع باشد | Rule روشن |
| پرداخت ناموفق | مبلغ کسر نشد/وضعیت در حال بررسی؛ دوباره پرداخت نکنید | State و Recovery |
| دسترسی ندارید | برای این درخواست نقش X لازم است؛ با Y تماس بگیرید | Problem service نه input |
GOV.UK Design System توصیه میکند Error کنار Field و در Summary نمایش داده شود، پاسخهای درست و غلط حفظ شوند و برای مشکل Service که کاربر قادر به اصلاحش نیست از Error field استفاده نشود؛ صفحه باید مسئله و اقدام بعدی را توضیح دهد.
تراکنش حساس، مرحله Review میخواهد
برای سفارش، پرداخت، درخواست رسمی یا حذف داده، خلاصه قابل بررسی، امکان اصلاح و Confirmation روشن لازم است. الگوی Check answers در GOV.UK پیش از Submit، بازبینی پاسخها را پیشنهاد میکند؛ پیادهسازی دقیق باید متناسب با ریسک و Process شما باشد.
Message، Form، Event، A/B test و کیفیت Lead در راهنمای طراحی Landing page و فرم با جزئیات بیشتری آمده است.
اشتباه ۱۳: Dark pattern را «بهینهسازی تبدیل» نامیدن
| الگو | نمونه | آسیب |
|---|---|---|
| False urgency | Timer یا موجودی ساختگی | تصمیم فریبخورده |
| Preselection | خدمت/رضایت از پیش فعال | Consent نامعتبر/هزینه |
| Confirmshaming | «نه، من رشد نمیخواهم» | فشار و بیاعتمادی |
| Hidden cost | هزینه در آخرین مرحله | شکست انتظار |
| Obstruction | ثبتنام آسان، لغو سخت | حبس کاربر |
| Roach motel | خروج/حذف پنهان | کنترل از دسترفته |
Conversion محلی ممکن است بالا برود و همزمان Complaint، Refund، Unsubscribe، RTO یا اعتماد افت کند. Guardrail و مرزهای Ethical UX در راهنمای طراحی اخلاقی و دارکپترن آمده است.
اشتباه ۱۴: اعتمادسازی با تزئین بهجای Evidence
لوگو، Badge امنیت، شمارنده مشتری و Testimonial وقتی بدون منبع، اجازه، Scope یا تاریخاند میتوانند ضداعتماد شوند. Evidence باید نزدیک Decision و قابل بررسی باشد.
| ریسک/سؤال | Evidence | Placement |
|---|---|---|
| این شرکت کیست؟ | هویت، مالکیت، تماس، آدرس | Header/Footer/About/Checkout |
| چه چیزی میخرم؟ | Scope، قیمت، محدودیت | Offer/Product |
| اگر مشکل شد؟ | Support/return/cancel/complaint | پیش از تعهد |
| آیا ادعا واقعی است؟ | Method، case، source، تاریخ | کنار ادعا |
| دادهام چه میشود؟ | Purpose، retention، control | زمان جمعآوری |
| وضعیت تراکنش چیست؟ | Reference، state، reconciliation | Success/pending/error |
Trust با نبود خطا، پاسخگویی، شفافیت و جبران ساخته میشود؛ نه فقط Seal. الگوی شواهد و Promise/Proof/Policy در راهنمای اعتماد کاربران به سایت تکمیل شده است.
اشتباه ۱۵: Performance را بعد از طراحی حل کردن
Hero video، Font متعدد، Slider، Animation، Tag و Library هرکدام هزینه شبکه، CPU و Layout دارند. Performance budget باید در Brief و Design review وجود داشته باشد.
| Metric/شاهد | چه میگوید؟ | نمیگوید |
|---|---|---|
| LCP | نمایش عنصر بزرگ اصلی | کل Task سریع است |
| INP | پاسخگویی تعاملها | علت دقیق بدون trace |
| CLS | پایداری دیداری | همه مشکلات Layout |
| RUM | تجربه کاربران واقعی | دلیل فنی بهتنهایی |
| Lab/trace | تشخیص تکرارپذیر | توزیع کاربران واقعی |
| Task metric | اثر بر نتیجه | Root cause فنی |
راهنمای Web Vitals معیارهای جاری LCP، INP و CLS را Field metric میداند، RUM اختصاصی را برای تشخیص دقیقتر توصیه میکند و Lab را جایگزین Field نمیداند. برای مخاطب ایرانی، P75 را با Device/Network/Template و Route واقعی ببینید.
چارچوب Outcome، بودجه عملکرد، Field/Lab و اولویت فنی در راهنمای سرعت سایت، UX و تبدیل آمده است.
اشتباه ۱۶: امتیاز Page experience را هدف نهایی گرفتن
Google درباره Page experience میگوید یک سیگنال واحد وجود ندارد و تمرکز بر یک یا دو Aspect کافی نیست. Core Web Vitals خوب یا امتیاز ابزار، رتبه یا Conversion را تضمین نمیکند؛ طراحی باید دسترسی امن، موبایل، محتوای اصلی متمایز، تبلیغ و Interstitial غیرمزاحم و تجربه کلی را هم بسنجد.
اشتباه ۱۷: فقط Happy path را طراحی کردن
| State | سؤال طراحی | Evidence |
|---|---|---|
| Loading | کار ادامه دارد؟ چقدر؟ Cancel؟ | Progress/status |
| Empty first-use | چگونه شروع کند؟ | Example/CTA |
| Empty no-result | چگونه Query/Filter را اصلاح کند؟ | Recovery |
| Error validation | کدام ورودی و چگونه اصلاح؟ | Inline+summary |
| Error service | Retry امن است؟ داده حفظ است؟ | Reference/owner |
| Offline/timeout | Resume یا retry چه میشود؟ | Persist/idempotency |
| Permission | چرا و از چه کسی دسترسی؟ | Role/request path |
| Partial success | چه بخش انجام/انجامنشده؟ | Item-level state |
| Success | Reference و قدم بعدی چیست؟ | Receipt/history |
Stateها باید در Design، API contract، Analytics و Support vocabulary نام یکسان داشته باشند. «خطای نامشخص» مسئولیت تیم را به کاربر منتقل میکند.
اشتباه ۱۸: فارسی و RTL را فقط Text-align دیدن
رابط فارسی دائماً متن RTL را با URL، Email، شماره کارت، کد رهگیری، SKU، نسخه نرمافزار و عبارت انگلیسی LTR ترکیب میکند. بدون Bidi isolation، ترتیب رقم، پرانتز و علائم میتواند عوض یا مبهم شود.
| داده | Direction محتمل | کنترل |
|---|---|---|
| پاراگراف فارسی | RTL | dir="rtl" lang="fa" در ساختار |
| Email/URL/code | LTR | Wrap با dir="ltr" |
| User-generated name | نامعلوم | dir="auto" یا bdi |
| عدد/مبلغ | ترکیبی | واحد، separator و reading test |
| Icon جهتدار | وابسته به معنا | Mirror بر معنا، نه خودکار همه Iconها |
راهنمای Bidi در W3C برای عبارت با جهت معلوم، Wrap دقیق و dir؛ و برای متن Runtime با جهت نامعلوم، dir="auto" یا bdi را توضیح میدهد. اسکرینشات فارسی سالم، جای تست داده ترکیبی و Copy/paste را نمیگیرد.
اشتباه ۱۹: Component سفارشی بدون قرارداد تعامل
Dropdown، Date picker، Combobox، Tabs، Modal و Toast سفارشی اغلب ظاهر خوبی دارند اما Name/Role/Value، Keyboard، Focus، Escape، Live region یا Touch behavior آنها ناقص است.
| Component | Contract حداقلی | Failure |
|---|---|---|
| Modal | Initial focus، trap مناسب، Escape، restore | Focus پشت Overlay |
| Combobox | Label، expanded، active option، keyboard | فقط Mouse |
| Tabs | Selected/controls و arrow behavior | Linkهای بیمعنا |
| Toast/status | Programmatic announcement، timeout کافی | فقط Flash بصری |
| Date picker | Text fallback و format hint | تقویم اجباری غیرقابل تایپ |
تا وقتی Native HTML Task را حل میکند، Component سفارشی هزینه تست و نگهداری اضافه دارد. Design system باید Interaction contract، State، Accessibility annotation، Example و Test را کنار Visual token نگه دارد.
اشتباه ۲۰: امنیت و حریم خصوصی را خلاف UX دانستن
امنیت ضعیف تجربه را نابود میکند، اما کنترل امنیتی نامتناسب نیز کاربر را قفل میکند. تیم Design، Product و Security باید Threat/Abuse case را با Task و Risk همزمان ببینند.
| نقطه | UX امن | ضدالگو |
|---|---|---|
| Login | Password manager/paste، MFA قابل بازیابی | منع Paste و CAPTCHA همهجا |
| Error | راهنمای مفید بدون افشای حساس | Stack trace یا Enumeration |
| Session | Warning/extend/save متناسب | Timeout ناگهانی و از دسترفتن فرم |
| Consent | Choice هموزن و purpose روشن | Accept برجسته/Reject پنهان |
| Data collection | Minimum، purpose، retention | فیلد «شاید بعداً لازم شود» |
| Sensitive action | Re-auth/confirm/review بر Risk | Friction یکسان برای همه |
راهنمای Authentication در OWASP کنترل قدرت گذرواژه، بازیابی امن، TLS، Re-authentication رویدادهای حساس، پاسخ خطا، محافظت از حمله خودکار، MFA و Logging را در یک چرخه میبیند. نسخه اجرا باید با Risk و معماری سامانه بررسی امنیتی شود.
اشتباه ۲۱: Validation سمت کاربر را کنترل امنیتی دانستن
Client-side validation بازخورد سریع UX میدهد، اما قابل دورزدن است. Server باید مستقل Validation، Authorization و Business rule را اعمال کند. OWASP Input Validation Allowlist و Validation زودهنگام در جریان داده را توصیه میکند؛ Sanitize یا Encoding جای Validation و Contextual output protection نیست.
اشتباه ۲۲: اندازهگیری را به Pageview و Click محدود کردن
| سطح | Metric | Guardrail |
|---|---|---|
| Discover | Findability/first click | Wrong path |
| Understand | Comprehension/confidence | Misinterpretation |
| Complete | Task success/time/error | Assisted completion |
| Business | Qualified lead/order kept | Refund/RTO/complaint |
| Accessibility | Blocker by flow/template | Regression |
| Reliability | Error/latency/retry | Duplicate/lost transaction |
Click روی CTA فقط Intent اولیه را نشان میدهد. اگر Form error، Lead نامرتبط، Cancel یا پرداخت تکراری را نبینید، طراحی ممکن است در Dashboard موفق و در واقعیت شکستخورده باشد.
Event dictionary بسازید
| فیلد | مثال |
|---|---|
| Event | form_submit_succeeded |
| Trigger | پاسخ موفق Server، نه Click button |
| Properties | form_id، step، error_count، experiment |
| PII policy | عدم ارسال نام/موبایل/متن آزاد |
| Owner | Product analytics |
| Reconciliation | Lead ID یا Order backend با روش امن |
اشتباه ۲۳: بازطراحی همهچیز بدون Baseline
Redesign بزرگ همزمان Message، IA، UI، URL، Performance، Tracking و Technology را تغییر میدهد. اگر همه متغیرها یکجا عوض شوند، علت نتیجه و مسیر Rollback معلوم نیست.
| قبل از Rollout | خروجی |
|---|---|
| Inventory | Page/template/component/state |
| Baseline | Task، business، accessibility، performance |
| Dependency | CMS/API/auth/payment/analytics |
| Pilot | Flow/segment نماینده |
| Acceptance | Functional+content+AT+performance |
| Migration | URL/redirect/canonical/tracking |
| Rollback | Trigger، owner، data compatibility |
اشتباه ۲۴: تحویل Design بدون State، Content و Acceptance
فایل Figma فقط تصویر State منتخب است. Hand-off باید Behavior و مرزها را مشخص کند:
- Responsive rule، min/max و overflow؛
- Default/hover/focus/active/disabled/loading/error/success؛
- Content constraint، truncation، empty و localization؛
- Keyboard، Screen reader و motion/reduced-motion؛
- API state، timeout، retry و duplicate prevention؛
- Analytics event و PII rule؛
- Acceptance test با نمونه داده فارسی/لاتین و Extremes.
اشتباه ۲۵: QA را فقط تطبیق Pixel دانستن
| QA lane | نمونه تست |
|---|---|
| Functional | Submit/retry/back/deep-link |
| Content | واقعی، طولانی، خالی، منقضی |
| Responsive | Viewport/orientation/zoom/keyboard |
| Accessibility | Keyboard/focus/name-role-value/status |
| Localization | RTL/Bidi/date/number/currency |
| Performance | Budget/trace/RUM guardrail |
| Security/privacy | permission/session/PII/log |
| Analytics | event once، property و consent |
| Resilience | timeout/offline/partial/API error |
از سه نوع Evidence استفاده کنید
| نوع | منبع | قوت | محدودیت |
|---|---|---|---|
| Behavioral quantitative | Event، funnel، search، RUM | Scale/pattern | چرایی را کامل نمیگوید |
| Behavioral qualitative | Usability، field observation | Failure و mental model | نمونه کوچک |
| Attitudinal | Interview، survey، support | نیاز/نگرانی/زبان | گفته با رفتار فرق دارد |
| Technical | Log، trace، audit، accessibility | Root cause سیستم | Outcome را تنها نمیسنجد |
Session replay و Heatmap نیز Sample و instrumentation هستند، نه ذهنخوانی. Masking، Consent، Retention، access و حذف داده حساس را پیش از ضبط طراحی کنید.
تست کاربردپذیری را با Task و Success criterion بسازید
«این صفحه را دوست دارید؟» Task test نیست. سناریو باید Goal بدهد، نه مسیر. رفتار، Success، Critical error، Time/effort، Confidence و Quote را ثبت کنید. روش Moderated/unmoderated، Sample، Facilitation و تحلیل در راهنمای تست کاربردپذیری آمده است.
| فیلد Test | نمونه |
|---|---|
| Scenario | برای تحویل هفته آینده یک محصول مناسب پیدا کنید |
| Success | Variant/price/promise درست انتخاب و توضیح داده شود |
| Critical error | انتخاب کالای ناموجود یا قیمت اشتباه |
| Observation | مسیر، backtrack، hesitation، error |
| Probe | پس از اقدام: انتظار داشتید چه شود؟ |
| Severity | task blocked/assisted/minor |
سه سناریوی ایرانی
۱. شرکت B2B با Homepage زیبا و پیام نامعلوم
Hero میگوید «تحول هوشمند برای آینده»، پنج CTA دارد و نام سه محصول داخلی را نمایش میدهد. مدیر مالی نمیفهمد محصول چه مسئلهای را برای چه اندازه شرکت حل میکند. اصلاح: مصاحبه با Leadهای برده/باخته، Message براساس Job و Constraint، یک Primary path به Demo، Secondary path به Guide و Case واقعی با Method. معیار: Comprehension و Qualified demo، نه Click خام.
۲. فروشگاه پوشاک در Checkout موبایل
انتخاب استان، شهر و آدرس با Keyboard پوشانده میشود؛ Error قرمز بدون متن است؛ بازگشت از درگاه سبد را خالی نشان میدهد. اصلاح: Input mode/label، Error summary+inline، Sticky safe، ذخیره state، Payment pending/reconciliation و جلوگیری از Double submit. معیار: Completion، field error، duplicate payment، RTO/kept order.
۳. سامانه نوبت با داده فارسی و LTR
کد پیگیری و شماره تماس داخل متن RTL بههم میریزند؛ Time-out پاسخها را پاک و Status فقط با Toast دیداری اعلام میشود. اصلاح: Bidi markup، Timeout warning/extend، Draft امن، Status message programmatic و Receipt قابل بازیابی. معیار: Task success با Keyboard/Screen reader و کاهش تماس «نوبت ثبت شد؟».
برنامه ۳۰، ۶۰ و ۹۰ روزه
| بازه | خروجی | Acceptance |
|---|---|---|
| روز ۱–۳۰ | Top task، journey/state inventory، baseline، severity backlog | Evidence و owner برای Top ۱۰ |
| روز ۳۱–۶۰ | Prototype/Pilot برای پیام، ناوبری، فرم و blockerها | Task/AT/functional test پاس |
| روز ۶۱–۹۰ | Rollout تدریجی، design-system contract، monitoring/runbook | Outcome بهتر و guardrail سالم |
روزهای ۱ تا ۳۰: مشاهده و Baseline
- سه تا پنج Top task و Flow کامل را تعریف کنید.
- Analytics، Support، Error log، Accessibility و RUM را مثلث کنید.
- با ۵ تا ۸ کاربر نماینده برای هر موج، Test کیفی آغاز کنید؛ عدد نسخه ثابت نیست.
- Stateهای Happy/error/empty/offline/permission را Inventory کنید.
- مسائل Critical و High را با Owner و Acceptance جدا کنید.
روزهای ۳۱ تا ۶۰: اصلاح کوچک و قابلسنجش
- Message و Primary path را روی یک Page/Segment Pilot کنید.
- Accessibility blocker و از دسترفتن داده را پیش از Polish رفع کنید.
- Form و Error contract را با داده ایران و Failure واقعی تست کنید.
- Performance budget و Component state را وارد Definition of Done کنید.
- Event dictionary و Guardrail را پیش از انتشار اصلاح کنید.
روزهای ۶۱ تا ۹۰: مقیاس و جلوگیری از بازگشت خطا
- Patternهای تأییدشده را به Design system منتقل کنید.
- Automated check را در CI و Manual regression را در Release gate بگذارید.
- Template/Cohort را مرحلهای Rollout و Drift را پایش کنید.
- Support/complaint و Business outcome را با Task metric Reconcile کنید.
- Owner، cadence و runbook نگهداری محتوا/Component را ثبت کنید.
چکلیست ممیزی اشتباهات طراحی سایت
- Top task، کاربر، Context و Outcome روشن است.
- Message مخاطب، مسئله، خروجی، Scope، Evidence و Next step دارد.
- سلسلهمراتب دیداری با سلسلهمراتب تصمیم همسو است.
- Navigation، Search، Filter و Deep link Recovery دارند.
- Mobile با Touch، Keyboard، Zoom، Network و Sticky element تست شده است.
- WCAG ۲.۲، Keyboard، Focus، Screen reader و Human evaluation در Scopeاند.
- Form فقط داده لازم، Label دائمی، Hint، Error و حفظ داده دارد.
- Loading، Empty، Error، Offline، Permission، Partial و Success طراحی شدهاند.
- RTL/Bidi، رقم، Email، URL، مبلغ و User-generated text تست شدهاند.
- Trust evidence واقعی، تاریخدار و نزدیک تصمیم است.
- Consent، Privacy، Authentication و Security با Risk همترازند.
- RUM، Lab، Task success، Business outcome و Guardrail تعریف شدهاند.
- Hand-off شامل State، Content constraint، Accessibility و Acceptance است.
- Redesign دارای Baseline، Pilot، Release gate و Rollback است.
- هر مشکل Owner، Severity، Evidence و Retest دارد.
پرسشهای متداول
۱. بزرگترین اشتباه طراحی سایت چیست؟
طراحی بدون Task و Outcome روشن. این خطا باعث میشود Message، Navigation، Content و Metric بر سلیقه یا درخواست داخلی ساخته شوند. در هر سایت، بزرگترین خطای اجرایی همان مانعی است که Critical task یا حق کاربر را بیشتر مسدود میکند.
۲. آیا اسلایدر صفحه اصلی همیشه بد است؟
خیر؛ حکم مطلق نداریم. اگر چند پیام را پنهان کند، کنترل Keyboard/Touch ناقص باشد، حرکت مزاحم بسازد یا Performance را خراب کند، استفادهاش باید رد شود. هدف، Evidence و Alternative سادهتر را با Task test مقایسه کنید.
۳. چند CTA در یک صفحه مناسب است؟
عدد ثابت وجود ندارد. Primary action باید مشخص باشد و Secondary action با مرحله تصمیم کاربر تناسب داشته باشد. تکرار همان CTA در صفحه طولانی میتواند مفید باشد؛ چند Action متضاد و هموزن معمولاً Decision را مبهم میکنند.
۴. آیا ابزار Accessibility برای تست کافی است؟
خیر. ابزار بخشی از Failureهای ماشینی را مییابد؛ Keyboard، Screen reader، معنی Alt/Label، Focus، جریان و تجربه واقعی به ارزیابی انسانی و تست با کاربران دارای معلولیت نیاز دارند.
۵. اول کدام مشکل طراحی را اصلاح کنیم؟
ابتدا Incident، از دسترفتن پول/داده، Security/Privacy و Accessibility blocker؛ سپس مشکلات Critical task با Severity، Frequency و Evidence بالا. Cosmetic inconsistency بدون اثر Task معمولاً پس از اینهاست، مگر اینکه بخشی از الگوی بزرگتر باشد.
جمعبندی
اشتباه طراحی سایت را با «دوست ندارم» پیدا نمیکنیم. باید Task، Context و State را ببینیم؛ Failure را با رفتار، داده، تست و Log اثبات کنیم؛ کوچکترین اصلاح را بسازیم؛ و Outcome را همراه Guardrail دوباره بسنجیم.
سایت خوب فقط در Screenshot خوب نیست. در موبایل و Keyboard، با شبکه ناپایدار و داده فارسی، هنگام خطا و بازگشت از درگاه، برای کاربر دارای معلولیت و پس از ماهها نگهداری نیز باید قابل فهم، قابل استفاده، قابل اعتماد و قابل بازیابی بماند.
