فرض کنید فردی سالمند می‌خواهد از یک سامانه اینترنتی نوبت بگیرد. اطلاعاتش را وارد می‌کند، به مرحله تایید هویت می‌رسد، اما نمی‌داند باید با کد پیامک‌شده چه کار کند. چند بار تلاش می‌کند و در نهایت از فرزندش کمک می‌خواهد.
تیم طراحی پیشنهاد می‌دهد نوشته‌ها و دکمه‌ها را بزرگ‌تر کنیم. تیم پشتیبانی هم معتقد است باید امکان تماس تلفنی را بیشتر در دسترس قرار دهیم.
اما آیا مشکل واقعا اندازه دکمه‌هاست؟ یا ما خدمتی ساخته‌ایم که کاربر در حساس‌ترین مرحله آن، اختیار انجام کارش را از دست می‌دهد؟
این مسئله فرضی، ما را به هشتمین سؤال از مجموعه هزار سؤال مصاحبه مدیر محصول می‌رساند:
«چطور به سالمندان کمک می‌کنید یک خدمت دیجیتال را بدون کمک دیگران تکمیل کنند؟»
مصاحبه‌کننده دقیقا دنبال چیست؟
این سؤال در دسته طراحی محصول و تجربه کاربری قرار می‌گیرد و بیشتر از اینکه دانش طراحی رابط کاربری را بسنجد، قدرت تشخیص مسئله و تصمیم‌گیری محصولی را ارزیابی می‌کند.
مصاحبه‌کننده می‌خواهد ببیند آیا می‌توانیم:
- نیاز واقعی کاربر را از برداشت اولیه خودمان جدا کنیم.
- به‌جای در نظر گرفتن همه سالمندان به‌عنوان یک گروه یکسان، کاربران را براساس نیاز و شرایطشان بشناسیم.
- محدودیت‌های انسانی و فنی را هم‌زمان در تصمیم‌ها لحاظ کنیم.
- از میان راه‌حل‌های مختلف، گزینه‌ای قابل آزمایش انتخاب کنیم.
- برای سنجش موفقیت، معیاری فراتر از تعداد کلیک یا بازدید تعریف کنیم.
پاسخ ضعیف معمولا از فهرست امکانات شروع می‌شود: فونت بزرگ، دکمه درشت، راهنمای صوتی و یک نسخه مخصوص سالمندان.
اما پاسخ قوی ابتدا می‌پرسد: کاربر برای انجام چه کاری، در کدام مرحله و به چه دلیلی به کمک دیگران نیاز پیدا می‌کند؟
استقلال کاربر را درست تعریف کنیم
قبل از پیشنهاد راه‌حل باید روشن کنیم که منظورمان از انجام مستقل یک خدمت چیست.
استقلال صرفا این نیست که کاربر بدون کمک روی دکمه نهایی کلیک کند. او باید بتواند هدف خدمت را بفهمد، اطلاعات درست وارد کند، از نتیجه مطمئن شود و بدون وابستگی ناخواسته به فرد دیگری، کارش را با امنیت و اطمینان به پایان برساند.
این تفاوت مهمی است.
ممکن است فردی با کمک یکی از اعضای خانواده بتواند در کمتر از دو دقیقه نوبت بگیرد، اما همان کار را به‌تنهایی نتواند انجام دهد. در چنین شرایطی، نرخ تکمیل فرایند بالا می‌ماند، ولی تجربه کاربری همچنان مشکل دارد.
از طرف دیگر، نباید استقلال را به معنای حذف امکان دریافت کمک بدانیم. بعضی کاربران به حمایت نیاز دارند یا خودشان ترجیح می‌دهند از مسیر دیگری استفاده کنند. محصول خوب هم مسیر مستقل را ساده می‌کند و هم راه کمک‌گرفتن را محترمانه و در دسترس نگه می‌دارد.
سالمندان یک گروه با نیازهای یکسان نیستند
یکی از اشتباهات رایج این است که افزایش سن را معادل ناتوانی در استفاده از فناوری فرض کنیم.
ممکن است کاربری ۷۵ ساله هر روز با گوشی هوشمند کار کند، اما فردی ۶۵ ساله تجربه بسیار محدودی از خدمات اینترنتی داشته باشد. حتی دو نفر با سطح مهارت دیجیتال مشابه نیز ممکن است با مشکلات متفاوتی روبه‌رو شوند.
موانع احتمالی را می‌توان در چند دسته بررسی کرد:
موانع دیداری و حرکتی: نوشته‌های کم‌کنتراست، دکمه‌های کوچک، فاصله نامناسب کنترل‌ها یا تعامل‌هایی که به دقت زیاد نیاز دارند.
موانع شناختی و زبانی: اصطلاحات نامفهوم، فرم‌های طولانی، الزام به حفظ اطلاعات، مراحل غیرمنتظره یا پیام‌های خطای مبهم.
موانع اعتماد و امنیت: نگرانی از پرداخت اشتباه، افشای اطلاعات شخصی، کلاهبرداری یا ندانستن اینکه عملیات واقعا انجام شده است.
موانع دسترسی و تجربه: نداشتن اینترنت پایدار، ناآشنایی با مرورگر، دشواری کار با پیامک یا استفاده از دستگاه‌های قدیمی.
راهنمای W3C درباره کاربران سالمند نیز توضیح می‌دهد که بسیاری از نیازهای این گروه با اصول شناخته‌شده دسترس‌پذیری دیجیتال هم‌پوشانی دارند.
بنابراین، نباید تنها براساس سن کاربر طراحی کنیم؛ باید بفهمیم چه مانعی جلوی انجام کار را گرفته است.
از کجا بفهمیم مشکل اصلی چیست؟
من به‌عنوان مدیر محصول، قبل از تصمیم درباره قابلیت‌ها، یک خدمت مشخص و پرکاربرد را انتخاب می‌کنم.
برای مثال، اگر محصول چندین خدمت دارد، ابتدا روی فرایندی تمرکز می‌کنم که کاربران مسن‌تر در آن بیشترین نیاز به کمک یا بیشترین ریزش را نشان می‌دهند.
سپس از سه منبع شواهد استفاده می‌کنم.
مشاهده رفتار واقعی
با افرادی از سطح‌های مختلف سواد دیجیتال، در محیط و با دستگاهی که معمولا استفاده می‌کنند، آزمون کاربردپذیری انجام می‌دهیم.
از آن‌ها می‌خواهیم یک کار واقعی را انجام دهند و مشاهده می‌کنیم کجا مکث می‌کنند، چه چیزی را اشتباه می‌فهمند و چه زمانی درخواست کمک دارند.
برای سنجش تکمیل مستقل، باید مشخص باشد که تسهیل‌گر آزمون چه زمانی اجازه راهنمایی دارد. اگر در میانه کار پاسخ را به کاربر بگوییم، دیگر نمی‌توانیم نتیجه را تکمیل کاملا مستقل حساب کنیم.
بررسی داده‌های محصول
مسیر حرکت کاربر را از شروع تا دریافت نتیجه بررسی می‌کنیم.
برای مثال:
- کاربران در کدام مرحله بیشتر خارج می‌شوند؟
- چند بار اعتبارسنجی اطلاعات خطا می‌دهد؟
- چه تعداد فرایند بعد از ورود به مرحله تایید هویت متوقف می‌شود؟
- چند بار کاربر یک مرحله را تکرار می‌کند؟
- چه تعداد از کاربران پس از دریافت خطا به پشتیبانی مراجعه می‌کنند؟
این داده‌ها محل احتمالی مشکل را نشان می‌دهند، اما لزوما دلیل آن را توضیح نمی‌دهند.
گفت‌وگو با پشتیبانی و کاربران
در تماس‌های پشتیبانی به دنبال الگوهای تکرارشونده می‌گردیم.
ممکن است متوجه شویم کاربران نه به دلیل دشواری فرم، بلکه به دلیل ابهام در نتیجه نهایی تماس می‌گیرند. در این صورت، بازطراحی فرم احتمالا اولویت نخست نیست.
نکته مهم این است که نمونه تحقیق را فقط از سالمندان آشنا با فناوری انتخاب نکنیم. چنین نمونه‌ای ممکن است بخش مهمی از مشکلات واقعی را پنهان کند.
کدام راه‌حل را انتخاب کنیم؟
در این مسئله سه مسیر قابل دفاع وجود دارد.
مسیر اول: ساخت حالت مخصوص سالمندان
می‌توان نسخه‌ای با کنترل‌های بزرگ‌تر، مسیرهای محدودتر و توضیحات بیشتر طراحی کرد.
این راه‌حل ممکن است برای یک نیاز مشخص مفید باشد، اما چند ریسک دارد.
اول اینکه همه سالمندان به تجربه ساده‌شده نیاز ندارند. دوم اینکه محصول صاحب دو مسیر متفاوت می‌شود که نگهداری و آزمایش هر دو هزینه دارد. سوم اینکه امکان دارد برخی قابلیت‌های موردنیاز کاربر در نسخه ساده حذف شوند.
اگر تحقیق نشان دهد گروه مشخصی واقعا به یک شیوه تعامل متفاوت نیاز دارد، این گزینه ارزش بررسی دارد؛ اما صرف سن بالای کاربر دلیل کافی برای ساخت آن نیست.
مسیر دوم: اصلاح تجربه اصلی برای همه کاربران
انتخاب اولیه من این مسیر است.
به‌جای ساخت محصولی جداگانه، موانع اصلی را از همان تجربه موجود حذف می‌کنیم.
برای نمونه، متن‌ها را روشن‌تر می‌نویسیم، مراحل را قابل پیش‌بینی می‌کنیم، امکان اصلاح خطا را فراهم می‌کنیم و کاری می‌کنیم که کاربر بدون نیاز به حفظ اطلاعات یا حدس زدن، مسیر را ادامه دهد.
این رویکرد می‌تواند برای سایر کاربران نیز مفید باشد؛ از افراد کم‌تجربه گرفته تا کسانی که تحت فشار زمانی یا با اینترنت ضعیف از خدمت استفاده می‌کنند.
بااین‌حال، اصلاح تجربه اصلی هم نباید به حذف اطلاعات ضروری یا ساده‌سازی افراطی منجر شود.
مسیر سوم: تقویت پشتیبانی انسانی
راهنمای تلفنی، چت یا کمک حضوری می‌تواند بخشی از راه‌حل باشد.
اما اگر تنها پاسخ ما به مشکل، ارجاع همه کاربران به پشتیبانی باشد، وابستگی را برطرف نکرده‌ایم؛ فقط محل آن را تغییر داده‌ایم.
به همین دلیل، پشتیبانی را مسیر جایگزین و ایمن در نظر می‌گیرم، نه جانشین اصلاح محصول.
این موضوع با رویکرد راهنمای خدمات دیجیتال دولت بریتانیا نیز هماهنگ است: کاربرانی که نمی‌توانند خدمت را آنلاین تکمیل کنند، نباید از دریافت آن محروم شوند.
تجربه پیشنهادی چه ویژگی‌هایی دارد؟
پس از شناخت مانع اصلی، طراحی را بر چند اصل متمرکز می‌کنم.
۱. هر مرحله باید هدف روشنی داشته باشد.
کاربر باید بداند در کدام مرحله است، چه اطلاعاتی از او خواسته شده و بعد از ادامه چه اتفاقی می‌افتد.
در فرم‌های پیچیده، نمایش یک سؤال یا تصمیم مشخص در هر مرحله می‌تواند به تمرکز کمک کند؛ البته اگر تعداد رفت‌وبرگشت‌ها و زمان انجام کار را بی‌دلیل افزایش ندهد.
۲. خوانایی و تعامل باید واقعا دسترس‌پذیر باشند.
کنتراست مناسب، امکان بزرگ‌نمایی نوشته‌ها، کنترل‌های قابل تشخیص، فاصله کافی میان دکمه‌ها و سازگاری با ابزارهای کمکی اهمیت دارند.
برای نمونه، WCAG 2.2 در معیار AA مربوط به اندازه هدف لمسی، حداقل ۲۴ در ۲۴ پیکسل CSS را با استثناهای مشخص تعریف می‌کند. این حداقل فنی را نباید با اندازه مطلوب همه کاربران یکسان دانست.
۳. خطا نباید به بن‌بست تبدیل شود.
پیام «اطلاعات نامعتبر است» کافی نیست.
بهتر است دقیقا مشخص کنیم کدام اطلاعات اشتباه است، چگونه می‌توان آن را اصلاح کرد و آیا داده‌های قبلی حفظ شده‌اند یا نه.
۴. احراز هویت نباید به آزمون حافظه تبدیل شود.
اگر از کاربر می‌خواهیم رمز یا کد تایید را از جایی به خاطر بسپارد و در جای دیگری تایپ کند، ممکن است مانعی جدی ایجاد کنیم.
WCAG 2.2 در معیار دسترس‌پذیری احراز هویت به همین موضوع توجه دارد. پشتیبانی از مدیر رمز عبور، کپی و جای‌گذاری و روش‌های جایگزین مناسب، راه‌هایی برای کاهش بار شناختی هستند.
البته ساده‌تر کردن ورود نباید امنیت حساب را قربانی کند.
۵. نتیجه عملیات باید روشن و قابل پیگیری باشد.
پس از ثبت درخواست، کاربر باید تایید واضح، شماره پیگیری در صورت نیاز و مسیر مشاهده یا اصلاح وضعیت را دریافت کند.
گاهی همین اطمینان از نتیجه، بیشتر از تغییر ظاهر صفحات به استقلال کاربر کمک می‌کند.
یک مثال فرضی از طراحی محصول نرم‌افزاری
فرض کنیم تیم محصول یک سامانه نوبت‌گیری خدمات شهری متوجه شده بخشی از کاربران مسن‌تر برای ثبت نوبت از اعضای خانواده کمک می‌گیرند.
بررسی اولیه سه فرضیه پیش روی تیم می‌گذارد:
فرضیه اول این است که کاربران در پیدا کردن خدمت مناسب مشکل دارند.
فرضیه دوم به مرحله احراز هویت مربوط می‌شود.
فرضیه سوم می‌گوید کاربران نوبت را ثبت می‌کنند، اما به دلیل ابهام در پیام نهایی، مطمئن نیستند که ثبت موفق بوده است.
در این شرایط، ساخت یک نسخه کامل مخصوص سالمندان تصمیم زودهنگامی است.
تیم تحقیق و طراحی با تعدادی از کاربران واقعی، سه نمونه اولیه را آزمایش می‌کند: مسیر انتخاب خدمت با توضیحات روشن‌تر، احراز هویت با تعامل ساده‌تر و صفحه تایید نهایی با وضعیت و اطلاعات پیگیری مشخص.
مهندسان محدودیت‌های فنی و امنیتی را بررسی می‌کنند. تیم پشتیبانی موارد پرتکرار را در اختیار محصول قرار می‌دهد و مسئول امنیت بررسی می‌کند که ساده‌تر شدن مراحل، راه سوءاستفاده ایجاد نکند.
اگر مشاهده‌ها نشان دهند مشکل اصلی هنگام ورود کد تایید اتفاق می‌افتد، تغییر همان مرحله در اولویت قرار می‌گیرد.
در نسخه آزمایشی می‌توان اجازه جای‌گذاری کد، استفاده از تکمیل خودکار در دستگاه‌های پشتیبانی‌شده، پیام خطای واضح و درخواست مجدد کد با محدودیت امنیتی مناسب را فراهم کرد.
سپس باید دید کاربران هدف می‌توانند فرایند را مستقل تکمیل کنند یا فقط از یک مانع به مانع بعدی منتقل شده‌اند.
اگر مشکل اصلی تایید هویت نباشد، تصمیم هم باید عوض شود.
هدف مدیر محصول دفاع از اولین ایده نیست؛ پیدا کردن تغییری است که واقعا مانع انجام کار را برطرف می‌کند.
موفقیت را با چه شاخص‌هایی بسنجیم؟
مهم‌ترین معیار من، نرخ تکمیل موفق و مستقل خدمت است.
در آزمون کاربردپذیری، این نرخ را به‌صورت تعداد شرکت‌کنندگانی تعریف می‌کنیم که کار مشخصی را بدون راهنمایی و با نتیجه درست و ایمن تکمیل کرده‌اند، تقسیم بر تعداد شرکت‌کنندگان واجد شرایطی که آزمون را شروع کرده‌اند.
این معیار را نباید مستقیما از نرخ تکمیل ثبت‌شده در ابزار تحلیل محصول استخراج کرد؛ چون داده‌های معمول رویدادها به ما نمی‌گویند آیا شخص دیگری در کنار کاربر کمک کرده است یا نه.
در کنار آن سه دسته شاخص لازم داریم.
شاخص‌های تشخیصی: زمان انجام کار، خطاهای ورودی، تکرار مراحل، نقطه درخواست کمک و میزان درک کاربر از نتیجه.
شاخص‌های عملیاتی: نرخ رهاکردن فرایند، تماس‌های پشتیبانی مرتبط با هر مرحله و موفقیت مسیرهای جایگزین.
شاخص‌های محافظتی: خطاهای پرهزینه، ثبت درخواست اشتباه، مشکلات امنیتی و حریم خصوصی، و افت کیفیت تجربه سایر کاربران.
برای یک آزمون اولیه، داده‌های کیفی و مشاهده چند کاربر می‌تواند مشکل را آشکار کند، ولی برای ادعای بهبود آماری به نمونه مناسب و طراحی سنجش معتبر نیاز داریم.
در یک پایلوت محدود، بازه مشاهده و معیار توقف یا اصلاح را قبل از اجرا تعیین می‌کنیم. برای مثال، می‌توان عملکرد را طی چند هفته و در مقایسه با مسیر قبلی بررسی کرد؛ بدون اینکه از پیش ادعایی درباره میزان بهبود داشته باشیم.
مسئولیت مدیر محصول در این تصمیم چیست؟
مدیر محصول باید مشخص کند کدام مشکل ارزش حل کردن دارد، برای چه گروهی و با چه نتیجه قابل‌اندازه‌گیری.
طراح محصول مسئول شکل‌دادن و آزمایش تعامل‌هاست. تیم توسعه امکان‌پذیری و کیفیت پیاده‌سازی را بررسی می‌کند و تیم‌های امنیت و پشتیبانی محدودیت‌ها و ریسک‌های واقعی را روشن می‌کنند.
مدیر پروژه، در صورت وجود این نقش، روی هماهنگی اجرا، زمان‌بندی و وابستگی‌ها تمرکز دارد.
در تیمی که از Scrum استفاده می‌کند، Product Owner نیز طبق Scrum Guide پاسخ‌گوی بیشینه‌سازی ارزش محصول و مدیریت موثر Product Backlog است. این مسئولیت را نباید صرفا با عنوان شغلی مدیر محصول یا مدیر پروژه یکسان فرض کرد.
پاسخ پیشنهادی در مصاحبه
اگر بخواهم به این سؤال در یک مصاحبه واقعی پاسخ بدهم، احتمالا این‌طور توضیح می‌دهم:
«اول مشخص می‌کنم درباره چه خدمتی صحبت می‌کنیم و کاربران دقیقا در کدام قسمت آن به کمک نیاز دارند. چون همه سالمندان شرایط یکسانی ندارند، کاربران را فقط براساس سن دسته‌بندی نمی‌کنم.
بعد با مشاهده رفتار کاربران و بررسی داده‌ها مشخص می‌کنم مشکل از خوانایی، پیچیدگی مسیر، احراز هویت، اعتماد یا چیز دیگری است.
اگر شواهد خلافش را نشان ندهند، ترجیح می‌دهم ابتدا مسیر اصلی محصول را اصلاح کنم تا اینکه نسخه جداگانه‌ای مخصوص سالمندان بسازم. مثلا اگر کاربران در تایید پیامکی مشکل دارند، همان مرحله را ساده‌تر و دسترس‌پذیرتر می‌کنم.
موفقیت را هم فقط با تعداد تکمیل فرایند نمی‌سنجم؛ می‌خواهم بدانم چند نفر واقعا بدون کمک، با خطای قابل‌قبول و بدون کاهش امنیت کارشان را انجام داده‌اند.
در کنار این تغییرات، مسیر پشتیبانی را برای کسانی که همچنان به کمک نیاز دارند حفظ می‌کنم. اگر آزمون‌ها نشان دهند مانع اصلی جای دیگری است، اولویت و راه‌حل را تغییر می‌دهم.»
این پاسخ به‌جای وعده یک راه‌حل قطعی، منطق تصمیم‌گیری و شرایط بازنگری در تصمیم را نشان می‌دهد.
سؤال‌های تکمیلی مصاحبه
اگر فقط دو هفته فرصت داشته باشید، چه می‌کنید؟
این یکی از دو سؤال تکمیلی مطرح‌شده در منبع اصلی است.
در دو هفته نمی‌توان همه مشکلات دسترس‌پذیری یک خدمت پیچیده را حل کرد، اما می‌توان مهم‌ترین مانع را پیدا و یک راه‌حل محدود را آزمایش کرد.
در چند روز نخست، داده‌های موجود و تماس‌های پشتیبانی را بررسی می‌کنم و با چند کاربر هدف، فرایند اصلی را مشاهده می‌کنم.
سپس یک مشکل پرتکرار و اثرگذار را انتخاب می‌کنم، نمونه اولیه می‌سازم و با کاربران واقعی آزمایشش می‌کنم.
در پایان، به‌جای ادعای حل کامل مسئله، گزارشی از مانع شناسایی‌شده، نتیجه آزمون، ریسک‌ها و تصمیم پیشنهادی برای مرحله بعد ارائه می‌دهم.
چه شواهدی باعث می‌شود راه‌حل پیشنهادی خود را رد کنید؟
این سؤال تکمیلی دوم منبع است.
اگر پس از اصلاح مرحله احراز هویت، کاربران همچنان نتوانند خدمت را مستقل تکمیل کنند، باید فرضیه اولیه را زیر سؤال ببرم.
همین‌طور اگر کاربران سریع‌تر کار را تمام کنند، اما خطاهای حساس یا نگرانی‌های امنیتی بیشتر شود، نمی‌توان تغییر را موفق دانست.
ممکن است تحقیق نشان دهد مسئله اصلی اصلا طراحی رابط کاربری نیست؛ بلکه اعتماد به ارائه‌دهنده خدمت، دسترسی به اینترنت یا یک الزام اداری پیچیده است.
در آن صورت باید دامنه راه‌حل را تغییر دهیم و شاید حتی بخشی از فرایند کسب‌وکار را بازطراحی کنیم.
چه پاسخ‌هایی در این مصاحبه ضعیف محسوب می‌شوند؟
«همه دکمه‌ها را بزرگ می‌کنم.»
این پیشنهاد بدون تشخیص مشکل ارائه شده است. بزرگ‌تر کردن دکمه‌ها نمی‌تواند ابهام احراز هویت، نبود اعتماد یا پیچیدگی مراحل را به‌تنهایی حل کند.
«یک نسخه ساده برای همه سالمندان می‌سازم.»
این پاسخ تفاوت نیازهای کاربران را نادیده می‌گیرد و ممکن است به ساخت مسیری پرهزینه و ناقص منجر شود.
«اگر نرخ تکمیل بالا رفت، موفق شده‌ایم.»
نرخ تکمیل به‌تنهایی مشخص نمی‌کند کاربر مستقل عمل کرده یا اشتباه پرهزینه‌ای انجام داده است.
«کمک گرفتن از خانواده را حذف می‌کنم.»
استقلال نباید به اجبار تبدیل شود. قرار است نیاز ناخواسته به کمک را کم کنیم، نه اختیار استفاده از حمایت را از کاربر بگیریم.
«استانداردهای دسترس‌پذیری را رعایت می‌کنیم، پس مسئله حل است.»
رعایت استانداردهای فنی ضروری است، اما کافی نیست. W3C نیز بر ترکیب ارزیابی استانداردها با آزمون کاربران واقعی تاکید می‌کند؛ چون بعضی مشکلات کاربردپذیری فقط در تعامل واقعی آشکار می‌شوند.
جمع‌بندی
برای کمک به سالمندان در تکمیل مستقل خدمات دیجیتال، نباید طراحی را از سن کاربر شروع کنیم؛ باید از مانعی شروع کنیم که جلوی انجام کار او را گرفته است.
انتخاب اولیه من اصلاح تجربه اصلی محصول، کاهش پیچیدگی غیرضروری، دسترس‌پذیر کردن تعامل‌ها و حفظ مسیرهای کمک‌رسانی است. اما این انتخاب فقط تا زمانی معتبر است که تحقیق و آزمون‌ها نشان دهند مانع اصلی در همان تجربه قرار دارد.
یک محصول دیجیتال زمانی واقعا فراگیر است که افراد با توانایی‌ها و تجربه‌های متفاوت بتوانند بدون وابستگی ناخواسته، با امنیت، اطمینان و حفظ اختیار خود از آن استفاده کنند. موفقیت این طراحی را هم باید در نتیجه واقعی کاربر دید، نه فقط در ظاهر ساده‌تر صفحات.
منابع
۱. W3C — Older Users and Web Accessibility
https://www.w3.org/WAI/older-users/
۲. W3C — How to Meet WCAG 2.2
https://www.w3.org/WAI/WCAG22/quickref/
۳. W3C — Understanding Accessible Authentication (Minimum)
https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum
۴. W3C — Involving Users in Evaluating Web Accessibility
https://www.w3.org/WAI/test-evaluate/involving-users/
۵. GOV.UK Design System — Question Pages
https://design-system.service.gov.uk/patterns/question-pages/
۶. GOV.UK Service Manual — Designing Assisted Digital Support
https://www.gov.uk/service-manual/helping-people-to-use-your-service/designing-assisted-digital
