https://virgool.io/feed/@m_52295666 طراح محصول fa 2026-06-16 08:07:37 https://files.virgool.io/upload/users/721376/avatar/vw79tp.jpg?height=120&width=120 https://virgool.io/@m_52295666 https://virgool.io/@m_52295666/%D9%85%D8%B7%D8%A7%D9%84%D8%B9%D9%87%D9%94-%D9%85%D9%88%D8%B1%D8%AF%DB%8C-%D8%AA%D8%AC%D8%B1%D8%A8%D9%87%D9%94-%D9%86%D8%A7%D8%A8%DB%8C%D9%86%D8%A7%DB%8C%D8%A7%D9%86-%D8%AF%D8%B1-%D8%A7%D9%BE%D9%84%DB%8C%DA%A9%DB%8C%D8%B4%D9%86-%D8%A8%D9%84%D9%87-ayejdpto1hvd مقدمهدر دنیای امروز، پیام‌رسان‌ها یکی از ابزارهای اساسی ارتباطی برای میلیاردها کاربر با توانایی‌های مختلف در سراسر جهان تبدیل شده‌اند. یکی از مهم‌ترین چالش‌های موجود، دسترس‌پذیری این ابزارها برای تمامی افراد جامعه، به ویژه افراد دارای معلولیت است. در این مطالعهٔ موردی، به بررسی اقدامات و بهبودهایی که در فاز اول برای بخش دسترس‌پذیری اپلیکیشن «بله» برای کاربران نابینا انجام شده است، پرداخته می‌شود.مسئلهبا رشد تعداد کاربران «بله»، گزارش‌های زیادی از سمت پشتیبانی دریافتیم که افراد نابینا در استفاده از اپلیکیشن «بله» به کمک نرم‌افزارهای صفحه‌خوان با مشکلاتی مواجه هستند.برای اطلاعات بیشتر در مورد صفحه‌خوان، می‌توانید به این لینک مراجعه کنید.فرآیند طراحیتحقیقبرای طراحی محصولات دیجیتال برای کاربران نابینا، ابتدا لازم بود نحوهٔ استفاده این کاربران از اپلیکیشن‌ها و وب‌سایت‌ها را به طور دقیق مورد بررسی قرار دهیم و سپس اقدامات لازم را متناسب با نیازهای آن‌ها تعریف کنیم.پس از بررسی استانداردهای دسترس‌پذیری WCAG برای صفحه‌خوان‌ها و درک نیازهای کاربران مانند برچسب‌گذاری برای هر عنصر و ترتیب حرکت حالت‌های متمرکز و...، نیازمندی‌های لازم برای طراحی را مشخص کردیم. در این راستا، یک جلسهٔ مشترک با تیم فنی برگزار کردیم و نیازمندی‌های مربوط به طراحی و فنی محصول را شفاف کردیم.در نهایت، با توجه به گستردگی و پیچیدگی اپلیکیشن «بله»، اولویت‌بندی دسترس‌پذیری را براساس تعداد کاربران هر بخش و ویژگی‌های مورد نیاز و بازخوردهای کاربران، در نظر گرفتیم.پس از بررسی‌های لازم، تصمیم گرفتیم که در فاز اول، روی دسترس‌پذیری بخش گفتگوی اندروید تمرکز کنیم. بخش گفتگو شامل فیچرها و جزئیات بسیاری بود، بنابراین تصمیم گرفتیم که این بخش را نیز مجدداً فازبندی کنیم.پیش از شروع، به عنوان دیزاینر نیاز بود که صفحه‌خوان خود را فعال کرده و با محصولات مشابه که برای کاربران نابینا دسترس‌پذیر هستند، کار کنیم. این فرآیند به ما کمک کرد تا نحوهٔ کارکرد صفحه‌خوان‌ها و روش‌های حل مسائل مختلف را به طور کامل درک کنیم. این بنچ‌مارک‌ها به ما این امکان را دادند تا راه‌حل‌های موثرتری برای بهبود دسترس‌پذیری ارائه دهیم.راهکار طراحیدر این مرحله، نیازمندی‌های مشخص شده شامل تعیین برچسب‌های مناسب برای عناصر در صفحه (اگر محصول چند زبانه باشد، این برچسب‌ها باید به تمامی زبان‌ها مشخص شوند)، ترتیب پیمایش در صفحه با کشیدن انگشت (سوایپ)، نقش هر عنصر و نحوه‌ی انتخاب هر عنصر نیز باید تعریف شود.در فاز اول، به سه سناریو زیر پرداختیم:مشاهده پیام: در صورتی که کاربر در گروه‌ها و کانال‌ها عضو باشد یا چت شخصی قبلی داشته باشد، به راحتی به آن‌ها دسترسی پیدا کند.مواردی که در این سناریو در نظر گرفته شد، شامل موارد زیر بود:- آیکون منو، جستجو و موارد نویگیشن برچسب‌گذاری شدند.- در تب صفحهٔ دیالوگ لیست، هر بخش برچسب‌گذاری شد و در صورتی که پیام‌ خوانده‌شده، پیام خوانده‌ نشده یا پیامی که خوانده‌ نشده و دیالوگ آن گفتگو توسط کاربر قبلا بی‌صدا شده است را به تفکیک توسط صفحه‌خوان برای کاربران نابینا مشخص شد.- در بخش دیالوگ لیست، چت شخصی، گروه، کانال و بات به تفکیک در نظر گرفته شد.- نحوه‌ی خواندن هر دیالوگ شامل ترتیب خواندن عنوان، توضیحات، ساعت، در صورت دریافت پیام، شمارنده پیام و در صورت ارسال پیام، وضعیت پیام شامل ارسال شده، در حال ارسال، ارسال شده و دیده شده درنظر گرفته شد.یافت‌پذیری مخاطب: کاربر نابینا پس از باز کردن اپلیکیشن «بله» بتواند به راحتی به مخاطبان خود پیام ارسال کند.مواردی که در این سناریو در نظر گرفته شد:- نحوهٔ دسترسی به دکمهٔ مخاطبین و برچسب‌گذاری این دکمه مشخص شد.- با کلیک روی دکمهٔ مخاطبین، لیست مخاطبین نمایش داده شود و امکان اسکرول در لیست و خواندن اسم مخاطب و زمان آخرین حضور مخاطب مشخص شد و با کلیک روی هر لیست، صفحهٔ گفتگو آن شخص باز شود.ارسال انواع پیام: کاربر بتواند در صفحهٔ گفتگو با مخاطبان خود یا گروه‌ها، انواع پیام‌های متنی، صوتی، ویدیویی، فایل، موقعیت جغرافیایی، پیام‌های فوروارد شده، استیکرها و تماس‌ها را تشخیص داده و پیام‌های خود را ارسال کند.مواردی که در این سناریو در نظر گرفته شد:- آیکون بازگشت، تماس، ارسال پیام صوتی، اموجی، موارد بیشتر و پروفایل کاربر برچسب‌گذاری شدند.- اصلاحاتی روی اینپوت‌بار انجام شد.- در انواع پیام‌ها حالت‌هایی شامل پیامی که خودم ارسال کردم و وضعیت پیام شامل ارسال شده، در حال ارسال، ارسال شده و دیده شده، پیامی که از گفتگوی شخصی یا گروه دریافت شده مشخص شد.- نحوه‌ی باز شدن کانتکست منو و حالت لانگ پرس برای اپ‌بار انواع پیام‌ها مشخص شد.تصویر زیر یک بخشی از داکیومنتی که برای سناریو اول برای حالت‌های مختلف درنظر گرفتیم را نمایش می‌دهد.تست پس از پیاده‌سازی اولیه، علاوه‌بر تست با صفحه‌خوان توسط طراح و دولوپر، توانستیم با ۸ کاربر نابینای اپلیکیشن «بله» ارتباط بگیریم و نسخهٔ آماده شده را برای آن‌ها ارسال کنیم. این تست به صورت ریموت انجام شد و پس از اجرای کامل موارد پیاده‌شده، طبق بازخوردهای دریافتی از کاربران، متوجه شدیم که سناریوهای اصلاح‌شده از نظر دسترس‌پذیری برای کاربران نابینا قابل استفاده هستند و به راحتی می‌توانند به هدف خود برسند. همچنین، کاربران مشکلاتی را که در سناریوها با آن‌ها مواجه بودند را به ما گزارش دادند.مشکلات گزارش‌شده۷۵ درصد کاربرها به مشکل ارسال و پخش ویس اشاره کردند.۳۷ درصد به باز شدن کانتکست منو و اپ‌بار اشاره کردند....پس از بررسی مشکلات گزارش‌شده توسط کاربران نابینا و براساس میزان تکرار آن‌ها، اولویت‌بندی لازم را انجام دادیم. در چند نسخه، تلاش کردیم مشکلاتی که اولویت بالاتری داشتند را برطرف کنیم و مجدد از کاربران بازخورد بگیریم.در بین گزارش‌ها، همهٔ کاربرها به مشکل تماس هم اشاره کردند که این مورد را جز فازبندی در نظر نگرفته بودیم و با توجه به گزارش پرتکرار این ویژگی در اولویت کارها در نظر گرفتیم.درس‌ آموخته‌هارعایت استانداردهای دسترس‌پذیری در مراحل اولیه طراحی و پیاده‌سازی محصول، هزینه کمتری نسبت به زمانی دارد که محصول ابتدا پیاده‌سازی شود و سپس به دسترس‌پذیری آن پرداخته شود. این رویکرد اقتصادی‌تر بوده و باعث می‌شود از بروز مشکلات پیچیده‌تر در مراحل بعدی جلوگیری شود.در ارائه راهکار برای مسائل مختلف دسترس‌پذیری، تلاش کنید مدل ذهنی کاربران نابینا که در محصولات مختلف شکل گرفته را تغییر ندهید. یادگیری مدل جدید برای کاربران بسیار پیچیده است و احتمالاً به عنوان یک مشکل گزارش خواهد شد.در صورتی که روی دسترس‌پذیری کار می‌کنید، توصیه می‌شود برای تست محصول و تغییراتی که اعمال می‌کنید، با چند کاربر نابینا در ارتباط باشید تا تغییرات اعمال شده توسط آن‌ها کامل تست شود.اگر محصولی که با آن کار می‌کنید پیچیدگی و جزئیات زیادی دارد و مشکلات بسیاری در استفاده از صفحه‌خوان ایجاد می‌کند، حتماً از فازبندی استفاده کنید. اولویت‌بندی‌ها را براساس اصلی‌ترین سناریوها در نظر بگیرید تا به تدریج مشکلات را حل کنید.به طور مستمر از کاربران نابینا در مورد محصول خود بازخورد بگیرید، زیرا احتمالاً با هر تغییری، برخی بخش‌ها تحت تأثیر قرار گرفته و دسترس‌پذیری آن‌ها دچار مشکل شود. رویا خیرالهی رویا خیرالهی Fri, 26 Jul 2024 12:44:20 +0330 https://virgool.io/@m_52295666/%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%B5%D9%81%D8%AD%D9%87-%D8%AE%D9%88%D8%A7%D9%86-%D9%87%D8%A7-%D8%AF%D9%86%DB%8C%D8%A7%DB%8C-%D9%86%D8%A7%D8%A8%DB%8C%D9%86%D8%A7%DB%8C%D8%A7%D9%86-%D8%B1%D8%A7-%D8%AA%D8%BA%DB%8C%DB%8C%D8%B1-%D9%85%DB%8C-%D8%AF%D9%87%D9%86%D8%AF-za3hz3fts7cf مقدمهدر عصر دیجیتال امروز، دسترسی‌پذیری محصولات دیجیتالی برای تمامی افراد با توانایی‌های مختلف اهمیت به‌سزایی دارد. یکی از گروه‌های مهمی که نیازمند توجه ویژه‌ای هستند، افراد نابینا می‌باشند. این افراد برای استفاده از محصولات دیجیتالی از ابزاری به نام صفحه‌خوان که محتوای متنی را به صدا تبدیل می‌کند، استفاده می‌کنند. طراحی محصولات دیجیتال به گونه‌ای که با این ابزارها سازگار باشد، مستلزم رعایت اصول و استانداردهای خاصی است. در این مقاله، به بررسی نکات کلیدی در طراحی محصولات می‌پردازیم که برای افراد نابینا و کاربران صفحه‌خوان‌ها مناسب و قابل دسترس باشند.صفحه‌خوان صفحه‌خوان (Screen Reader) نرم‌افزاری است که به افراد نابینا یا کم‌بینا کمک می‌کند تا از طریق تبدیل متن به گفتار (Text-to-Speech) یا نمایش خط بریل (Braille Display)، با محتوای دیجیتالی تعامل داشته باشند. این نرم‌افزارها محتوای متنی را به صورت گفتار صوتی یا بریل تبدیل می‌کنند. از جمله معروف‌ترین صفحه‌خوان‌ها که به‌صورت پیش‌فرض در دستگاه‌ها وجود دارند، می‌توان به TalkBack برای دستگاه‌های اندروید و VoiceOver برای iOS اشاره کرد که از قسمت تنظیمات و بخش دسترس‌پذیری قابل فعال‌سازی هستند. همچنین، VoiceOver برای سیستم‌عامل مک و JAWS و NVDA برای سیستم‌عامل ویندوز قابل استفاده هستند.برای استفاده از صفحه‌خوان در محصولات ایرانی با زبان فارسی، لازم است نرم‌افزار eSpeak نیز نصب گردد.اصول طراحی دسترس‌پذیر، سازگار با صفحه‌خوان‌هاطراحی محصولات دیجیتال دسترسی‌پذیر که سازگار و قابل استفاده توسط صفحه‌خوان‌ها باشند، نیازمند رعایت مجموعه‌ای از اصول و استانداردها هستند. این اصول به کاربران نابینا یا کم‌بینا کمک می‌کنند تا تجربه‌ای بهتری از تعامل با محتوای دیجیتالی داشته باشند. در ادامه، به برخی از مهم‌ترین اصول طراحی برای دسترسی‌پذیری با صفحه‌خوان‌ها اشاره می‌کنم:استفاده از برچسب‌های مناسبیکی از مهم‌ترین نکات در طراحی برای صفحه‌خوان‌ها، برچسب‌گذاری مناسب برای عناصر مختلف در صفحه است. هر عنصری که کاربر نابینا برای رسیدن به هدف نیاز به تعامل با آن دارد، باید به درستی برچسب‌گذاری شود. به عنوان مثال، آیکون‌ها، دکمه‌ها، لیست‌ها، تکست‌فیلدها و …. همگی باید دارای برچسب مناسب باشد تا کاربران نابینا بتوانند به کمک صفحه‌خوان‌ و برچسب‌های درنظر گرفته شده، به محتوای صفحه دسترسی داشته باشند.توصیف تصاویردر صورتی که در صفحه تصویری وجود داشته باشد و کاربر نابینا برای دستیابی به هدفش نیاز به درک محتوای آن دارد،‌ باید متن جایگزین (Alternative text) تعریف شود. این متن جایگزین باید به صورت مختصر و با زبانی واضح و قابل فهم، محتوای تصویر را توصیف کند.حالت‌های متمرکز (Focus States)برای کاربران نابینا که از صفحه‌خوان استفاده می‌کنند؛ پیمایش در صفحه، نیازمند تعیین ترتیب حرکت از یک عنصر به عنصر دیگر است. در دستگاه‌های موبایل، این پیمایش با حرکت سوایپ (کشیدن انگشت) انجام می‌شود، در حالی که در دسکتاپ، کاربران از کیبورد برای جابجایی بین عناصر استفاده می‌کنند. تعیین صحیح حالت‌های متمرکز (focus states) اطمینان می‌دهد که کاربران نابینا می‌توانند به ترتیب و بدون مشکل به تمام بخش‌های مهم صفحه دسترسی پیدا کنند.تست و ارزیابی تست با ابزارتست‌های دستی شامل تست با کیبورد و تست با صفحه‌خوان است. طراحان محصول پس از پیاده‌سازی هر ویژگی، باید از طریق صفحه‌خوان بررسی کنند تا عناصر صفحه به‌درستی برچسب‌گذاری شده‌ باشند و همه عناصر در صفحه قابل دسترسی هستند. در دسکتاپ، باید با استفاده از کیبورد، جریان طراحی شده را طی کرده و ترتیب حالت‌های متمرکز (focus states) را تست کنند.تست‌های اتوماتیک با استفاده از ابزارهایی مانند Arc Toolkit ،Lighthouse و... انجام می‌شوند. این ابزارها می‌توانند حدود ۲۰ تا ۳۰ درصد از مشکلات دسترس‌پذیری را شناسایی کنند.تست با کاربر واقعیمحصولات دیجیتالی باید با مشارکت کاربران نابینا یا کم‌بینا تست شوند تا اطمینان حاصل شود که تمامی عناصر به درستی کار می‌کنند. تست با کاربران واقعی، می‌تواند مشکلاتی را که ابزارهای اتوماتیک قادر به شناسایی آن‌ها نیستند را مشخص کند و به بهبود کلی دسترس‌پذیری کمک کند.نتیجه‌گیریدر دنیای دیجیتال امروز، تضمین دسترسی‌پذیری محصولات دیجیتالی از اهمیت بالایی برخوردار است. این امر باعث می‌شود که محصولات دیجیتالی توسط تمامی افراد با توانایی‌های مختلف قابل استفاده باشد.با رعایت اصول طراحی مانند برچسب‌گذاری مناسب، توصیف دقیق تصاویر، تنظیم درست حالت‌های متمرکز و انجام تست‌ها، می‌توان اطمینان حاصل کرد که محصولات دیجیتالی برای کاربران نابینا قابل دسترس هستند. همچنین، تست محصولات با کاربران واقعی نابینا می‌تواند به شناسایی و رفع مشکلاتی که در مراحل اولیه طراحی نادیده گرفته شده‌ است، کمک کند.با توجه به این موارد، توسعه‌دهندگان و طراحان باید همواره به دسترس‌پذیری توجه ویژه‌ای داشته باشند و آن را به عنوان یک بخش اساسی از فرآیند طراحی و توسعه محصول در نظر بگیرند. این تلاش‌ها باعث بهبود تجربه‌کاربری برای افراد نابینا و کم‌بینا می‌شود. به این ترتیب، ما می‌توانیم به‌سوی دنیایی حرکت کنیم که در آن همه افراد، صرف نظر از توانایی‌های جسمی خود، بتوانند به طور برابر از مزایای فناوری‌های دیجیتال بهره‌مند شوند. رویا خیرالهی رویا خیرالهی Fri, 26 Jul 2024 11:20:06 +0330 https://virgool.io/@m_52295666/%D9%85%D8%B7%D8%A7%D9%84%D8%B9%D9%87%D9%94-%D9%85%D9%88%D8%B1%D8%AF%DB%8C-%D8%AA%D9%85%D8%A7%D8%B3-%D8%A8%D9%84%D9%87-dqnsnslpmkvd مقدمهاین مطالعهٔ موردی در مورد ویژگی تماس اپلیکیش «بله» است که بیش از ۱۰ میلیون کاربر فعال ماهانه دارد. این ویژگی امکان برقراری تماس صوتی و تصویری را به صورت فردی و گروهی برای کاربرانی که در اپلیکیشن «بله» حساب کاربری دارد را ممکن می‌سازد. در روزهای عادی به طور میانگین ۶۰۰ هزار و در مناسبت‌های مختلف بیش از ۲ میلیون تماس در «بله» برقرار می‌شود.مسئلهبعداز لانچ محصول تماس «بله» و بررسی بازخوردها و نظرات مارکت‌های داخلی و گزارش‌های پشتیبانی به یک سری مسا‌ئل رسیدیم که یکی از مهترین موارد، برخی از کاربران جدیدی بودند که «بله» را نصب می‌کردند ولی نمی‌توانستند تماس «بله» را به راحتی پیدا کنند.برای پیدا کردن مشکلات تماس، تصمیم گرفتیم از تست کاربردپذیری استفاده کنیم.تست کاربردپذیری اولپس از تعریف مسئله، شروع به آماده‌سازی سند تست کردیم که در زیر به صورت خلاصه موارد مهم را توضیح می‌دهم.هدف تست اولمسائلی که کاربران جدیدی که «بله» را نصب می‌کنند، در برقراری تماس مواجه می‌شوند.در صورت اضافه شدن تاریخچهٔ تماس، کاربر این اطلاعات را کجا جستجو می‌کند؟انتخاب جامعه هدفبرای برگزاری این تست، به کاربرانی نیاز داشتیم که تا به حال از اپلیکیشن «بله» استفاده نکرده باشند. بنابراین ما «باغ کتاب تهران» را به عنوان محلی انتخاب کردیم که به ما امکان دسترسی به تعداد زیادی از کاربرانی را مهیا می‌ساخت که تا به حال از محصول ما استفاده نکرده بودند.متن پیشنهادی برای دعوت به تستسلام خوب هستین؟ ما نیاز داریم اپلیکیشن «بله» را تست کنیم. شما فرصت دارید در حد ۱۰ دقیقه تو تست ما شرکت کنید. اگر جواب بله بود: خیلی ممنون که وقتتونو در اختیار ما میزارید.بیان مقدمات و ترسیم فضای جلسه برای کاربرمن یک توضیح کلی در مورد فرآیند تست بهتون میدم. ما برای توسعه محصولات دیجیتال، معمولا با کاربرانمون در تعامل هستیم تا بتونیم محصولی طراحی بکنیم که برای کاربرها مفید باشه و به راحتی ازش استفاده کنند.اپلیکیشن «بله» چند وقتی هست که تماس اضافه کرده و در حال حاضر در حال توسعه این محصول هستیم. توی این جلسه ما یک حساب تستی برای شما آماده کردیم که شما ازش استفاده کنید و یک سری سوالات مطرح می‌کنیم و شما به آن‌ها پاسخ می‌دهید.این تست، صرفا تست تماس «بله» است و ما این محصول را تست می‌کنیم نه شما را و هیچ پاسخ درست و غلطی وجود ندارد و از شما می‌خوایم در طول تست هر چیزی که به ذهنتون میرسه رو بیان کنید و به این فک نکنید که پاسخی که می‌دهید درسته یا غلط.سناریو تست۱. اخیرا شما یک جایی شنیدید اپلیکیشن «بله» یک تماس صوتی و تصویری خوب داره. می‌خوام وارد اپلیکیشن بشید و ثبت نام کنید و با یک دوست فرضی به نام ابراهیمی تماس بگیرید.۲. فرض کنید وقتی آنلاین نبودید چند تا از دوستاتون باهاتون تماس گرفتند. این تماس‌هارو پیدا کنید. (فلوی برای این سناریو در محصول وجود ندارد و ما برای این سناریو از تست فیک استفاده کردیم)این تست به کمک همکارم فهیمه بهرامی انجام شد.نتایج تست:این تست در «باغ کتاب تهران» برگزار شد. به حدود ۸۰ نفر پیشنهاد حضور در تست داده شد و در نهایت با ۱۲ نفر تست موفق انجام شد.برای تحلیل نتایج تست ما نقشه سفر هر کاربر را بررسی کردیم و در نهایت برای هرسناریو به دیتای زیر رسیدیم:سناریو ۱: اخیرا شما یک جایی شنیدید اپلیکیشن «بله» یک تماس صوتی و تصویری خوب داره. میخوام وارد اپلیکیشن بشید و ثبت نام کنید و با یک دوست فرضی به نام ابراهیمی تماس بگیرید.در این سناریو، متوجه شدیم که کاربران با پیدا کردن لیست مخاطبین برای تماس مشکل دارند و تنها حدود ۱۶ درصد از کاربران با اولین کلیک موفق به پیدا کردن لیست مخاطبین شدند. علاوه‌بر این، مشکلاتی در بخش ثبت نام شناسایی کردیم که آنها را به تیم مربوطه ارجاع دادیم.سنایو ۲: فرض کنید وقتی آنلاین نبودید چند تا از دوستاتون باهاتون تماس گرفتند. این تماس‌هارو پیدا کنید.در این سناریو ۹۱ درصد کاربران برای پیدا کردن تاریخچه تماس‌ها، تب بالا را نگاه کردند و ۵۹ درصد برای پیدا کردن تاریخچه تماس، روی آن کلیک کردند.راه حل و طراحی:بعداز تحلیل نتایج تست و بررسی راه‌حل‌های پیشنهادی با ذی‌نفعان پروژه و در نظر گرفتن محدودیت‌های زمانی، برای نسخه اول به اقدامات زیر رسیدیم:بخش تماس با بیشترین درصد، به تب بالا بخش گفتگو اضافه شود.برای کاربران جدیدی که وارد بله می‌شوند، تب به صورت دوتایی نمایش داده شود.برای کاربران جدید تولتیپ تصویری تماس نمایش داده شود.در تب تماس برای حالتی که لیست تماسی ندارد، دکمه مخاطبین برای شروع تماس در وسط صفحه نمایش داده شود.بعداز اولین لاگ تماس، تولتیپ متنی روی‌ دکمه FAB نمایش داده شود.تست کاربردپذیری دومپس از پیاده‌سازی راه‌حل‌های ارائه شده برای ارزیابی راه‌حل‌ها، مجدد با ۷ کاربر همان سناریو را تست گرفتیم و با بهبود فلوی کاربران جدید برای تماس، ۱۰۰ درصد کاربرها با موفقیت لیست مخاطبین خود را پیدا کردند و تماس گرفتند.درس‌ آموخته‌های تستبرای دسترسی به کاربرانی که از محصول استفاده نکردند، «باغ کتاب تهران» که جای پرتردد و از لحاظ محیطی شرایط مناسبی برای تست دارد و خیلی راحت می‌توان کاربران هدف خود را پیدا کرد.در روز برگزاری تست در ساعات ابتدایی صبح، در محل حاضر شوید تا جای مناسبی پیدا کنید.پذیرایی مناسبی برای شرکت‌کنندگان آماده کنید.به افرادی پیشنهاد شرکت در تست را بدهید که از لحاظ ذهنی آمادگی حضور در تست را داشته باشند. افرادی که کسی منتظرشان نیست و وقت کافی دارند. تشخص این مورد کار سختی نیست؛ افرادی که سریع راه نمی‌روند، با تلفن همراه صحبت نمی‌کنند، دنبال چیزی نمی‌گردند و …برای انجام تست دستگاه و حساب تستی خود را در اختیار کاربران قرار دهید. این کار کمک می‌کند کاربران با کمترین مانع ذهنی در تست شرکت کنند. رویا خیرالهی رویا خیرالهی Tue, 03 Oct 2023 19:02:48 +0330 https://virgool.io/@m_52295666/%D8%AA%D8%A8%D9%84%DB%8C%D8%BA%D8%A7%D8%AA-%D8%AF%D8%B1-%D9%BE%DB%8C%D8%A7%D9%85%D8%B1%D8%B3%D8%A7%D9%86-%D8%A8%D8%A7%D9%86%DA%A9%DB%8C-%D8%A8%D9%84%D9%87-wegvoy9yg7qv در دنیایی که رقابت تجاری روز به روز در حال افزایش است، ما در «بله» به دنبال راه‌های درآمدزایی هستیم که بتوانیم ارزشی برای کسب و کارها و کاربرها ایجاد کنیم که باعث دیده شدن کسب و کارهای کوچک خانگی تا سازمان‌ها و مؤسسات بزرگ در «بله» شویم و هم بتوانیم بستری برای رشد کانال‌دارهای «بله» ایجاد کنیم. یکی از بهترین راه‌ها برای رسیدن به این هدف، استفاده از تبلیغات در «بله» است.هدفدو هدف اصلی که ما قصد داریم از طریق تبلیغات به آن دست یابیم، تبدیل شدن تبلیغات به یکی از کانال‌های درآمد برای «بله» و ایجاد ارزش برای صاحبان کانال، از جمله سازندگان محتوا و فروشندگان است.مرحله اولتحلیل رقبابرای طراحی MVP تبلیغات، نیاز بود فرآیند سفارش تبلیغات توسط کاربران و قوانینی که در پیامرسان‌ها به آن‌ها باید توجه شود را بررسی کنیم. به این منظور چندین محصول مختلف داخلی و خارجی بررسی شد که دو مورد از محصولات داخلی تو بخش پیامرسانی، گپ و ایتا بود. بعداز تحلیل رقبا، به یک سری دیتا در مورد اینکه چه قوانینی باید در نظر گرفته شود، چه اطلاعاتی از کاربر زمان سفارش تبلیغ باید گرفته شود و علاوه بر سرویس سفارش تبلیغ سمت کاربر، باید یک باتی سمت پشتیبانی طراحی شود تا قبل پرداخت کاربر، تبلیغ سفارش داده شده بررسی شود و در صورت عدم تطابق با قوانین تبلیغات از لیست سفارش‌دهندگان حذف شود.نقشه سفر کاربربراساس فرضیه ذی‌نفعان و نتایج تحلیل رقبا به یک نقشه سفر مشتری که وضعیت ایده‌آل کاربر در محصول سفارش تبلیغ در آینده را نشان می‌دهد، رسیدیم و هدف اصلی این نقشه، بررسی مراحل مختلف و نقاط تماس کلیدی در سفر کاربر است و به اعضای تیم برای رسیدن به درک مشترک و حرکت سریع به سمت پیاده‌سازی محصول را آموزش می‌دهد. بعداز طراحی نقشه سفر کاربر، برامون شفاف شد که تو چه بخش‌های نیاز به طراحی فلو داریم.یوزر فلودر بخش سفارش تبلیغ با توجه به بالا بودن تعداد کاربران پیامرسان «بله»، برای انجام تبلیغات، لازم است کاربر سفارش‌دهنده تبلیغ، قابل اعتماد باشد. در مرحله اول که سفارش از سمت کاربر ثبت می‌شود باید از سمت ادمین بررسی شود که آیا شرایط و قوانین رعایت شده است یا خیر. برای این مورد ما یک فلو سمت کاربر و یک فلو بات سمت ادمین برای تایید و رد درخواست‌ها در نظر گرفتیم.در بررسی کلی برای نمایش تبلیغ، به ۳ جایگاه سرچ، تب گفتگو و ویترین که پتانسیل نمایش تبلیغ را داشت که هم سمت سفارش‌دهنده تبلیغ و هم کاربران «بله» راضی باشند، رسیدیم. با بررسی تعداد بازدیدهای روزانه، تب گفتگو با ۲۵ میلیون بازدید انتخاب شد.طراحیپس از یوزر فلو، طراحی سفارش تبلیغ سمت کاربر را انجام دادیم و برای سمت ادمین به دلیل هزینه بالای پیاده سازی، از بات استفاده کردیم.تحلیل دیتابه مدت چند روز بعد از پیاده‌سازی اولیه سرویس سفارش تبلیغ، از طریق یک سری راه‌های ارتباطی که کانال‌دارهای «بله» در آن عضو هستند، اطلاع‌رسانی اولیه انجام شد که تعداد درخواست‌های ثبت شده ۱ درصد اعضای کانال، تعداد درخواست‌های تایید شده از بین تعداد ثبت شده‌ها ۱۳ درصد و تعداد پرداختی‌ها ۱۷ درصد بود.مرحله دوممسئلهتعداد پرداختی‌ها نسبت به تعداد درخواست‌های تایید شده (Conversion rate) حدود ۱۷ درصد است که رقم خیلی کمی بود.مصاحبه با کاربربرای بررسی مسئله تعریف شده، بعداز تحلیل داده‌ها از متد مصاحبه استفاده کردیم که دلیل اصلی پرداخت نکردن کاربران را مشخص کنیم.جامعه هدف: کانالدارانی که برای سفارش تبلیغات درخواست داده بودن و محتوا و سایر موارد کانال آن‌ها از سمت ادمین تایید شده بود و پیام پرداخت را دریافت کردند ولی در مهلت ۲۴ ساعته، پرداختی انجام ندادند.تعریفبعد از مصاحبه با کاربرانی که پیام تایید درخواست‌شان را دریافت کرده بودند و پرداختی انجام نداده بودند، به ۳ سناریوی کلی رسیدیم.من به عنوان کسی که تمایل دارم کسب و کارم را از طریق تبلیغ توسعه دهم. زمان ثبت درخواست، هزینه‌ی نهایی را ندیدم. بعد تایید، متوجه هزینه شدم و به دلیل بالا بودن هزینه، پرداخت نکردم.من به عنوان کسی که تو پلتفرم‌های دیگه مثل آپارات و کافه بازار و ... تبلیغ میدیم با مقایسه‌ی قیمت‌ها، هزینه «بله» خیلی بالا بود.من به عنوان کسی که تمایل دارم از پیام‌رسان ایرانی استفاده کنم ولی چون از میزان بازدهی «بله» مطمئن نیستم و هزینه‌ی تبلیغ برام خیلی زیاد بود، این رسیک را نکردم.ایده‌پردازیبعداز سناریوهای تعریف شده، به کمک تیمی که شامل بچه‌های دیتا، مارکتینگ، مدیران و...بودند، جلسه‌ی ایده‌پردازی برگزار شد و حدود ۲۱ ایده مطرح شد که با رای‌گیری به ۳ ایده نهایی برای این سناریوها رسیدیم.طراحیسناریو ۱: در نظر گرفتن صفحه‌ی جدا برای پرداخت و تایید نهاییسناریو ۲: پیشنهاد ثبت درخواست‌ با تعداد بازدید پایین‌ترسناریو ۳: پیشنهاد ثبت درخواست با قیمت پایین‌تر به ازای هر بازدیدتحلیل دیتابا اعمال تغییرات، نسبت تعداد پرداختی‌ها به کل درخواست‌های تایید شده (Conversion rate) از ۱۷ درصد به ۵۶ درصد افزایش پیدا کرد.مرحله سوممسئلهکاربرانی که اولین بار سفارش خود را ثبت کرده بودند و تبلیغ آن‌ها در تب‌گفتگو نمایش داده شده بود، حاضر به استفاده‌ی مجدد از تبلیغات نبودند.مصاحبه با کاربربرای بررسی این مسئله، مجدد به سراغ کاربران رفتیم، چون یکی از کم هزینه‌ترین راه‌ها برای رسیدن به پاسخ بود.جامعه هدف: کاربرانی که یک‌بار تبلیغ سفارش داده‌اند و تبلیغ آن‌ها در «بله» نمایش داده شده است. affinity diagramبعد از مصاحبه با کاربران که تبلیغ برای آن‌ها انجام شده بود، به دسته‌بندی‌های زیر رسیدیم.تعریفبعداز دسته‌بندی نتایج مصاحبه به چند مشکل رسیدیم که اصلی‌ترین مشکل ما کم بودن بازدهی نسبت به هزینه است که اغلب کاربرها اشاره کردند.ایده‌پردازیبعداز تعریف مشکل، مجدد به کمک تیمی که روی تبلیغات کار می‌کردیم، جلسه‌ی ایده‌پردازی برگزار شد و ایده‌هایی مطرح شد که با رای‌گیری به ۳ ایده نهایی رسیدیم.قیمت‌گذاری را متناسب با بازدهی تغییر دهیم.هر بازدید را به ازای کاربر یکتا محاسبه کنیم.علاوه بر تبلیغات ویویی، تبلیغات کلیکی هم اضافه شود.طراحیسناریو ۱: مبنای قیمت‌گذاری فعلی ادنتورک‌ها (یکتانت و تپسل) بودند. با توجه به انتظار کاربران، مبنا را رقبای نزدیک‌تر مانند ایتا و اینستاگرام در نظر گرفتیم.نتیجهبا تغییرات اعمال شده، میزان بازدهی به ۴ برابر افزایش پیدا کرد. با توجه به بررسی‌های انجام شده، تا این مرحله بازدهی به حد اشباع رسید و متوقف شد. در این مرحله با در نظر گرفتن سود کسب و کار تا مدتی تمرکز اصلی تیم روی جذب و نگه داشت کاربران جدید از طریق سرویس‌های دیگر «بله» است.یکی از این سرویس‌ها سامانه اربعین بود که باعث شد تعداد کاربران فعال ماهانه افزایش پیدا کند و Engagement کاربران زیاد شود که این باعث افزایش بازدهی تبلیغات شد و «بله» علاوه بر این موارد با وارد کردن تبلیغات به Business-to-business توانست به تارگت درآمدی ماهانه‌ای که برای تبلیغات تعیین کرده بود، برسد که این دو مورد باعث شد موتور رشد تبلیغات روشن شود و توسعه محصول ادامه‌دار شود و فرآیندهایی که تا این مرحله کامل دستی انجام می‌شد به سمت سیستمی برود و برای تبلیغات، پنل جدا طراحی شود. رویا خیرالهی رویا خیرالهی Thu, 28 Sep 2023 22:13:19 +0330 https://virgool.io/@m_52295666/%D9%85%D8%B7%D8%A7%D9%84%D8%B9%D9%87%D9%94-%D9%85%D9%88%D8%B1%D8%AF%DB%8C-%D9%BE%D8%B1%D8%B3%D9%88%D9%86%D8%A7-%D9%85%D8%AF%D8%A7%D8%B1%D8%B3-%D8%A8%D9%84%D9%87-xhlkxgdsgozq پرسوناها نماینده‌هایی از مخاطبان هدف محصول ما هستند که رفتارها، اهداف، انگیزه‌ها و نیازهای مشابهی در محصول دارند و ما در محصول سعی می‌کنیم نیازهایشان را برطرف کنیم.هدفدر دوره شهریور سال ۱۳۹۹ و ۱۴۰۰، که در آن ما با شیوع ویروس کرونا و تغییرات بسیار در حوزه آموزش و استفاده از ابزارهای دیجیتال مواجه بودیم، متوجه شدیم که تعداد زیادی کاربر از طرف مدارس به «بله» پیوستند. هدف ما در این تحقیق بررسی اهداف، نیازها، رفتارها و چالش‌های این گروه از کاربران در «بله» بود و در صورت لزوم، اقداماتی را برای پاسخگویی به این نیازها در نظر بگیریم.بخش‌بندیبرای بخش‌بندی، به کمک تیم دیتا کاربران را در ۴ دسته زیر گروه‌‌بندی کردیم.کاربران قدیمی کادر مدرسه: برای مصاحبه، ۲۵ نفر از ادمین گروه‌های مدرسه‌ای که در سال گذشته در «بله» گروه ساختند و همچنان فعالیت دارند، انتخاب شد.کاربران جدید کادر مدرسه: برای مصاحبه، ۲۵ نفر از ادمین گروه‌های مدرسه‌ای که از ماه شهریور به بعد، گروه ساختند و خود ادمین هم در ۲ ماه اخیر حساب کاربری بله‌اش ساخته شده بود، انتخاب شد.کاربران قدیمی دانش‌آموز: برای مصاحبه، ۲۵ نفر از کسانی که در گروه‌های مدرسه‌ای که در شهریور سال گذشته عضو شدند ولی دیگر فعالیتی ندارند. (بیشتر از دوماه هست که به برنامه سر نزدند)کاربران جدید دانش‌آموز: برای مصاحبه، ۲۵ نفر از کسانی که در گروه‌های مدرسه‌ای از ماه شهریور به بعد عضو شدند و خود کاربر هم در ۲ ماه اخیر، حساب کاربری بله‌اش ساخته شده بود.هدف از انتخاب کاربران جدید در هر دو دسته‌ی کادر مدرسه و دانش آموز، شناخت آن‌ها در مواجهه‌های اول با محصول بود. اینکه چه مشکلات و نیازهایی دارند و هدف از انتخاب کاربران قدیمی، شناخت کاربرانی که بیشتر به محصول مسلط هستند. این گروه می‌توانستند اطلاعات زیادی در مورد نیازها، مشکلات و…. دهند.طراحی پیش‌نویس مصاحبهاین پیش‌نویس شامل هدف، مخاطبان هدف، سوالات مصاحبه، اطلاعات شخصی برای معرفی خودمان و یک تمپلیت برای نتایج مصاحبه در نظر گرفته شد. یکی از مهم‌ترین بخش‌‌های این پیش‌نویس، سوالات مصاحبه است که باید به زبان کاربر ترجمه می‌کردیم. به دلیل شرایط کرونا، ما مصاحبه تلفنی را انتخاب کردیم و در طراحی سوالات این مورد را در نظر گرفتیم که به علت مصاحبه به صورت تلفنی، زمانی زیادی را از کاربر نگیریم. پس از طراحی سوالات، این سند را با سایر اعضای شرکت که به این پروژه مرتبط می‌شد، به اشتراک گذاشتیم و نظرات آن‌ها را درباره این سوالات بررسی کردیم و در نهایت یک‌سری سوالات را نهایی کردیم. بعداز تکمیل این سند، یک مصاحبه آزمایشی با همکارم که قرار بود این تحقیق را باهم انجام دهیم، برگزار کردیم و مواردی که نیاز بود در سند اصلاح شود یا مواردی که در طول مصاحبه بهتر بود رعایت کنیم را اعمال کردیم.مصاحبه با کاربرانبه دلیل برگزاری مصاحبه‌ها به صورت تلفنی، مدت زمان هر مصاحبه معمولا بین ۵ تا ۲۰ بود. در ابتدای مصاحبه تلاش ‌می‌کردیم تا اطلاعات شخصی از کاربران نگیریم. تنها در صورت تمایل طرف مقابل به ادامه مصاحبه، سوالاتی شخصی مورد نیاز را مطرح می‌کردیم و این اطمینان را به کاربران می‌دادیم که این اطلاعات گرفته شده محرمانه است و صرفا برای بهبود تجربه‌ی کاربری استفاده می‌شود.در طول مصاحبه، با چالش‌هایی مواجه شدیم که عبارتند از:برخی از کاربران تمایلی به ادامه مصاحبه نداشتند.برخی از کاربران به دلیل احساس ترس، اطلاعات صحیح را ارائه نمی‌کردند.شماره‌هایی که داشتیم، کاربران پاسخگو نبودند.برخی از کاربران در بازه‌ی سنی ۹ تا ۱۲ سال قرار داشتند و در سوالات مصاحبه، این گروه سنی را در نظر نگرفته بودیم و بعد از دومین مورد، سوالات مصاحبه را برای این گروه سنی ترجمه کردیم و به پیش‌نویس مصاحبه اضافه کردیم.…..در کل با برگزاری مصاحبه با ۵۸ نفر از ۴ گروه مختلف، به اشباع نظری رسیدیم.تحلیل نتایج مصاحبهبعد از انجام مصاحبه، ما به کدگذاری نتایج پرداختیم و از روش کدگذاری قیاسی استفاده کردیم. در طول مصاحبه، این کدگذاری‌ها را اعمال کرده و با برآوردی که انجام دادیم، کدگذاری هر مصاحبه‌، شش برابر مدت زمان واقعی مصاحبه بود.فرآیندی که ما برای کدگذاری داشتیم، به کمک همکارم هر کدام از مصاحبه‌ها را در Google form وارد می‌کردیم. سپس هر مصاحبه‌ی انجام شده را در بخش‌های مختلفی مانند نیازها(کارت زرد)، انگیزه‌ها(بنفش)، فرصت‌ها(سبز)، مشکلات(قرمز) و سایر(سفید) دسته‌بندی کردیم و همچنین یک قسمت دموگرافیک هم برای هر بخش متناسب با دیتاهای که از شرکت‌کنندگان دریافت کرده بودیم، وارد کردیم. پس از آن، کدهای ایجاد شده را بررسی کردیم و تفاوت‌ها، شباهت‌ها و تضاد‌ها را مورد بررسی قرار دادیم و مواردی که در یک گروه قرار گرفتند برای هر گروه، کدهای تفسیری جدیدی در نظر گرفتیم.طراحی پرسونابعد از انجام کدگذاری بر روی ۵۸ مصاحبه انجام شده، ما توانستیم بر اساس الگوهای رفتاری مشابه، این مصاحبه‌ها را به ۵ دسته‌ی مختلف تقسیم کنیم. این دسته‌ها شامل دبیران، دانش‌آموزان، اولیا، نماینده‌های دانش‌آموزان و نماینده‌های اولیا بودند. با انجام بررسی بیشتر، ما به ۳ پرسونای کیفی برای دانش‌آموزان، اولیا و دبیران رسیدیم که  اهداف، نیازها و الگوهای رفتاری مشابهی داشتند.پس از طراحی پرسونا، ما نیازمندی‌های اصلی این ۳ پرسونا را شناسایی کردیم و آن‌ها را به تیم محصول ارائه دادیم. سپس، بر اساس این نیازمندی‌ها، راهکارهای محصولی برای پاسخ به آن‌ها طراحی شد و در اولویت پیاده‌سازی لاین پلتفرم قرار گرفت. رویا خیرالهی رویا خیرالهی Thu, 28 Sep 2023 22:03:41 +0330 https://virgool.io/baleacademy/%D9%81%D8%B1%DB%8C%D9%85-%D9%88%D8%B1%DA%A9-%D9%87%D8%A7%D8%B1%D8%AA-%DA%AF%D9%88%DA%AF%D9%84google-heart-framework-sfkryz8xqlfo همه می‌دانند که طراحی تجربه‌کاربری داده‌محور بهتر از طراحی و توسعه تجربه‌کاربری احساسی است.درحال حاضر‌‌،ما بیش از هر زمان دیگری به داده‌ها دسترسی داریم،اما این کار مدیریت داده‌ها را آسان نمی‌کند.فقط شرکت‌های کوچک نیستند که با این مسئله روبه‌رو شده‌اند،حتی تیم‌های تحقیقاتی یوایکس گوگل هم با داده‌های رفتاری در مقیاس گسترده‌ای روبه‌رو شده‌اند.بنابراین،تیم‌های تحقیقاتی یوایکس گوگل،برای سنجش کیفیت تجربه‌کاربر،فریم‌ورک‌هارت گوگل(Google Heart Framework) را ارائه دادند که به اندازه‌گیری پیشرفت برای رسیدن به اهداف اصلی و تصمیم‌های مربوط به محصول کمک می‌کند.فریم‌ورک‌هارت(Heart Framework) روشی خوب برای اندازه‌گیری کیفیت تجربه‌کاربر برای به دست آوردن بینش عملی است.تجربه‌کاربر نه‌تنها باید به‌خوبی طراحی شود،بلکه باید به‌خوبی اندازه‌گیری شود.به‌صورت دقیق‌تر بررسی می‌کنیم که فریم‌ورک‌هارت گوگل(Google Heart Framework) چه‌طور به شما در اندازه‌گیری تجربه‌کاربر کمک خواهد کرد.این فریم‌ورک ایده‌ اصلی تیم تحقیقاتی یوایکس گوگل است که معیارهای مفید محصول را در پنج دسته قرار داده است.با قرار دادن این دسته‌ها کنار هم به مخفف Heart رسیده‌اند که یک نوعی ساختار جامع برای سازمان‌دهی داده‌های مربوط به تجربه‌کاربر است.فریم ورک هارت گوگل(Google Heart Framework) Happiness___H:میزان رضایت کاربر از محصول ونگرش را نشان می‌دهد.شما می‌توانید میزان رضایت را در مقیاس وسیع از طریق نظرسنجی‌های کاربر اندازه‌گیری کنید.نظرسنجی درون‌محصولی سطح رضایت را بیشتر از نظرسنجی از طریق ایمیل نشان می‌دهد.Engagement___E:میزان تعامل کاربر با محصول را در یک بازه زمانی مشخص اندازه‌گیری می‌کند.برخی متغیرهای خاص برای اندازه‌گیری عبارت‌اند از:میزان استفاده وسطح تعامل در طی یک دوره زمانی خاص،برخی نمونه‌ها شامل تعداد بازدیدها به ازای هر کار در مدت زمان خاص و... اما توجه کنید که معیارهای مناسب،بسته به جایگاه شما،متفاوت خواهد بود.Adoption___A: در بازه زمانی مشخص،محصول یا ویژگی به روز شده چه تعداد کاربر جدید می‌یابد.برای مثال وقتی ویژگی جدیدی به محصول اضافه می شود،شروع به سنجش تعداد کاربرانی می‌کنیم که در طی دو هفته از این ویژگی استفاده کرده‌اند. Retention___R:میزان بازگشت کاربران به محصول را اندازه‌گیری می‌کند،برای مثال تعداد کاربران فعال شمادر بازه زمانی مشخصی که در برخی زمان‌های دیگر هم حضور دارند ودر هنگام ارائه نسخه جدید معیار نگهداری بسیار مفید خواهد بود. Task success___T:این متغیر معیاری فنی به نظر می‌رسدزیرا شما زمان انجام کار یا میزان خطا را در آن کار خاص را اندازه‌گیری خواهید کرد.برای مثال زمان بارگذاری هر پست در اینستاگرام اندازه‌گیری می‌شود.معیارهای(Metrics) فریم ورک‌هارت(Heart Framework) برای طراحی کل محصول یا ویژگی‌های خاص اعمال می‌شود واین معیارها به تیم محصول کمک می‌کند تا معیارهای لازم را برای جمع آوری داده بداند.اکنون که همه‌ دسته‌بندی‌ها را در فریم ورک‌هارت گوگل(Google Heart Framework) دانستید، می‌خواهید یکی یا دوتایش را برای محصول خود انتخاب کنید.اما چگونه می‌توانید تصمیم بگیرید که کدام معیارها(Metrics) را اندازه بگیریدو کدام‌یک را حذف کنید؟همه‌چیز با هدف شروع می‌شود این یکی از فرایندهای GSM (اهداف،سیگنال‌ها،معیارها) است که شما باید شناسایی کنید.شناسایی اهداف تجربه‌کاربری هر محصول ممکن است پیچیده باشد،این فریم‌ورک ممکن است تیم را به‌سمت هدف مشترک متحد کند و اهداف پروژه را از اهداف محصول دور کند.برای مثال، همه می‌خواهند تعداد زیادی کاربر در اپلیکیشن داشته باشند،بااین‌حال آن‌ها باید تصمیم بگیرند که کدام معیار را می‌خواهند اندازه بگیرند؟تعامل یا کاربران جدید.مرحله بعد در فرایند GSM سیگنال است.اقداماتی که نشان می‌دهد هدفی برآورده شده است یا احساساتی که با موفقیت وشکست ارتباط دارد باید در اینجا ترسیم شود.مرحله آخر در فرایند GSM معیار(Metrics)است اینجاست که داده‌های بزرگ به آمار تبدیل می‌شود،سپس آن‌ها را با استانداردهای محصول مقایسه می‌کنیم.برای مثال، در یک فروشگاه اینترنتی نسبت تعداد کاربرانی که خرید می‌کنند به تعداد کل کاربرانی که از سایت بازدید کرده‌اند. اگر می‌خواهید طراحی محصول شما با داده‌های بزرگ پشتیبانی شود فریم‌ورک‌هارت گوگل (Google Heart Framework)پاسخگوی شماست. رویا خیرالهی رویا خیرالهی Fri, 14 May 2021 18:34:59 +0430 https://virgool.io/@m_52295666/%D8%AA%D8%B3%D8%AA-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF%D9%BE%D8%B0%DB%8C%D8%B1%DB%8C-alffvwd8hl9g تست کاربردپذیری یکی از متدهای تجربه‌ی کاربری است که با انجام ان می توان مشکلات موجود در محصول (اپلیکیشن یا وب سایت) را شناسایی کردوفرصت ها برای بهبود محصول را کشف کرد ومیزان کاربردی بودن محصول برای مشتری را مشخص کرد چون اگر محصولی کاربردپذیر نباشد با گذشت زمان توسط کاربران مورد استفاده قرار نمی گیرد و ریزش کاربر به معنی شکست محصول است.با انجام تست کاربردپذیری تیم طراحی و تیم توسعه محصول قبل از لانچ محصول می توانند مشکلات را شناسایی کنند وبا هزینه‌ی کمتر از لحاظ زمان هزینه ونیروی انسانی ان‌ها را برطرف کنند.برای انجام تست کاربردپذیری باید چه کار کنیم؟قبل از انجام تست کاربردپذیری باید مشخص کنید که از چه تعداد شرکت کننده برای انجام تست استفاده خواهیم کرد.جالب است بدانید که با تست گرفتن از 5 نفر می توانیم حدودا 85 درصد از مشکلات کاربردپذیری را به دست اوریم که با توجه به هزینه‌ی که برای این تست میشه درصد قابل قبولی است.نوشتن یک تست کاربردپذیری خوب کار سخت و پیچیده ای نیست اگر به چند نکته توجه کنید:انواع تست کاربردپذیری داریم اما عناصر اصلی همه‌ی تست ها سناریو و ناظرجلسه و شرکت کننده‌ها می باشد.ناظرجلسه فردی است از طرف تیم طراحی که در جلسه حضور دارد.از وظایف ناظر جلسه این است که همه‌ی نکات ضروری در مورد تست را به شرکت کننده ارائه دهد توجه کنید که این تست را با گفتگو در مورد محصول اشتباه نگیرید.کاربر باید احساس کند که تنهاست و سعی کنید هیچ سوالی را پاسخ ندهید تا کاربر بتواند رفتار واقعی خود را در مواجه با محصول نشان دهد.شرکت کننده باید یک فرد باشد که در حال استفاده از محصول در زندگی واقعی باشد یا ممکن است یک پیش زمینه‌ی مشابه با گروه کاربران هدف داشته باشد یا ممکن است همان نیازها را داشته باشد حتی اگر قبلا از محصول استفاده نکرده باشند. وشرکت کننده باید سعی کنند در جلسه بلند بلند فکر کند یعنی هر سوالی که به ذهنش امد بلند بگوید این اطلاعات می تواند کمک بزرگی به محصول بکند.سناریو تست بهتر است به صورت یک داستان طراحی شود وبه جای کلمات مبهم از کلمات مشخص استفاده کنید داستانی بودن سناریو باعث می شود کاربرخودشو در ان موقعیت تصور کند و هر سناریو شامل چند تسک می باشد.مثال: _فرض کنید یک اخر هفته‌ی زمستانی در خانه تنها هستید و می خواهید وقت خود رابا دیدن فیلم سپری کنید.یک فیلم ترسناک که بالاترین امتیاز را گرفته است برای تماشا انتخاب کنید._این فیلم را برای مشاهده‌ی بعدی در لیست مورد علاقه ذخیره کنید._تصمیم میگیرید پس از فیلم ترسناک یک فیلم با حضور تام هنگس ببینید فیلم مورد علاقه‌ی خود را پیدا کرده و ان‌ها را ذخیره کنید.این سناریو یک داستانی را برای کاربر تعریف می کند که امکان دارد که کاربر در ان موقعیت قرارگرفته باشد و بتواند با این سناریو‌ها فضای ذهنی کاربر را برای انجام وظایف اماده کند. رویا خیرالهی رویا خیرالهی Tue, 16 Mar 2021 14:37:46 +0330