کاربر برای تماشای رابط وارد سایت نمیشود؛ میخواهد قیمت را بفهمد، محصول مناسب را پیدا کند، نوبت بگیرد، هزینه را بپردازد یا پاسخ قابلاعتمادی بگیرد. اگر صفحه زیبا باشد اما کاربر در انتخاب شهر، ورود رمز پیامکی، تشخیص ریال و تومان یا بازگشت از درگاه گیر کند، وبسایت کاربرپسند نیست. معیار اصلی «کامل شدن کار درست در شرایط واقعی» است، نه تعداد افکتها، کوتاهی منو یا سلیقه طراح.
این راهنما طراحی سایت کاربرپسند را به یک قرارداد قابلآزمون تبدیل میکند: ابتدا User، Context و Task را با شواهد تعریف میکنیم؛ سپس Journey، معماری اطلاعات، محتوا، UI state، فرم، Responsive، Performance، Accessibility و Trust را میسازیم؛ در پایان با Usability test، Telemetry و ماتریس پذیرش تصمیم میگیریم آیا تجربه آماده انتشار است. اگر دنبال تصویر کلی رشته UX هستید، راهنمای طراحی تجربه کاربری مرجع کاملتری است؛ این مقاله مالک پذیرش عملی یک وبسایت در سطح Task است.
وبسایت کاربرپسند دقیقاً چیست؟
کاربرپسندی صفت ثابت یک رابط نیست. یک سامانه برای کاربر مشخص، هدف مشخص و Context مشخص میتواند قابلاستفاده باشد و برای فرد یا موقعیت دیگر نباشد. استاندارد ISO 9241-11:2018 Usability را Outcome استفاده میداند و بر User، Goal و Context تکیه دارد. بنابراین جمله «سایت ما ساده است» تا زمانی که Task، کاربران و شواهد تعریف نشدهاند، ادعاست نه نتیجه.
| مفهوم | پرسش اصلی | شاهد قابلقبول | خطای رایج |
|---|---|---|---|
| Usability | کاربر هدف میتواند کار را درست، با هزینه معقول و رضایت انجام دهد؟ | Task success، خطای بحرانی، زمان/تلاش، مشاهده و گزارش کاربر | یکی دانستن آن با زیبایی |
| UX | تجربه پیش، حین و پس از تعامل چگونه است؟ | Journey، اعتماد، انتظار، احساس و Outcome در کانالهای مختلف | محدود کردن UX به یک صفحه |
| UI | کنترلها، محتوا و Stateها چگونه ارائه و تعامل میشوند؟ | Design system، Prototype، QA بصری و تعاملی | فرض اینکه UI زیبا خودبهخود UX خوب میسازد |
| Accessibility | افراد با تواناییها و ابزارهای متفاوت میتوانند محتوا و کارکرد را درک و کنترل کنند؟ | WCAG، تست Keyboard/Screen reader/Zoom و پژوهش فراگیر | واگذاری کامل به اسکنر خودکار |
| Conversion | Outcome مطلوب کسبوکار رخ میدهد؟ | سفارش سالم، Lead واجدشرایط یا تمدید؛ همراه Guardrail | بهینهسازی کلیک با فریب یا حذف اطلاعات |
سه بُعد Effectiveness، Efficiency و Satisfaction نقطه شروع خوبیاند، اما در کارهای مالی، سلامت، هویت یا حذف داده باید Safety، Recovery، Accessibility و Trust نیز معیار پذیرش باشند. «کمترین کلیک» قانون نیست: یک مرحله تأیید اضافه برای انتقال پول یا حذف حساب میتواند خطای پرهزینه را کم کند. طراحی خوب Friction بیفایده را حذف میکند و Friction محافظ را آگاهانه نگه میدارد.
پیش از Wireframe، قرارداد Task بنویسید
صفحهمحور فکر کردن باعث میشود تیم Home، Product و Checkout بسازد اما پیوستگی کار را نبیند. واحد طراحی و آزمون باید Task باشد. برای هر کار بحرانی یک Task contract بنویسید و آن را به نیاز کاربر، Outcome کسبوکار و معیار پذیرش متصل کنید.
| فیلد قرارداد | نمونه فروشگاه ایرانی | پرسش پذیرش |
|---|---|---|
| Actor و Context | خریدار بازگشتی با موبایل میانرده و اینترنت ناپایدار | آیا نمونه آزمون واقعاً این Context را دارد؟ |
| Trigger | نیاز فوری به هدیه تا فردا | آیا وعده ارسال قبل از Commit روشن است؟ |
| Goal و Done | سفارش پرداختشده با کد پیگیری و زمان تحویل | Done در UI، Backend و پیام کاربر یکسان است؟ |
| Input و Dependency | آدرس، کدپستی، موجودی، درگاه و پیامک | در خرابی هر Dependency چه Stateی دیده میشود؟ |
| Happy path | یافتن، مقایسه، افزودن، پرداخت و تأیید | آیا بدون راهنمای Moderator کامل میشود؟ |
| Exception | تأخیر پیامک، اتمام موجودی یا Callback مبهم | کاربر میفهمد چه شده و چگونه بازیابی کند؟ |
| Consequence | پول کسر میشود یا اطلاعات هویتی ثبت میشود | تأیید، Undo، Audit و پشتیبانی متناسباند؟ |
| Evidence و Owner | تست Task، تیکت پشتیبانی و Funnel سفارش | چه کسی و در چه تاریخ تصمیم را بازبینی میکند؟ |
برای نمونه، «صفحه ثبتنام را ساده کنیم» Requirement مناسبی نیست. نسخه قابلآزمون چنین است: «کاربر جدید با شماره موبایل معتبر، در شبکه کند، باید بتواند بدون از دست رفتن ورودی پس از تأخیر SMS حساب بسازد؛ پیام وضعیت و مسیر ارسال مجدد باید روشن باشد و Duplicate account ساخته نشود.» اکنون طراحی، مهندسی، QA و Analytics درباره یک Outcome مشترک حرف میزنند.
کارهای بحرانی را با Risk اولویتبندی کنید
همه Taskها ارزش آزمون برابر ندارند. Frequency، ارزش برای کاربر، پیامد شکست، میزان ابهام و حجم تماس پشتیبانی را امتیاز دهید. پرداخت، ورود، بازیابی حساب، رزرو، لغو و مرجوعی معمولاً از صفحه «درباره ما» ریسک بیشتری دارند. فهرست Critical task باید کوتاه، دارای Owner و نسخه باشد؛ وگرنه به Backlog بیانتها تبدیل میشود.
نیاز کاربر را از شواهد بسازید، نه از Persona تزئینی
نام خیالی، عکس استوک و سن بهتنهایی تصمیم طراحی نمیسازند. بخشبندی باید تفاوت رفتاری یا محدودیتی را نشان دهد که روی Task اثر میگذارد: تازهکار یا حرفهای، دسترسی فقط با موبایل، استفاده از Screen reader، خرید برای دیگری، حساسیت به قیمت، اینترنت ناپایدار یا نیاز به سند رسمی. راهنمای GOV.UK درباره یادگیری نیازهای کاربر توصیه میکند مشاهده، مصاحبه، Analytics، Search log و داده مرکز تماس را بهکار ببریم و نظرهای بدون شاهد را فرضیه بدانیم.
| منبع Evidence | چه چیزی میآموزیم؟ | محدودیت | خروجی تصمیمپذیر |
|---|---|---|---|
| مصاحبه و مشاهده | هدف، زبان، workaround و Context | گزارش رفتار همیشه معادل رفتار واقعی نیست | Need، Task و سؤال پژوهش |
| Search و Support log | واژه کاربر و Failure پرتکرار | فقط کاربران/مشکلات ثبتشده را میبیند | Label، FAQ، Recovery و اولویت |
| Analytics | کجا و برای چه Segmentی افت رخ میدهد | چرایی را بهتنهایی نمیگوید | Funnel و فرضیه تشخیصی |
| Usability test | فهم، رفتار، خطا و مدل ذهنی در Task | برآورد نرخ جمعیت از نمونه کوچک معتبر نیست | Issue، Severity و Design change |
| Accessibility audit | مانع فنی و تجربی برای روشهای ورودی متفاوت | ابزار خودکار همه Criteria یا تجربه را پوشش نمیدهد | Defect، معیار پذیرش و Regression test |
برای هر Need، Source، تاریخ، Segment، Confidence و تصمیم مرتبط را نگه دارید. «کاربر سرعت میخواهد» مبهم است؛ «خریدار موبایلی هنگام بازگشت از درگاه نمیداند سفارش ثبت شده یا نه و با Refresh سفارش دوم میسازد» مستقیماً State، Copy و Idempotency را تغییر میدهد.
Journey را از Trigger تا Recovery ببینید
وبسایت فقط بخشی از خدمت است. کاربر ممکن است از گوگل وارد شود، در سایت قیمت ببیند، با تلفن سؤال کند، در درگاه پرداخت شود و پیامک دریافت کند. راهنمای طراحی خدمت GOV.UK بر توانایی انجام کار از ابتدا تا انتها تأکید دارد. اگر هر کانال پیام متفاوتی بدهد، بهترین UI نیز تجربه را نجات نمیدهد.
| مرحله | سؤال کاربر | Frontstage | Backstage/Truth | Failure مهم |
|---|---|---|---|---|
| Discover | این گزینه برای من مناسب است؟ | نتیجه جستوجو و Landing | Catalog و Eligibility | وعدهای که صفحه مقصد تأیید نمیکند |
| Understand | قیمت، شرط و تفاوت چیست؟ | محتوا، مقایسه و Help | Price/Policy source | ریال/تومان یا هزینه نهایی مبهم |
| Commit | اگر ادامه بدهم چه میشود؟ | فرم، CTA و Summary | Validation و Availability | تغییر ناگهانی شرط یا موجودی |
| Complete | کار واقعاً انجام شد؟ | Success/Pending/Error | Order/Payment state | موفقیت ظاهری با ثبت Backend ناموفق |
| Recover | چطور اصلاح، لغو یا پیگیری کنم؟ | History، Undo و Support | Workflow و Audit | بنبست یا تکرار تراکنش |
Service blueprint برای هر گام، Touchpoint، داده مرجع، Dependency و Owner را نشان میدهد. این ابزار مرز بین «مشکل رابط» و «مشکل عملیات» را روشن میکند. وقتی وضعیت سفارش در انبار و سایت هماهنگ نیست، تغییر رنگ دکمه درمان نیست.
معماری اطلاعات و ناوبری باید Findability بسازند
کاربر ساختار سازمان شما را نمیشناسد. منویی که بر اساس واحدهای داخلی یا واژههای تخصصی ساخته شده، هزینه ترجمه ذهنی ایجاد میکند. ابتدا Top task و زبان واقعی کاربر را استخراج کنید؛ سپس Navigation، Search، Category، Breadcrumb و Cross-link را بهعنوان چند مسیر مکمل بسازید. جزئیات روش Card sort، Tree test و Label governance در راهنمای معماری اطلاعات سایت آمده است.
Label باید پیشبینیپذیر باشد
«راهکارها»، «خدمات ویژه» یا آیکون بدون متن ممکن است برای تیم داخلی روشن و برای کاربر مبهم باشد. Label خوب با واژهای که کاربر جستوجو یا بیان میکند همراستاست، مقصد را پیشبینیپذیر میسازد و در Contextهای مختلف یک معنا دارد. Navigation را با Tree test و Task واقعی بسنجید، نه با پرسش «این منو را دوست دارید؟».
Search و No-results بخشی از ناوبریاند
جستوجوی داخلی باید Unicode فارسی، فاصله و نیمفاصله، املای رایج، مترادف و در صورت نیاز Finglish را مدیریت کند. صفحه صفر نتیجه نباید بنبست باشد: Query را نگه دارد، اصلاح پیشنهادی و Category مرتبط نشان دهد و امکان درخواست کمک بدهد. Query log نیز ورودی ارزشمندی برای Content و Taxonomy است، به شرط حفظ حریم خصوصی.
محتوا بخشی از رابط است
عنوان، Label، Helper text، پیام خطا و Confirmation همگی Interaction را هدایت میکنند. متن کوتاه همیشه بهتر نیست؛ متن باید در لحظه تصمیم، پاسخ کافی و قابلاسکن بدهد. اطلاعات پرریسک مثل قیمت نهایی، تمدید خودکار، زمان ارسال و محدودیت لغو را پشت Tooltip یا متن خاکستری پنهان نکنید.
| عنصر | نسخه مبهم | نسخه تصمیمپذیر | معیار QA |
|---|---|---|---|
| CTA | ادامه / ثبت | پرداخت ۸۹۰ هزار تومان | عمل و پیامد روشن است |
| Label | شماره | شماره موبایل دریافتکننده | هدف بدون Placeholder فهمیده میشود |
| Helper | فرمت صحیح وارد کنید | کدپستی ۱۰رقمی، بدون خط تیره | فرمت قبل از خطا مشخص است |
| Error | خطای ۴۲۱ | پرداخت تأیید نشد؛ پول کسر شده؟ وضعیت را بررسی کنید | علت معلوم/نامعلوم و اقدام بعدی روشن است |
| Success | موفق بود | سفارش ۱۴۰۵۲ ثبت شد؛ زمان ارسال شنبه و مسیر پیگیری اینجاست | Outcome و Reference قابلبازیابی است |
برای فارسی، طول متن، نیمفاصله، اعداد فارسی/لاتین، واحد پول، تاریخ شمسی/میلادی و ترکیب رشتههای راستبهچپ و چپبهراست را در Fixtureهای QA نگه دارید. Design فقط با Lorem ipsum، شکست واقعی Label و Wrap را نشان نمیدهد.
هر تعامل، مجموعهای از UI Stateهاست
Mockup معمولاً Default state را نشان میدهد؛ شکستها در Stateهای دیگر رخ میدهند. برای هر Component و Task حداقل Loading، Empty، Partial، Valid، Invalid، Disabled، Permission denied، Offline، Timeout، Conflict، Success، Pending و Recoverable/terminal error را تعریف کنید.
| State | کاربر باید بداند | رفتار سیستم | Recovery |
|---|---|---|---|
| Loading | درخواست دریافت شده و چه چیزی منتظر است | از ارسال تکراری جلوگیری؛ Focus بیدلیل جابهجا نشود | Timeout و Retry امن |
| Empty | چرا چیزی نیست | فرق First-use، No-result و No-permission روشن باشد | Create، اصلاح فیلتر یا Help |
| Invalid | کدام مقدار چرا رد شد | ورودی سالم حفظ و خطا به Field متصل شود | مثال و مسیر اصلاح |
| Pending | نتیجه هنوز قطعی نیست | Status واقعی از Backend خوانده شود | Check status بدون ایجاد درخواست دوم |
| Conflict | قیمت/موجودی/داده تغییر کرده | آخرین truth و اثر تغییر نشان داده شود | بازبینی و Confirm آگاهانه |
| Error | چه میدانیم، چه نمیدانیم و اثر چیست | کد رهگیری برای Support؛ داده حساس لو نرود | Retry، alternative، Undo یا تماس |
Feedback باید نزدیک اقدام، بهموقع و پایدار باشد. Toastی که پیش از خواندن محو میشود، تنها با رنگ وضعیت را نشان میدهد یا برای Screen reader اعلام نمیشود، Feedback کافی نیست. در اقدامهای پرپیامد، Preview/Review، Confirm صریح و امکان Undo یا Recovery را متناسب با Risk طراحی کنید.
فرم کاربرپسند: ورودی کمتر، خطای قابلاصلاح
فرم کوتاهتر معمولاً بار کمتری دارد، اما هدف «حداقل Field لازم برای Outcome و تعهد قانونی» است؛ نه حذف دادهای که بعداً کاربر را مجبور به تماس میکند. هر Field باید Purpose، Owner، Retention و وضعیت Required/Optional روشن داشته باشد. راهنمای رسمی فرمهای دسترسپذیر W3C بر Label، Instruction، Validation، Notification، تقسیم منطقی فرم طولانی و زمان کافی تأکید میکند.
قرارداد Field و Validation
- Label پایدار و متصل به Control باشد؛ Placeholder جای Label نیست.
- فرمت و محدودیت پیش از ورود گفته شود و Validation فقط سمت Client نباشد.
- ورودی معقول را forgiving بپذیرید؛ مثلاً فاصله یا خط تیره را برای شماره پاکسازی کنید، اما مقدار نهایی را شفاف نشان دهید.
- پس از خطا دادههای درست حفظ، Summary خطا در بالا و پیام اختصاصی کنار Field ارائه شود.
- خطا با متن و نشانه، نه صرفاً رنگ، بیان و Focus بهصورت قابلپیشبینی مدیریت شود.
- Autocomplete و input type مناسب را بهکار ببرید و Paste یا Password manager را بیدلیل مسدود نکنید.
سناریوهای ویژه ایران
شماره موبایل با ۰۹ یا +۹۸، کدپستی ۱۰رقمی، استان/شهر، پلاک/واحد، نام فارسی، تاریخ شمسی، ارقام فارسی و لاتین و واحد پول را با داده واقعی تست کنید. رشتههایی مانند شماره پیگیری، ایمیل، URL و SKU در متن RTL به کنترل Bidirectional نیاز دارند؛ راهنمای جهت متن در HTML از W3C استفاده از dir مناسب در سطح سند و عناصر را توضیح میدهد. Copy/paste و خواندن Screen reader را هم بیازمایید؛ ظاهر صحیح بهتنهایی کافی نیست.
Responsive یعنی تداوم Task، نه نسخه کوچک Desktop
تجربه لازم نیست در همه دستگاهها یکسان باشد؛ باید Outcome و اطلاعات حیاتی معادل بماند. در موبایل میتوان ترتیب، Density یا کنترل را تغییر داد، اما قیمت، شرط، امکان لغو یا Recovery نباید ناپدید شود. راهنمای تخصصی طراحی ریسپانسیو قرارداد Breakpoint و QA را عمیقتر پوشش میدهد.
| محور آزمون | نمونه | قبولی |
|---|---|---|
| Viewport و Orientation | موبایل باریک، Landscape، Tablet و Desktop | بدون گمشدن محتوا/عمل یا Scroll دوبعدی ناخواسته |
| Zoom و Text resize | Zoom مرورگر و افزایش متن | Reflow، خوانایی و دسترسی به کنترلها حفظ شود |
| Input | Touch، Keyboard، Mouse و Voice | هیچ Taskی به Hover یا Gesture پیچیده منحصر نباشد |
| Content stress | نام بلند، قیمت بزرگ، خطا و ترجمه | Wrap و Layout بدون حذف معنا کار کند |
| Continuity | شروع با موبایل و ادامه در Desktop | State، Draft و Reference با Consent قابلبازیابی باشد |
Breakpoint را از شکست Content و Task استخراج کنید، نه از مدل تلفنهای مشهور. ماتریس دستگاه باید با داده واقعی مخاطبان و ریسک انتخاب شود؛ حداقل یک دستگاه ضعیفتر، مرورگرهای اصلی، Keyboard-only و اتصال کند/قطعووصل را پوشش دهید.
Performance را در مسیر کاربر اندازه بگیرید
سرعت فقط نمره Lighthouse یا زمان Home نیست. باید Loading، Responsiveness و Visual stability صفحههای بحرانی و تعاملهای پس از Load را در Field و Lab ببینید. راهنمای Core Web Vitals در web.dev معیارهای LCP، INP و CLS را و سنجش Field در صدک ۷۵، جدا برای Mobile و Desktop، توضیح میدهد. این معیارها مهماند، اما کل Usability یا زمان تکمیل Task را نمایندگی نمیکنند.
| لایه | معیار | پرسش تشخیصی | Guardrail |
|---|---|---|---|
| Field page | p75 LCP/INP/CLS به تفکیک Segment | کاربران واقعی چه تجربهای دارند؟ | نمونه، Geography و Device mix را ببینید |
| Lab | Waterfall، Long task، Image/JS/CSS budget | کدام Resource یا Thread گلوگاه است؟ | یک اجرای شبیهسازیشده نماینده همه کاربران نیست |
| Task | زمان تا امکان اقدام، Submit latency و Recovery | آیا کاربر میتواند کار را بیابهام ادامه دهد؟ | Skeleton نباید محتوای دروغین یا Layout shift بسازد |
| Business | Success، abandonment و تماس مرتبط با کندی | بهبود فنی به Outcome کمک کرد؟ | همبستگی را علت فرض نکنید |
برای مخاطب ایرانی، Probe را از چند ISP، شبکه موبایل/ثابت، Cache سرد/گرم و مسیرهای داخلی/خارجی اجرا کنید. Timeout در SMS، نقشه، CAPTCHA، Analytics یا درگاه را بهعنوان Dependency failure تست کنید. راهنمای سرعت سایت و اثر تجاری برای Budget، Observability و تشخیص عمیقتر است.
Accessibility یک Quality gate است
دسترسپذیری افزونه پایان پروژه یا لطف به گروهی حاشیهای نیست؛ بخشی از کیفیت محصول برای تنوع دیداری، حرکتی، شنوایی، شناختی و موقعیتی است. WCAG 2.2 معیارهای قابلآزمونی مانند Text alternative، Keyboard، Focus، Contrast، Reflow، Target size، Error identification و Accessible authentication دارد؛ اما انطباق استاندارد نیز همه نیازهای انسانی را پوشش نمیدهد.
پشته آزمون دسترسپذیری
- Semantic HTML، Heading و Landmark را پیش از ARIA درست کنید.
- Lint و اسکن خودکار را برای خطاهای قابلکشف در CI اجرا کنید.
- Keyboard-only: ترتیب Focus، Focus visible، Modal، Menu، فرم و خروج از Component.
- Zoom/Reflow، Contrast، Color independence، Reduced motion و Forced colors را بررسی کنید.
- Screen reader روی Taskهای بحرانی؛ Name/Role/Value و Announcement تغییر State.
- آزمون با کاربران دارای نیاز دسترسی، مخصوصاً برای تصمیمهای پرریسک و کنترلهای سفارشی.
برای تصویر Informative، Alt باید Purpose تصویر را در Context منتقل کند؛ تصویر تزئینی معمولاً alt="" میخواهد، نه توضیح اجباری. Chart پیچیده به توضیح یا داده معادل نیاز دارد. Accessibility را با Severity، Owner، Deadline و Regression test مدیریت کنید. برای Governance کاملتر، راهنمای طراحی فراگیر و WCAG را ببینید.
اعتماد را با شفافیت و اختیار بسازید
رنگ آبی تضمین اعتماد نیست. Trust از همخوانی ادعا و واقعیت، قیمت و شرایط روشن، هویت و مسیر تماس، امنیت متناسب، کنترل کاربر و Recovery قابلپیگیری شکل میگیرد. گزارش FTC درباره Dark patterns الگوهای فریبندهای را بررسی میکند که انتخاب کاربر را منحرف یا دشوار میکنند.
| ریسک | الگوی مخرب | طراحی سالم | Guardrail سنجش |
|---|---|---|---|
| قیمت | افزودن هزینه در آخر مسیر | مبلغ و اجزای آن پیش از Commit | شکایت، Refund و فهم قیمت |
| رضایت | Opt-in پیشفرض یا دکمه نامتقارن | انتخاب آزاد، متن مشخص و Withdraw آسان | Consent validity، نه فقط opt-in rate |
| لغو | ثبت آنلاین و لغو فقط با تماس | مسیر لغو متناسب، اثر و زمان روشن | زمان/خطای لغو |
| فوریت | Countdown یا موجودی ساختگی | فقط Claim قابلاثبات و منبع وضعیت | Audit ادعا و شکایت |
| حذف | CTA مبهم و بدون Undo | Preview، Confirm متناسب و Recovery | حذف ناخواسته و Restore success |
بهینهسازی Conversion بدون Guardrail میتواند کلیک را بالا و اعتماد، کیفیت Lead یا سفارش سالم را پایین بیاورد. جزئیات بیشتر در راهنمای طراحی اخلاقی و Dark pattern آمده است.
Usability test باید Task و رفتار را بسنجد
در تست کاربردپذیری از کاربر نپرسید «این صفحه خوب است؟»؛ سناریوی واقعگرایانه بدهید و ببینید چگونه کار را انجام میدهد. راهنمای تست تعدیلشده GOV.UK بر شرکتکننده واقعی یا محتمل، Task مشخص و مشاهده فهم و تکمیل کار تأکید میکند.
| جزء Study | تعریف | خطر سوگیری | خروجی |
|---|---|---|---|
| Research question | مثلاً کاربر وضعیت پرداخت مبهم را میفهمد؟ | اثبات طرح دلخواه | پرسش تصمیمساز |
| Participant | Segment و Context مرتبط | همکار، کاربر حرفهای یا نمونه راحت | Screener و Consent |
| Task | Goal و اطلاعات لازم، بدون لو دادن مسیر | استفاده از واژه همان Label | Scenario و success criteria |
| Observation | مسیر، مکث، خطا، کمک و Recovery | تفسیر نیت بدون شاهد | Note با Timestamp/Evidence |
| Severity | Impact × Frequency evidence × Persistence × Risk | رأی سلیقهای تیم | Issue و اولویت |
| Decision | Fix، test، defer یا accept risk | فهرست Insight بدون Owner | Owner، Deadline و Retest |
عدد «پنج کاربر» قانون جهانی نیست. اندازه و ترکیب نمونه به ناهمگونی Segmentها، پیچیدگی Task، ریسک تصمیم، روش و هدف Study بستگی دارد. تست کوچک تکرارشونده برای کشف مسئله مفید است، اما درصد مشاهدهشده در نمونه کوچک را نرخ کل جامعه معرفی نکنید. پروتکل Recruit، Facilitation، تحلیل و Ethics در راهنمای تست کاربردپذیری بهتفصیل آمده است.
کاربرپسندی را با چند سیگنال مکمل بسنجید
Bounce rate یا Dwell time بهتنهایی نه اثبات UX بد است و نه میانبُر رتبهگیری. ممکن است کاربر پاسخ را در یک صفحه بگیرد و خارج شود، Tracking ناقص باشد یا Session timeout نتیجه را تغییر دهد. Measurement باید از Task به Event و از Event به Outcome قابلردگیری باشد و Privacy را رعایت کند.
| لایه | نمونه معیار | تعریف لازم | Guardrail |
|---|---|---|---|
| Effectiveness | Task success و Correct outcome | Done واقعی در Backend، نه کلیک CTA | تقلب/تکرار/لغو بعدی |
| Error | Critical error و Recovery success | Taxonomy و Severity ثابت | خطای خاموش و تماس خارج کانال |
| Efficiency | Time on task، Step و Help | Start/stop و Segment روشن | سرعت نباید Safety را قربانی کند |
| Perception | Ease rating و Confidence | پرسش و زمان ثابت | گزارش خوداظهاری را با رفتار ترکیب کنید |
| Experience | Abandonment، Return و Support contact | Reason code و Channel reconciliation | علت را فقط از Funnel حدس نزنید |
| Quality | A11y defect، CWV و State coverage | Version، Device و Environment | Pass فنی جای Outcome انسانی نیست |
| Business | Kept order یا Qualified lead | Window و Eligibility | Refund، شکایت، رضایت و Consent |
Event dictionary باید نام Event، Trigger، Preconditions، Properties مجاز، PII policy، Owner و نسخه را ثبت کند. تغییر UI را Annotation بزنید و قبل/بعد را با Seasonality، Campaign و Mix کاربران تفسیر کنید. برای ترکیب داده کمی و کیفی و طراحی Experiment، راهنمای UX مبتنی بر داده را ببینید.
ماتریس پذیرش طراحی سایت کاربرپسند
«تأیید UX» نباید امضای سلیقهای در پایان Sprint باشد. برای هر Critical task، معیار قابلتکرار، محیط آزمون، Evidence، Threshold، Owner و تصمیم Release تعریف کنید. Thresholdها را براساس Baseline، ریسک و ظرفیت تیم تعیین کنید؛ اعداد زیر قالباند، نه استاندارد عمومی.
| Gate | Scope نمونه | Evidence | Release rule نمونه |
|---|---|---|---|
| Need/Task | Task contract و Segment | Research/source log | هیچ Requirement بحرانی بدون شاهد/فرضیه برچسبخورده نیست |
| Content/IA | Label، Findability و Critical copy | Tree/Task test و review | بنبست شناختهشده Critical رفع یا Risk پذیرفته شود |
| State/Form | Happy path و Exception | State inventory و automated/manual test | Data loss یا Duplicate action بحرانی صفر |
| Responsive | Device/Input/Content matrix | QA run با Environment ثبتشده | Outcome معادل در Scope پشتیبانیشده |
| Accessibility | WCAG target و Critical task | Automation + manual + AT/user test | Blocker حل؛ Exception مستند و زماندار |
| Performance | Critical page و interaction | Lab budget + Field baseline | Regression خارج Budget متوقف یا Risk پذیرفته شود |
| Usability | Representative participant/task | Recording/note، success و issue | خطای بحرانی حل و Retest شود |
| Trust/Safety | Price، Consent، Commit و Recovery | Legal/security/ethics review | فریب، ابهام مالی یا اقدام برگشتناپذیر پنهان وجود ندارد |
| Observability | Outcome، Error و Dependency | Event QA و dashboard | تیم پس از Release شکست را میبیند و Runbook دارد |
Release میتواند Pass، Conditional pass با Owner/Deadline، یا Fail باشد. استثنا باید Scope، دلیل، اثر، اقدام جبرانی و تاریخ انقضا داشته باشد. این Governance مانع تبدیل «موقت» به بدهی دائمی میشود.
سناریوهای ایرانی که باید در QA باشند
| سناریو | شکست محتمل | آزمون | طراحی/Recovery |
|---|---|---|---|
| ریال و تومان | برداشت دهبرابری یا ناسازگاری Cart/درگاه | قیمت بزرگ، تخفیف، جمع و رسید | واحد کنار مبلغ و Confirmation نهایی |
| شمسی/میلادی | رزرو یا اعتبار در روز اشتباه | مرز ماه/سال، Leap و Timezone | Label تقویم و Preview خوانا |
| RTL/Bidi | بههمریختن کد، شماره، ایمیل و Breadcrumb | Fixture فارسی/لاتین و Copy/paste | dir و Isolation مناسب |
| شبکه ناپایدار | ارسال تکراری یا State نامعلوم | Offline/timeout هنگام Submit و Callback | Idempotency، Pending و Check status |
| SMS دیررس | کدهای همزمان یا قفل حساب | Delay، resend و کد منقضی | Countdown واقعی، masked number و fallback |
| درگاه پرداخت | کسر پول با سفارش نامشخص | Cancel، back، refresh و callback loss | Verify server-side، وضعیت قابلپیگیری و عدم سفارش دوم |
| آدرس ایران | فیلد ناکافی یا ارسال ناممکن | استان/شهر/روستا، کدپستی، پلاک/واحد | ساختار منعطف و Validation معقول |
| وابستگی خارجی | Font، Map، CAPTCHA یا Script در دسترس نیست | Block دامنه و Timeout | Fallback و عدم توقف Critical task |
Environment آزمون را ثبت کنید: Device، OS، Browser، ISP، Network profile، Login state، Locale، Data fixture و Build. نتیجهای که فقط روی لپتاپ سریع دفتر بهدست آمده، Evidence کافی برای کاربران واقعی نیست.
برنامه ۳۰روزه از Audit تا Release
روز ۱ تا ۵: Scope و Evidence
- پنج تا ده Critical task را از Search، Analytics، Support و Stakeholder map استخراج کنید.
- برای هر Task، User/Context/Trigger/Done/Exception/Risk/Evidence/Owner بنویسید.
- Baseline برای Success، Error، Support و Performance ثبت کنید؛ شکاف Instrumentation را علامت بزنید.
روز ۶ تا ۱۲: Journey، IA و Content
- Journey/Blueprint و Source of truth هر مرحله را بسازید.
- Navigation و Labelهای حساس را با Tree/Task test بررسی کنید.
- Critical copy برای قیمت، شرط، Consent، Error، Pending، Success و Recovery را بازنویسی کنید.
روز ۱۳ تا ۲۰: State، Form و Quality
- State inventory و Failure injection برای Network، SMS، Payment و Dependency بسازید.
- فرمها را با Keyboard، Screen reader، Zoom، RTL/Bidi و داده مرزی تست کنید.
- Responsive matrix و Performance budget را روی Critical journey اجرا کنید.
روز ۲۱ تا ۲۶: پژوهش و اصلاح
- Usability test با شرکتکنندگان مرتبط و Taskهای بیطرف اجرا کنید.
- Issueها را با Severity و Evidence ترکیب، Owner تعیین و تغییرهای بحرانی را Retest کنید.
- Event dictionary و Dashboard Outcome/Error/Dependency را QA کنید.
روز ۲۷ تا ۳۰: Release و یادگیری
- ماتریس پذیرش را با Product، Design، Engineering، QA، Support و در صورت نیاز Legal/Security مرور کنید.
- Rollout مرحلهای، Guardrail، Alert، Runbook و Rollback تعریف کنید.
- هفت و سی روز بعد، Outcome، خطا، تماس و Segmentها را مرور و Assumption ledger را بهروز کنید.
چکلیست نهایی وبسایت کاربرپسند
- Critical task، User، Context، Done و پیامد شکست مستند است.
- Needها شاهد، Confidence، تاریخ و Owner دارند؛ Persona بر کلیشه جمعیتشناختی بنا نشده است.
- Journey از Trigger تا Post-completion و Recovery پوشش داده شده است.
- Navigation، Search، Label و No-results با زبان و Task واقعی آزموده شدهاند.
- محتوا قیمت، شرط، پیامد CTA و اقدام بعدی را روشن میکند.
- Loading، Empty، Invalid، Pending، Conflict، Error و Success طراحی و آزموده شدهاند.
- فرم Label، Instruction، Validation، Error summary، حفظ داده و Recovery دارد.
- RTL/Bidi، ارقام، تومان/ریال، تقویم و آدرس ایران در Fixtureهای QA هستند.
- Outcome در Mobile/Desktop و Touch/Keyboard معادل میماند.
- Performance در Field و Lab و در سطح Task، با چند مسیر شبکه، سنجیده میشود.
- Accessibility با Automation، آزمون دستی و فناوری کمکی بررسی میشود.
- قیمت، Consent، لغو و ادعا شفافاند و Dark pattern ندارند.
- Usability test با Participant و Task مرتبط انجام و Issueها Retest شدهاند.
- Measurement شامل Success، Critical error، Recovery، Perception و Guardrail است.
- Release rule، Owner، Deadline، Alert، Runbook و برنامه یادگیری مشخصاند.
پرسشهای متداول
تفاوت سایت کاربرپسند با سایت زیبا چیست؟
زیبایی میتواند فهم، اعتماد و لذت را تقویت کند، اما کاربرپسندی با انجام موفق Task در Context واقعی سنجیده میشود. سایتی میتواند زیبا باشد و بهدلیل Label مبهم، فرم شکننده یا Recovery ضعیف قابلاستفاده نباشد؛ یا ساده بهنظر برسد و Task را دقیق و امن کامل کند.
آیا کم کردن تعداد کلیک همیشه UX را بهتر میکند؟
خیر. کلیک اضافه بدون ارزش باید حذف شود، اما Review و Confirm برای پرداخت، حذف داده یا تصمیم حقوقی میتواند خطا را کم کند. معیار بهتر Success، خطای بحرانی، تلاش، فهم و Recovery است؛ نه عدد کلیک بهتنهایی.
برای تست کاربردپذیری چند کاربر لازم است؟
یک عدد ثابت برای همه Studyها وجود ندارد. تعداد به هدف، ریسک، تنوع Segmentها، پیچیدگی Task و روش بستگی دارد. مطالعه کوچک تکرارشونده برای کشف Issue مفید است؛ برای مقایسه کمی یا ادعای نرخ جمعیت به طراحی نمونه و تحلیل متناسب نیاز دارید.
آیا قبولی WCAG یعنی سایت کاملاً کاربرپسند است؟
خیر. WCAG بخش مهمی از معیارهای دسترسپذیری وب را قابلآزمون میکند، اما همه نیازهای کاربران یا کیفیت End-to-end را پوشش نمیدهد. انطباق را با تست Task، فناوری کمکی، پژوهش فراگیر، Content، Performance، Trust و Recovery ترکیب کنید.
مهمترین معیار سایت کاربرپسند چیست؟
برای هر Critical task، Correct task success مهمترین نقطه شروع است؛ سپس Critical error، Recovery، زمان/تلاش، Confidence، Accessibility، Performance و Outcome پس از تکمیل را ببینید. Metric واحد بدون Segment و Context تصویر ناقصی میدهد.
جمعبندی
طراحی سایت کاربرپسند با انتخاب رنگ یا سادهکردن ظاهری شروع نمیشود؛ با شناخت User، Context و Task آغاز میشود و با Journey، IA، Content، State، Form، Responsive، Performance، Accessibility، Trust و Recovery ادامه پیدا میکند. خروجی حرفهای یک Mockup تأییدشده نیست؛ مجموعهای از قراردادهای قابلآزمون و Evidence است که نشان میدهد کاربر میتواند Outcome درست را، حتی در شرایط نامطمئن، بهدست آورد.
از یک Task بحرانی شروع کنید: قرارداد آن را بنویسید، مسیر Happy و Failure را روی دستگاه و شبکه واقعی اجرا کنید، با کاربران مرتبط مشاهده کنید، Outcome و خطا را بسنجید و فقط پس از عبور از Gateهای کیفیت منتشر کنید. سپس همین چرخه را به Regression suite تبدیل کنید تا کاربرپسندی با هر Release دوباره اثبات شود، نه اینکه فقط یکبار ادعا شود.
