پست‌های انتشارات تیم محصول صباایده

نکته‌های کاربردی برای تجربه‌نویسی در فلوی لغو اشتراک

دردانه شیبانی — Sun, 20 Oct 2024 16:56:36 +0330

من دردانه شیبانی نویسنده تجربه کاربری در محصولات فیلیمو، آپارات، سینماتیکت و … هستم. در این مقاله نکاتی را که در پروژه متن‌های تجربه کاربری برای فلوی لغو اشتراک با تمدید خودکار در فیلیمو به آن‌ها رسیدم، به صورت یک مطالعه موردی با شما به اشتراک می‌گذارم.در دنیای محصولات دیجیتال، نوشتن تجربه کاربری (UX Writing) نقشی حیاتی در ایجاد ارتباط مؤثر با کاربران دارد. این اهمیت در فرآیندهای حساس مانند لغو اشتراک با تمدید خودکار دوچندان می‌شود، زیرا کاربران در این لحظات به تجربه‌ای روان، شفاف و همدلانه نیاز دارند. اگر لغو اشتراک به‌درستی مدیریت نشود، ممکن است تجربه‌ای منفی از برند در ذهن کاربر باقی بماند و احتمال بازگشت او کاهش یابد. به همین دلیل، نوشتن پیام‌های دقیق و همدلانه در این مراحل اهمیت ویژه‌ای پیدا می‌کند.در ادامه براساس جریان کاربری لغو اشتراک خودکار در محصول فیلیمو پیش می‌رویم و نکات تجربه نویسی (UX Writing) هر مرحله را در یک پروژه کاری واقعی با هم بررسی می‌کنیم.۱- صفحه مدیریت اشتراککاربر در بخش مدیریت اشتراک و قبل از لغو، می‌تواند وضعیت اشتراک با تمدید خودکار خود را ببیند.صفحه مدیریت اشتراک در فیلیمونکته‌ها:در این صفحه باید وضعیت اشتراک با تمدید خودکار شامل تاریخ فعال شدن اشتراک، تاریخ تمدید بعدی و ... به کاربر اعلام شود.از نکات مهمی که در این صفحه لازم است به آن پرداخته شود، یادآوری این نکته است که مبلغ به صورت خودکار از حساب او کسر می‌شود.به مبلغ دقیقی که از حساب کاربر برداشته می‌شود اشاره کنیم.اگر در درگاه پرداخت مبلغی به عنوان مالیات اضافه می‌شود خوب است در این مرحله به آن اشاره شود.نکته مهم بعدی امکان لغو اشتراک در همین صفحه است. هرچند موضوع دیزاینی است اما ما هم به عنوان یوایکس رایتر باید با کلمات این اطمینان را به کاربر بدهیم که میتواند بدون دردسر و در هر زمان اشتراکش را لغو کند.۲- صفحه مزایای اشتراک با تمدید خودکاراین صفحه در فلوی لغو اشتراک با تمدید خودکار مرحله مهمی است. چرا که این فرصت را داریم که یک بار دیگه مزایای اشتراک را به کاربر بگوییم و در تصمیم گیری به او کمک کنیم.مزایای اشتراک با تمدید خودکار در فیلیمو نکته‌ها:هنگام نوشتن مزایا به دغدغه‌های کلی کاربران در مورد محصول هم توجه کنیم. چطور؟ برای این کار دیتای کیفی را از طریق خواندن نظرات متنی کاربران در فضایی مثل کافه بازار و همچنین گوش دادن به دغدغه‌های کاربران در تماس‌های پشتیبانی بررسی می‌کنیم و مزایا را براساس این داده ارزشمند اولویت‌بندی می‌کنیم.اگر تخفیف یا قیمت پایین‌تر جزو مزایایی است که با آن اشاره می‌کنیم، قیمت قبل و بعد را به کاربر نمایش دهیم و او را متوجه به‌صرفه بودن این نوع اشتراک کنیم.با اینکه ما ترجیح می‌دهیم کاربر اشتراک را لغو نکند، متن CTA لغو اشتراک را واضح بنویسیم و دکمه را به عنوان CTA اولیه در دسترس او بگذاریم تا کاربر بدون اشتباه و سردرگمی اشتراکش را لغو کند. اگر کاربر به خاطر طراحی ما دکمه لغو اشتراک را به راحتی نبیند و به اشتباه دکمه دیگری مثل ادامه اشتراک (انصراف از لغو) را بزند و بعدا متوجه شود اشتراکش برخلاف میلش همچنان فعال مانده، باعث نارضایتی او از محصول و بی‌اعتمادی به برند ما می‌شود.۳- صفحه دلایل لغو اشتراکاین قسمت از این جهت نقطه مهمی است، که به شما اطلاعات زیادی در مورد دلایل لغو اشتراک توسط کاربر می‌دهد.اما از آنجایی که به هر حال در این صفحه با کاربری که به هر دلیل از اشتراک شما ناراضی بوده و آن را لغو کرده طرف هستید، لازم است نکاتی را برای جلوگیری از نارضایتی بیشتر در نظر بگیرید.صفحه دلایل لغو اشتراک در فیلیمونکته‌ها:پرسیدن دلایل لغو اشتراک از کاربر باید محترمانه باشد و با عبارتی مثل “نظر شما به بهبود سرویس/خدمات ما کمک می‌کند”، به نظر او ارزش بیشتری بدهیم.گزینه‌های دلایل لغو اشتراک را هم می‌توانیم با خواندن نظرات کاربران و گوش دادن به تماس‌های پشتیبانی در مورد همین صفحه اولیت‌بندی کنیم و بنویسیم.دلایل لغو اشتراک را به‌صورت اول شخص بنویسیم تا کاربر احساس نزدیکی بیشتری کند.۴- صفحه پیام موفقیت و پیشنهاد اشتراک‌های دیگردر این صفحه به کاربر اعلا می‌کنیم که اشتراک با تمدید خودکار با موفقیت لغو شده.نکته‌ها:در پیام موفقیت اشاره کنیم که اشتراک به درخواست خودت لغو شده، تا از سوتفاهم جلوگیری شود.این‌ مرحله نقطه خوبی برای پیشنهاد دادن اشتراک‌ها یا سرویس‌های دیگر به کاربر است.در CTAها فقط امکان دیدن اشتراک‌های دیگر را قرار ندهیم و امکان خروج از صفحه یا بازگشت به صفحه خانه را هم در دسترس کاربر بگذاریم.در نهایت، تجربه‌نویسی (UX Writing) در جریان‌های حساسی مانند لغو اشتراک با تمدید خودکار می‌تواند تفاوت چشمگیری در تجربه کاربران ایجاد کند. پیام‌های دقیق، شفاف و همدلانه در هر مرحله از این فرآیند به کاربران حس کنترل و اطمینان می‌دهد و از بروز نارضایتی‌های احتمالی جلوگیری می‌کند. همان‌طور که در این مقاله بررسی کردیم، توجه به نیازها و دغدغه‌های کاربران، شناخت عمیق از داده‌های کیفی، و ایجاد ارتباط مؤثر با آن‌ها، همگی عواملی هستند که به بهبود تجربه کاربری کمک می‌کنند.رعایت این نکات نه تنها باعث می‌شود کاربر با احساس خوبی از سرویس خداحافظی کند، بلکه به ایجاد تصویری مثبت از برند و افزایش شانس بازگشت او در آینده نیز کمک می‌کند. به یاد داشته باشید که حتی در لحظات جدایی، تجربه کاربر باید همدلانه و حرفه‌ای باشد، چرا که در دنیای رقابتی امروز، هر لحظه فرصتی برای ایجاد اعتماد و تعامل دوباره با کاربران است.

چک‌لیست ضروری ارزیابی هیوریستیک برای محققان تجربه کاربری

کیمیا زمانپور — Tue, 12 Dec 2023 16:15:06 +0330

من کیمیا زمان‌پور هستم. محقق تجربه کاربر (UX Researcher) تیم یوایکس صباایده که وظایفی مثل ارزیابی جریان‌های کاربری، سنجش کاربردپذیری، استخراج و تحلیل دیتای کمی و کیفی، را در محصولات آپارات، فیلیمو، و سینماتیکت برعهده دارم.به عنوان یک محقق تجربه کاربر، معمولاً پروژه‌هایم را با بررسی وضعیت موجود یک محصول یا جریان کاربری (UX Expert Review) شروع می‌کنم. این بررسی اولیه برای شناسایی نقاط ضعف،قوت و موارد قابل بهبود در تجربه کاربر در یک محصول حیاتی است. یکی از متد‌هایی که برای بررسی اولیه و ارزیابی استفاده می‌کنم، Heuristic Evaluation (تحلیل اکتشافی) است که در این مقاله این روش تحلیل را به شما معرفی می‌کنم.مزایای تحلیل اکتشافیبه طور کلی تحلیل اکتشافی در جواب دادن به این سوالات به شما کمک می‌کند:روند تصمیم‌گیری کاربر در یک جریان کاربری یا محصول چیست؟آیا شرایط لازم و مناسب برای تصمیم‌گیری کاربر در محصول مهیا است؟از چه راهکارهایی می‌توان برای بهبود این جریان کاربری استفاده کرد؟موضوعات این مقاله:مفهوم Heuristic Evaluation Checklist یا همان چک‌لیست تحلیل اکتشافیمعرفی ۲ چک‌لیست‌ معروف تحلیل اکتشافی (Heuristic Evaluation)چک‌لیست ۷ مرحله‌ای تحلیل اکتشافی (Heuristic Evaluation)مراحل تصمیم‌گیری و تبدیل کاربر (conversion)راهکاری برای افزایش اعتبار تحلیل اکتشافیمفهوم Heuristic Evalation Checklist یا همان چک‌لیست تحلیل اکتشافیهیوریستیک به معنی میان‌برهای ذهنی است که به ما کمک می‌کنند تصمیم‌گیرهای سریع‌تر و با بار ذهنی (Cognitive load) کمتری داشته باشیم و منظور از تحلیل اکتشافی بررسی محصول بر اساس بهترین روش‌ها (Best practices) و استراتژی‌های امتحان شده است، که امکان شناسایی سریع‌تر و آسان‌تر مشکلات تجربه کاربری را به ما می‌دهد.فواید ارزیابی با تحلیل اکتشافیمعرفی ۲ چک‌لیست‌ معروف تحلیل اکتشافی (Heuristic Evaluation)برای انجام تحلیل اکتشافی، قالب‌های متفاوتی وجود دارد، که هرکدام از زاویه دید خاصی محصول را ارزیابی می‌کنند.در زیر دو قالب معروف و کاربردی تحلیل اکتشافی را از دو نظریه‌پرداز مختلف معرفی می‌کنیم:چک لیست اول: ۱۰ اصل کاربردپذیری یاکوب نیلسونچک لیست دوم: تحلیل اکتشافی آندره موریسچک لیست اول: ۱۰ اصل کاربردپذیری یاکوب نیلسون Jakob Nielsen's 10 Usability Heuristics:این چارچوب بر اساس اصول طراحیِ تعامل (Interaction Design) تدوین شده‌ و شامل یکپارچگی، طراحی مینیمال، رفع خطاها و … است.۱۰ اصل کاربردپذیری یاکوب نیلسونچک لیست دوم: تحلیل اکتشافی آندره موریس (André Morys)یکی از مهم‌ترین قالب‌های تحلیل اکتشافی منسوب به آندره موریس(متخصص بهینه‌سازی نرخ تبدیل) است که این روش بر اساس اصول فرآیند(نرخ تبدیل یا Conversion) طراحی شده‌است. که هدف من این است که در این مقاله چک لیست آندره موریس را مفصل بررسی کنم.“نرخ تبدیل درصد کاربرانی است که عمل مورد نظر ما را در محصول انجام می‌دهند. برجسته‌ترین مثال این موضوع درصد بازدیدکنندگان یک وبسایت فروشگاهی است که خریدی را در آن وبسایت انجام می‌دهند.” بیشتر بخوانیدنکته بسیار مهم: شاید برای شما این سوال پیش‌آمده باشد که چک‌لیست تحلیل اکتشافی از کجا ساخته‌شده است؟ در پاسخ به این سوال می‌توان گفت که این چک‌لیست یک روش برای ارزیابی کاربردپذیری (Usability Inspection Method) است و شباهت‌هایی به UX Expert Review نیز دارد. اما در نظر داشته‌باشید که UX Expert Review، تحلیلی جامع‌تر است و نکته مهم دیگر در مورد این تحلیل این است که؛ چک لیست آندره موریس علاوه بر درنظر داشتن اصول کاربردپذیری٬ انگیزه و اصول روانشناسی تاثیرگذار بر تصمیم‌گیری کاربر را هم درنظر دارد و بر آن‌ها هم تاثیر می‌گذارد.چک لیست ۷ مرحله‌ای آندره موریس منطبق بر مراحل تصمیم‌گیری و تبدیل کاربر (Conversion)این چک‌لیست شامل ۷ مورد است که در ادامه هرکدام را بررسی می‌کنیم. در هر مرحله پرسش‌های ذهنی کاربر را بررسی می‌کنیم و راهکار پیشنهاد می‌دهیم:مرحله اول: مرتبط بودن (Relevance)مرحله دوم: اعتماد (Trust)مرحله سوم: جهت‌دهی (Orientation)مرحله چهارم: انگیزش (Stimulation)مرحله پنجم: امنیت (Security)مرحله ششم: آسانی (Convenience)مرحله هفتم: تایید (Confirmation)مراحل تبدیل و تصمیم‌گیری کاربرمرحله اول: مرتبط بودن (Relevance)تلاش ما این است که در اولین برخورد٬ محصول و ارزش‌های آن را به شکلی به کاربر ارایه دهیم که آن را مرتبط با نیاز خودش بداند و به بررسی بیشتر ترغیب شود. دو نقطه تماس کلیدی (Touch point) در این مرحله وجود دارد. ❓ پرسش‌های کاربر در این مرحله:این محصول/وبسایت در چه زمینه‌ای فعالیت دارد؟برای چه افرادی طراحی شده‌ است و چه نیازهایی‌ را برطرف می‌کند؟چه تفاوتی بین این وبسایت‌ با بقیه وبسایت‌های نتایج جستجو دارد؟آیا این وبسایت می‌تواند راهکاری برای نیاز حال حاضر من ارایه دهد؟دو نقطه تماس کلیدی (Touch point) در این مرحله:نقطه تماس اول - شکل دادن به ذهنیت کاربر قبل از مواجه شدن با محصول در منابع ترافیک (Traffic sources) مثل تبلیغات و یا نتایج موتورهای جستجو(SERP):مثال:اگر کاربری بخواهد فیلم و سریال تماشا کند٬ با جستجوی این عبارت، در نتایج جستجو با فیلیمو مواجه می‌شود. متن‌ها (متا دسکریپشن) بر تنوع محتوا تاکید می‌کنند که این موضوع می‌تواند این کاربر را به ورود و بررسی بیشتر تشویق کند.نقطه تماس دوم - ورود به محصول از منابع ترافیک و بازدید از صفحه فرود (Landing page): اگر در منابع ترافیک (نقطه تماس اول) موفق شده‌باشیم توجه کاربر را جلب کنیم و کاربر از طریق موتورهای جستجو وارد محصول بشود٬ باید به او اطمینان دهیم که محصول ما مرتبط با نیاز اولیه‌‌اش (که او را به جستجو تشویق کرده بود) و آنچه که در منابع ترافیک گفتیم است.مثال:کاربری که دنبال تماشای فیلم و سریال بوده و حالا وارد پلتفرم شده است٬ در این صفحه هم عبارت “۸۵ هزار اپیزود فیلم و سریال برای تماشا” و تعدادی از فیلم و سریال‌های موجود را می‌بیند که متنوع بودن محتوا در فیلیمو را در ذهن او تقویت می‌کند.مرحله دوم: اعتماد (Trust)عواملی که در اعتماد کاربر به یک محصول موثر هستند شامل موارد زیر هستند:۱- طراحی مناسب فضاهای وبسایت۲- شفافیت در روند پیش‌رو۳- محتوای به روز و تخصصی مرتبط با فضای فعالیت محصول۴- تایید اجتماعی (Social proofs)❓پرسش‌های کاربر در این مرحله:ظاهرا این محصول با نیاز من مرتبط است. آیا قابل اعتماد هم هست؟این وبسایت چقدر سابقه فعالیت و چند کاربر یا مشتری دارد؟میزان رضایت افرادی که از سرویس یا محصولاتشان استفاده کردند چقدر بوده‌است؟این وبسایت چقدر در حیطه فعالیت خودش متخصص و شناخته‌ شده است؟۱- طراحی مناسب فضاهای وبسایت:طراحی خوب یک وبسایت، این ذهنیت را به کاربر می‌دهد که سرویس دریافت شده هم کیفیت خوبی خواهد‌ داشت.۲- شفافیت در روند پیش‌رو:مثال:در لندینگ پیج درآمدزایی در وبسایت آپارات٬ شرایط ورود به سیستم درآمدزایی به طور شفاف به کاربر توضیح داده شده‌است.۲- محتوای به روز و تخصصی مرتبط با فضای فعالیت محصول:بارگذاری محتواهای تخصصی و مرتبط با فضای محصول، حرفه‌ای و به روز بودن محصول را نشان داده و اعتماد کاربران را جلب می‌کند. دلیل اینکه بسیاری از سایت‌ها بخش وبلاگ دارند و در حیطه خودشان تولید محتوا می‌کنند ایجاد اعتماد بیشتر است.۳- تایید اجتماعی (Social proofs):هدف از بازتاب تجربه مثبت مخاطبان قبلی محصول، جلب اعتماد بیشتر مخاطبان بلقوه‌ است.نمونه‌‌هایی از تایید اجتماعی:نمایش آمار تعامل کاربران با محصولتاییدیه یا نظر مثبت کاربران درمورد تجربه استفاده از محصولهمکاری با برند یا اشخاص متخصصنشان‌های اعتماد و گواهینامه‌‌هامثال:در صفحه فرود فیلیمو٬ تاییدیه یا نمونه‌هایی از نظرات مثبت کاربران نمایش داده شده که می‌تواند بر اعتماد بیشتر کاربران جدید تاثیر بگذارد.مرحله سوم: جهت‌دهی (Orientation)عوامل موثر بر هدایت و جهت‌دهی توجه کاربر شامل موارد زیر است:۱- هدف و عمل اصلی سرویس۲- در نظر گرفتن یک عمل ثانویه❓ پرسش‌های کاربر در این مرحله:این محصول چه سرویس یا امکاناتی ارایه می‌کند؟آشنا شدن با کاربرد یا سرویس‌های این وبسایت را از کجا شروع کنم؟چطور کالا یا سرویس مورد نظرم را در این وبسایت پیدا کنم؟از کدام قسمت این وبسایت می‌توانم اطلاعات بیشتری در مورد آن به دست بیاورم؟به طور کلی، در این مرحله تمرکز ما بر هدایتِ توجه کاربر است.عوامل موثر بر هدایت توجه کاربر:۱- هدف و عمل اصلی یا سرویس‌هایی که ارایه می‌کنیم را واضح نشان دهیم.مثال:در صفحه فرود فیلیمو، هدف و عمل اصلی یعنی خرید اشتراک برجسته است و توجه کاربر را جلب می‌کند.۲- در نظر گرفتن یک عمل ثانویه:مثال:در صفحه فرود درآمدزایی آپارات٬ در حالتی که کاربر مطمین نیست می‌خواهد در سیستم عضویت داشته باشد، دکمه دیگری هم کنار دکمه درخواست عضویت وجود دارد که به کاربر فرصت دریافت اطلاعات بیشتر در مورد این سرویس را می‌دهد. مرحله چهارم: انگیزش (Stimulation)عوامل تاثیرگذار بر انگیزه کاربر شامل موارد زیر است:۱- ارزش‌های پیشنهادی۲- کار کردن روی ادراک کاربران از قیمت Perceived price۳- ایجاد حس فوریت و کمیاب بودن❓ پرسش‌های کاربر در این مرحله:کالا یا سرویس موردنظرم را در این وبسایت پیدا کردم. اما چرا باید از آن خرید کنم؟مزیت این وبسایت از نظر کیفیت و قیمت خدمات نسبت به رقبای آن چیست؟چرا باید الان تصمیم‌گیری کنم و خریدم را نهایی کنم؟ می‌توانم زمان دیگری هم این کار را انجام دهم.در این مرحله هدف‌ ما این است که محصول خود را به عنوان بهترین گزینه به کاربر معرفی کنیم.۱- ارزش‌های پیشنهادی:باید مزایای محصول یا کالا را طوری برجسته کنیم که بیش از هزینه‌ و ریسک‌های خرید در ذهن کاربر باشد.مثال:در محصول فیلیمو، مزایای مختلف مثل امکان تماشا با ۳ دستگاه به صورت همزمان٬ محتوای رایگان و یا امکان ساخت پروفایل کودک و … بعضی از ارزش‌های پیشنهادی هستند و پیش از خرید اشتراک به کاربر نشان داده می‌شوند.۲- کار کردن روی ادراک کاربران از قیمت Perceived price:نحوه نمایش قیمت‌ها در محصول از نظر متنی و طراحی باید به شکلی باشد که به کاربر حس مواجه شدن با یک پیشنهاد قیمتی خوب (Offer) را بدهد.مثال:در صفحه خرید اشتراک فیلیمو٬ گزینه اشتراک ۳ ماهه و پیشنهاد قیمتی آن به شکلی طراحی شده که توجه کاربر را بیشتر جلب کند.۳- ایجاد حس فوریت و کمیاب بودن:استفاده از پیشنهادهای قیمتی در زمان محدود برای تشویق کاربر به تصمیم‌گیری فوری سریعتر.مرحله پنجم: امنیت (Security)راه‌های ایجاد حس امنیت در کاربر شامل موارد زیر است:۱- پاسخ دادن به سوالات در نقطه درست۲- بخش سوالات متداول۳- دسترسی به پشتیبانی۴- ارایه گارانتی یا پیشنهاد روش‌هایی برای کم کردن ریسک❓پرسش‌های کاربر در این مرحله:آیا خرید از این محصول امن است؟چطور درمورد مراحل مختلف کار با این محصول اطلاعات بیشتری پیدا کنم؟چطور می‌توانم با کمترین ریسک و هزینه از محصول استفاده کنم و بعد از تجربه کردن آن٬ برای خرید تصمیم نهایی بگیرم؟در مرحله خرید، در ذهن کاربر افکاری در مورد ریسک‌های خرید از محصول جریان دارد و ما تلاش می‌کنیم به سوالاتشان پاسخ دهیم.۱- پاسخ دادن به سوالات در نقطه درستمثال:در یک محصول فروشگاهی امکان پس دادن کالا، یکی از سوالاتی است که برای کاربران به وجود می‌آید. می‌توان در صفحه هر محصول، بخشی را به اطلاعات مهم در مورد کالا یا سرویس اختصاص داد تا کاربر نیاز نداشته‌باشد در بخش‌های دیگر دنبال جواب خود بگردد.۲- بخش سوالات متداول:طراحی بخشی جداگانه برای پرسش‌ به سوالات رایج کاربران.۳- دسترسی به پشتیبانیمثال:در روند خرید اشتراک فیلیمو دسترسی به پشتیبانی قرار داده شده است.۴- ارایه گارانتی یا پیشنهاد روش‌هایی برای کم کردن ریسک امتحان کردن محصول مامثل ارائه ترایال رایگان برای یک بازه زمانی محدود که امکان کار با محصول بدون نیاز به پرداخت هزینه را به ما می‌دهد.مرحله ششم: آسانی (Convenience)عوامل موثر بر سادگی کار با محصول شامل موارد زیر است:۱- برداشت ما از سادگی کار با محصول۲- کاربردپذیری محصول❓پرسش‌های کاربر در این مرحله:(قبل از استفاده) در یک نگاه و بررسی کلی٬ کار کردن با این محصول چقدر راحت بنظر می‌رسد؟(در حین استفاده) آیا استفاده از این محصول آسان است؟۱- برداشت ما از سادگی کار با محصول:یک کاربر قبل از کار با یک محصول و تنها از روی ظاهر محصول باید در زمان کوتاهی به این نتیجه برسد که کار با این محصول کاملا آسان خواهد بود. استفاده از طراحی مینیمال و تمرکز بر عناصر ضروری می‌تواند به این موضوع کمک کند.۲- کاربردپذیری محصول:در حین کار با محصول، رعایت اصول کاربردپذیری می‌تواند تجربه تعامل مناسبی برای کاربر به وجود آورد.مرحله هفتم: تایید (Confirmation)❓پرسش کاربر در این مرحله:آ‌یا در این وبسایت در مسیر درستی حرکت می‌کنم؟آیا با طی کردن این مسیر، نیاز اولیه‌ من برطرف می‌شود؟(در حین استفاده) آیا خرید و یا استفاده از این محصول انتخاب خوبی است؟آیا باید استفاده خرید را همین جا متوقف کنم و از رقبا هم بازدید کنم؟کاربران میکرو و ماکرو اکشنهای (Micro and Macro actions) مختلفی در محصول انجام می‌دهند. میکرو اکشن‌ها شامل عملیاتی مثل یک کلیک و ماکرو اکشن‌ها شامل عملیاتی مثل انجام دادن یک خریدی محصول هستند.هدف ما این است که در حین هر دو نوع عمل (Action) این اطمینان را به کاربر بدهیم که تصمیم منطقی و عمل درست را انجام داده و در حال حرکت به سمت هدف اصلی است.مثال:در روند خرید اشتراک فیلیمو به مزایای مختلف خرید اشتراک اشاره می‌شود.راهکاری برای افزایشِ اعتبارِ تحلیل اکتشافییکی از راهکارهای موثری که اعتبار نتیجه تحلیل اکتشافی را بالا می‌برد، افزایش تعداد بررسی‌کنندگان (Evaluators) از یک نفر به ۳ تا ۵ بررسی‌کننده می‌باشد.مزایای این راهکار:می‌توانیم دیدگاه‌های متنوع بررسی‌کنندگان را کنار هم آنالیز کنیم و به یافته‌های جامع‌تر و قابل اعتمادتری برسیم و مشکلات کاربری بیشتری را شناسایی کنیم.ریسک سوگیری شخصی یک بررسی‌کننده (Subjective bias) کاهش پیدا می‌کند.جمع بندیدر این مقاله مفهوم تحلیل اکتشافی به عنوان روشی برای بررسی روند تصمیم‌گیری کاربر در یک محصول و بهینه‌سازی آن را بررسی کردیم و با چک‌لیست ۷ موردی آندره موریس آشنا شدیم.به‌کارگیری این روش در پروژ‌ه‌های طراحی محصول، تحقیقات تجربه‌کاربری و توسعه یک محصول به ما کمک می‌کند تا درک درست‌تری از نیازهای کاربر و عوامل موثر بر انگیزه آن‌ها داشته‌باشیم، همچنین به اهدافی مثل افزایش رضایت کاربران و بهینه‌سازی نرخ تبدیل محصول (CRO) برسیم.

چطور با تحلیل سشن‌‌ریکورد دیدگاه‌های ناشناخته کاربر را کشف کنیم؟

کیمیا زمانپور — Sun, 11 Jun 2023 13:50:29 +0330

fبه عنوان UX Researcher (محقق تجربه کاربر) یکی از روش‌هایی که برای جمع‌آوری اطلاعات در مورد رفتار کاربران استفاده می‌کنیم، بررسی سشن ریکورد است.این بررسی به این صورت است که حدود 100 یا 200 ریکورد از تعامل کاربران با محصول را روی یک جریان کاربری بخصوص بررسی میکنیم. این بررسی با درنظر داشتنِ فاکتورهای بخصوص و تا رسیدن به مرحله اشباع انجام می‌شود.در این مقاله تجربه انجام یک سشن ریکورد و ابعاد مختلف آن را را بررسی می‌کنیم:1- سشن ریکورد چیست؟2- سشن ریکورد با بقیه متدهای تحقیق کاربری چه تفاوت‌هایی دارد و مزایای استفاده ار آن چیست؟3- در روند یک تحقیق، در چه موقعیت‌هایی سشن ریکورد را بررسی کنیم؟4- چطور یک سشن ریکورد را ببینیم؟نکته: در این مقاله‌ها مثال‌ها با علامت?مشخص شده‌اند.1- سشن ریکورد چیست؟یک session یا نشست با ورود کاربر به یک سایت آغاز میشود و با خروج یا غیرفعال بودنش برای 30 دقیقه در همان سایت به پایان می‌رسد.سشن ریکورد ویدیویی از رفتار کاربر در محصول در طول یک session (نشست) است که با بررسی آن می‌توانیم حرکت کاربر در صفحات مختلف، کلیک‌ها، اسکرول‌ها و توقف‌ها را مشاهده کنیم.? در زیر نمونه‌ای از یک سشن ریکورد در لندینگ پیج فیلیمو را ببینید:نمونه‌ای از یک سشن ریکورد در لندینگ پیج فیلیموابزارهای مختلفی مثل Microsoft Clarity، Hotjar، Mouse Flow و … به ما امکان بررسی سشن ریکورد روی محصول را می‌دهد. هرچند فارغ از ابزاری که برای راه‌اندازی سشن ریکورد استفاده می‌کنیم، نحوه دیدن، تحلیل، اعتبارسنجی و پیاده‌سازی داده‌ها در اولویت قرار دارند.سشن ریکورد را به عنوان یک روش جمع‌آوری اطلاعات کیفی درمورد تجربه کاربر، می‌توانیم درقالب موارد زیر عمیق‌تر بشناسیم:1-1- افزایش حس همدلی با تجربه کاربران در محصول:بررسی سشن ریکورد می‌تواند بر افزایش احساس همدلی ما نسبت به تجربه کاربر و حتی بالا رفتن کیفیت پیشتیبانی تاثیر بگذارد.در روش‌های مختلف جمع‌آوری اطلاعات، مثل بررسی داده کمی در ابزاری مثل Google Analytics، یا در دیتای پشتیبانی مثل تماس‌های پشتیبانی یا لایوچت، ما گزارشی از چالش‌های کاربران دریافت می‌کنیم، در صورتی‌ که در بررسی سشن ریکورد می‌توانیم مواجه شدن با یک چالش جدید را از زاویه دید کاربر و در حالی که با یک چالش مواجه می‌شوند، ببینیم.با یک مثال می‌توانیم این موضوع را بهتر درک کنیم.? بطور مثال در بررسی تماس‎‌های پشتیبانی متوجه می‌شویم که کاربران گزینه دانلود را پیدا نمی‌کنند، در حالی که با بررسی سشن ریکورد روی این بخش، می‌توانیم ببینیم که کاربرانی که زمان زیادی را برای پیدا کردن گزینه دانلود صرف می‌کنند، ابتدا در چه قسمت‌هایی به دنبال این قابلیت می‌گردند و در نهایت چطور آن را پیدا می‌کنند.مواجه شدن با این چالش از زاویه دیدِ کاربران، به افزایش احساس همدلی ما با کاربر، طراحی تجربه کاربری و حتی ارائه پشتیبانی بهتر کمک می‌کند.2-1- تحلیل دقیق از گشت و گذار کاربر، شکست‌ها و اصطکاک:با استفاده از سشن ریکورد می‌توانیم مراحل مختلف تجربه کاربر با یک جریان کاربری بخصوص را بررسی کنیم:قبل از ورود به جریان کاربری و مسیر ورود:? بطور مثال در فیلیمو لندینگ پیجی وجود دارد که روش‌های تماشای فیلیمو روی تلویزیون را معرفی می‌کند. با تحلیل سشن ریکورد می‌توانیم بررسی کنیم که کاربرانی که می‌خواهند فیلیمو را روی تلویزیون تماشا کنند و در این جریان کاربری با چه چالش‌هایی مواجه هستند و چطور راه خود را به این لندینگ پیج آموزشی پیدا می‌کنند.نحوه تعامل کاربر با جریان کاربری:? به طور مثال می‌توانیم بررسی کنیم که کاربران پس از ورود به لندینگ پیج، صفحه را برای چه مدتی و با چه سرعتی بررسی می‌کنند و در چه بخش‌هایی بیشتر مکث می‌کنند.اگر تعداد زیادی از کاربران ما مدت زمانِ کوتاهی مثلا 30 ثانیه در صفحه می‌مانند و تنها روی یک یا دو روش مکث می‌کنند، معرفی روش‌های موجود در صفحه در بخش‌های ابتدایی اولویت بالایی پیدا میکند تا کاربر بتواند سریعتر بخشِ کاربردی موردنظر خود را پیدا کند.نحوه خروج از جریان کاربری:?کاربر بلافاصله قبل از خروج از لندینگ پیج مشغول به چه کاری ست؟بطور مثال، آیا خطایی مثل لود نشدنِ یک ویدیو یا کار نکردن یک CTA باعث شده است که کاربر از صفحه خارج شود؟کاربر در نهایت چطور از لندینگ پیج خارج می‌شود؟ از دکمه back مرورگر استفاده می‌کند و یا دکمه بازگشت به فیلیمو در دسترس کاربر است و می‌تواند از آن برای خروج استفاده کند؟نمونه‌ای از خروج یک کاربر از لندینگ پیج را در زیر می‌بینیم.3-1- درکِ عوامل موثر بر کارهایی که کاربران نمی‌کنند و تصمیم‌هایی که نمی‌گیرند:داده کمی در قالبِ آمارهایی مثل نرخ تبدیل و یا نرخ کلیک به ما نشان می‌دهد که چند درصد از کاربران اکشن موردنظر ما را انجام داده‌اند. بررسی این آمارها همیشه با این سوال همراه است که چرا درصد بیشتری از کاربران این اکشن را انجام نداده‌اند. سشن ریکورد روش خوبی برای جمع‌آوری اطلاعات بیشتر و نتیجه‌گیری در این مورد است.?در نظر بگیرید شما صاحب یک فروشگاه اینترنتی هستید و درصد زیادی از کاربران خرید از شما با روش‌های دیگر مثل سوشال مدیا، خرید تلفنی و … را به خرید از سایت شما ترجیح می‌دهند. همچنین با بررسی داده کمی متوجه شده‌اید که آمار ترکِ محصول در Checkout Page (صفحه تکمیل اطلاعاتِ سفارش) بالاست.در چنین موقعیتی بررسی سشن ریکورد به شما این امکان را می‌دهد که متوجه شوید کاربران در چه بخشی‌هایی در این صفحه با چالش مواجه هستند و چه چیزی باعث می‌شود تکمیل سفارش در سایت صورت نگیرد.2- چرا سشن ریکورد؟شاید این سوال به ذهن شما برسد که چرا باید به سراغ سشن ریکورد برویم و در مقایسه با بقیه روش‌های تحلیل رفتار کاربر مثل تست کاربردپذیری، مصاحبه و … چه مزایایی دارد.با بررسی بعضی از سوالاتِ متداولی که در این خصوص وجود دارد، در این مسئله عمیق می‌شویم:1-2- آیا سشن ریکورد روش کاملا معتبری برای تحلیل رفتار کاربر است؟دیتای سشن ریکورد بسیار ارزشمند است اما ممکن است دیدِ دقیق و کاملا معتبری از تجربه کاربران در محصول ایجاد نکند. برای بالاتر بردن اعتبار دیتاها و فرضیاتی که با بررسی سشن ریکوردها شکل‌ می‌گیرند میتوان از روش‌های تحقیق کاربری مختلف استفاده کرد، چند نمونه از این روش‌ها را در زیر معرفی کریدم:مصاحبه:انجام مصاحبه به ما امکانِ تعامل مستقیم با کاربران را می‌دهد. در مصاحبه می‌توانیم دلایلِ بعضی از رفتارهایی که در سشن ریکورد دیده‌ایم را بهتر درک کنیم چرا که می‌توانیم بطور مستقیم درمورد انگیزه‌ها، افکار و تمایلاتشان درمورد یک موضوع خاص صحبت کنیم.تست کاربردپذیری:در تست کاربردپذیری می‌توانیم تعامل کاربران با محصول را موقعِ انجام امور بخصوص مشاهده کنیم.بررسی سشن ریکورد قبل از گرفتنِ تستِ کاربردپذیری کمک می‌کند که بخش‌هایی که کاربران با آن چالش دارند را شناسایی کنیم و سناریو و امور تست را به نوعی طراحی کنیم که درمورد این بخش‌های چالش‌برانگیز بازحوردهای کاربری بیشتری دریافت کنیم.انجامِ A/B Test:با انجام A/B Test می‌توانیم عملکرد کاربران را در آلترناتیوهای مختلفی از یک طراحی مقایسه کنیم.با استفاده از این روش می‌توانیم یافته‌های سشن ریکورد را در نسخه‌های مختلف پیاده کنیم و رفتار و عملکرد کاربران را در آنها مقایسه کنیم. این مسئله به تصمیم‌گیری داده-محور هم کمک می‌کند.2-2- آیا سشن ریکورد دید درستی از تنوع کاربران، رفتارها و نیازهای آن‌ها به ما می‌دهد؟سشن ریکورد به ما در شناخت بیشتر الگوهای رفتاری کاربران کمک می‌کند. اما برای شناخت این الگوها، لازم است سشن ریکوردها براساس یک چک لیست بررسی شوند. این موارد عموما بصورت فیلتر در ابزارهای بررسی سشن ریکورد وجود دارند و می‌توانیم سشن ریکوردها را براساس این عوامل فیلتر و بررسی کنیم.نمونه این فیلترها در ابزار Microsoft clarity قرار داده شده‌اند. این چک لیست میتواند بسته به پروژه مورد نظر ما شخصی‌سازی شود.منابع (Source) ورودی کاربران:کاربران عموما از چه سایت‌هایی به جریان کاربری مورد نظر ما وارد شده‌اند؟مسیر‌ حرکت کاربران (Navigation Path):کاربران قبل از ورود به این بخش، در چه صفحات دیگری هستند؟چطور و از چه مسیرهایی به جریان کاربری موردنظر وارد می‌شوند؟با خروج از این جریان کاربری به چه صفحات دیگری می‌روند؟دستگاه و مرورگر کاربرانزمان سپری شده و نوع تعامل با صفحه/بخش موردنظرنرخ تبدیل Conversion Rate:چه درصدی از کاربران اکشن‌های موردنظر ما را در این صفحه را انجام می‌دهند.آمار Conversion Rate می‌تواند نسبت به موارد قبلی هم سنجیده شود. مثلا بررسی کنیم که کاربران در کدام منبع (Source) بیشترین نرخ تبدیل را داشته‌اند.اکشن‌های خاصی مانند خروج سریع یا Rage click (که در ادامه معرفی می‌کنیم) و …در بخش “چطور سشن ریکورد ببینیم؟” جزئیات و مثال‌های بیشتری درمورد این چک‌لیست آورده شده.3-2- چرا به جای بررسی سشن ریکورد از روش‌های دیگری مثل یوزبیلیتی تست‌ها، مصاحبه و … استفاده نکنیم؟انجام دادن تست‌های کاربری دیگر مثل مصاحبه ،سشن ریکورد و … نیازمند شرکت‌کنندگان، هزینه و زمانِ بیشتری هستند، و در مقایسه با این روش‌ها سشن ریکوردها دسترسی بالاتر و هزینه کمتری دارد.در بخش “چه زمانی سراغ سشن ریکورد دیدن برویم” توضیح می‌دهیم که چطور سشن ریکورد می‌تواند در کنار سایر تست‌های کاربری استفاده شود.4-2- آیا سشن ریکورد یک روش اخلاقی است و امنیت اطلاعات و حریم شخصی کاربران در آن درنظر گرفته می‌شود؟با توجه به مواردی که در زیر آوردیم، ابزارهای سشن ریکورد از امنیت اطلاعاتِ کاربران و حریم خصوصی آنها محافظت می‌کند.حذف اطلاعات شخصی کاربران مانندِ نام، ایمیل، شماره موبایل و … از سشن ریکوردها.حذفِ بخش‌هایی که کاربران در آن اطلاعات وارد می‌کنند، مثل فرم‌ها.حذفِ صفحاتی که کاربران اطلاعاتِ محرمانه‌ای خود را وارد می‌کنند، مانند صفحات پرداخت و درگاه‌ها.3- چه زمانی سراغ سشن‌ ریکورد دیدن برویم؟تنوع روش‌های تحقیق کاربری، انتخاب روش درست در هر موقعیت را برای ما مشکل می‌کند.بنابراین یکی از مهمترین تصمیماتِ ما به عنوان User Researcher (محقق کاربر) تشحیص این موضوع است که در چه مرحله‌ای و قبل و بعد از چه روش‌های تحقیقی دیگری سشن ریکورد ببینیم تا به بیشترین شناخت از رفتار کاربران و معتبرترین داده برسیم.1-3- بعد از بررسی داده‌های کمی و کیفی موجود:اولین قدم ما بررسی داده‌های موجود مانند داده کمی در ابزارهای آنالتیکس و داده کیفی پشتیبانی است.در این مرحله بررسی می‌کنیم که چه رفتارهایی در داده کمی و کیفی، پتانسیل بررسی شدن در سشن ریکورد را دارند.زمانی که دیتای کمی آمار قابل توجهی را نشان می‌دهد و می‌خواهیم برای رسیدن به دلیل این آمار، دیتای رفتاری بیشتری جمع آوری کنیم.این داده‌های کمی میتوانند شامل:بانس ریت Bounce Rateنرخ ریزش در فانل Churn Rateنرخ کلیک CTRنرخ کانورژن Conversion Rateزمان سپری شده در یک بخش Time Spend?بطور مثال در این محصول نرخ تبدیل ورود/ثبت‌نام به شکل قابل‌توجهی پایین آمده و با بررسی سشن ریکورد پی برده شده که در این بخش، کنترل‌کننده اتوماتیک پسورد مشکل داشته. در نتیجه کاربران موفق به ثبت‌نام نمی‌شدند.زمانی که در دیتای کیفی (فیدبک، تماس‌های پشتیبانی، لایوچت و…) سوالات زیادی درمورد یک فلوی بخصوص پرسیده می‌شود.این رفتار نشان دهنده ضرورت بررسی آن فلوی بخصوص است تا متوجه شویم که کاربران در چه بخشی دچار مشکل هستند.?مثلا اگر کاربران ما برای پیدا کردن امکانِ کنسلی بلیت یا سفارش خود دچار مشکل هستند و از پشتیبانی برای این مسئله کمک می‌گیرند، بررسی سشن ریکورد روی این فلو به ما کمک می‌کند متوجه شویم کاربران در چه بخشی از این پروسه مشکل دارند: پیدا کردن امکان کنسلی برایشان مشکل است، در فرآیند کنسلی با ارور یا چالش خاصی مواجه هستند یا مشکل دیگری دارند؟2-3- قبل از انجام تست‌های کاربری:در مرحله بعد از بررسی داده‌های موجود، بعضی از نقاطی که احتمال می‌دهیم کاربران چالش دارند را پیدا می‌کنیم.با بررسی سشن ریکورد، به دو دسته داده می‌رسیم:مشکلات یا باگ‌های کاملا مشخصی که می‌توانند برای برطرف شدن به تیم‌های مربوط گزارش داده شوند.مشکلاتی که درمورد آن‌ها فرضیاتی داریم اما می‌خواهیم که درمورد دلیل آن مورد بخصوص و نیازهای کاربران اطلاعاتِ بیشتری جمع‌آوری کنیم و تاثیر این مشکلات را روی تجربه کار با محصول اعتبارسنجی کنیم.در این مرحله میتوانیم به سراغ تست‌های کاربری برویم و سناریویی طراحی کنیم که فرضیاتمان را اعتبارسنجی کند.مصاحبه:?هنگام بررسی سشن ریکوردهای مربوط به برخورد کاربران با آنبردینگ(Onboarding) در یک جریان کاربری جدید، مشاهده می‌کنیم که تعداد زیادی از کاربران آنبردینگ را رد میکنند (Skip می‌کنند) و تعامل زیادی با آن ندارند. با انجام مصاحبه در این مورد می‌توانیم متوجه شویم که دریافت چه اطلاعاتی در آنبردینگ و در چه بخشی از تجربه کاربری می‌تواند برای افراد جالب توجه باشد.نظرسنجی:?با بررسی سشن‌ریکورد در بخش خرید اشتراک مشاهده می‌کنیم که کاربران بسیاری در این بخش مکث دارند، زمانی که به شکل قابل توجهی زیاد است را در این صفحه سپری صرف می‌کنند، و بین صفحه خرید اشتراک و آنبردینگ‌های معرفی محصول در رفت‌و‌آمد هستند. این مسئله می‌تواند نشانه‌ دهنده وجود ابهام برای کاربر و یا سوالاتِ برطرف نشده درمورد خرید اشتراک باشد. برای جمع‌آوری اطلاعات از تعداد زیادی از کاربران در این مورد، می‌توانیم یک نظرسنجی طراحی کنیم و در درمورد سوالاتی که کاربران درمورد اشتراک دارند و یا مشکلاتی که در روند خرید با آن مواجه می‌شوند اطلاعات کسب کنیم.تست کاربردپذیری:?در سشن‌ریکوردهای بخشی که کاربران باید یک فرم چند قسمتی را تکمیل کنند، مشاهده می‌کنیم که کاربران در بخش‌های خاصی فرم را ترک می‌کنند. با انجامِ تستِ کاربردپذیری می‌توانیم چالش کاربران با این بخش را دقیقا شناسایی کنیم.تست 5 ثانیه:?در دیتای کمی و سشن‌ریکوردهای یک لندینگ پیچ آموزشی مشاهده می‌کنیم که مدت زمانِ بازدید کاربران و تعامل آن‌ها با این صفحه کم است. همچنین در هیت‌مپ‌ها (Heat Maps) هم دیده‌ایم که کاربران اسکرول زیادی در صفحه ندارند. با گرفتنِ تست 5 ثانیه مخصوصا در بخش بالایی صفحه (Hero Section) می‌توانیم مواجهه اولیه (First Interaction) کاربران با این صفحه را بسنجیم و ببینم که در لحظاتِ کوتاهِ اولیه کاربران به چه ذهنیتی از این صفحه می‌رسند.تست کاردسورتینگ و یا Tree Testing:?با بررسی سشن ریکورد‌ها می‌بینیم که کاربران زیادی منو و دسته‌‌بندی‌های سایت را بررسی می‌کنند، اما در نهایت از طریق جستجو(Search) به نتیجه موردنظر می‌رسند. با انجامِ این تست‌ها می‌توانیم چالش‌های کاربران با معماری اطلاعات سایت را بهتر متوجه شویم و به دسته‌بندی‌ موضوعی ایده‌‌آلی که به مدلِ ذهنی کاربرانِ هدف ما نزدیک‌تر است برسیم.تست A/B Test:? با بررسی دیتای کمی متوجه می‌شویم که نرخ کلیک (CTR) روی یک قابلیت(فیچر) جدید در یک تاچ‌پوینت بخصوص مثلا در صفحه اصلی پایین است. همچنین با بررسی سشن ریکورد‌ها می‌بینیم با وجود این که کاربران از مسیرهای دیگر از این قابلیت استفاده می‌کنند اما در صفحه اصلی با آن تعامل ندارند. یک فرضیه در این خصوص این است که Visibility این قابلیت در صفحه اصلی پایین است. با تست کردن گزینه‌های طراحی(آلترناتیو) مختلف درمورد نحوه نمایش‌ این قابلیت در صفحه اصلی میتوانیم این فرضیه را بررسی و طراحی بهینه‌تری را انتخاب کنیم.3-3- بررسی میزان تعامل کاربران با یک قابلیت جدید:بعد از راه‌اندازی یک قابلیت جدید در محصول، ممکن است که داده کمی و کیفی زیادی درمورد آن جدید نداشته‌باشیم. اما سشن ریکورد این امکان را بوجود می‌آورد که درمورد برخورد‌های اولیه کاربران با این قابلیت هم اطلاعات جمع‌آوری کنیم.دنبال کردن نحوه تعامل کاربران با آن می‌تواند در این دو بخش مهم به ما پتانسیل‌های بهبود را نشان دهد:بهبودِ پروسه آنبوردینگ:برای بهبودِ برداشت اولیه (First Impression) کاربران از یک قابلیت جدید می‌توانیم این موارد را بررسی کنیم:کاربران چقدر متوجه این فیچر جدید می‌شوند؟از چه مسیرهایی به آن وارد می‌شوند؟آیا با فلوی آنبوردینگ تعامل دارند و یا با سرعت از آن می‌گذرند؟بهبود تجربه کاربری فیچر جدید:می‌توانیم بسنجیم که طراحی این فیچر جدید چقدر به مدلِ ذهنی (Mental Model) کاربران نزدیک است.آیا تعامل با این فیچر برای کاربران راحت است یا برای یادگیری نحوه کار با آن به زمان و تلاش‌های زیاد نیاز دارند؟4-3- ارائه پشتیبانی بهتر:ما به عنوانِ محقق تجربه کاربر، بطور مداوم و با روش‌های مختلف مثل مصاحبه، تست کاربردپذیری و … با کاربران و چالش‌هایشان در ارتباط هستیم اما بعضی از اعضای تیمِ محصول ممکن است این مجاورت را با کاربران و چالش‌هایشان نداشته باشند.بررسی سشن ریکورد فرصت منحصربه‌فردی بوجود می‌آورد که این افراد هم نحوه تعامل کاربران با محصول و مشکلاتشان را ببینند. نتایج این مسئله:افزایش همدلی تیم محصول:منظورمان از همدلی درکِ عمیق‌تر نیازهای کاربران است و دیدنِ محصول از زاویه دیدِ کاربر می‌تواند به افزایش آن کمک کند.?مثلا مشاهده رفتار کاربری که برای پیدا کردن مسیرِ درست زمان زیادی در صفحات مختلف عقب و جلو می‌رود، روی دکمه‌های مختلف کلیک خشمگین دارد و سپس از محصول خارج می‌شود، می‌تواند احساس همدلی بیشتری در اعضای مختلف تیم ایجاد کند.ارائه پشتیبانی بهتر توسط تیم پشتیبانی:تیم پشتیبانی در ارتباطِ مستقیم با کاربران است و در تماس و یا چت، شرحی از چالش‌های کاربران را می‌شنود. اما برای این اعضای تیمِ محصول هم دیدنِ نحوه کارِ کاربران با محصول در مواقعی که با مشکل مواجه شده‌اند می‌تواند ذهنیت بهتری برای راهنمایی و همدلی ایجاد کند.یک خاطره از بررسی ریکورد سشن:شرایطی را درنظر بگیرید که برای اولین بار بعد از راه‌اندازی ابزار و یا بعد از مدت زمانِ زیادی که سشن ریکورد را تحلیل نکرده‌ایم، می‌خواهیم بررسی انجام دهیم. در این مرحله با یک منبع بزرگ و حجم زیادی از اطلاعات مواجه هستیم.در این حالت، انتخاب یک نقطه برای شروع می‌تواند برایمان مشکل باشد و بررسی تصادفی سشن ریکورد ما را به نتیجه‌ای منسجم و کاربردی نمی‌رساند.بنابراین نیاز داریم که نقاط اضطرار و بخش‌هایی که دیتای سشن‌ریکورد می‌تواند برایشان مفید باشند را شناسایی کنیم و یک پروژه بررسی سشن ریکورد تعریف کنیم.در این قسمت در مورد این موضوع صحبت می‌کنیم که بر چه اساسی یک جریان کاربری یا موضوع را برای بررسی با سشن ریکورد انتخاب کنیم.اهداف پروژه یا بیزنس:به عنوان مثال در یک پلتفرم اشتراک-محور که خرید اشتراک از اهداف بیزنس است، بررسی سشن ریکورد در مسیر خرید اشتراک می‌تواند به شناخت چالش‌های کاربران در این بخش کمک کند.تمرکز تیم طراحی:با ارتباط با تیمِ طراحی می‌توانیم بخش‌هایی که در پروسه طراحی و بازطراحی هستند را موردبررسی قرار دهیم. این اطلاعات می‌تواند در طراحی بهتر و کاربر محور‌تر آن بخش به تیم کمک کند.فیچر جدید:همانطور که در بخش قبل هم به جزئیات اشاره کردیم، رصد رفتار کاربران روی یک فیچر جدید می‌تواند اطلاعاتِ کاربردی در جهت بهبود ارایه دهد.موضوعاتی که در دیتای کمی و کیفی آمار قابل توجهی دارند و می‌خواهید اطلاعاتِ بیشتری در مورد آن جمع‌آوری کنید: همانطور که در بخش‌های قبلی هم اشاره کردیم، دیتای کمی و کیفی نقاط خوبی برای طراحی یک پروژه سشن ریکورد هستند.دیتای کیفی:?بطور مثال در نظرسنجی‌های دوره‌ای در فیلیمو، بعضی از کاربران پیشنهاد داده بودند که بخشی ایجاد شود که بتوانند در آن به آخرین محتوایی که دیدند و یا درحال تماشا آن هستند دسترسی داشته باشند. در حالی که چنین بخشی با عنوانِ “به تماشا ادامه دهید” در فیلیمو وجود دارد.با بررسی سشن ریکورد و دیدنِ تعامل کاربران با این بخش، می‌توانیم مسائلی را شناسایی کنیم که باعث می‌شوند کاربران به این یخش دسترسی نداشته‌باشند یا متوجه آن نشوند.دیتای کمی:آمارها و بخش‌هایی که نحوه رفتار کاربران در آن برای تیم سوال ایجاد کرده است، مثل آمار ریزش در یک بخش فانل بخصوص.درک بهتر رفتار کاربران در A/B test:درنظر بگیرید که چند راه حل (آلترناتیو) از یک طراحی را در A/B test بررسی کردیم.واکنش‌های کاربران را در دیتای کمی رصد و این موضوع را بررسی کردیم که کدام نسخه نرخ کلیک و یا نرخ تبدیل بالاتری دارد. اما با بررسی سشن ریکورد می‌توانیم دلیلِ تفاوت این آمارها در دو نسخه را بهتر متوجه شویم.هچنین با مقایسه رفتار کاربران در این دو نسخه می‌توانیم به شناخت بهتر کاربران برسیم و بفهمیم کاربرانمان به چه نوع تجربه کاربری واکنش بهتری دارند و مدل‌های ذهنی و رفتاری آن‌ها چیست.4- چطور سشن ریکورد ببینیم؟بعد از انجام UX Review روی محصول و بررسی اطلاعات کمی و کیفی موجود و با مشخص کردن نقاطی که حدس می‌زنیم ممکن است روی تجربه کاربر تاثیر بگذارند، با بررسی سشن ریکورد می‌توانیم درخصوص فرضیاتی که شکل داده‌ایم اطلاعات بیشتری جمع‌آوری کنیم.موارد و رفتارهایی که در بررسی سشن ریکورد در نظر می‌گیریم:1-4- رفتار کاربر در navigation:کاربران چطور به یک بخش بخصوص می‌رسند و در آن بخش حرکت می‌کنند؟مسیرهای انتخابی کاربران چقدر با مسیرهای طراحی شده و مورد انتظار ما تفاوت دارد، دلیل این تفاوت‌ها چیست و چطور می‌توان در بهبود طراحی آن‌ها را لحاظ کرد؟?در مثال زیر نحوه ورود کاربر به لندنیگ تماشا با تلویزیون در فیلیمو را می‌بینیم. کاربر از فلوی فعال‌سازی به این صفحه وارد می‌شود، در هیرو سکشن (قسمت اصلی صفحه) مکث زیادی ندارد و یا ویدیو معرفی را نمی‌بیند، با استفاده از منو به بخشِ تلویزیونِ اندروید می‌رود و بعد از زمان کوتاهی به صفحه اصلی فیلیمو بازمی‌گردد.?و در این نمونه می‌بینم که کاربر در بخش فیلیموتور و برای جابجایی بین تورها از فلش‌های پایین استفاده نکرده و با کلیک روی تورها بین آن‌ها جابجا می‌شود.نحوه تعامل کاربران با المان‌های کلیکی:با بررسی سشن‌ ریکورد می‌توانیم ببینیم نحوه تعامل کاربران با المان‌های کلیکی مانند CTAها، لینک‌ها و … به چه صورت است. حتی مانند نمونه پایین می‌توانیم ببینیم که چه المان‌های غیر کلیکی از نظر کاربران کلیکی بنظر می‌رسد.?بطور مثال در لندینگ پیج سایت RocketLink، فیچرها بصورت کارت معرفی شده‌اند و کارت‌ها قابل کلیک شدن نیستند. اما در سشن ریکوردها دیده‌شده که کاربران روی این کارت‌ها کلیک می‌کنند. این رفتار می‌تواند به این معنی باشد که کاربران می‌خواهند اطلاعات بیشتری درمورد این فیچرها دریافت کنند.کشف نقاط مبهم برای کاربر:سشن‌ریکورد همچنین به ما کمک می‌کند که نقاطی که کاربر در آن‌ها دچار اصطکاک می‌شود را شناسایی کنیم و بررسی کنیم که چه عواملی از پیشرفت کاربر در مسیر موردنظرش جلوگیری می‌کند.بعضی از انواعِ این نقاطِ اصطکاک:کلیک‌های اشتباه:? در یک لندینگ‌پیج ممکن است کاربر متوجه CTA اصلی نشود و برای ادامه مسیر روی نقاط دیگری کلیک کند.مسیرهای اشتباه:? در یک فروشگاه اینترنتی ممکن است به دلیل پیدا نکردنِ سبد خرید، کاربر برای تکمیل سفارش خود با چالش مواجه شود و از راه‌حل (آلترناتیو) دیگری بخواهد سفارش خود را تکمیل کند.نقاط گمراه‌کننده:مانند مثال پایین باید بررسی کنیم که کاربر در چه نقاطی گمراه شده و اکشنِ درست بعدی را متوجه نمی‌شود.?در این سایت کاربران متوجه نشده‌اند اکه باید ابتدا سایز انتخاب را انتخاب کنند و سپس کالا به سبد خرید اضافه می‌شود و بارها روی CTA افزودن به سبد خرید کلیک کرده‌اند.نقاطی در journey که نشانه‌هایی از کلافگی و عدم اطمینان در رفتار کاربر وجود دارد:کلافگی کاربر از پیدا نکردنِ اکشن درست و یا حرکت نکردن در مسیر موردنظر، نشانه‌هایی دارد که بعضی از آن‌ها در سشن‌ریکورد قابل دیدن هستند. مانند:عقب و جلو رفتن (U Turn): زمانی که کاربر بدلیل پیدا نکردنِ بخش موردنظر، بین صفحات تکراری عقب و جلو می‌رود.کلیک خشمگین (Rage Click): زمانی که کاربر به دفعات روی یک المان کلیک/ ضربه می‌زند.?نمونه‌ای از آن را در پایین می‌بینم که کاربر در فیلیموتور و برای رفتنِ به تور بعدی به دفعات روی صفحه ضربه می‌زند.رفتار کاربران بلافاصله قبل از رها کردن فلو و ترک سایت:این نوع داده می‌تواند بسیار مهم باشد، به این دلیل که به ما کمک میکند متوجه شویم که چه چالش یا مشکلی باعث میشود که کاربر فلوی موردنظر یا محصول را ترک کند. شناسایی این موارد و بهبود آن‌ها می‌تواند بر بالا رفتن نرخ تبدیل (Conversion Rate) تاثیرگذار باشد.?چند نمونه از چالش‌هایی که کاربران ممکن است قبل از خروج از محصول داشته باشند:کلیک روی دکمه‌ای که به درستی کار نمی‌کند.بخشی که طراحی responsive درستی روی موبایل ندارد.اسکرول با سرعتِ بالا و پیدا نکردن cta اصلیسخن آخر:بطور کلی سشن‌ریکورد روش مفید و کم‌هزینه‌ای برای شناختِ دقیق‌تر الگوهای رفتاری و تعاملات کاربران با محصول است. همان‌طور که اشاره کردیم اگر این بررسی با درنظر داشتنِ فاکتورهای بخصوص انجام شود، می‌تواند به افزایش احساس همدلی اعضای مختلف تیم و شناسایی چالش‌های کاربران کمک کند. ترکیبِ درستِ سشن ریکورد با سایر روش‌های جمع‌آوری اطلاعات کمی و کیفی و تست‌های کاربری هم همانطور که در مقاله به آن اشاره شد و راهکارهایی برای آن پیشنهاد شد، در بالا بردن اعتبار این داده‌ها بسیار مهم است.

چطور تست کاربردپذیری در طراحی‌‌ جدید به ما کمک کرد؟

هانیه مجد — Tue, 28 Feb 2023 09:25:26 +0330

من در این مقاله تصمیم دارم تجربه خودم را روی محصول فیلیمو به عنوان یک یوزرریسرچر در یک پروژه بازطراحی با شما به اشتراک بگذارم و با جزییات بیشتری برایتان توضیح دهم که چطور با تست کاربردپذیری به تیم طراحی فیلیمو کمک کردیم تا بین طرح‌های پیشنهادی موجود حول محور بهبود ساختار قسمت‌بندی و فصل‌بندی سریال‌ها بهترین طرح را انتخاب کند.ابتدا تست کاربردپذیری را برای صفحه فعلی اجرا کردیم و نقاط ضعف و قدرت آن را بررسی کردیم و بر اساس آن تیم طراحی دو طرح پیشنهاد داد و ما تست کاربردپذیری را برای هر دو طرح اجرا کردیم در ادامه روند و نتایج این تست‌ها را بررسی می‌کنیم.تست کاربردپذیری در صفحه فعلی سریالبرای انجام این تست، همانطور که در مقاله قبل توضیح دادیم، پس از بررسی امکانات صفحه‌، یک سناریو برای گرفتن تست کاربردپذیری نوشتیم.هدف سناریو ما باید این باشد:نحوه پیدا کردن قسمت آخر یک سریال (تا بفهمیم کاربر چگونه قسمت آخر سریال در حال پخش را پیدا می‌کند).نحوه پیدا کردن یک قسمت از یک فصل خاص (تا نحوه کارِ کاربر با فصل‌های سریال را ببینیم).نتایج تست کاربردپذیری صفحه فعلی فیلیموبا گرفتن تست از کاربرها و همچنین تحلیل داده‌های به‌دست‌آمده، به جدول زیر رسیدیم و نتایج را به‌صورت زیر ثبت کردیم.جدول نتایج تست طرح فعلی:نکته: "no" یعنی کاربر، مشکل موجود در توضیحات را نداشته و "yes" یعنی کاربر به این مشکل برخورد کرده است.نتایج تست طرح فعلی:کاربران در صفحه ،درسوال 1(جدول بالا)در طرح فعلی مشکلی نداشتند. در نتیجه شدت بحرانی بودن این مشکل، طبق جدول بالا 0 محاسبه شده است.کاربران در سوال۲ با مشکل روبرو شدند شدت بحرانی بودن این مشکل " 1.44" است.نکته:با استفاده از این متریک"شدت بحرانی بودن"، متوجه می‌شویم که «مشکل کاربر حاد است» و می‌توانیم اولویت‌بندی رسیدگی به مشکلات طرح‌ها را با مقایسه این متریک، انجام دهیم.نحوه نمایش فصل‌ها و قسمت‌ها در فیلیمو در طرح فعلی:اجرا و تست طرح جدید در صفحه سریال1. بر اساس نتایج تست کاربردپذیری صفحه فعلی فیلیمو، یک طرح جدید ارایه و در فیلیمو جایگزین صفحه قبلی شد. برای سادگی بیشتر ، طرح‌ها را به صورت زیر نام‌گذاری میکنیم و در ادامه مقاله از آن‌ها استفاده می‌کنیم.طرح فعلی: طرح Aطرح پیشنهادی اول: طرح Bطرح پیشنهادی دوم: طرح C2.در مرحله بعد، یک تست کاربرد پذیری را برای طرح B اجرا کردیم و بر اساس نتایج هر دو طرح (طرح A,طرح B) طرح پیشنهادی دوم(طرحC) را ارایه کردیم.3. و با مقایسه هر سه طرح، متوجه شدیم کاربران در طرح C عملکرد بهتری دارند. به همین دلیل طرح C را به عنوان طرح نهایی انتخاب کردیم، که در ادامه جزییات آن را توضیح می‌دهیم.نمایش فصل‌ها و قسمت‎‌ها در هرسه طرح به ترتیب:نحوه نمایش فصل و قسمت ها در طرح Aنحوه نمایش فصل و قسمت ها در طرح BC نحوه نمایش فصل و قسمت ها در طرح جزییات تست کاربردپذیری روی طرح B برای تست این طرح، از سناریویی مشابه تست کاربردپذیری طرح A استفاده کردیم تا بتوانیم مقایسه درستی با تست قبلی داشته باشیم.سناریو طرح B:کاربر در فیلیمو لاگین است.1.سریال ... را پیدا کن و قسمت آخر آن را تماشا کن.2.سریال ... را پیدا کن و قسمت 3 از فصل 7 را تماشا کن.و در نهایت به داده‌های جدول زیر رسیدیم: نتایج تست طرح Bنتیجه جدول داده‌ها:کاربران در سوال ۱ (جدول بالا) مشکل داشتند و شدت بحرانی بودن این مشکل 5.94 است.کاربران در سوال ۲ نیز مشکل داشتند. که شدت بحرانی بودن این مشکل 2.97 است.برای آشنایی با نحوه محاسبه داده‌های جدول بالا، به این مقاله مراجعه کنید.نحوه نمایش قسمت‌ها در طرح Bنحوه نمایش فصل‌ها در طرح Bدر مقایسه تست کاربرد پذیری طرح A و طرح B به چه نتیجه‌ای رسیدیم؟در مقایسه این دو تست متوجه شدیم، طرح B پاسخگوی نیازهای کاربران نیست.مشکلاتی که کاربران در طرح B با آن برخورد کردند:کاربران قسمت‌های سریال را به راحتی پیدا نمی‌کنند.کاربران فصل‌های سریال را به راحتی پیدا نمی‌کنند.کاربران اشتباها روی تیتر ” قسمت‌‌ها” کلیک می‌کنند؛ فکر می‌کنند از طریق آن می‌توانند به قسمت‌های مختلف دسترسی پیدا کنند.جزییات تست کاربردپذیری روی طرح Cبا توجه به مشکلات طرح A و طرح B ، به طرح C رسیدیم و تست کاربردپذیری را برای آن اجرا کردیم.سناریو تست کاربردپذیری برای طرح C:کاربر در فیلیمو لاگین است.1.سریال ... را پیدا کن و قسمت آخر آن را تماشا کن.2.سریال … را پیدا کن و قسمت 10 از فصل 11 را تماشا کن.جدول نتایج تست طرح C:همان‌طور که در جدول بالا می‌بینیم، شدت بحرانی بودن هر دو تسک در طرح C به صفر رسید. یعنی کاربران توانستند به راحتی با ساختار فصل و قسمت‌های سریال کار کنند.نکات موجود در طرح C:1. طراحی قسمت‌های آن به طرح A شباهت بیشتری داشت (با طراحی متفاوت).2. طراحی نمایش فصل‌ها تغییر پیدا کرد و فصل‌ها به جای کمبوباکس، به صورت تب کنار هم قرار گرفتند.3. عبارت” قسمت‌ها” حذف شد.نحوه نمایش فصل و قسمت در طرح Cنحوه نمایش فصل‌ها در طرح Cمقایسه نتایج تست کاربردپذیری در طرح‌های پیشنهادیما در تست‌های کاربردپذیری، جدول‌های بالا را با متریک‌های موجود در آن‌ها، طراحی کردیم تا به میزان بحرانی بودن مشکلات کاربرها پی ببریم و مشکلات بحرانی‌تر را در اولویت قرار دهیم.ولی برای مقایسه بهتر، در هر تست سوالاتی طراحی کردیم و جواب آن‌ها را از عملکرد کاربر پیدا کردیم؛ تا بتوانیم نمودارهای درصدی برای عملکرد کاربران ترسیم کنیم.سوالات طراحی شده در هر تست:1. آیا کاربر در نگاه اول توانست قسمت آخر سریال را پیدا کند. (بله/خیر)2. آیا کاربر توانست به راحتی با فصل‌ها وقسمت‌ها کار کند. (بله/خیر)پس از بررسی سوالات در طرح‌ها، یک نمودار طراحی کردیم تا نتایج هر دو طرح پیشنهادی را در یک نمودار باهم مقایسه کنیم تا تصمیم نهایی را بگیریم.نمودار مقایسه دو طرح پیشنهادی A ,Bنمودار درصد مشکلات کاربران در دو طرح همانطور که در نمودارهای بالا دیدیم، در طرح C کاربران به راحتی قسمت آخر سریال را پیدا کردند (طرح C علاوه بر طراحی کاربردی، رابط کاربری بهتر و جذاب‌تری داشت).طرح C مشکلات کاربران در کار با ساختار قسمت‌ها و فصل‌های سریال را برطرف کرد.حرف آخر:با تست کاربرد پذیری روی این نمونه از صفحه، ما توانستیم طرحی که سهولت بیشتری برای کاربران فراهم می‌کند را انتخاب کنیم؛ البته همانطور که می‌دانیم، فرآیند طراحی هیچ وقت تمام نمی‌شود و یک مسیر ادامه‌دار است.

روزمرگی‌های یک UX Writer در آپارات

شهاب صفاری — Sat, 24 Dec 2022 20:59:40 +0330

هر گوشه از وبسایت یا نرم‌افزاری را که نگاه کنیم، متن‌هایی می‌بینیم که یا روش کارکردن با آن محصول را به ما آموزش می‌دهند، یا آگاهی بیشتری از ابعاد آن محصول به ما می‌دهند. این متن‌ها را در جاهای مختلفی از محصول می‌توان پیدا کرد؛ برای مثال:متن‌های صفحه اصلی یک وبسایتمتن ارورهامتن دکمه‌هامتن Hint ها‌(نکات کمک‌کننده)و هر متن دیگری در محصول ما، که اصول “نوشتن متن‌های تعاملی” در آن باید رعایت شود. در حقیقت متن‌های تعاملی باعث می‌شوند کاربر، جریان‌های کاربری مختلف را سریع‌تر و آسان‌تر متوجه شود؛ برای مثال متن‌های تعاملی در فرآیندهایی مانند ثبت‌نام یا خرید یک محصول، به کاربران کمک می‌کنند تا مراحل را آسان‌تر و ساده‌تر بگذرانند. درنتیجه متن‌های درست با تسهیل و قابل فهم کردن جریان‌های کاربری، کاربر را به سمت هدفی که ما از او انتظار داریم هدایت می‌کنند. ازطرفی، متن‌های تعاملی سوالات و شک‌های کاربران درمورد محصول‌ها را پاسخ می‌دهند.برای مثال؛در صفحه‌های اصلی (Landing Pages) معمولا توضیح می‌دهند که در این محصول چه خدماتی ارایه می‌شود و شما چطور می‌توانید به ما اعتماد کنید.در صفحه‌های جستجو یا لیست، متن‌های تعاملی باعث می‌شوند کاربر سریع‌تر به آن چیزی که از وبسایت ما می‌خواهد برسد و آن را انتخاب کند.در فرایند خرید و پرداخت نیز، قوانین موجود و اطلاع‌رسانی ازطریق پیامک و… باعث می‌شود کاربر با خیال راحت خرید خود را انجام دهد و به محصول ما اعتماد داشته باشد.درنتیجه هرچه جریان‌های کاربری آسان‌تر و قابل فهم‌تر شوند و اعتمادسازی بیشتری شکل بگیرد، هدف محصول ما نیز سریع‌تر و با روند رو به رشد به‌دست می‌آید. پس تاثیر متن‌های تعاملی در تحقق ارزش‌های محصول، به خوبی دیده می‌شود.انواع متن‌های تعاملی کدام‌اند؟متن‌های پیوسته:صفحه اول یا صفحات ثابت هر وبسایت یا نرم‌افزار، باید حاوی محتوایی باشد که خدمات و ارزش‌های محصول را به‌صورت خلاصه، کامل و دقیق به کاربر ارایه دهد. بخشی از این محتوا نیز همیشه شامل متن‌هایی است که باید با اصول متن‌های تعاملی نوشته شوند. در قسمت‌های مختلف مثل؛منودکمه ثبت‌نامجستجودکمه ورود به بخش خدماتباید با استفاده از متن‌های تعاملی درست، کاربر را هدایت کنیم. پس در این نوع از متن‌ها باید به پیوسته بودن متن در یک صفحه و هدایت کاربر به سمت مشخص، توجه کنیم.متن‌های جریان کاربری:جریان کاربری یعنی کاربر از یک نقطه در وبسایت شروع کند و به یک هدف نهایی برسد. برای مثال جریان کاربری ثبت‌نام، ابتدا با صفحه ثبت‌نام شروع می‌شود و سپس در مراحل بعدی (ارسال کد ازطریق پیامک یا ایمیل و تایید کد و…) تکمیل می‌شود. جریان‌های کاربری نیازمند متن‌های:کوتاهدقیقو هدفمندهستند که کاربر را دقیق به مرحله بعدی هدایت کنند و البته تمام اطلاعات موردنیاز را نیز به او بدهند.چطور پروژه‌ نوشتن و اصلاح متن‌های تعاملی را ایجاد کنیم؟نویسنده‌های تجربه کاربری همیشه در فرایند ایجاد یک قابلیت در وبسایت، وظیفه نوشتن متن‌های تعاملی آن را برعهده دارند. اما اگر فرآیند ایجاد قابلیت جدید در یک محصول کاهش یافت یا متوقف شد، آیا کار UX Writer تمام می‌شود؟خیر. نویسنده تجربه‌کاربری باید برای خودش پروژه ایجاد کند!تیم محققان تجربه‌کاربری، همواره درحال دریافت نظر کاربران از روش‌های مختلفی هستند. روش‌هایی مثل:فرم‌ نظرسنجیضریب وفاداری کاربر به محصول یا همان NPSمصاحبهتست کاربردپذیری یا همان Usability Testرصد تماس‌های پشتیبانیچت آنلایندرنتیجه از دل نظرات کاربران، می‌توانیم مشکلات کاربر با محصول را پیدا کنیم. از مشکلاتی که استخراج می‌کنیم، می‌توانیم پروژه‌هایی را برای خودمان به عنوان یک نویسنده تجربه‌کاربری ایجاد کنیم. پروژه‌هایی مثل:نوشتن سوالات متداول کاربران (FAQ)اصلاح متن‌های صفحه فروداصلاح دکمه‌هاو هرچیزی که بتوان با یک متن درست در آن نقطه از جریان کاربری، مشکل کاربر را برطرف کرد. با این روش، به مرور نقاط درد کاربر در محصول اصلاح و کم می‌شود و می‌توانیم در رصدهای بعدی، نتیجه آن را بررسی کنیم.چند نمونه از پروژه‌های موفق UX Writing در صباایدهالف) نمونه‌هایی از متن‌های پیوستهنمونه اول:در وبسایت آپارات، یک قابلیت جدید ایجاد شد و از داده‌های موجود، فهمیدیم که کاربران به درستی متوجه این قابلیت نشدند. برای اینکه یک اطلاع‌رسانی درست به کاربران خود داشته باشیم، یک صفحه ظاهرشونده در داشبورد کاربری‌شان، نمایش دادیم که به شکل زیر است:تصویر طراحی‌شده، قبل از نوشتن متن تعاملی مناسبپس از تغییر متن‌های این صفحه، نوشته‌ها به حالت زیر درآمد:تیتر بالا: 2 امکان جدید، برای تبلیغات شما!از این پس اگر بخش ویدیوهای مشابه را برای تبلیغ ویدیو خود انتخاب کردید، ویدیو شما را درحین گشت‌وگذار و جستجوی مخاطبان، در سه جایگاه زیر نمایش می‌دهیم:1- بخش ویدیوهای مشابه2- نتایج کلمات جستجوشده (جدید)3- بخش هشتگ‌های آپارات (جدید)چه نکاتی در نوشتن این متن رعایت شد؟با نوشتن یک تیتر جذاب، توجه کاربر جلب می‌شود.در متن، توضیح می‌دهیم که «اگر چه کاری را در کجا انجام دهند، می‌توانند از این امکان جدید استفاده کنند».سه امکان را در قالب بولت نوشتیم تا خوانایی بیشتر و بهتری داشته باشد.از کلمات فارسی استفاده کردیم تا همه کاربران به درستی متوجه منظورمان شوند.نمونه دوم:در تماس‌های پشتیبانی سینماتیکت، متوجه شدیم که بسیاری از کاربران، پشتیبانی سینماتیکت را با خود سینما اشتباه می‌گیرند. درنتیجه متن صفحه تماس با ما که به صورت زیر بود، اصلاح شد:تصویر موجود در سایت سینماتیکت، قبل از نوشتن متن تعاملی مناسبپس از تغییر متن‌های این صفحه، نوشته‌ها به حالت زیر درآمد:تیتر: قبل از تماس با کارشناسان سینماتیکت به نکات زیر توجه کنید:آیا قوانین را مطالعه کردید؟ شاید پاسخ خود را در جزییات قوانین بیابید. (جزییات قوانین لینک شود به صفحه مربوط)سینماتیکت فقط یک مرجع فروش بلیت سینما است و توانایی پاسخ به سوال‌های شما در رابطه با جزییات و شرایط سینما را ندارد.(شماره تلفن)دکمه: تماس با کارشناسان سینماتیکتچه نکاتی در نوشتن این متن رعایت شد؟تیتری برای جلب توجه کاربر نوشتیم.کاربر را به سمت صفحه جزییات قوانین هدایت کردیم تا شاید جواب سوال‌اش را آنجا پیدا کند.توضیحی درمورد تفاوت سینماتیکت با سینما برای کاربر نوشتیم.موارد را به صورت بولت آوردیم تا خوانایی بیشتر و بهتری داشته باشد.در متن دکمه دقیقا به سینماتیکت اشاره کردیم تا اشتباه کاربران درمورد سینما و سینماتیکت برطرف شود.ب) نمونه‌هایی از متن‌های جریان کاربرینمونه اول:در حساب کاربری فیلیمو، یک لیست از علاقمندی‌ها، فیلم‌های تماشا شده و… وجود دارد که مخصوص هر فرد است. بعضی از بخش‌های این لیست به صورت خودکار از سمت فیلیمو پُر می‌شوند (مثل فیلم و سریال‌های تماشاشده) و بعضی از بخش‌های دیگر، با گزینه‌هایی که کاربر انتخاب می‌کند. برای مثال:وقتی کاربر سریالی را تماشا می‌کند که درحال انتشار است و هر هفته قسمت‌های جدید آن منتشر می‌شود، می‌تواند گزینه‌ای که با کادر قرمز در تصویر زیر مشخص شده را فعال کند. پس از فعال کردن این گزینه، پیامی با این عنوان به او نمایش داده می‌شود: به لیست “سریال‌های من” افزوده شد.حالا کاربر می‌تواند در قسمت حساب کاربری، وارد بخش «سریال‌های من» شود و لیست زیر را ببیند:چه نکاتی در نوشتن این متن رعایت شد؟موارد زیر به صورت یک جریان کاربری متصل هستند که در نوشتن متن‌های آن نیز، یکپارچگی را حفظ کردیم:انتخاب اسم دکمهپیامی که به کاربر نشان داده می‌شوداسم بخش در لیستنمونه دوم:هر حساب کاربری در فیلیمو، می‌تواند سه عضو جداگانه برای تماشا داشته باشد. یعنی سه نفر، از سه دستگاه جداگانه، می‌توانند همزمان فیلیمو تماشا کنند. همچنین می‌توان برای هر عضو، محدودیت سنی ایجاد کرد تا فیلم و سریال‌های مناسب همان سن نشان داده شود.اگر برای یک عضو، محدودیت سنی 6-12 سال ایجاد کنیم (کودک)، صفحه اصلی فیلیمو برای آن کودک به صورت تصویر زیر نمایش داده می‌شود:حالا اگر بخواهیم از حالت کودک خارج شویم، گزینه سمت چپ بالا را می‌زنیم و وارد صفحه زیر می‌شویم:با انتخاب عضو «شهاب» که یک بزرگسال است، برای جلوگیری از کنجکاوی یا اشتباه کودکان، ازطریق شماره تلفنی که در فیلیمو ثبت‌نام شده، یک پیامک تایید ارسال می‌کنیم:متن پیامک نیز باید با متنی که در صفحه رایانه نشان داده می‌شود، یکپارچه باشد:بعد از وارد کردن کد در رایانه، تماشای فیلیمو از حالت کودک به بزرگسال تغییر می‌کند.چه نکاتی در نوشتن این متن رعایت شد؟تمام متن‌های موجود در این جریان کاربری را با درنظر گرفتن مراحل قبل و بعد نوشتیم.متن پیامک را با توجه به متن موجود در رایانه نوشتیم تا کاربر از دریافت کد مطمئن شود.متن موجود در رایانه که برای ارسال پیامک بود را با کلمه “اجازه” نوشتیم تا کاربر دقیقا متوجه شود چرا برایش پیامک ارسال می‌شود.رده سنی فرد را زیر تصویر عضویت او نوشتیم تا عضوها را با یکدیگر اشتباه نگیرد.

تست کاربردپذیری، شروع یک بازطراحی موفق

هانیه مجد — Mon, 15 Aug 2022 16:31:35 +0430

فیلیمو به تازگی یک قابلیت جدید به نام مولتی پروفایل یا همان قابلیت چند عضوی را به سیستم تماشای خود اضافه کرده . با وجود این قابلیت، هر حساب کاربری می‌تواند سه عضو جداگانه داشته باشد و هرکدام از این عضوها، می‌توانند تاریخچه تماشا و فیلم‌های موردعلاقه خود را به صورت جداگانه ببینند. بعد از اینکه قابلیت چند عضوی روی فیلیمو اجرا شد، برای بررسی نحوه کار کاربرها با آن، تصمیم گرفتیم یک تست کاربردپذیری از کاربران بگیریم و براساس نتایج آن، در بازطراحی این قابلیت، رابط کاربری ساده‌تری برای کاربران ایجاد کنیم.چگونه تست کاربردپذیری را شروع می‌کنیم؟همان‌طور که در مورد تست کاربردپذیری می‌دانیم، در قدم اول باید قابلیتی که می‌خواهیم مورد تست قرار دهیم را بررسی و ویژگی‌های آن را چک کنیم، تا بتوانیم براساس آن یک سناریو درست طراحی کنیم.تعریف سناریو: منظور از سناریو، لیست وظایفی است که کاربران باید در طول تست، انجام دهند.بررسی اولیه قابلیت چندعضوی:در این مرحله ما مسیری که کاربر در قابلیت چندعضوی طی می‌کند را بررسی کردیم و امکانات آن را به صورت زیر نوشتیم:ساخت عضو جدیدساخت عضو کودکحذف عضوویرایش عضوورود با یک عضو دیگر (انتخاب بین عضوها)چگونه با داده‌های بدست آمده سناریو طراحی کنیم؟در نوشتن سناریو ما دو مورد را در نظر گرفتیم:ایجاد فضای فکری راحت برای کاربر؛ تا بتواند بهتر با ما ارتباط برقرار کند.تعیین وظایفی که کاربر باید در حین تست انجام دهد.طراحی فضای سناریو:برای نوشتن سناریو ابتدا یک محیط فرضی برای کاربر می‌سازیم و با لحن خودمانی با کاربر صحبت می‌کنیم، تا کاربر بتواند راحت‌تر نظراتش را به ما بگوید و حین انجام تست استرسی نداشته باشد.در طول تست بسیار اهمیت دارد که کاربر فکر کند “او دارد به ما خدماتی می‌دهد” و ما به دنبال موفقیت یا شکست در انجام وظیفه‌ای که به او دادیم، نیستیم.ما سعی می‌کنیم هنگام مکالمه با کاربر، از کلمه “تست یا آزمون” استفاده نکنیم؛ مثلا به کاربر می‌گوییم قرار است چندتا کار باهم توی فیلیمو انجام بدیم و نظراتت رو بشنویم.از کاربر می‌خواهیم بلند بلند فکر کند تا بتوانیم پیش‌فرض‌های کاربر را متوجه شویم.بعد از طراحی فضای سناریو، در این مرحله وظایفی که کاربر باید به ترتیب انجام دهد را مشخص کردیم:نوشتن سناریو تست کاربردپذیری در فیلیمو:یک حساب فیلیمو خریدید و می‌خواهید در خانواده‌تان، هر کدام با دسترسی خود وارد فیلیمو شوید تا با سلیقه خودتان فیلم تماشا کنید.وظیفه 1: وارد حساب کاربری خود شوید.وظیفه 2: یک عضو جدید، برای خودتان و با نام خودتان، بسازید.وظیفه 3: حالا یک کودک 5 ساله دارید که می‌خواهید کارتون‌های مناسب خودش را ببیند. برای کودک خود یک پروفایل به نام خودش بسازید و تصویر پروفایل را کودکانه انتخاب کنید.(بررسی نحوه تعیین بازه سنی و انتخاب عکس)وظیفه 4: با دسترسی کودک خود وارد فیلیمو شوید.وظیفه 5: حالا تصمیم می‌گیرید خودتان یک فیلم بزرگسال ببینید، به پروفایل خود برگردید تا بتوانید یک فیلم بزرگسال انتخاب کنید.وظیفه 6: مشغله همسر شما زیاد است و می‌خواهید به جای او، فرزند بزرگتان را به فیلیمو اضافه کنید. یک عضو جدید بسازید و عضو قبلی همسرتان را حذف کنید.وظیفه 7: .دسترسی کودکی که ساختید را ویرایش کنید و سن کودک را بیشتر کنید.برای انجام تست باید شرایطی تعیین کنیم تا بعد از نوشتن سناریو، کاربران را انتخاب کرده و تست را شروع کنیم.چه تعداد کاربر برای انجام تست کاربردپذیری نیاز داریم؟در این مرحله ما باید تعداد کاربرانی که برای تست احتیاج داشتیم را مشخص را مشخص می‌کردیم.طبق مقالات منتشرشده درمورد تست کاربردپذیری، 5 کاربر برای انجام یک تست کافی است. در سایت nngroup نیز دلیل آن به طور کامل توضیح داده شده.پس از بررسی قابلیت چندعضوی به این نتیجه رسیدیم که باید نحوه کار کاربران، در موبایل و دسکتاپ را به طور جداگانه بررسی کنیم. از آنجایی که در موبایل علاوه بر وب، اپلیکشن فیلیمو را نیز داریم، به این نتیجه رسیدیم تست را در سه دسته زیر، هرکدام در گروه‌های 5 تایی انجام دهیم:وب ویو (دسکتاپ)وب ویو (موبایل)اپلیکیشن (موبایل)پس از مشخص شدن تعداد کاربران و سناریو، باید شرایط لازم برای انجام تست را فراهم کنیم.به چه امکاناتی برای انجام تست کاربردپذیری نیاز داریم؟برای تحلیل دقیق تست‌ها باید صدای کاربر و تصویر صفحه نمایش او را ضبط کنیم تا بتوانیم رفتارها و جملات کاربر را بعد از انجام تست، راحت‌تر بررسی و تحلیل کنیم.به همین دلیل دو برنامه Camtasia برای لپ‌تاپ و Az Screen را برای موبایل، جهت ضبط صفحه نمایش و صدای کاربران انتخاب کردیم.تمام شرایط برای انجام تست آماده شد و باید به صورت حضوری با کاربران ملاقات می‌کردیم و تست را انجام می‌دادیم. بعد از ضبط تست‌ها، با تماشای ویدیوهای ضبط‌شده باید به تحلیل رفتارهای کاربر بپردازیم و از آن‌ها گزارش تهیه کنیم.به چه نحوی داده‌های کاربران را برای گزارش‌نویسی پیاده‌سازی کنیم؟تمام مراحل بالا انجام شد و ما از 15 کاربر، تست گرفتیم و ویدیوهای این تست‌ها را تحلیل کردیم.هر ویدیو را به صورت جداگانه تماشا کردیم و نکات مهم آن (به تفکیک کاربر) را در جداول جداگانه ثبت کردیم: نحوه کار کاربر، جملات مهم و سوالات مهم کاربر. در واقع برای هر کاربر به صورت جداگانه یک جدول برای “رفتارهای کاربر“ و یک جدول برای ”جملات و سوالات مهم کاربر“ ترسیم کردیم.مثال:در این مثال دو جدول برای رفتارهای کاربر و جملات مهم کاربر را می‌بینید.توضیحات جدول:ستون1: محل رفتار کاربر (کاربر در کدام صفحه، فعالیت خاصی را انجام داده)ستون2: رفتار کاربر (یا جملات کاربر)ستون3: توضیحات (در صورتی که نکته‌ای از رفتار(یاجملات) کاربر برداشت کردیم، در این ستون می‌نویسیم)نمونه جداول تحلیل رفتار وجملات کاربرانهمانطور که در مثال بالا دیدید، این جداول را برای هرکدام از کاربران به صورت جداگانه ترسیم می‌کنیم تا در مرحله بعد بتوانیم با استفاده از این جداول مشکلات کاربران را جمع‌آوری و دسته‌بندی کنیم.چگونه داد‌ه‌های کاربران(رفتارها،جملات کاربران) را تحلیل کنیم؟پس از بررسی تست‌های گرفته‌شده از کاربران به صورت جداگانه، در این مرحله داده‌های کاربران را با هم مقایسه کردیم تا بتوانیم مشکلات مشترک آن‌ها را پیدا و دسته‌بندی کنیم. در نهایت جدول زیر ایجاد شد که در ادامه جزییات آن را می‌خوانید.نکته: هر گروه 5 تایی را با توجه به دستگاه مورداستفاده، به صورت جداگانه بررسی کردیم.جدول بررسی داده‌های کاربران تست کاربردپذیریتوضیحات جدول بالا:درستون where : محل رفتار کاربر ذکر شده.در ستون Task : کاری که کاربر براساس سناریو باید انجام می‌داد.ستون description : موارد مهمی (مشکلاتی) که کاربران هنگام انجام تسک، با آن‌ها برخورد کردند.ستون users : کاربران را به تفکیک (user1 ,user2...) آوردیم تا اگر با مشکلی که در ستون قبل ذکرشده برخورد کردند، با yes نشان دهیم و اگر با مشکل برخورد نکردند، با no نشان دهیم.در تست‌های کاربردپذیری می‌توانیم از متریک‌هایی که پایین‌تر به آن‌ها اشاره می‌کنم استفاده کنیم تا مشکلات را با توجه به عدد متریک severity (شدت سختی مشکل) که در انتها محاسبه می‌شود،اولویت‌بندی کرده و در بازطراحی آن‌ها را برطرف کنیم.5.متریک task criticality: میزان بحرانی بودن مشکل در یک تسک. نمره دهی از 1 تا 5 (غیربحرانی=1 /بحرانی=5)(این عدد را خودمان تعیین می‌کنیم)به عنوان مثال مشکل ورود یک مشکل بحرانی است و عدد 5 به آن تعلق میگرد چون اگر کاربر نتواند وارد شود،وظایف دیگر را نمی‌تواند در ادامه انجام دهد.6.متریک impact: میزان تاثیرگذاری مشکل در تجربه کاربر:اگر نتوانست تسک را کامل کند >> blocker: نمره 5اگر کامل کردن تسک طولانی شد و کاربر خسته شد >> major: نمره 3اگر مشکل جزیی بود >> minor: نمره 2اگر مشکلی نبود ولی کاربر پیشنهادی برای بهترشدن داشت >> suggestion: نمره 17.متریک frequency: میزان تکرار مشکل در بین شرکت‌کنندگان.میانگین تعداد کاربرانی که با مشکل برخورد کردند.مثال: از 5 کاربر سه کاربربار این مشکل را داشتند.3/5=0.68.متریک severity: سختیِ مشکلاتی که کاربرها در طول این تست با آن برخورد کردند، که از فرمول زیر به‌دست می‌آید:در انتها با توجه به دیتاهای جدول، severity را محاسبه کردیم تا بتوانیم مشکلات را اولویت‌بندی کنیم.severity = task criticality × impact × frequencyبررسی نتایج بدست‌آمده از تحلیل داده‌های کاربرانهمانطور که گفتم، جدولی که در مرحله قبل مثال زدیم را برای هر سه تست (موبایل‌وب، اپلیکیشن، دسکتاپ‌وب) ترسیم کردیم. از دل این نتایج، مشکلات پرتکرار را استخراج کرده و به نتایج زیر رسیدیم.نتایج زیر را بر اساس عدد severity اولویت بندی کردیم. و درنهایت راه‌حل‌های پیشنهادی خود را ارایه دادیم.نتایج نهایی برای بازطراحی:کاربران نمی‌توانند دکمه تغییر پروفایل در منو را تشخیص دهند. این دکمه نیازمند نوشته یا طراحی بهتری است.کاربران ممکن است مفهوم “ویرایش” و امکان انجام این کار را ندانند. اما این مورد آموزش‌پذیر است و با یک نوشته یا طرح بهتر، قابل اصلاح است.برای کاربران، دریافت sms، برای تغییر دسترسی از کودک، اذیت‌کننده است. می‌خواهند با یک پسورد این کار را انجام دهند.دکمه ویرایش عضو (و به طور کلی طراحی ویرایش عضو)، در بیشتر دستگاه‌های موبایلی به‌هم ریخته است (دکمه با اسکرول باید پیدا شود. گاهی هم پیدا نیست!)در صفحه “چه کسی تماشا می‌کند”، نوشته و راهنمای مناسب برای “فقط سه دسترسی مجاز است” داشته باشیم.در ابتدای انتخاب عضو، باید به کاربر توضیح دهیم که پروفایل‌سازی چه مزایایی دارد. (یک مدال راهنما در صفحه چه کسی تماشا می کند)کاربران برای حذف عضو، نمی‌دانند که حتما باید به ویرایش بروند تا دکمه حذف را ببینند.برای قسمت تغییر دسترسی کودک، متن پیام اصلاح شود. (پیام باکس اس ام اس و داخل قسمت ویرایش عضو)مفهوم قفل کودک و دسترسی کودک، یا با همدیگر هماهنگ باشند یا حذف شود تا کاربرها اشتباه نکنند.حرف آخر:در این مورد مطالعه، ما توانستیم یک قابلیت را با انجام تست کاربردپذیری بررسی و مشکلات آن را استخراج کنیم. تا در بازطراحی بعدی این مشکلات برطرف شوند. بعد از بازطراحی بعدی، می‌توانیم از کاربران دیگر دوباره یک تست کاربردپذیری بگیریم تا بفهمیم چند درصد از مشکلات کاربران در طراحی جدید برطرف می‌شود.

یک سناریو خوب، یک مصاحبه عالی!

شهاب صفاری — Wed, 10 Aug 2022 10:00:43 +0430

به جرات می‌توانم بگویم تنها راه شناخت کاربران یک محصول (فرقی نمی‌کند، محصول فیزیکی یا مجازی)، صحبت کردن با آن‌هاست! یعنی به نظر شما چطور می‌شود مشکلات و دردهای کاربرانی که از محصول ما استفاده می‌کنند، و حتی نقاط قوت یک محصول از نظر کاربرانِ آن را فهمید، بدون اینکه به صحبت‌های آن‌ها گوش داد؟چرا و چطور باید با کاربرها صحبت کنیم؟اولین روش برای شنیدن حرف‌های کاربران، رصد تماس‌های پشتیبانی تلفنی، تیکت‌ها، ایمیل‌ها و به‌طور کلی راه‌های ارتباطی کاربران با ما است. اما به جز این روش‌هایی که نارضایتی‌های عمده را به ما انتقال می‌دهند، برای تحلیل یک بخش خاص از محصول باید چه کنیم؟ جواب مشخص است:صحبت کردن با مشتری یکی از اصلی‌ترین مهارت‌ها، هم برای توسعه مشتری و هم برای عملی‌کردن چرخه لین استارتاپ (lean startup) است. همه ما می‌دانیم که باید با مشتری صحبت کنیم، اما انگار هیچ‌کس حاضر نیست اعتراف کند که انجام دادن کار درست “خیلی سخت است” و خراب کردن “خیلی راحت است”. (راب فیتز پاتریک)به همین دلیل باید کار درست و سخت را انجام دهیم و از همین حالا صحبت کردن با کاربران را شروع کنیم. اما یک لحظه صبر کنید!چه سوالی بپرسیم؟از چه کسی سوال بپرسیم؟ضرب‌المثل معروفی دربارۀ مدیریت می‌گوید: «هرگز نباید نظر مادرمون رو درمورد کسب‌وکاری که می‌خوایم راه‌اندازی کنیم، بپرسیم»؛ چون او به خاطر علاقه و محبتی که به ما دارد، پاسخ صادقانه‌ای نمی‌دهد و از ما (محصول ما) تعریف می‌کند؛ پس پاسخ او قابل‌ اطمینان نخواهد بود. اما از نظر راب فیتز پاتریک (نویسنده کتاب تست مامان)، این ضرب‌المثل گمراه‌کننده است، چون شما نباید به تعریف‌های مثبت هیچ‌کس درمورد کسب‌وکارتان اعتماد کنید!یک مثال بد، از مصاحبه با مامان!پسر: "مامان، من یه فکر خوب برای شروع یه کسب و کار دارم ... میتونی بهم کمک کنی؟" کلی درباره‌ش فکر کردم لطفا بهم نه نگو.مامان: "البته عزیزم" تو پسر منی و من آمادم هر کاری از دستم برمیاد برات انجام بدم.پسر: "تو آی‌پدت رو خیلی دوست داری، درسته؟ خیلی ازش استفاده می‌کنی؟"مامان: "بله" خودت اینو خوب میدونی.پسر: "خب می‌خوای یه نرم افزار مثل یه کتاب آشپزی برای آی‌پد خودت بخری؟"مامان: "اوهوم. انگار که توی این سن یه کتاب آشپزی نیاز دارم.”پسر: "خب فقط 40 هزار تومن پول میخواد که خیلی ارزون‌تر از کتاب فیزیکی‌ش هست."به نظرم بدترین نوع مصاحبه برای شناخت نیاز کاربر و تبلیغ کردن محصول، همین مثال بالاست!کتاب تست ماماندر دنیای یوزر ریسرچ (تحقیق درمورد کاربرها)، کتاب خیلی مهمی به نام “THE MOM TEST” یا همان تست مامان وجود دارد که در قالب 7 فصل، شما را برای مصاحبه با کاربر و درک نیازهای او آماده می‌کند. در تکمیل این موضوع نیز در فصل‌های 8 و 9، توصیه‌هایی درباره برنامه‌ریزی برای شروع و توسعه کسب و کار، ارائه می‌دهد. سرفصل‌های این کتاب عبارتنداز:تست ماماندوری از داده‌های بدپرسیدن سوال‌های مهمپیچیده و رسمیش نکنینتعهد و پیشرویپیداکردن گفت‌وگوهاانتخاب مشتری‌هابرنامه‌ریزی و روند کارنتیجه‌گیری و برگۀ تقلبیک مثال خوب، از مصاحبه با مامانپسر: "سلام مامان. آی‌پد جدیدت چطوره؟"مامان: "خب میدونی که خیلی دوسش دارم! هر روز ازش استفاده می‌کنم".پسر: "معمولا باهاش چی کار می‌کنی؟" (یک سوال کلی پرسیدم، پس احتمالا جوابی که داده میشه، جواب با ارزشی نخواهد بود.)مامان: "معمولا اخبار می‌خونم، سودوکو بازی می‌کنم، از حال دوستام باخبر می‌شم. کارهای معمولی انجام می‌دم دیگه."پسر: "آخرین کاری که باهاش انجام دادی چیه؟" (درمورد نمونه هایی که بیان می کنید دقیق باشید، تا داده واقعی و درست بدست بیارید.)مامان: "میدونی من و پدرت برنامه اون سفر رو ریخته بودیم؟ فهمیدم که کجا باید بمونیم." (او هم برای تفریح و هم به عنوان ابزار از آن استفاده کرده بود که در پاسخ‌های معمولی به آن‌ها اشاره نکرده بود.)پسر: "از نرم افزاری استفاده کردی؟" (این سوال کمی سوال تلقینی است، اما بعضی وقت‌ها لازم است تا به موضوع مورد علاقه خودمان اشاره کنیم.)مامان: "نه، فقط از گوگل استفاده کردم. نمی‌دونستم نرم افزاری هم وجود داره. اسمش چیه؟" (جوانان از اپ استور به عنوان موتور جست وجو استفاده می‌کنند. در حالی‌که مادر شما منتظر یک توصیه و دستورالعمل خاص است. اگر این امر به‌طور گسترده‌تر بیان شود، پیدا کردن یک کانال بازاریابی قابل اعتماد، خارج از اپ استور بسیار مهم است.)پسر: "بقیه مواردی که پیدا کردی رو از کجا پیدا کردی؟" (به دنبال پاسخ‌های جالب و غیرمنتظره بروید تا انگیزه‌های نهفته در آن‌ها را متوجه شوید.)مامان: "روزنامه یکشنبه هر هفته بخشی را به نرم افزارها اختصاص میده." (شما یادتان نمی‌آید آخرین بار چه زمانی یک مقاله خواندید، اما به نظر می‌رسد مطالب مطبوعاتی قدیمی ممکن است گزینه مناسبی برای جلب توجه مشتریانی همانند مادرتان باشد.)پسر: " خیلی خب مامان. راستی یک جفت کتاب آشپزی جدید تو قفسه دیدم، از کجا اومدند؟" (ایده‌های تجاری جدید معمولا چندین نقص دارند که منجر به شکست آن می‌شود. که در اینجا خرید اپلیکیشن آی پد و محتوای کتاب آشپزی است.)مامان: "این کتاب‌ها یکی از چیزهایی هستن که فقط باید توی تعطیلات تمومشون کنی. فکر می‌کنم یکی از اونا رو همکارم بهم داده. تا حالا یه بارم بازش نکردم. فکر کنم که تو این سن، یه دستورالعمل دیگه‌ای برای لازانیا لازم دارم!" (آهان! این پاسخ به سه دلیل جواب طلایی محسوب می‌شود:1. افراد مسن دیگر به دستورالعمل عمومی نیاز ندارند!2. بازار هدیه ممکن است داغ باشد.3. آشپزهای جوان، از آنجایی که هنوز اصول اولیه را نمی‌دانند شاید مشتری‌های خوبی برای این بخش باشند.)پسر: "آخرین کتاب آشپزی‌ای که خودت خریدی چی بوده؟"مامان: "حالا که یادم انداختی، سه ماه پیش، یه کتاب آشپزی مخصوص پخت سبزیجات خریدم. بابات می‌خواد غذای سالم‌تر بخوره و فکر کرد که اینطوری تو هزینه‌ها هم صرفه‌جویی می‌شه" (نکته‌ای مهم‌تر و باارزش‌تر: سرآشپزهای باتجربه ممکن است کتاب آشپزی‌های تخصصی و خوب را بخرند.)مثال بالا، یک نمونه قابل قبول از تستی بود که بدون پرسیدن سوال‌های مستقیم و با درنظر گرفتن راه‌حل‌هایی که در کتاب تست مامان گفته شده، انجام شد. نکات بسیار خوبی از آن استخراج شد که برای شروع و توسعه یک اپلیکیشن آشپزی، به ما بسیار کمک می‌کنند.یک سناریو درست، محصول ما را نجات می‌دهدیکی از نمونه‌های موفق سناریونویسی برای مصاحبه تلفنی، مربوط به مشکل چرن کاربران فیلیمومدرسه است. با استفاده از دیتاهای کمّی، متوجه شدیم که در بازه زمانی خاص، گروهی از کاربران پس از تمام شدن اشتراک‌شان در فیلیمومدرسه، اقدام به تمدید اشتراک نمی‌کنند. پس از استخراج دیتاهای کمی دیگر مثل “واچ‌تایم کاربران در بازه امتحان و تعطیلات”، “بسته‌های اشتراکی خریداری‌شده توسط کاربران چرن‌شده”، “محبوب‌ترین محتواهای کاربران فعال و کاربران چرن‌شده” و… و همپوشانی این دیتاها با یکدیگر، دو سگمنت مشخص از کاربران را برای مصاحبه تلفنی انتخاب کردیم. 1. کاربرانی که حداقل دوبار از فیلیمومدرسه اشتراک خریدند و از زمان چرن‌شدن آن‌ها بیش از 1 ماه گذشته 2. کاربرانی که اکنون اشتراک فعال دارند.با نوشتن سوالات صحیح (با استفاده از راه‌حل‌های کتاب تست مامان)، و انجام مصاحبه از کاربران، نتایج دو سگمنت را با یکدیگر مقایسه کردیم تا نقاط ضعف و قوت محصول از نگاه کاربران را به دست آوریم. نتیجه این شد که افزایش چرن کاربران در فیلیمومدرسه تحت تاثیر موارد زیر است:حضوری شدن مدارس بعد از کاهش آمار مبتلایان کرونا. (دانش آموزان فرصتی برای تماشای فیلیمومدرسه نداشتند)دانش آموزان در زمان امتحانات، کم‌تر به فیلیمومدرسه مراجعه می‌کنند. مراجعه مداوم در طول هفته به فیلیمومدرسه، باعث می‌شود کاربر در زمان امتحان نیز سر زدن به فیلیمومدرسه را ادامه دهد. (تعامل مداوم باعث می‌شود تسلط بیشتری به محتواها داشته باشند و در زمان امتحان نیز رجوع کنند)و…درنتیجه فیلیمومدرسه، با استفاده از دیتای به‌دست‌آمده از مصاحبه‌ها به بازطراحی روند تعامل با کاربران و اعتمادسازی در زمینه محتوا مشغول شد و نتایج مثبتی به‌دست آورد.نتیجه‌گیریبرای اینکه یک مصاحبه صحیح همراه با جواب‌های موثر داشته باشیم، باید سوالات مناسبی (سناریو مناسبی) برای آن طراحی کنیم. حالا می‌خواهم یک برگه تقلب برای طرح صحیح سوال‌های مصاحبه به شما بدهم. سوال‌های زیر، سوال‌هایی هستند که هیچ‌وقت نباید در مصاحبه‌های خود از کاربران بپرسید:آیا فکر می‌کنید این ایده خوبی است؟آیا اگر این محصول تولید شود شما آن را می‌خرید؟چقدر برای این محصول پول پرداخت می‌کنید؟و اما سوال‌هایی که پرسیدن آن‌ها همواره می‌تواند به شما کمک کند:از آخرین باری که این مشکل برایت پیش آمده برای من صحبت کن.چه راه حل‌های دیگری را امتحان کردی.چرا برای محصولی که x تولید کرده حاضر هستی این مبلغ را هزینه کنی.در حال حاضر چه طور با این مشکلی که داری کنار آمدی؟به نظرت باید با چه کس دیگری دراین‌باره صحبت کنم؟به نظر شما سوالی مانده که من باید بپرسم؟

سیستم پیشنهاددهنده اولیه فیلیمو (Jump Start Recommendation System)

امیر واهب — Tue, 26 Apr 2022 15:27:26 +0430

مقدمهیکی از اهداف ما در فیلیمو بهبود تجربه کاربران تازه‌وارد است. پیش از این در صفحه اصلی (Homepage) فیلیمو، برای پیشنهاد دادن فیلم به کاربران جدید یک صفحه عمومی داشتیم که نتیجه برآیند انتخاب‌های کلی کاربران بود. بعدتر برای بهبود تجربه کاربران جدید یک سیستم پیشنهاددهنده اولیه ساختیم که کاربران با انتخاب حداقل سه فیلم یا سریال، سلیقه اولیه خود را معرفی می‌کنند و طبق این سلیقه اولیه، فیلم‌ها در صفحه اصلی نمایش داده می‌شوند. به مرور که کاربر فیلم‌های بیشتری تماشا می‌کند سلیقه اولیه او به سلیقه شخصی‌سازی شده تبدیل و صفحه اصلی بر اساس امتیازات جدید کاربر، ساخته می‌شود.این مساله که در مورد همه کاربران جدید در سیستم‌های پیشنهاددهنده وجود دارد را «شروع سرد» می‌گوییم. اصطلاح شروع سرد (cold start) از مدل کار کردن موتور ماشین گرفته شده. وقتی هوا سرد است، با روشن شدن ماشین، اجزا آن به درستی کار نمی‌کند و بعد از رسیدن به دمای مطلوب و اصطلاحا گرم شدن موتور، می‌توان ماشین را به راحتی به حرکت در آورد. در موتورهای پیشنهاددهنده هم «شروع سرد» به این معنی است که شرایط هنوز برای موتور بهینه نیست تا بهترین نتیجه ممکن را پیشنهاد دهد. شروع سرد موقعی اتفاق می‌افتد که یک کاربر جدید یا یک فیلم جدید وارد سیستم شود و سیستم در مورد آن‌ اطلاعات خاصی ندارد. پس برای پیشنهاد دادن دچار مشکل می‌شود. در شروع سرد، دو دسته اصلی وجود دارد:شروع سرد آیتم‌هاشروع سرد کاربراندر این مقاله قصد داریم مساله شروع سرد کاربران را که یکی از چالش‌های ما در فیلیمو بود، بررسی کنیم. سیستم پیشنهاددهنده اولیهاین سیستم دو بخش اصلی دارد. بخش اول انتخاب فیلم‌های منتخب برای نمایش به کاربران و بخش دوم پیدا کردن کاربران (فعال) مشابه (بر اساس فیلم‌های انتخاب شده) و محاسبه امتیاز اولیه.فیلم‌های منتخببرای انتخاب فیلم‌ از بین هزاران فیلم نیاز به روشی داریم که تا جای ممکن طیف وسیعی از سلایق را پوشش دهد و محبوبیت بالایی داشته باشد. یکی از بهترین روش‌ها روش یادگیری فعال (Active Learning) است که حالت‌های مختلفی دارد. در این مقاله (لینک) طبقه‌بندی آن توضیح داده شده است.در این روش، سیستم یک امتیاز بر اساس استراتژی‌های مختلف به تمام فیلم‌ها می‌دهد. استراتژی‌هایی مانند محبوبیت یا آنتروپی (انتخاب آیتم‌هایی که بیشترین اختلاف آرا را دارند) یا ترکیب آن‌ها و بعد از بین آنها فیلم‌هایی با بیشترین امتیاز را به کاربران نمایش می‌دهد. پیشنهاد می‌کنم برای درک بهتر جزئیات این روش، ارائه دکتر الهی (لینک) را مشاهده کنید.در نسخه اول از روش غیر شخصی‌سازی شده استفاده می‌کنیم و به تمامی کاربران، فیلم‌های مشابهی نشان می‌دهیم. برای بیشتر کردن طیف سلیقه کاربران، ابتدا همه فیلم‌ها خوشه‌بندی می‌شوند سپس بر اساس امتیاز سلیقه کلی (استراتژی محبوبیت) هر خوشه را مرتب کرده و فیلمی که بیشترین امتیاز را دارد انتخاب می‌شود.خوشه‌بندی فیلم‌هابرای خوشه‌بندی فیلم‌ها از الگوریتم Hierarchical clustering استفاده شده و به هر فیلم یک برچسب شماره خوشه اختصاص می‌یابد.امتیازدهی به فیلمها در هر خوشه برای محاسبه سلیقه کلی کاربران از امتیازات به دست آمده از الگوریتم شخصی سازی شده (variational autoencoder) استفاده می‌کنیم و آن را در فرمول زیر قرار می‌دهیم (از این فرمول برای انتخاب بهترین فیلم‌ها در سایت imdb استفاده شده است) :GS = (n ÷ (n + i)) × M + (i ÷ (n + i)) × ?M = میانگین امتیاز فیلم برای همه کاربرانn = تعداد حضور فیلم در لیست تماشای کاربرانi = حداقل تعداد حضور فیلم در لیست تماشای کاربران برای محاسبه سلیقه کلی (در حال حاضر ۲۰)C = میانگین تعداد حضور فیلم در لیست تماشای کاربرانبا محاسبه امتیاز کلی برای هر فیلم در هر خوشه، هر فیلمی که امتیاز بیشتری داشته داشته باشد به عنوان نماینده آن خوشه انتخاب می‌شود. در نهایت با استفاده از امتیاز سلیقه همه کاربران، فیلم‌های منتخب مرتب می‌شوند.در دیاگرام زیر فرآیند این مرحله نمایش داده شده اند.پیدا کردن کاربران مشابهاضافه کردن فیلم‌های مشابه به لیست انتخابی کاربربرای تقویت لیست انتخابی کاربران و بهبود نتایج، از سیستم پیشنهاددهنده فیلم به فیلم استفاده کردیم. در بعضی از موارد، یافتن کاربران مشابه با داشتن ۳ فیلم، مخصوصا اگر فیلم‌ها بسیار محبوب باشد، نتیجه خوبی ندارد. بنابراین با استفاده از این سیستم، تعدادی فیلم مشابه به ازای هر فیلم انتخابی (بر اساس تعداد انتخاب‌های کاربران) در نظر گرفته و لیست انتخابی کاربران را تقویت کرده و در نهایت نتایج دقیق‌تری تولید می‌شود.محاسبه امتیاز اولیه کاربر جدید بر اساس امتیازات کاربران مشابهاین لیست تقویت شده را به عنوان یک لیست تماشا شده توسط کاربر جدید در نظر گرفته و به عنوان ورودی به همراه لیست تماشای همه کاربران به الگوریتم شخصی سازی شده (VAE) می‌دهیم. با استفاده از لایه میانی این الگوریتم، یک فضای برداری برای همه لیست تماشای کاربران تشکیل می‌شود. سپس از کتابخانه FAISS استفاده کرده و شبیه‌ترین بردارها یا در واقع لیست تماشای کاربران را پیدا می‌کنیم. در نهایت ۵ کاربر (فعال) مشابه بر اساس این لیست تماشا انتخاب شده و میانگین امتیازات آنها را به کاربر جدید اختصاص می‌دهیم.بر اساس این امتیازات و توضیحاتی که در پست قبلی داده شده است، یک صفحه اولیه برای کاربر ساخته می‌شود.در دیاگرام زیر فرآیند یافتن امتیاز کاربران جدید شرح داده شده.آنالیز رفتار کاربران در انتخاب فیلمهای کاندیدبرای آنالیز رفتار کاربران در انتخاب فیلم‌، ابتدا ترتیب نمایش فیلم‌ها را بررسی کردیم. برای این کار ترتیب نمایش که به صورت پیش‌فرض بر اساس امتیاز سلیقه کلی بود را یک بار با ترتیب تصادفی و یک بار با برعکس امتیازات کلی مورد آزمایش قرار دادیم.تعداد فیلم‌های نمایش داده شده حدود ۸۰ فیلم است و بازه‌های زمانی تست، در هر حالت، یک ماه در نظر گرفته شده.رفتار کاربران در انتخاب فیلمها با امتیازات کلیجدول زیر، تعداد انتخاب کابران در هر جایگاه را نشان می‌دهد. بر اساس این اعداد بیشتر کاربران ۱۰ فیلم اول را انتخاب کرده‌اند.هیت مپ متناظر با جایگاه فیلمها در صفحهنمودار زیر تعداد انتخاب‌های کاربران در جاهای مختلف را نشان می‌دهد. همانطور که مشاهده می‌شود جایگاه ۱ تا ۱۰ بیشترین انتخاب را دارند.هیستوگرام جایگاه فیلمهای انتخاب شده توسط کاربرانرفتار کاربران در انتخاب فیلم‌ها با ترتیب برعکس امتیازات کلیبا برعکس کردن امتیازات، کاربران زیادی جایگاه‌های آخر را انتخاب کردند اما تعداد قابل توجهی از کاربران فقط ۳ فیلم اول را انتخاب کرده و به نظر می‌رسد توجهی به انتخاب فیلم‌ها ندارند.رفتار کاربران در انتخاب فیلم‌ها با ترتیب تصادفیهمانطور که می‌بینید در این حالت، باز هم فیلم‌های جایگاه ۱ تا ۱۰ بیشتر مورد توجه کاربران است.نتیجه‌گیرینتیجه این که تعداد قابل توجهی از کاربران، به جای در نظر گرفتن‌ فیلم‌های مورد علاقه خود، توجه بیشتری به فیلم‌های ابتدایی لیست که آن‌ها دسترسی آن‌ها راحت‌تر است، دارند. در واقع کاربران تازه‌وارد اهمیتی به انتخاب دقیق‌تر برای داشتن پیشنهاد بهتر نمی‌‌دهند. حالا باید دنبال راه‌حل‌هایی برای افزایش دقت کاربران برای انتخاب محتوا باشیم.قدم بعدیهدف از بررسی این سیستم، بهبود تجربه کاربران تازه‌وارد است اما در هر دو بخش اصلی بر اساس داده‌هایی که از رفتار کاربران جمع‌آوری می‌کنیم اصلاحاتی قابل انجام است. در بخش اول در حال بررسی و تست استراتژی‌های دیگری هستیم که فیلم‌های منتخب مناسب‌تری به کاربران ارائه شود و در بخش دوم الگوریتم و فرمول‌های جدید را مورد ارزیابی قرار می‌دهیم.منابعhttps://www.sciencedirect.com/.../S1574013715300150?via%3Dihubhttps://www.aparat.com/v/3NSYthttps://medium.com/@markmilankovich/the-cold-start-problem-for-recommender-systems-89a76505a7https://analyticsindiamag.com/cold-start-problem-in-recommender-systems-and-its-mitigation-techniques/

چگونه از نتایج آزمایش Usability (کاربردپذیری) استفاده کنیم؟

هانیه مجد — Sat, 22 Jan 2022 13:30:08 +0330

جمع‌آوری و مرتب‌سازی داده‌ها و درک آن‌ها در طول تحقیق روی کاربران و گرفتن تست کاربردپذیری، یکی از مهارت‌های حیاتی UX است.با گرفتن یک تست کاربردپذیری متوجه می‌شوید که «آیا کاربران هدف شما می‌توانند از محصول شما به‌راحتی استفاده کنند یا خیر؟». همچنین می‌توانید برای شناسایی مشکلاتی که افراد با رابط کاربری محصول شما دارند، دشواری‌های محصول موجود برای کاربر و نوشته‌های گیج‌کننده در آن، از تست کاربردپذیری یا همان یوزبیلیتی تست استفاده کنید. به‌طور معمول، تست کاربردپذیری شامل آماده‌سازی و تجزیه و تحلیل گسترده است و به عنوان یکی از باارزش‌ترین تکنیک‌های تحقیقاتی در نظر گرفته می‌شود. این تست می‌تواند نتایجی در قالب داده‌های کمی و کیفی ارائه دهد که به هدایت تیم محصول برای پیدا کردن راه‌حل‌های مناسب کمک کند.یک تست کاربردپذیری منظم با پنج الی ده شرکت‌کننده، می‌تواند بسیاری از مشکلات موجود در محصول را برای ما آشکار کند.چگونه داده‌های تست کاربردپذیری را به راه‌حل‌های کاربردی تبدیل کنیم؟بعد از جمع‌‌آوری داده‌های کاربر، ما به روش‌هایی کارآمد برای مدیریت آن‌ها نیاز داریم تا مطمئن شویم درست‌ترین راه‌حل‌ها را برای برطرف‌کردن مشکلات کاربران انتخاب می‌کنیم.یکی از مدل‎‌هایی که طراحان می‌توانند از آن برای سازماندهی افکار خود، به‌منظور بهبود فرآیند خلاقیت استفاده کنند، مدل Double Diamond است.مدل رسمی طراحی Double Diamond شامل چهار فرایند است:1- جمع‌آوری داده‌ها 2- اولویت‌بندی مشکلات 3- ارائه راه‌حل 4- اولویت‌بندی راه‌حل‌هااین چهار فرایند در نمودار زیر آورده شده:در این مقاله ما به بررسی دو روش اولویت‌بندی راه‌حل‌ها می‌پردازیم:1.استفاده از جدول‌های داده که نیازمند محاسبات ریاضی است.2.استفاده از ماتریس که به‌صورت بصری به افراد تیم کمک ‌می‌کند.در ادامه به توضیح این دو روش می‌پردازیم:روش اول: استفاده از جدول‌های دادهمرحله1:جمع‌آوری داده‌هامرحله2: تنظیم اولویت‌بندی‌هامرحله3: ارائه راه‌حل‌هامرحله4: اولویت‌بندی راه‌حل‌هامرحله 1: جمع‌آوری داده‌های به‌دست‌آمده از تست کاربردپذیریاولین گام، جمع‌آوری داده‌های به‌دست‌آمده از تست کاربردپذیری است که باید برای پیداکردن راه‌حل‌ها و ایده‌ها در مراحل بعدی تنظیم شود. نکته کلیدی این است که داده‌ها را باید به نوعی سازماندهی کنید که از به‌هم‌ریختگی جلوگیری شود:در این مرحله به چهار مورد زیر نیاز دارید:سیستم شناسایی مشکل داشته باشید.توجه داشته باشید که مشکل کجا اتفاق افتاده است (صفحه نمایش، ماژول، ویجت UI، جریان و غیره).از وظیفه‌ای که کاربر درگیر آن بوده است، آگاه باشید.توضیح مختصری از موضوع ارائه دهید.یک رویکرد متداول برای سازماندهی داده‌های تست کاربردپذیری، ترسیم داده‌ها است که در جدول زیر نمایش داده‌شده. تصویر زیر، ترسیم داده‌ای در یک تست مشخص را، نشان می‌دهد (ستون‌ها به ترتیب از چپ به راست: محل رفتار، تسک کاربر، توضیح مشکل، کاربران (P1,P2..))چطور باید داده‌های موجود را دسته‌بندی کنیم: نمونه جدول داده مربوط به تست کاربردپذیریمرحله 2: تنظیم اولویت‌بندی‌هااز آنجایی که منابع محدود هستند، لازم است مسائل مربوط به کاربردپذیری به گونه‌ای اولویت‌بندی شود که تجزیه و تحلیل را بهینه کند (سرعت و دقت تحلیل را بالا ببرد).به‌طورمعمول، هر مشکل در تست کاربردپذیری دارای درجه‌ای از شدت است که این درجه، تحت تأثیر متریک‌های critically, frequency, impact است. در ادامه به توضیح مختصری در مورد هر متریک می‌پردازیم:متریک Task criticality: بحرانی بودن یک مشکل از نظر تأثیر مخرب بر تجارت یا کاربر، با این متریک مشخص می‌شود. این متریک توسط خودمان مقداردهی می‌شود؛ یعنی به زبان ساده، تعیین می‌کنیم که این مشکل چقدر برای کسب و کار یا کاربر حیاتی است و مقدار عددی برای آن تعیین می‌کنیم. مقادیر ممکن است از یک دنباله خطی ساده (مثلاً 1، 2، 3، 4، و غیره) باشد. بهترین راه این است که از 1 تا 10، بحرانی‌بودن مشکل را مشخص کنیم (10= بسیار بحرانی)متریک frequency: این متریک به تعداد افرادی که در تسک موجود، با مشکل موردنظر برخورد کردند مربوط است. یعنی تعداد تعداد کاربرانی که به مشکل برخورد کردند، تقسیم بر تعداد کل کاربرانی که تست داده‌اند.frequency= (افرادی که با مشکل برخورد کردند) ÷ (کل شرکت کنندگان)متریک impact: این متریک به تاثیرگذاری مشکل بر روند کار کاربر اشاره دارد:با اختصاص یک مقدار (همانند مقداردهی در criticality) میزان تاثیرگذاری یک مشکل بر روند کار کاربر در محصول مشخص می‌شود:مقدار5: (مسدود کننده) مشکل، کاربر را از انجام وظیفه باز می‌دارد.مقدار3: (عمده) باعث ناامیدی یا تاخیر در انجام وظیفه می‌شود.مقدار2: (جزئی) تأثیر جزئی در انجام کار دارد.مقدار1: (پیشنهاد) کاربر هنگام انجام وظیفه، پیشنهادی می‌دهد.در نهایت، شدت (severity) هر مشکل را با ضرب سه متغیر بالا محاسبه می‌کنید:severity=impact*frequency*criticalityچطور نتایج تست کاربردپذیری را تحلیل کنیم: اولویت‌بندی مشکلاتدر مثال بالا، سناریوی زیر را داریم:سه مشکل توسط سه شرکت‌کننده (P2 ،P1 و P3) تجربه شده:وظایف کاربروظیفه کاربر: "create a post"وظیفه کاربر: “social login”مقداردهی متریک‌ها:متریک criticality: مقدار”5” برای وظیفه 1، مقدار”2” برای وظیفه 2 (یک وظیفه با درجه اهمیت کمتر)متریک impact: مقدار “3” برای وظیفه 1، مقدار”2” برای وظیفه 2متریک frequency: در وظیفه 1، یک مشکل، 1 بار با سه شرکت‌کننده اتفاق افتاد، بنابراین 1/3 = 0.33در نهایت،متریک severity برای یک وظیفه محاسبه می‌شود:severity = task criticality × impact × frequencyپس در مثال بالا شدت برابر است با: 3×5×0.33 = 4.95تا اینجا ما مهمترین مسائل کاربردپذیری خود را به ترتیب یافتیم، و در این مرحله دیدگاه خوبی نسبت به چشم‌انداز مسئله کاربردپذیری داریم؛ تصویر بزرگی که به تیم کمک می‌کند تا مشکلات بسیار جدی را چارچوب‌بندی و بهنیه‌سازی کند.مرحله 3: ارائه راه‌حلبه‌طورمعمول، آزمایش‌های کاربردپذیری بدون فهرستی از توصیه‌ها (پیشنهادات عمومی) و راه‌حل‌ها (دستورالعمل‌های خاص) کامل نمی‌شوند. گاهی اوقات راه حل کاملاً واضح است، مانند اصلاح محل قرارگیری یک دکمه یا نوشته در وب‌سایت.اما در بعضی موارد وضعیت برای برطرف‌کردن مشکلات با راه‌حل‌های مختلف، پیچیده می‌شود. کدام راه حل بهتر است؟ کدام یک امکان‌پذیرتر است؟ هزینه/فایده اجرای یک آزمایش برای کشف چقدر است؟ در اینجا، روش سنتی «پیشنهادات عمومی» کافی نخواهد بود. برای کاهش خطر تصمیم‌گیری بد در طراحی، ما به چندین راه‌حل جایگزین و یک فرآیند انتخاب موثر، باتوجه به داده‌های جمع‌آوری‌شده و اولویت‌بندی مراحل در قسمت قبل، نیاز داریم:برای هر مسئله، ایده‌ها و راه‌حل‌های متعددی ایجاد کنید: راه‌های ممکن برای رسیدگی به مسئله چیست؟ در اینجا، یک فرصت عالی برای همکاری با سایر اعضای تیم (توسعه‌دهندگان، طراحان، مدیران محصول و غیره) فراهم‌شده.راه‌حل‌ها را دوباره سازماندهی کنید: هرکدام از راه‌حل‌ها را به‌صورت جداگانه یادداشت کنید و در صورت لزوم، آن‌ها را ادغام یا تقسیم کنید تا از اضافه‌کاری اجتناب کنید و بتوانید در آینده سریع‌تر، بهترین راه‌حل را انتخاب کنید.مشکلات دیگری که هرکدام از راه‌حل‌ها ممکن است آن‌را حل کند، علامت‌گذاری کنید: در عمل، یک راه حل خوب می‌تواند چندین مشکل را برطرف کند. راه‌حل‌های خوب همه‌کاره هستند!با انجام مراحل بالا، جدول زیر حاصل می‌شود:جمع‌آوری داده برای تحقیق کاربردپذیری (راه‌حل‌هایی که تمام افراد تیم ارائه می‌کنند) در جدول بالا در ستون اول سمت چپ، راه‌حل‌ها ذکرشده و در ستون دوم، مشکلات موجود (I1,I2,..) مقداردهی شده‌است.نکته: عدد 1 نشان‌دهنده این است که این راه حل برای این مشکل مناسب است.مرحله 4: اولویت بندی راه‌حل‌هابه طور مشابه برای اولویت‌بندی راه‌حل‌ها، باید آن‌ها را بر اساس برخی پارامترها اولویت‌بندی کنیم. در تیم‌هایی که از سیستم مدیریت اجایل ( agile team) استفاده می‌کنند، با این موضوع بسیار جدی برخورد می‌شود. یعنی از متریک‌هایی برای سنجش ارزش تجاری و پیچیدگی‌های معمول استفاده می‌کنند تا ضریب بازگشت سرمایه (ROI) را محاسبه کنند. ما نیز برای محاسبه ارزش پیاده‌سازی هرکدام از راه‌حل‌ها به‌صورت زیر عمل می‌کنیم:1.اثربخشی (effectiveness) هر راه حل را محاسبه می‌کنیم:هرچه مشکل جدی‌تر باشد، راه‌حل بهتری خواهد داشت. پس شدت (severity) تمام مسائلی که راه‌حل، آن‌ها را برطرف می‌کند را با یکدیگر جمع می‌کنیم.اثربخشی = مجموع شدت مشکل‌ها2.پیچیدگی راه‌حل را پیدا می‌کنیم:منابع مورد نیاز برای اجراکردن این راه‌حل چیست؟الزامات کسب و کار/کاربر چقدر واضح است؟به عبارت دیگر، هر چه تلاش برای پیاده‌سازی و عدم اطمینان به راه‌حل بیشتر باشد، راه‌حل پیچیده‌تر است. درنتیجه پیچیدگی را به یک مقدار قابل اندازه‌گیری تبدیل می‌کنیم، مانند دنباله فیبوناچی (1، 2، 3، 5، 8، و غیره). اگر این کار را به عنوان یک تیم انجام می دهید، Planning poker کاملاً مناسب است.3.متریک ROI راه حل را محاسبه می‌کنیم:در نهایت ضریب ROI را محاسبه می‌کنیم. بازگشت سرمایه (ROI) یک معیار عملکردی است که برای ارزیابی کارایی یا سودآوری یک سرمایه‌گذاری یا مقایسه کارایی تعدادی از سرمایه‌گذاری‌های مختلف استفاده می‌شود.ROI = پیچیدگی / اثربخشیحالا جدول نهایی راه‌حل‌ها به شکل زیر است:چدول نهایی اولویت‌بندی راه‌حل‌های پیشنهادشده، برای برطرف‌کردن مشکلاتی که در تست یوزبیلیتی مشاهده شدندستون‌ها از چپ به راست:1.لیست راه‌حل‌ها2.مشکلات (i1 تا i3) همراه با شدت آن‌ها (4.95، 6.7 و 10.05).نکته: هر بار که یک راه‌حل می‌تواند یک مشکل را برطرف کند، مقدار 1 داده‌ می‌شود (مثلاً اگر یک راه‌حل، دو مشکل را حل می‌کرد، عدد 2 قرار می‌دهیم).3.اثربخشی هر راه‌حل (4.95، 4.95 و 16.75).4.پیچیدگی هر راه‌حل (1، 3 و 5) که توسط تیم برآورد شده.با توجه به این مثال، ما باید اجرای راه‌حل‌ها را به ترتیب زیر (از ROI بالاتر به پایین‌تر) اولویت‌بندی کنیم: ابتدا راه حل 1، سپس راه حل 3 و درنهایت راه‌حل 2.تمام فعالیت ما در یک نگاهابتدا با جمع‌آوری داده‌ها شروع کردیم، سپس مسائل را با توجه به پارامترهای خاص اولویت‌بندی کردیم. پس از آن، ایده‌ها و راه‌حل‌هایی برای آن مسائل ایجاد کردیم و در نهایت، راه‌حل‌ها را نیز اولویت‌بندی کردیم.استفاده از جدول‌های دادهاین روش شامل برخی از محاسبات (پایه) است که بارها تکرار می‌شود، بنابراین بهتر است از یک قالب جدول مشخص استفاده کنید. اگر می‌خواهید از روشی که در بالا توضیح دادیم استفاده کنید، می‌توانید قالب مربوط به آن را در لینک زیر مشاهده کنید: https://goo.gl/RR4hEd. می‌توانید مطابق نیازهای خود آن را تغییر دهید.روش دوم: استفاده از روش بصریبسیاری از افراد می‌خواهند با روش یادداشت‌های برچسبی و تخته‌های سفید کار کنند، چرا که معمولاً سریع‌تر و سرگرم‌کننده‌تر است، و همچنین همکاری افراد تیم را نیز تسهیل می‌کند. اما چگونه می‌توانیم از ابزارهای بصری مانند یادداشت‌های برچسبی برای پیاده‌سازی و تحلیل نتایج استفاده کنیم؟ایجاد یک ماتریس برای مسائل (impact x frequency).ایجاد یک ماتریس برای راه‌حل‌ها (effectiveness x complexity).هر ماتریس به چهار قسمت تقسیم شود که نشان دهنده اولویت‌بندی است.نمودارهای مربوط به اولویت‌بندی مشکلات و راه‌حل‌ها، به صورت بصریمراحل:ماتریس موضوع را با قراردادن برچسب‌ها در ربع مناسب، با توجه به تأثیر و فرکانس ایجاد کنید. برای ساده‌کردن این رویکرد، مجبور شدیم بحرانی‌بودن وظیفه را کنار بگذاریم.ماتریس راه‌حل را با سازماندهی برچسب‌ها براساس اثربخشی و پیچیدگی هر راه‌حل ایجاد کنید:راه‌حل‌ها برای هر موضوع، با شروع مسائل در ربع 1 ماتریس موضوع (آن‌هایی که شدت بیشتری دارند).راه‌حل‌ها را در ماتریس راه‌حل قرار دهید، از ربع 1 (بالا سمت چپ) شروع کنید. هر چه موضوع شدیدتر باشد، راه‌حل آن موثرتر است.پیچیدگی هر راه‌حل را با حرکت‌دادن آن روی محور افقی تنظیم کنید (هرچه پیچیده‌تر، بیشتر به سمت راست باشد).مراحل بالا را برای مسائل باقی‌مانده (به ترتیب ربع 2، 3 و 4) تکرار کنید.در پایان، راه‌حل‌های ربع 1 راه‌حل‌هایی هستند که بهترین بازگشت سرمایه (مؤثرتر و پیچیده‌تر) را دارند که نشان‌دهنده اولویت اصلی است. نتیجه در تصویر زیر نشان‌داده‌شده است.مثالی از اولویت‌بندی مشکلات و راه‌حل‌های موجود، به صورت بصری نقاط قوت و ضعف روش بصری چیست؟نقطه ضعف در اینجا این است که به جای محاسبات مانند جدول داده‌ها، باید به دقت بصری تکیه کنید. اما از جنبه مثبت نیز ما روشی داریم که همکاری اعضا را تقویت می‌کند.کدام رویکرد بهتر است؟پاسخ کوتاه است. پاسخی که به بهترین وجه با شرایط شما مطابقت دارد و با اهداف شما هماهنگ است.نکات نهایی برای تجزیه و تحلیل داده‌های تست کاربردپذیریزمانی که با مطالعات بزرگتر سر و کار دارید، اولویت بندی موضوع ها به تمرکز بیشتر گروه کمک می‌کند، با کاهش چالش های شناختی،اطلاعات اضافی، تحلیل‌های ناقص در زمان و منابع صرفه‌جویی می‌کند.کامل‌کردن هر دو جدول داده، راه‌حل‌ها را با نتایج تست هماهنگ نگه‌می‌دارد (به دلیل جفت‌شدن مسائل و راه‌حل‌ها) و ریسک اجرای راه‌حل‌های کم‌اهمیت‌تر را کاهش می‌دهد.ابزارهای آنلاینی وجود دارند که ما به راحتی می‌توانیم این روش را به صورت مشترک (به طور جزئی یا کلی) با استفاده از آن‌ها نیز پیاده‌سازی کنیم.درک محدودیت‌های این رویکرد بسیار مهم است. به‌عنوان مثال، در طول مرحله اولویت‌بندی، نگرش‌ها و رفتارهای مثبت مشاهده‌شده کاربران، در آزمایش لحاظ نمی‌شود. تمرکز روی مشکلات تست کاربردپذیری است. یک پیشنهاد این است که این نوع داده‌ها را به‌طور جداگانه ثبت کنید و از آن در طول مسیر طراحی یا بازطراحی، در صورت نیاز، استفاده کنید.در نهایت، جدا از تست کاربردپذیری، این رویکرد را می‌توان به سایر تکنیک‌های تحقیق UX نیز تعمیم داد (رویکرد پیاده‌سازی نتایج و ارائه راه‌حل‌های موجود و اولویت‌بندی آن‌ها). با استفاده از رویکرد «Double Diamond» (مسائل و راه‌حل‌های واگرا/همگرا)، می‌توانیم داده‌های تحقیقاتی کاربران مختلف را ترکیب کنیم و از روش‌های بالا در هر پروژه‌ای استفاده کنیم.منابع:https://uxplanet.org/turning-usability-testing-data-into-action-without-going-insane-9f364a683076https://www.toptal.com/designers/usability-testing/turning-usability-testing-data-into-action?

استفاده از Tag Manager برای بررسی رفتار کاربران در نرم‌افزارهای موبایلی

ستاره مقاری — Sun, 26 Dec 2021 01:14:59 +0330

دنبال‌کردن رفتار کاربران در وب‌سایت‌ها و نرم‌افزارها همیشه بهترین روش برای شناسایی نقاط قوت و ضعف محصول است که می‌تواند به فرایند بازطراحی کمک کند. امروزه ابزارهای جانبی مختلفی برای بررسی رفتار کاربران به کمک تیم‌های توسعه آمده‌اند که می‌توان از آن‌ها به همین منظور استفاده کرد. ازجمله دلایل همه‌ تیم‌های توسعه محصول برای بررسی رفتار کاربر نیز می‌توان به 4 مورد زیر اشاره کرد:پیداکردن نقاط ضعف و قوت محصول.پیداکردن مسیرهایی که کاربر در محصول ما طی می‌کند؛ مثلا کاربر برای خرید اشتراک یا خرید یک محصول در وب‌سایت ما، از کجا شروع می‌کند و چه بخش‌هایی را مشاهده می‌کند.سنجش موثربودن تغییرات محصول در تعامل کاربر؛ یعنی بعداز انجام یک‌سری تغییرات جدید، تعامل کاربر با این تغییرات چگونه است؟انجام A/B تست و تست‌های دیگر؛ مثلاً همزمان دو نسخه از محصول را در اختیار دو گروه از کاربران قرار می‌دهیم و با بررسی رفتار آن‌ها، میزان موفق‌بودن هرکدام از این نسخه‌ها در بخش‌های مختلف را می‌سنجیم.چالشی سر راه بررسی رفتار کاربران!امروزه ابزارهای مختلف بسیاری برای بررسی رفتار کاربران در وب‌سایت‌ها ارائه شده، اما هنوز چالش اصلی ما برای بررسی رفتار کاربر، در نرم‌افزارهای تلفن همراه است. اما دلیل اینکه بررسی رفتار کاربر در نرم‌افزار موبایل، سخت‌تر از وب‌سایت است چیست؟ازطریق وب‌سایت می‌توانیم تغییرات مربوط به بررسی رفتار کاربر را راحت‌تر انجام دهیم؛ یعنی در وب‌سایت به‌راحتی و در هرزمان می‌توانیم تنظیمات مربوط به ابزار بررسی رفتار کاربر را تغییر دهیم و نتایج جدیدتری دریافت کنیم.نرم‌افزار موبایل نیازمند راه‌اندازی مجدد است؛ در نسخه وب‌سایت ما فقط یک کد جاوااسکریپت را در صفحه‌ای که می‌خواهیم رفتار کاربر بررسی شود قرار می‌دهیم و نتایج دل‌خواه را به‌دست می‌آوریم. اما در نرم‌افزار باید هربار مراحل بازطراحی، تست QA و راه‌اندازی طی‌شود و درنهایت می‌توانیم قبل از راه‌اندازی، کدهای مربوط به ابزارهای جانبی بررسی رفتار کاربر را در آن قرار دهیم.در وب‌سایت به اطلاعات بیشتری دسترسی داریم؛ مثلاً داده‌های مربوط به Site Heatmap در نرم‌افزار موبایلی وجود ندارد.ابزارهای بیشتری برای بررسی رفتار کاربر در وب‌سایت موجود است؛ تعداد ابزارهای جانبی موجود برای وب‌سایت و همچنین امکانات آن‌ها بسیار بیشتر از ابزارهای جانبی برای بررسی رفتار کاربر در نرم‌افزارهای موبایلی است.یک مثال از نمونه داده به‌دست‌آمده از بررسی وب‌سایت: در وب‌سایت ما می‌توانیم قسمت‌هایی از صفحه که کاربر بیشترین توجه به آن را داشته (ازطریق نگه‌داشتن موس روی آن قسمت) پیدا کنیم که نام این داده، نقشه Site Heatmap است. اما در نرم‌افزار موبایل، این اطلاعات را نمی‌توانیم به‌دست آوریم. به تصویر زیر توجه کنید:بررسی رفتار کاربر در نرم‌افزارهای موبایلیبرای بررسی رفتار کاربران در نرم‌افزارهای موبایلی، ممکن است مجبور باشیم همزمان از ابزارهای بسیار زیادی استفاده کنیم؛ زیرا هرکدام از این ابزارها فقط بخشی از خواسته ما را برآورده می‌کنند و رفتارهای خاصی را رصد می‌کنند. پس مثلاً ممکن است مجبور باشیم همزمان از Firebase، Facebookpixel، Segmentino، Branch، WebEngage، Adjust، Adtrace، Metrix و… روی نرم‌افزار موبایلی استفاده کنیم. تصور کنید که چه اوضاع به‌هم‌ریخته‌ای ممکن است برای تیم توسعه به‌وجود آید، و طبیعتاً مدیریت کدهای مربوط به این ابزارها برای برنامه‌نویسان بسیار سخت است! حالا اگر نرم‌افزار نیازمند یک تغییر کوچک باشد، آیا باید تنظیمات مربوط به تمام این ابزارهای جانبی را نیز تغییر دهیم؟ جواب بله است! سخت‌ترین چالشی که در بررسی رفتار کاربر روی نرم‌افزارهای موبایلی برای ما پیش می‌آید، همین است. اما آیا راه‌حلی برای برطرف‌کردن این مشکل وجود دارد؟یک واسطه، حلال مشکلات!راه‌حلی که ما در صبا ایده برای حل این مساله پیدا کردیم استفاده از ابزار Google Tag Manager به عنوان واسط بین Firebase و سایر ابزارهایی است که می‌خواهیم از آن‌ها استفاده کنیم. معماری راه‌حلِ ما، به طور شماتیک در تصویر زیر نشان داده شده است:درواقع tag manager به عنوان یک داشبورد مدیریتی عمل می‌کند و تمام اطلاعات مربوط به eventها را از نرم‌افزار می‌گیرد و به ابزارهای جانبی ارسال می‌کند. علاوه‌بر این می‌توانیم تمام تنظیمات مربوط به ابزارهای جانبی دیگر را ازطریق tag manager مدیریت کنیم؛ مثلاً برای متوقف‌کردن آنالیتیکس می‌توانیم از داخل tag manager این کار را انجام دهیم. اما نکته مهم این است که این tag manager نیز همانند ابزارهای جانبی دیگر، دارای یک کد جاوااسکریپت است که در وب‌سایت، در قسمت کدهای مربوط به صفحه موردنظر قرار می‌گیرد، و هنوز مشکل ما در برقراری ارتباط آن با نرم‌افزار موبایلی برقرار است. در این بین متوجه شدم که ابزار Firebase که قبلاً نیز از آن برای بررسی رفتار کاربر ازطریق نرم‌افزار موبایل استفاده کردیم، می‌تواند به‌عنوان پُلی بین نرم‌افزار موبایل و tag manager قرار گیرد و تمام اطلاعات را به‌صورت یک‌جا به tag manager ارسال کند.فایربیس eventها (رخدادهایی که می‌خواهیم رفتار کاربر را در آن‌ها بررسی کنیم) را از نرم‌افزار دریافت می‌کند، به tag manager ارسال می‌کند و اینجا tag manager تصمیم می‌گیرد که اطلاعات مربوط به هر event را به کدام‌یک از ابزارهای جانبی ارسال کند. ممکن است اطلاعات را به خود فایربیس نیز برگرداند (چون فایربیس نیز یکی از ابزارهای جانبی برای بررسی رفتار کاربران محسوب می‌شود).خبر خوش برای برنامه‌نویس‌ها!اضافه‌کردن فایربیس و tag manager به نرم‌افزار موبایلی می‌تواند با افزودن SDK توسط برنامه‌نویس به‌راحتی انجام شود. در ادامه می‌خواهم کار با داشبورد tag manager و نحوه کار با آن را توضیح دهم. در مرحله اول شما باید در این بستر عضو شوید. بعد از واردشدن و ساخت حساب در tag manager با صفحه زیر روبرو می‌شوید.پس‌از اینکه در tag manager حساب خود را ساختید، می‌توانید در قسمت Triggers (همانند تصویر زیر)، eventهایی که قصد دارید در بررسی رفتار کاربر صدا بزنید را مشاهده کنید. می‌توانید دقیقاً همان eventهایی که در فایربیس ساختید را با همان اسم در اینجا تعریف کنید.مثلاً برای ساختن event «خرید» (purchase) با چنین تنظیماتی می‌توانیم آن را ایجاد کنیم:هرکدام از این eventها یک سری پارامترهایی به‌همراه دارند که توضیحات بیشتری راجع‌به آن event می‌دهند. مثلاً اگر درحال ساختن event خرید هستیم، پارامترهای آن عبارتنداز:چه کالایی خریداری شده؟قیمت آن کالا چقدر بوده؟شناسه آن کالا چیست؟و….که این پارامترها را می‌توانیم در بخش variables، دقیقاً به همان نامی که در فایربیس ایجاد شدند تعریف کنیم. مثلاً یکی از پارامترهای event خرید، می‌تواند «نوع پرداخت» باشد که با نام PAYMENT_TYPE آن را تعریف کردیم:بعداز تعریف کردن این eventها و پارامترهای مربوط به آن‌ها، نوبت آن است که مشخص‌کنیم وقتی هرکدام از این eventها اتفاق می‌افتند، کدام‌یک از ابزارهای دیگر فراخوانی شوند و اطلاعات به‌دست‌آمده به آن انتقال داده شود؟به‌همراه هرکدام از این eventها می‌توانید event دیگری را فراخوانی کنید، جلوی آن را بگیرید (بلاک کنید) یا اسم آن event را تغییر دهید.یک نکته مهماگر ابزارهای آنالیتیکسی که قصد استفاده از آن‌ها را داریم در tag manager وجود نداشتند، می‌توانیم از بخش function call استفاده کنیم. که به این ترتیب، اطلاعات eventها و پارامترهایی که از فایربیس آمده، به نرم‌افزار موبایل برگردانده می‌شود و در ادامه می‌توانیم مشخص کنیم که این اطلاعات ازطریق خود نرم‌افزار موبایل به کدام ابزار جانبی ارسال شود؟درواقع درصورتی که ابزار در tag manager وجود نداشت، به‌جای اینکه اطلاعات ازطریق tag manager به ابزار جانبی ارسال شود، مستقیماً از خود نرم‌افزار به ابزار جانبی ارسال می‌شود.کلام آخرخلاصه این که، مدیریت داده‌های رفتار کاربر با کمک Google Tag Manager، ما را از اتصال تک‌تکِ ابزارهای جانبی به نرم‌افزار بی‌نیاز می‌کند و روشی بسیار منعطف و بهینه برای مدیریت همه‌ ابزارهای اندازه‌گیری و Analytics در یک داشبورد واحد است. استفاده از ابزار Tag Manager با این که بسیار مفید و کارگشا است ولی هنوز بین تیم‌های توسعه رایج نشده و به همین دلیل احساس کردم که به اشتراک‌گذاشتن تجربه‌ی تیم ما در پیاده‌سازی این ابزار کاربردی، می‌تواند برای تیم‌های دیگر نیز مفید باشد.

استراتژی هک رشد برای مدیران ارشد و محصول

امین مسگری — Sat, 27 Nov 2021 17:00:47 +0330

هک رشد چیست؟ اصطلاح هک رشد برای اولین بار توسط شان الیس (Sean Ellis) در سال 2010 ابداع شد. استارتاپ‌هایی که می‌خواهند در ابتدای کار با مدت زمان کوتاه و بودجه کم، رشد چشم‌گیری پیدا کنند، به سراغ استراتژی به نام هک رشد (Growth Hacking) می‌روند. درحقیقت هدف از استراتژی هک رشد، به‌دست‌آوردن هرچه بیشتر کاربران یا مشتریان در مدت زمان کوتاه و با هزینه کمتر است.اعضای کلیدی تیم رشدتیم رشد با توجه به هدف و تسک‌هایش نیاز دارد تا یک‌سری افراد با مهارت‌های خاص را در تیم داشته‌باشد. لازم‌است گفته‌شود که در بعضی مواقع و در یک‌سری تسک‌ها، افرادی از تیم‌های دیگر وارد تیم می‌شوند تا به یک تسک کمک کنند و دوباره از تیم خارج می‌شوند، اما به صورت کلی باید افراد زیر در تیم حضور داشته باشند:رهبر تیم رشدرهبر تیم رشد موظف است تیم را رهبری کند. این شخص باید دانش مدیریت افراد، اطلاعات، محصول و تحلیل را داشته‌باشد تا بتواند به‌خوبی در راستای اهدافی که تعیین شده‌است، تیم را پیش ببرد و از طرفی، این شخص باید تسلط کافی به کسب‌وکار داشته باشد تا بتواند به درستی متریک‌ها و اهداف را مشخص کند.مدیر محصولبرای اینکه تیم‌ها در راستای اهداف محصول با هم حرکت کنند و هماهنگی بین‌شان باشد، باید یک مدیرمحصول تعیین شود. مدیرمحصول باید شخصی باشد که به درستی محصول و نیازهای کاربر را بشناسد و از طرفی نیز مدیر محصول می‌تواند انحصار طلبی در شرکت‌ها را از بین ببرد؛ تا بتوانند بهترین تاثیر را بگذارند. به همین دلیل وجود مدیر محصول در این تیم الزامی است.مهندس نرم افزارهر تغییری که بخواهد روی محصول اعمال شود نیاز به یک مهندس نرم افزار دارد و باید این شخص در تیم حضور داشته‌‌باشد تا بتواند به سریع‌ترین شکل، تغییرات مورد نیاز را فراهم کند.متخصص بازاریابیبعضی از تیم‌های رشد بدون وجود دائمی متخصص بازاریابی کارها را پیش می‌برند و هر موقع که نیاز به این تخصص بود، این شخص به تیم وارد می‌شود. اما بهتر است که یک شخص با این تخصص به‌صورت دائم در تیم حضور داشته‌باشد.تحلیل‌گر دادهبرای اینکه بتوانید داده‌های هر بخش موردنیاز را آماده و تحلیل کنید، نیاز دارید تا تحلیل‌گر داده، اطلاعات مورد نیاز را در ابتدا جمع‌آوری و سپس آن را تحلیل کند و گزارش را به تیم ارائه کند.طراح محصولهمان‌طور که از اسم این تخصص مشخص است، شما نیاز به یک فردی دارید تا طراحی‌های وظایف پیش‌رو را فراهم کند.مراحل مختلف فرآیند هک رشدفرآیند هک رشد از ۴ بخش تشکیل شده‌است:تحلیل و پیدا کردن موارد مورد نظرایده‌پردازی برای همان بخشاولویت‌بندیتستوظیفه مدیران ارشد این است که از تیم هک رشد دفاع کنند: در فرآیند استفاده از هک رشد در کسب‌وکار، باید همان ابتدا مشخص شود که مدیر هک رشد به چه کسانی گزارش می‌دهد؟ بهتر است گزارش‌ها به‌صورت مستقیم به مدیران ارشد ارائه شوند؛ چون با این کار، لایه‌های بروکراسی ازبین می‌رود و تیم هک رشد درگیر فرآیندهای مختلف نمی‌شود و مدیران ارشد می‌توانند نظر تیم هک رشد را هرچه سریع‌تر در بخش‌های دیگر کسب‌وکار اعمال کنند.ساختارهای گزارش‌دهیساختار محصول‌محورساختار مستقلساختار محصول‌محوردر این ساختار، هر مدیر محصول یک تیم را مدیریت می‌کند و باتوجه به اینکه هرکدام از محصول‌ها، هدف مشخص یا شاید متفاوتی دارند، گزارش هرکدام از این مدیرها نیز متفاوت است. این گزارش‌ها جمع‌آوری می‌شوند و به‌صورت جداگانه در بخش‌های مربوط به خودشان اعمال می‌شوند.ساختار مستقلدر این ساختار، تیم هک رشد مستقل از محصول است. یعنی تیم رشد وظیفه خودش را انجام می‌دهد و گزارش را به مدیر ارشد ارائه می‌کند. در این ساختار استراتژی هک رشد بدون هیچ محدودیتی روی تمام کسب‌وکار اعمال می‌شود و تیم هک‌رشد با پیداکردن فرصت‌های مختلف و استراتژیک، سعی می‌کند به تیم محصول نیز کمک کند و در خدمت تولید محصول باکیفیت باشد (اما همیشه یک قدم جلوتر از تیم تولید محصول حرکت می‌کند!).طرح ایده‌های جدید و ترک عادت‌های خشک سازمانیپس از اینکه به فرآیند هک رشد آگاهی پیدا کردید، قطعاً با مقاومت‌هایی در اجرای این فرآیند مواجه می‌شوید که لازم است عادت‌های خشک سازمانی را با مدیران ارشد تغییر دهید و به یک شرکت منعطف تبدیل شوید و باید بدانید که برای این کار نیاز به زمان زیادی دارید:تعیین کنید که آیا محصول ضروری است؟ویژگی مشترک تمام استارتاپ‌های موفق این است که صرف‌نظر از مدل کسب‌وکارشان، محصولی را تولید می‌کنند که جزو نیازهای ضروری مشتری است. به همین دلیل یکی از قدم‌های اولیه تیم هک رشد این است که تحقیق کنند “آیا محصول موردنظرشان جزو نیازهای مشتری است یا خیر؟” زیرا شرط اول برای به‌دست‌آوردن رشد پایدار این است که محصول، موردنیاز کاربر باشد. باید توجه داشت که با روش‌های بازاریابی می‌توان یک رشد نسبی ایجاد کرد، اما رشد پایدار نه! به همین دلیل رشد موقتی است و به احتمال زیاد، در آینده نزولی خواهدشد.در ادامه نیز باید علت موردنیاز بودن و جامعه مخاطب محصول را نیز مورد بررسی قرار دهند. به بیان ساده‌تر تیم هک رشد باید ارزش محصول را پیدا کند و دقیق مشخص کند که مخاطب آن چه کسانی هستند؟ شاید تیم هک رشد در این بین متوجه شود که مسیر را اشتباه رفته یا محصولی که ساخته‌شده‌‌است، آن چیزی که باید باشد نیست. پس باید لحظه آها (Aha) را پیدا کنید!لحظه آها Aha را پیدا کنید!!!لحظه‌ آها(AHA) لحظه‌ای‌است که ارزش محصول برای کاربران آن روشن می‌شود و آن‌ها متوجه می‌شوند که چقدر این محصول ضروری است؟در آها (AHA) مشخص می‌شود که چرا کاربران به این محصول نیاز دارند و چه سودی از آن می‌برند؟برای مثال:شرکت یلپ (Yelp) یک پلتفرم بازرگانی است که فروشگاه‌های مختلف محصولات خود را در آن عرضه می‌کنند، این شرکت جز نمونه‌های موردی است که لحظه آها را کشف و تقویت می‌کند. در نتیجه کاربران با درک این لحظه، ارزش و ضرورت محصول را متوجه می‌شوند. به این صورت که، بعد از چند وقت یلپ متوجه شد که کاربران از فضای کامنت‌ها برای نوشتن نقدهای تخصصی و یا بررسی‌های مختلف استفاده‌می‌کنند؛ چیزی شبیه کامنت‌های وبسایت دیجیکالا که امروزه برای هر خریدی یک نوع اعتبارسنجی است.یلپ این پتانسیل را کشف و برای تقویت این فضای گفت و شنود و تعامل بیشتر، نیروهای مختلفی را برای پاسخ‌دادن به نظرات کاربران اختصاص داد تا این تعامل را به مرکز نقد و نظر درمورد فروشگاه‌ها تبدیل کند. کشف این پتانسیل همان کشف “لحظه آها” است!!!پس از کشف این لحظه، این شرکت نسبت به رقیب‌هایش رشد بیشتری پیدا کرد و در ادامه با ایجاد یک سری شرکت‌های جدید و اختصاص وب‌سایت‌های بیشتر، کاربرها را ترغیب‌کرد تا نظرهای بیشتری در وب‌سایت بگذارند و به‌مرور، یلپ یک رشد انفجاری پیداکند. اطلاعات قابل‌اعتماد ازسوی مردم علاوه‌بر برطرف‌کردن مشکلات موجود، اعتماد کاربرها را نیز به محصول موردنظر بیشتر کرد و محصول به‌صورت فرد به فرد نیز مورد تبلیغ قرار گرفت.استارتاپ‌ها و کسب‌وکارهای دیگری نیز با رسیدن به لحظه آها یعنی همان پیداکردن ارزش محصول خود، رشد چشم‌گیری پیدا کردند به مثال‌های زیر توجه کنید:فیس‌بوک: اشتراک هر چیزی که مربوط به خودت می‌شهاوبر: با یک کلیک ماشین میاد دنبالتدراپ‌باکس: بارگذاری راحت فایل و دسترسی راحت به اونچگونه کاربرها به “لحظه آها” می‌رسند؟لحظه آها، یا از همان ابتدای کار برای کاربر مشخص است؛ مانند دراپ‌باکس برای بارگذاری محتوایا کاربر باید مدتی از محصول استفاده کند و بعد از آمیخته‌شدن کاربر با محصول، به لحظه آها برسد.برای مثال:در توییتر، کاربر بعد از اینکه 30 نفر را دنبال کند، به “لحظه آها” می‌رسد. عدد 30 از تحلیل داده‌ها به‌دست می‌آید، یعنی پس از اینکه کاربر به این عدد برسد، کاربرد توییتر را به صورت کامل درک می‌کند و ارزش و ضرورت محصول را کامل متوجه می‌شود و در مثالی دیگر در اسلک (Slack) نیز لحظه آها زمانی است که کاربر بیشتر از 2000 پیام رد و بدل کند.یک کسب‌و کار چطور لحظه آها خود را کشف و تقویت کند؟یکی از کارهای سختی که باید انجام دهید پیداکردن لحظه آها، از اطلاعات موجود است. حتی ممکن است اطلاعات موجود در پایگاه‌های داده برای پیدا کردن ارزش محصول و نیاز کاربر، به ما کمکی نکند! پس می‌توان به سراغ یک بخش مهم دیگر رفت که معمولاً ما را خیلی راحت به اطلاعات مدنظرمان می‌رساند؛ نظرسنجی از کاربرها.با یک نظرسنجی از کاربرهای وفادار و فعال می‌توان متوجه‌شد که “آیا مسیر را درست آمده‌ایم یا خیر؟”اگر جواب خیر باشد، می‌توان از همین نقطه به توسعه و تغییر محصول پرداخت و نیاز اصلی کاربر را برطرف کرد تا رشد زیاد به‌دست‌آید. و اگر جواب بله باشد که متوجه می‌شویم مسیر را درست آمده‌ایم و می‌توانیم به لحظه آها برسیم.نظر سنجی برای یافتن میزان محبوبیتیکی از روش‌هایی که می‌توان از آن برای سنجش میزان محبوبیت محصول بین کاربران استفاده کرد، نظرسنجی است. نظرسنجی باید از هر کاربر فعالی که از محصول شما استفاده می‌کند انجام شود تا جواب‌های دقیق‌تری به‌دست‌آید. به‌صورت کلی برای هر محصولی می‌توان نظرسنجی مشابه زیر ایجاد کرد:اگر این محصول دیگر ارائه نشود، چقدر ناامید می‌شوید؟بسیار زیادتاحدودیاصلا (چندان مفید نیست)هیچ‌کدام (دیگر از آن استفاده نمی‌کنم)تحلیل نتایج سوال بالا می‌تواند به این صورت باشد:اگر بیش از 40 درصد از کاربران، گزینه “بسیار زیاد” را انتخاب کنند، یعنی محصول برای آن‌ها ضروری است.اگر بین 25 تا 40 درصد از کاربران، گزینه “بسیار زیاد” را انتخاب کنند، یعنی باید روی افزایش کارایی محصول کار کرد.اگر کمتر از 25 درصد از کاربران، گزینه “بسیار زیاد” را انتخاب کنند، یعنی محصول با نیاز کاربرها تناسبی ندارد.اما چه سوال‌های دیگری می‌توان در این نوع نظرسنجی مطرح کرد؟1- اگر این محصول وجود نداشت، از چه جایگزینی استفاده می‌کردید؟2- مزیت اصلی این محصول از دیدگاه شما چیست؟3- آیا استفاده از این محصول را به افراد دیگر توصیه می‌کنید؟4- به نظر شما چه نوع افراد دیگری از این محصول استفاده می‌کنند؟5- به نظر شما چه ویژگی‌های دیگری می‌تواند این محصول را بهتر کرده و نیازهای شما را برطرف کند؟نرخ حفظ مشتریان“نرخ حفظ مشتریان” معیار دیگری است که می‌توان با به‌دست‌آوردن آن، میزان ضروری بودن محصول برای کاربر را مشخص کرد. پایداربودن این نرخ، باعث رشد مداوم محصول می‌شود؛ یعنی درصورتی که علاوه‌بر حفظ کاربرهای قدیمی، کاربرهای جدید نیز اضافه شوند، نرخ حفظ مشتری پایدار است و محصول شما ارزشمند به حساب می‌آید. و درصورتی که کاربرهای قدیمی ریزش پیدا کنند یا کاربرهای جدید اضافه نشوند، این نرخ نزولی است و باید با استفاده از نظرخواهی از کاربرها، به این سوال پی‌برد که “چرا دیگر از محصول موردنظر استفاده نمی‌کنند؟”. با استفاده‌از نظرهای به‌دست‌آمده، می‌توانیم محصول را توسعه دهیم تا نرخ حفظ مشتریان دوباره رشد پیدا کند. تثبیت این نرخ نشان می‌دهد که کاربرها محصول موردنظر را ارزشمند می‌دانند.نسبت به نوع فعالیت کسب‌وکار و ماهیت محصول، نرخ حفظ مشتریان نیز متفاوت اندازه‌گیری می‌شود. مثلاً برای کسب‌وکارهایی که فروش کالا دارند، می‌توان مشتریانی که خرید کرده‌اند را رصد کرد و پس از 30 روز مقایسه کرد که چه تعداد از مشتریانی که قبلا خرید کرده‌اند، هنوز به کسب‌وکار شما وفادار هستند و چه تعداد از آن‌ها ریزش کرده. اساس کار این نرخ نیز در مقایسه با رقیب‌ها انجام می‌شود (مثلاً فیلیمو با بسترهای vod دیگر یا اسنپ با بستر مشابهی مثل تپسی).فرآیند رسیدن به محصول ضروریتمام روش‌ها و آزمایش‌های بالا، برای این طراحی شده‌ که شما متوجه شوید “آیا کاربر به لحظه آها رسیده یا خیر؟”. پس اگر با این روش‌ها نتوانستید به پاسخ این سوال برسید (یعنی کاربر شما متوجه لحظه آها نشده)، پس باید به پیداکردن پاسخ این سوال بپردازید که “چرا کاربر متوجه لحظه آها نشد؟”. پیداکردن جواب این سوال نیازمند جست‌وجوی عمیق‌تری است و شاید مجبور به مصاحبه رو در رو با کاربر باشید. بهتر است در این مواقع از توسعه بی‌نتیجه دست بردارید چون باعث پیچیدگی و سردرگمی بیشتر محصول می‌شود.برای پاسخ به سوال “چرا کاربر متوجه لحظه آها نشد؟” سه راه پیشنهاد می‌شود:نظرسنجی بیشتر و عمیق‌ترآزمایش قابلیت‌های جدید و ارسال پیام به کاربرتجزیه و تحلیل عمیق اطلاعات کاربراننکته: هنگام مصاحبه با کاربر (چه مصاحبه رو در رو، چه ازطریق فرم‌های ارتباطی) تعصب را کنار بگذارید تا نتایج واقعی به دست آورید.یک مثال از دنیای واقعیمدیرعامل تیندر هنگامی که در محیط دانشگاه قدم می‌زد، با دیدن دانشجوها به این نتیجه می‌رسد که محصول‌اش برای این مکان و این افراد بسیار مناسب است. درواقع “اولین مشتریان” (early adaptor) خودش را پیدا می‌کند و محصول را روی آن‌ها تست می‌کند. پس پیداکردن مشتریان واقعی و تحقیق از آن‌ها می‌تواند کمک بسیار بزرگی به پیداکردن جواب سوال بالا کند.بهترین روش برای آزمایش چیست؟توجه داشته باشید که آزمایش‌ها باید در ابتدا با کم‌ترین هزینه و به آسان‌ترین شکل انجام شوند و اگر نتیجه مثبتی داشت، می‌توان به آزمایش‌های پیچیده‌تر نیز پرداخت. یک نکته مهم دیگر اینکه اگر کاربران متوجه ارزش محصول نشدند، دلیل‌بر این نیست که محصول ارزشی ندارد! شاید فرآیند انتقال این ارزش به کاربر دچار مشکل است. برای آزمایش این امر، یکی از ابزارهای کاربردی، یعنی A/B تست را معرفی می‌کنیم. نکته مهم در استفاده از A/Bتست، بررسی و پیگیری رفتار کاربر تا انتهای مسیر است.نکته برای استفاده از این آزمایش: زمانی که می‌خواهیم آزمایش‌های پیچیده انجام دهیم، باید از نتایج تحلیل رفتار کاربر، چندین دلیل را آماده کنیم و ریسک موجود را بررسی کرده و سپس آزمایش را انجام دهیم.کاوش اطلاعاتمهم نیست که چه مقدار اطلاعات از کاربر و رفتارهای او جمع‌آوری می‌کنید! مهم این است که بتوانید این اطلاعات را تجزیه و تحلیل کرده و از درون آن، یک برنامه اجرایی (action plan) استخراج کنید. به همین دلیل بهتر است یک تحلیل‌گر داده داشته باشید که بتواند با تحلیل‌کردن اطلاعات، منابع ارزشمندی برای آزمایش شما پیدا کند. لازم است علاوه‌بر اطلاعات سطحی که ابزارها برای ما فراهم می‌کنند، داده‌های مشتریان را نیز دراختیار داشته باشیم؛ داده‌هایی فراتر از retention (ریتنشن) یا page view (میزان بازدید صفحه). بهترین مدلی که می‌توان از اطلاعات موجود استفاده کرد این است که داده‌های مربوط به مشتریان را با داده‌های سطحی آن‌ها مرتبط کرد تا بتوان از روش RFM استفاده کرد. با اطلاعات موجود در RFM می‌توان ازطریق همکاری با تیم مارکتینگ، کارهای بزرگی انجام داد.کاربران کلیدی چه کاری انجام می‌دهند؟برای اینکه متوجه شوید کاربرها چه فعالیتی در محصول شما انجام می‌دهند، باید ایونت‌هایی (event) را تنظیم کنید. ازطریق ایونت می‌توان متوجه شد که چه کسانی، چه کارهایی انجام می‌دهند و ازکدام نقاط محصول، ریزش کاربر داریم؟ آیا می‌توان کار ارزش‌مندی در آن نقطه انجام داد یا نه؟یک مثال برای روشن شدن این موضوع:نتفیلیکس با استفاده از داده‌های به‌دست‌آمده از ایونت‌های تنظیم‌شده، متوجه شد که کوین اسپیسی (بازیگر مشهور) بسیار موردتوجه کاربرها است. به همین دلیل روی سریال خانه پوشالی سرمایه‌گذاری کرد و با پخش این سریال، رشد خوبی پیدا کرد.چرا باید ایونت برگزار کنیم؟حقیقت این است که با برگزار کردن ایونت‌ها، همان ابتدای کار نمی‌دانیم که به دنبال چه چیزی هستیم! تا اینکه داده‌های غیرمنتظره و عجیب ازسوی کاربر دریافت می‌شوند و آنجا نقطه‌ای است که باید برنامه‌ریزی کنیم. در این مسیر، هرچه بیشتر اطلاعات جمع‌آوری کنیم و آن‌ها را مورد آزمایش قرار دهیم، نکته‌های غیرمنتظره بیشتری پیدا می‌کنیم.برای مثال: بربرن (Burbn) یا همان اینستاگرام فعلی متوجه شد که کاربرها در اوایل کار این محصول از اشتراک‌گذاری تصاویر، بسیار زیاد استفاده می‌کنند. پس قسمت “اشتراک‌گذاری تصاویر” را مورد بازطراحی قرار دادند و پس از آزمایش‌های مختلف، توانستند به نسخه امروزی اینستاگرام برسند.کلام آخر!!!تا اینجا یاد گرفتیم که هک رشد چیست و چه کاربردی دارد. همچنین یادگرفتیم که باید در مرحله اول، کسب‌وکار و مشتری‌های خود را بشناسیم تا بتوانیم به درستی لحظه آها را ایجاد کرده و آن‌ها را راهنمایی کنیم تا به این لحظه برسند.در قسمت‌های آینده وارد قسمت‌های بعدی هک رشد که اقدامات عملی است می‌شویم و راهکارهایی ارائه می‌دهیم تا بتوان به‌صورت دقیق‌تر با مفهوم هک رشد آشنا شد.

تست NPS چیست و چطور آن را اندازه‌گیری کنیم؟

شهاب صفاری — Wed, 17 Nov 2021 16:03:57 +0330

تست NPS یا همان Net Promoter Score، روشی برای اندازه‌گیری میزان وفاداری کاربرها به محصول موردنظر ما است (این محصول می‌تواند یک وب‌سایت مجازی یا یک محصول فیزیکی باشد). درحقیقت تست NPS مجموعه سوالاتی است که معمولاً در صفحه‌ای از وب‌سایت قرارداده می‌شود تا کاربران با مراجعه به آن صفحه، با فرم نظرسنجی مربوط به این تست روبه‌رو شده و در این نظرسنجی شرکت کنند. در تست NPS دو سوال پرسیده می‌شود که سوال اول مهم‌ترین سوال، و سوال دوم به نسبت پاسخی که کاربران به سوال اول می‌دهند، متفاوت است. در ادامه درمورد این سوال‌ها توضیحات کاملی می‌دهم. اولین و اصلی‌ترین سوالی که از کاربران پرسیده می‌شود:نمونه یک فرم تست NPSبعد از پاسخ کاربران به این سوال، باتوجه به امتیازدهی کاربر یک سوال متفاوت نیز از او پرسیده می‌شود که کاربر می‌تواند نظر خود را به صورت متن بنویسد. اما کمی درمورد چیستی تست NPS و کاربرد آن در تحقیق و توسعه محصول بدانیم.چرا باید NPS را محاسبه کنیم؟به‌دست‌آوردن عدد نهایی NPS در زمان‌های مختلف و مقایسه آن‌ها، می‌تواند میزان افزایش یا کاهش رضایت کاربرها از محصول شما را مشخص کند؛ رضایت از خدمات، پشتیبانی مشتری، ارسال و.... . از NPS می‌توان برای پیش‌بینی رشد کسب‌وکار نیز استفاده کرد. یعنی وقتی عدد نهایی NPS شرکت/محصول شما بالا است (یا حداقل از میانگین کسب‌وکارهای مشابه بیشتر است)، می‌توان فهمید که ارتباط خوبی بین مشتری و شما شکل گرفته؛ مشتری‌هایی که علاقمند به تبلیغ‌کردن برند شما هستند، برای شما تبلیغات شفاهی می‌کنند و رشد مثبتی را برای محصول شما رقم می‌زنند. همین حالا باید گفت که هدف از انجام تست NPS پیداکردن ارزش‌های یک محصول است، نه پیداکردن باگ‌ها و مشکلات محصول! چون این تست میزان وفاداری کاربران را محاسبه کرده و پتانسیل‌های پیشرفت محصول را برای ما مشخص می‌کند.درنظر داشته باشید که تست NPS برای بلندمدت است؛ یعنی حتماً باید در فواصل طولانی (مثلاً چندماه یک‌بار) این تست از کاربران گرفته شود تا میزان وفاداری را بسنجیم. پیشنهاد محققین تجربه کاربری این است که هر 3 تا 6 ماه، یک تست NPS از محصول‌هایی با مخاطبین زیاد گرفته شود. ازطرفی طبق آمارهای موجود، میزان پاسخ‌دهی کاربران به نظرسنجی شما عددی حدود 10 تا 15 درصد است؛ یعنی اگر این تست را به 1700 کاربر نمایش دهید، حدوداً 170-250 پاسخ دریافت می‌کنید.تقسیم‌بندی نتایج NPS: دفع‌کننده‌ها، منفعل‌ها، ترویج‌کننده‌هاکاربرها در پاسخ به میزان وفاداری خود به محصول، به سه دسته بالا تقسیم می‌شوند. این دسته‌بندی براساس امتیازی است که کاربر در پاسخ به سوال شما اعلام می‌کند (از 1 تا 10......).ترویج‌کننده‌ها (Promoters) امتیاز 9 و 10: این مشتری‌ها مشتاق‌ترین و وفادارترین افراد برای تبلیغ محصول شما هستند.منفعل‌ها (Passives) امتیاز 7 و 8: این مشتری‌ها شاید به تبلیغ محصول شما علاقمند نباشند، اما نسبت به آن بدبین نیستند و تبلیغات منفی نیز نمی‌کنند. به همین دلیل، این افراد در محاسبه معیار نهایی NPS دخیل نیستند و فقط برای تقسیم‌بندی افراد جداسازی می‌شوند.دفع‌کننده‌ها (Detractors) امتیازهای 6 تا 0: این مشتری‌ها نه‌تنها علاقمند به تبلیغ محصول شما نیستند، بلکه احتمالاً دیگر تمایلی به استفاده از محصول شما ندارند. این افراد نقدهای مختلفی نسبت به نقاط مختلف محصول دارند که می‌تواند در بازطراحی محصول شما بسیار موثر باشد.فرمول محاسبه عدد نهایی NPSدرصد دفع‌کننده‌ها - درصد ترویج کننده‌ها = نمره NPSمثال: درصد ترویج‌کننده برابر با 50 و درصد دفع‌کننده برابر با 35 است. درنتیجه عدد نهایی NPS برابر 15 به‌دست می‌آید.طراحی سوال برای تست NPSبا گرفتن تست NPS از کاربران و رسیدن به یک امتیاز نهایی، شما پاسخ یک سوال مهم را دریافت می‌کنید: کاربران چقدر به محصول شما وفادار هستند و چقدر از آن رضایت دارند؟اما نکته این است که شما می‌توانید درطول این تست، ازطریق یک فرم کوتاه و با جمع‌آوری نظرات کاربران، اطلاعات بسیار زیادی از نقاط ضعف و قوت محصول خود نیز به‌دست‌آورید. یعنی سوال اول شما باید اصلی‌ترین سوال درمورد میزان وفاداری کاربر و میزان تبلیغ محصول شما توسط کاربر باشد (تا چه اندازه تمایل به معرفی محصول ما به دیگران را دارید؟). سپس یکی از سه سوال زیر را از او بپرسید:اگر کاربر امتیاز 9 و 10 داد: مهم‌ترین دلیل انتخاب شما برای معرفی این محصول به دیگران چیست؟اگر کاربر امتیاز 7 و 8 داد: چه تغییرات و امکاناتی را به ما پیشنهاد می‌کنید تا در این محصول اعمال کنیم؟اگر کاربر امتیاز 0 تا 6 داد: در هنگام استفاده از این محصول با چه مشکلاتی روبرو شدید؟نکته: این سوال‌ها به صورت کلی و برای تمامی محصولات موجود در جهان ایجاد شده و شما می‌توانید نسبت به نوع محصول/کسب‌وکار خود، سوال‌هایی مشابه سوال‌های بالا طراحی کنید. برای پاسخ به این سوال‌ها، اجازه دهید کاربران نظرات خود را به صورت متن بنویسند.مزیت ایجاد سوال در تست NPS چیست؟شما با دریافت پاسخ‌های کاربران می‌توانید آن‌ها را جداسازی و تگ‌گذاری کنید و درنهایت با یک آمار کلی، از نقاط ضعف/قوت و تعداد نظرات مربوط به آن‌ها، بازطراحی خوبی در محصول خود داشته باشید.راهنمای محاسبه معیار NPSدر این راهنما به صورت گام به گام توضیح داده شده که از مرحله اول یعنی استخراج سوالات مربوط به تست، تا مرحله آخر یعنی مقایسه گزارش موجود با گزارش‌های قبلی مربوط به همان محصول و بررسی روند رشد یا کاهش معیار NPS، باید چه فعالیت‌هایی انجام شود و چه متریک‌هایی محاسبه شوند. فرم مربوط به معیار NPS ازطریق هاتجر ایجاد شده و روی سایت اعمال می‌شود تا از کاربران آنلاین درخواست کنیم که آن را کامل کنند. پس از اتمام زمان تست، نتایج به صورت یک فایل اکسل از هاتجر گرفته می‌شود و دسته‌بندی و جداسازی نظرات روی آن انجام می‌شود.مراحل به‌دست‌آوردن نتیجه کلی تست NPSمرحله اول و دوم: تدوین سوالات مربوط به تست NPS و گرفتن تست از کاربرهامرحله سوم: استخراج نتایج تست و مرتب‌سازی آن‌هامرحله چهارم: تگ‌گذاری نظرات کاربرهامرحله پنجم: محاسبه درصد شرکت‌کنندگان و پاسخ آن‌ها، تعداد و درصد تگ‌های مختلف، استخراج نظرات مفید کاربرها، تستیمونیال‌ها و جداسازی مشکلات موجودمرحله ششم: مقایسه آمار فعلی با آمار تست NPS قبلی (مربوط به همین محصول)مرحله اول و دوم:همان‌طور که گفتیم، سوالات مربوط به تست NPS را می‌توانید از روش ارائه‌شده، مخصوص محصول خود تدوین کنید و فرم را ازطریق هاتجر، ایجاد کنید. پس از شروع گرفتن نظرات کاربرها از این طریق، نتایج شما آماده تحلیل و بررسی است.مرحله سوم:خروجی اطلاعات تست NPS که از هاتجر گرفته می‌شود، یک فایل اکسل است که ممکن است حروف فارسی در آن به هم ریخته باشد. از روشی که در این لینک آمده استفاده می‌کنیم تا به‌طور کامل اطلاعات را به زبان فارسی برگردانیم و موارد اضافی (مثل آیدی کاربر و…) که در استخراج نتایج به‌کارنمی‌آیند را حذف می‌کنیم.سپس در ستون امتیازها یک sort انجام می‌دهیم و طبق معیار NPS، امتیازهای 9 و 10 را جداکرده و در یک شیت دیگر قرار می‌دهیم.به همین ترتیب امتیازهای 7 و 8 را نیز جدا می‌کنیم و درنهایت امتیازهای 0 تا 6 را نیز در یک شیت جداگانه قرار می‌دهیم. خروجی نهایی یک فایل اکسل شبیه زیر است:نمونه قالب آما‌ده‌شده برای تست NPS آپاراتمرحله چهارم:حال که اطلاعات در قالب ترویج‌کننده، منفعل و دفع‌کننده دسته‌بندی شدند، باید هر نظری که کاربر در پاسخ به سوال مربوط به خودش داده، تگ‌گذاری شود؛ مثلا اگر کاربر درمورد کیفیت پایین محصول شما شکایت داشت، یک تگ #کیفیت_ضعیف به آن کاربر اختصاص می‌دهیم تا درنهایت بتوانیم با محاسبه تگ‌ها، تعداد کاربران ناراضی از سیستم را مشخص کنیم.نکته: ممکن است یک کاربر درمورد بخش‌های مختلفی از محصول رضایت/نارضایتی داشته باشد. پس تگ‌های مختلفی نیز به او اختصاص داده می‌شود.نکته: اگر برای بار اول روی یک محصول تست NPS گرفته می‌شود، تگ‌ها نیز باید با توجه به پاسخ کاربرها برای اولین بار استخراج و نهایی شود. در تست‌های بعدی به همان بانک تگ قبلی رجوع می‌کنیم (مگر اینکه به بخش جدید یا نظر جدیدی درمورد محصول برخورد کنیم).مرحله پنجم:حال که دسته‌بندی و تگ‌گذاری نظرات کاربرها انجام شد، باید تعداد امتیازدهندگان در هر دسته، تعداد کسانی که امتیازدهی کردند اما به سوال پاسخ ندادند، درصد هر دسته نسبت به کل آمار، و درصد پاسخ‌دهندگان به سوال (نسبت به تعداد کل همان دسته) مشخص شود.بعد از این کار باید تگ‌های موجود را شمارش کنیم. ممکن است تگ‌ها به صورت رقابتی باشند؛ مثلا ترویج‌کننده‌هایی وجود داشته باشند که از سیستم سانسور موجود در محصول شما کاملا راضی‌اند و در مقابل آن‌ها، منفعل‌ها یا دفع‌کننده‌هایی باشند که از سیستم سانسور کاملاً ناراضی‌اند. پس باید در شمارش این تگ‌ها دقت شود و تعداد آن‌ها در مستند (Document) اطلاعات یک‌جا آورده شود تا مقایسه بهتری داشته باشیم.نکته: در شمارش هر تگ، تعدادی از نظرات مفید کاربرها را هایلایت می‌کنیم تا دقیقا خود نظر را در مستند بیاوریم (برای درک بهتر بقیه افرادی که مستند را مطالعه می‌کنند).نکته: تستیمونیال‌ها نیز که نظرات مثبت و کاربردی مربوط به محصول هستند، از قسمت ترویج‌کنندگان استخراج می‌شوند و عیناً در مستند آورده می‌شوند.مرحله ششم:پس از اینکه روی یک محصول مشخص، چندبار تست NPS گرفتیم (که باید طبق فواصل زمانی مشخص و بعد از بازطراحی نکات گزارش NPS قبلی، تست جدید گرفته شود)، می‌توانیم نموداری از تغییر NPS تهیه کنیم که نشان‌دهنده افزایش یا کاهش وفاداری کاربران به محصول است.نتیجه‌گیریدر آخر اینکه هیچ محصولی در دنیا، بدون نکات منفی و نارضایتی کاربران نیست. جالب است بدانید در آخرین تست NPS گوگل، عدد نهایی برابر 11 است! پس انتظار خودتان را از محصولتان پایین بیاورید و هدفتان از انجام تست NPS، پیداکردن نقاط قوت و ارزش‌های محصولتان باشد. این نقاط قوت، پتانسیل تبلیغاتی زیادی در اختیار شما قرار می‌دهند و علاوه‌بر جذب کاربران جدید، ممکن است باعث عوض‌شدن نظر کاربران ناراضی قدیمی نیز شود.

الگوهای معماری میکروسرویس بخش دوم : الگوهای جداسازی

علی کاویانی — Sat, 14 Aug 2021 18:09:04 +0430

از بخش اول الگوهای معماری میکروسرویس خیلی وقت گذشته و الوعده وفا! در پست قبلی در مورد کلیات الگوهای معماری میکروسرویس صحبت کردیم و به تفصیل به الگوهای بانک‌های اطلاعاتی پرداختیم، در بخش دوم این سری از مقالات به سراغ الگوهای جداسازی می‌رویم: https://aparat.design/microservice-patterns-part-1-xfktsz2zal3q الگوهای جداسازی الگوهای مورد استفاده برای جداسازی میکروسرویس‌ها یا به زبان دیگر، شکستن یک مونولیت به چندین میکروسرویس، عموماً براساس نوع تصمیم‌گیری دسته‌بندی می‌شوند. الگوهای زیر جزو موارد پرکاربرد در این زمینه هستند:جداسازی بر اساس قابلیت های کسب و کاریجداسازی بر اساس زیر دامنهجداسازی بر اساس تراکنشجداسازی به روش Stranglerهمان‌طور که در مقاله قبل دیدیم در معماری میکروسرویس تمام تلاش ما به استفاده از اصل مسئولیت‌پذیری یکتا برای طراحی میکروسرویس‌هایی است که تا جای ممکن به یک‌دیگر وابستگی نداشته‌باشند و ما را به هدف نهایی که افزایش سرعت توسعه و Delivery محصول است نزدیک کنند.مثلث موفقیتمعماری میکروسرویس این کار را به دو روش انجام می‌دهد:تست‌کردن بخش‌های مختلف، کد را ساده و در نتیجه امکان توسعه اجزای مختلف را به‌صورت مستقل فراهم می‌کند.تیم‌های مهندسی را ساختاربندی می‌کند یعنی تیم به صورت مجموعه‌ای از تیم‌های کوچک ۶ تا ۱۰ نفره‌ی مستقل، که هر کدام مسئولیت توسعه و نگهداری یکی از سرویس‌ها هستند، تقسیم می‌شوند.توجه: این مزایا به صرف تصمیم‌گیری برای استفاده از میکروسرویس به وجود نمی‌آیند و این امر نیازمند جداسازی نرم‌افزار به سرویس‌های کوچک‌تر وظیفه‌محور است، یک سرویس، باید آن‌قدر کوچک باشد که یک تیم کوچک برای توسعه و تست آن کفایت کند.یک راهبرد مفید در این زمینه استفاده از اصل مسئولیت واحد(Single Responsibility) از موضوع کلی‌تر Object Oriented Design است، در این اصل، گفته می‌شود: رای رسیدن به یک طراحی خوب، نیاز داریم که هر کلاس تنها و تنها یک هدف و وظیفه را در برنامه ایفا کند. کار تمام روش‌های(Methods) کلاس باید در راستای رسیدن به آن هدف باشد و استفاده از هر روشی با وظایف منحرف از هدف اصلی اشتباه است؛ این امر باعث درهم‌تنیدگی وظایف در برنامه و بنابراین پیچیدگی کد و در نتیجه کم‌کردن Reusability یا قابلیت استفاده مجدد از کدها می‌شود، همچنین هر روش کلاس باید تنها و تنها یک وظیفه را ایفا کند.جداسازی سرویس‌ها نیز باید به گونه‌ای باشد که تغییرات مورد نیاز تنها یک سرویس را تحت تاثیر قرار دهد. چون پیاده‌سازی امکاناتی که بتواند چند سرویس را تحت تاثیر قرار دهد، نیازمند هماهنگی بین چند تیم است که باعث کند شدن روال توسعه می‌شود.یکی از دیگر اصول مفید OOD برای جداسازی میکروسرویس ها اصل Common Closure Principle است. این اصل بیان میکند: کلاس‌هایی که به دلایل مشابهی نیاز به تغییر دارند باید در یک پیکچ قرار گیرند.به‌طور مثال فرض کنید دو کلاس بخش‌های متفاوتی از یک قاعده کاری (بیزینسی) را پیاده‌سازی می‌کنند. اگر این قاعده کاری تغییر کند، هدف ما این است که تغییرات مورد نیاز کد در کمترین تعداد پکیج‌ها لازم باشد(‌به‌صورت ایده‌آل تنها یک پکیج).این دیدگاه در زمان طراحی سرویس‌ها خیلی کمک‌کننده است؛ چون به ما کمک می‌کند مطمئن شویم هر تغییری تا جای ممکن فقط یک سرویس را تحت‌تاثیر قرار دهد.صورت مساله؛ چگونه یک نرم‌افزار را به چند سرویس کوچک‌تر تقسیم کنیم؟چگونه یک نرم افزار را به چند سرویس کوچکتر تقسیم کنیم ؟نیازمندی ها :معماری نهایی باید پایدار باشد.سرویس‌ها باید به هم پیوسته باشند. به عبارت دیگر هر سرویس باید مجموعه‌ای از توابع به‌شدت مرتبط باشد.هر سرویس باید از اصل CCP (Common Closure Principle) تبعیت کند، یعنی بخش‌هایی که باید باهم تغییر کنند داخل یک سرویس قرار بگیرند تا در صورت نیاز به تغییر، تنها یک سرویس تحت‌تاثیر قرار گیرد.سرویس‌ها باید کمترین وابستگی را به هم داشته باشند. هر سرویس به عنوان یک API پیاده‌سازی می‌شود و هرگونه تغییر در پیاده‌سازی داخلی نباید سرویس‌گیرندگان را تحت‌تاثیر خود قرار دهد.هر سرویس باید قابل تست باشد.هر سرویس باید به اندازه‌ای کوچک باشد که توسط یک تیم "دو پیتزایی" قابل پیاده‌سازی و نگهداری باشد.هر تیمی که مسئولیت یک یا چند سرویس را برعهده دارد باید خودکفا باشد. تیم باید با کمترین نیاز به هماهنگی با دیگر تیم‌ها، توانایی توسعه و پیاده‌سازی سرویس خود را داشته باشد.راهکار اول : جداسازی بر اساس قابلیت های کسب و کارییکی از پایه‌ای‌ترین راه‌ها برای طراحی سرویس‌ها، تعریف‌کردن آن‌ها براساس قابلیت‌های کسب و کاری سیستم است.تعریف قابلیت‌های کسب‌و‌کاری معمولاً بر پایه یک هدف انجام می‌شود. برای مثال:۱. سیستم مدیریت سفارشات، مسئولیت سفارش‌های کاربران را برعهده دارد.۲. سیستم مدیریت مشتریان، مسئولیت مدیریت کاربران را برعهده دارد.قابلیت‌های کسب و کاری اغلب به صورت وراثتی، چندلایه دسته‌بندی می‌شوند.در مثال یک نرم‌افزار سازمانی enterprise:ممکن است دارای دسته‌بندی‌های بالادستی به شرح زیر باشد:توسعه محصولتحویل محصولخلق نیازیا در مثال فروشگاه آنلاین:بخش‌های کسب و کار یک فروشگاه آنلاین می‌تواند شامل موارد زبر باشد:مدیریت محصولاتمدیریت انبارمدیریت سفارشاتمدیریت تحویل کالاو ...در این نمونه معماری میکروسرویس‌ها نیز می‌تواند معادل هر یک از این قابلیت‌ها باشد.جداسازی سرویس ها بر اساس قابلیت های کسب و کارمزایای این الگو :معماری سرویس‌ها پایدار است، زیرا قابلیت‌های کسب و کار معمولا این‌گونه هستند.تیم‌های پیاده‌سازی علاوه‌بر اینکه خودکار و مستقل هستند، براساس ارزش‌های کسب و کار و نه براساس امکانات فنی مورد نیاز، دسته‌بندی می‌شوند.سرویس‌ها چسبندگی لازم را دارند و کمتر به هم وابسته هستند.مشکلات این الگو :طراحی نرم‌افزار کاملاً به مدل کسب و کار وابسته است.این روش نیازمند شناخت عمیق از قابلیت‌های کسب و کار است و انجام این کار، امری مشکل خواهد‌بود.راهکار دوم، الگوی جداسازی براساس زیردامنه‌ها سرویس‌های خود را با استفاده از زیردامنه‌های الگوی Domain-Driven-Design(DDD) جدا کنید. در اینجا DDD به حوزه و دامنه‌ای اصلی و فرعی فعالیت نرم افزار اشاره می‌کند، به‌گونه‌ای که دامنه، متشکل از چندین زیردامنه است و هرکدام از این زیر دامنه‌ها معادل یکی از بخش‌های آن کسب و کار هستند.زیردامنه‌ها می‌توانند به صورت زیر دسته‌بندی شوند:هسته: وجه تمایز کسب و کار، از دیگر کسب و کارها به‌شمار می‌رود که به نوعی با‌ارزش‌ترین بخش آن نرم‌افزار است.پشتیبان‌ها: بخش‌هایی که برای سرویس‌دهی هسته مورد نیاز هستند، اما بخش مختص به کسب و کار شما نیستند (مثلاً بخش Automatioc Marketing)‌. این بخش‌ها می‌توانند به صورت داخلی پیاده‌سازی و یا برون‌سپاری شوند.بخش‌های عمومی: این بخش‌ها مخصوص کسب و کار نیستند و به‌ صورت ایده‌آل توسط نرم‌افزارها یا سرویس‌های آماده پیاده‌سازی می‌شوند، مانند ارسال پیامک.مثالی از یک سرویس ارایه محتوای ویدیويی:برای مثال به صورت خلاصه زیردامنه‌های یک سرویس UGC مبتنی‌بر ویدیو، مانند آپارات را در نظر بگیرید که می‌تواند شامل بخش‌های زیر باشد:زیردامنه کاتالوگ محتوازیردامنه مدیریت محتوا (آپلود، نظارت و انتشار)زیردامنه کاربرانزیردامنه ریکامندیشن (recommendation)زیردامنه جستجوزیردامنه نظرات کاربراننمونه دامنه های یک سرویس ویدیوئی ( ارتباطات واقعی متفاوت از تصویر فوق هستند ) در این مثال زیردامنه مدیریت محتوای ویدیویی بسته به نیاز به دو میکرسرویس کوچک‌تر برای آپلود ویدیو و مدیریت و ممیزی محتوا، تقسیم‌بندی شده است.مزایای این الگو:معماری سرویس‌ها پایدار هست، زیرا زیردامنه‌های نرم‌افزار معمولا این‌گونه هستند.تیم‌های پیاده‌سازی علاوه‌بر اینکه خودکار و مستقل هستند، براساس ارزش‌های کسب و کار و نه براساس امکانات فنی مورد نیاز، دسته‌بندی می‌شوند.سرویس‌ها چسبندگی لازم را دارند و کمتر به هم وابسته هستند.مشکلات این الگو:این الگو اتعداد میکروسرویس‌ها افزایش می‌دهد و در نتیجه عملیات service discovery (کشف خدمات) و پکپارچه‌سازی سیستم مشکل‌تر می‌شود.شناخت زیردامنه‌ها کار مشکلی است زیرا به شناخت عمیقی از کلیت کسب و کار نیاز دارد.راهکار سوم، جداسازی براساس تراکنش‌هادر یک سیستم توزیع‌یافته، نرم‌افزار معمولاً نیاز دارد چندین میکروسرویس را برای انجام یک تراکنش کسب و کاری فراخوانی کند. زمانی که شما سرویس‌ها را براساس تراکنش‌ها جدا می‌کنید، چندین تراکنش در سیستم وجود دارد. یکی از عوامل دخیل در تراکنش‌های توزیع‌شده وجود هماهنگ‌کننده transaction است. در این حالت یک تراکنش توزیع‌شده در دو مرحله انجام می‌شود.فاز آماده‌سازی: طی این مرحله همه شرکت‌کننده‌های تراکنش، آماده انجام تغییرات می‌شوند و به هماهنگ‌کننده اطلاع می‌دهند که آماده تکمیل تراکنش هستند.فاز انجام یا لغو تراکنش: طی این مرحله هماهنگ‌کننده دستور انجام یا لغو تراکنش را برای همه شرکت‌کننده‌های تراکنش ارسال می‌کند.یکی از بزرگ‌ترین مشکلات روال 2PC ، کُندی زیاد آن‌ها در مقایسه با زمان لازم برای انجام همان کار در قالب یک میکروسرویس است. این هماهنگی حتی زمانی که همه سرویس‌ها داخل یک شبکه داخلی باشند می‌تواند باعث کندی بسیار زیاد سیستم شود.برای جلوگیری از تأخیر در پاسخ‌دهی و مشکلات two-phase commit می‌توان سرویس‌ها را براساس تراکنش‌های بین آن‌ها دسته‌بندی کرد. این راهکار زمانی که مدت زمان پاسخ‌دهی برای شما اهمیت دارد و یا ترکیب چند ماژول (سرویس) با هم منجر به ساخت یک مونولیت جدید نمی‌شود، می‌تواند مورد استفاده قرار‌گیرد.مزایای این الگو:کاهش مدت زمان پاسخگویی به کاربرازبین بردن نگرانی بابت ثبات داده‌ها یا Data consistencyافزایش دسترسی‌پذیری نرم‌افزارمشکلات این الگو:چندین ماژول می‌توانند باهم دسته‌بندی شوند که این امر می‌تواند منجر به تولید یک مونولیت کوچک شود.هزینه و پیچیدگی به دلیل پیاده‌سازی چندین قابلیت در یک میکرسرویس به جای جداسازی آن‌ها به چندین میکروسرویس مستقل، افزایش می‌یابد .تعداد میکروسرویس‌های تراکنش‌محور با افزایش مدل‌های کسب و کار و وابستگی آن‌ها به هم افزایش می‌یابد.راهکار چهارم : جداسازی به روش Stranglerسه روشی که در بالا بررسی کردیم، بیشتر زمانی استفاده می‌شوند که شما یک نرم‌افزار Greenfield را از ابتدا می‌نویسید یا بازنویسی می‌کنید https://virgool.io/d/aphyynrugws3 (نرم‌افزار Greenfield به این‌صورت است که از پیش، نیازمند اجرای زیرساخت یا اعمال محدودیت نباشید).باید بگم صرف‌نظر از اینکه واقعاً جداکردن یک پروژه از ابتدا به‌صورت میکروسرویس درست است یا نه؟ در ۸۰ درصد مواقع شما با نرم‌افزارهای BrownField که نرم افزارهای مونولیتیک بزرگ و قدیمی‌اند (Legacy codebase) سر و کار دارید.در این زمان است که روش Strangler به کمک شما می‌آیند. در این روش:دو نرم‌افزار را که به‌صورت همزمان، هر دو روی یک مجموعه آدرس هستند را ایجاد خواهد کرد. یکی کدبیس (Code Base) قدیمی و دیگری پروژه‌ای جدید.با گذشت زمان نرم‌افزارهای (میکروسرویس‌های) جدید به تدریج جایگزین نرم‌افزار قبلی می‌شوند تا زمانی که بتوانید نرم افزار قدیمی را خاموش کنید.مراحل این کار شامل سه مرحله تبدیل، همزمانی و از رده خارج کردن کدبیس قبلی است.مرحله تبدیل: یک مجموعه سرویس جدید با رویه‌های مدرن‌تر ایجاد می‌کنیم.مرحله همزمانی: نرم‌افزار موجود را برای مدتی به حال خود می‌گذاریم و همزمان با تکمیل‌شدن بخش‌های مختلف نرم‌افزار جدید، ترافیک بیشتری را به سرویس‌های جدید منتقل می‌کنیم.مرحله از رده خارج کردن: ویژگی جدیدی که پیاده‌سازی شده را از سرویس قدیمی حذف می‌کنیم.مزایای این الگو:ریسک را در زمان تبدیل پروژه کاهش میدهد.سرویس قدیمی در زمان تبدیل و ریفکتور کردن به سرویس جدید به کار خود ادامه می‌دهد.امکان اضافه کردن امکانات جدید را در زمان تبدیل کد فراهم می سازد.مشکلات این الگو:مدیریت مسیردهی و شبکه در زمان توسعه توجه زیادی را می طلبد.ممکن است در مسیر انتقال سرویس‌ها به پروژه جدید درگیر مشکلات هماهنگ‌سازی سرویس‌ها شوید و مجبور خواهید شد راهکار بازگشت به پروژه قدیمی را برای هر سرویس در نظر بگیرید.به هر حال مشکلات در هر مرحله از کار ممکن است به وجود بیاید و شما باید قادر باشید در صورت نیاز به سرعت و بدون دردسر هر سرویسی را از پروژه قدیمی دریافت کنید.

چرا روش Content Group در آنالاتیکس برای کسب‌وکار ما ضروری است؟

هانیه علایی — Fri, 30 Jul 2021 13:34:17 +0430

یکی از صدها امکاناتی که آنالیتیکس در اختیار ما قرار می‌دهد، روش کانتنت گروپ(Content Group) یا دسته‌بندی محتوا است. این روش به شما اجازه می‌دهد تا گزارش صفحه‌های سایت خود را در پنل آنالیتیکس، در دسته‌بندی‌های مختلف قرار دهید. اما چرا باید از این قابلیت استفاده کنیم؟ جواب روشن است؛ انبوهی از داده‌های غیرمنظم، سر جای خودشان قرار می‌گیرند و می‌توانید کنترل بهتری روی داده‌ها داشته باشید.“دسته‌بندی صفحه‌های وب‌سایتی که هزاران صفحه و محتوای جداگانه دارد کار آسانی نیست!”دسته‌بندی نکردن گزارش‌ها و داده‌ها باعث می‌شود:1- حجم اطلاعات زیاد در پنل آنالاتیکس، ما را گیج کند.2- به هدف مورد نظرمان نرسیم.3- براساس هدفی که داریم، تصمیم درستی نگیریم.یک مثال برای اهمیت کانتنت گروپینینگ:فرض کنید یک وب‌سایت فروشگاهی لباس دارید و دقیقاً نمی‌دانید کدام صفحه از محصول‌ شما، بالاترین بازدید را دارد. ازطرفی ممکن است، ندانید که یکی از صفحه‌های تازه‌ای را که به سایت خود اضافه کردید (مثلاً یک کفش زنانه)، چقدر بازدید دارد؟ با استفاده از کانتنت گروپینگ می‌توانید در مرحله اول، صفحه‌های سایت خود را به دو دسته‌ زنانه و مردانه تقسیم کنید.در مرحله بعد می‌توانید برای این دو دسته‌بندی (زنانه و مردانه)، زیرمجموعه‌هایی تعریف کنید. مثلاً جداسازی دسته‌بندی‌هایی مثل تیشرت، شلوار جین، کفش و….با انجام مراحل بالا، به جای اینکه با حجم زیادی از صفحه‌های به هم‌ریخته (در پنل آنالیتیکس) روبه‌رو شوید، می‌توانید همه صفحه‌ها، اطلاعات و گزارش‌های موجود را در دسته‌بندی مخصوص خودشان ببینید. به تصویر زیر نگاه کنید:استفاده از این قابلیت و جداسازی صفحه‌، چه مزیت‌هایی دارد؟1- به راحتی متوجه می‌شوید که کدام یک از صفحه‌های جدید (محصولات) برای شما سودآور بوده‌اند.2- صفحه‌ای را که فکر می‌کردید می‌تواند برای شما بازدید یا سود مالی داشته باشد، تا چه اندازه شما را به اهداف خود نزدیک کرده‌است؟3-با دسته‌بندی کردن صفحه‌های سایت خود در آنالاتیکس می‌توانید از داده‌های فعلی‌ استفاده درست‌تری کنید و بعد از ارزیابی عملکرد هر بخش، تصمیم‌های مناسب‌تری بگیرید.چطور از قابلیت کانتنت گروپ آنالیتیکس استفاده کنیم؟ابتدا باید دسترسی خود را بررسی کنید شما باید دسترسی بالاتر از بیننده (view) داشته‌باشید، سپس از بخش تنظیمات (Setting) آنالیتیکس، وارد قسمت View شوید و در ادامه بخش Content Group را انتخاب کنید، حال به سه روش می‌توانید کانتنت گروپ را ایجاد کنید:روش اول (Group By Tracking Code)روش دوم (Group Using Extraction)روش سوم (Group Using Rule Definitions) روش اول (Group By Tracking Code):با این روش می‌توانید یک گروه محتوایی از صفحه‌های آنالیتیکس خود ایجاد کنید. اولین گزینه این است که کد رهگیری (Tracking Code) جاوااسکریپت خود را اصلاح کنید، برای انجام این کار، یا باید دانش فنی کافی در زمینه کدنویسی داشته باشید یا از یک برنامه‌نویس کمک بگیرید. حال به تصویر زیر دقت کنید: نکته: هنگام استفاده از این روش در وب سایت خود، برای هر بخش باید به صورت جداگانه تنظیمات مربوط به جداسازی محتواها را انجام دهید. استفاده از این روش یا روش‌های دیگر، بستگی به معماری وب سایت شما دارد. اما گاهی تنها روش برای جداسازی محتواها و دسته‌بندی آن‌ها، همین روش است.روش دوم (Group Using Extraction):ازطریق این روش می‌توانید یک گروه محتوایی براساس ساختار آدرس صفحه‌های (URL) سایت خود، ایجاد کنید. درواقع می‌توانید گروه‌های محتوای خود را براساس صفحه یا عنوان صفحه (وب‌سایت‌ها) یا نام صفحه (برنامه‌ها) تعریف کنید. توصیه می‌کنیم پیش از آن‌که از این روش برای جداسازی صفحه‌های محتوایی خود استفاده کنید، درمورد عبارات منظم (regular expressions) مطالعه کنید.در این روش، وب‌سایت‌هایی که ازلحاظ SEO ساختار مناسبی دارند، جداسازی محتواها و صفحات را برای شما بسیار آسان می‌کنند. چرا که در این حالت، آدرس صفحات با یک ساختار منطقی (logical) نام‌گذاری شده و به شما این امکان را می‌دهد که با مشخص کردن یک دسته از محتواها، تمامی صفحات زیرشاخه آن را در یک گروه دسته‌بندی و جداسازی کنید. برای مثال:/services/google-analytics-audit/services/google-analytics-coaching/services/google-analytics-implementationاین نام‌گذاری، یک نام‌گذاری کاملاً صحیح است و می‌توان با روش Group Using Extractions، دسته‌بندی‌های درستی ایجاد کرد.روش سوم (Group Using Rule Definitions):اگر کاربر حرفه‌ای گوگل آنالیتیکس نیستید، توصیه می‌کنیم از این روش برای جداسازی محتواهای خود استفاده کنید. ازطریق این روش می‌توانید یک گروه محتوایی را با کمک قوانین منطقی ساده ایجاد کنید. در این روش نیز مثل روش دوم، می‌توانید گروه‌بندی محتوا را براساس صفحه یا عنوان صفحه (وب‌سایت‌ها) یا نام صفحه (برنامه‌ها) انجام دهید. علاوه‌بر این می‌توانید از دستورات زیر نیز برای دسته‌بندی محتواهای خود استفاده کنید:محتواهایی که:حاوی x هستند.با x شروع می‌شوند.با x پایان می‌یابند.با x شروع نمی‌شوند.همه محتواها به جز محتواهایی که حاوی x نیستند.و….گاهی اوقات همه صفحه‌های خود را در دسته‌بندی‌های مشخص قرار می‌دهید، اما تعداد کمی از صفحه‌ها باقی می‌مانند. با استفاده از این روش، تنظیمات را طوری انجام دهید (صفحه‌هایی که شامل دسته‌بندی‌های شما نیستند) که صفحه‌های باقی‌مانده مشخص شوند.دسته‌بندی‌های ایجاد‌شده‌ی محتوایی را در کجا ببینیم؟اگر از مسیر زیر وارد شوید:Behavoir → Site Content → All pageمی‌توانید تمامی صفحه‌های سایت خود را مشاهده کنید و اطلاعات این بخش را براساس نرخ بیننده صفحه، نرخ پرش(Bounce rate)، نرخ خروج بالاتر صفحه‌ها و… فیلتر کنید. حال اگر دسته‌بندی صفحه‌ها را از قبل انجام داده‌باشیم، چقدر در تصمیم‌گیری و اجرا می‌توانیم دقیق‌تر و درست‌تر عمل کنیم؟ اگر از پیش، دسته‌بندی محتوایی را ازطریق یکی از سه راه بالا انجام داده باشید، می‌توانید در همین قسمت دسته‌بندی‌های مختلف خود را مشاهده کنید و دقیق‌تر به گزارش‌گیری و انجام عملیات‌های مدنظر خود بپردازید. نتیجه کانتنت گروپینگ را می‌توانید در تصویر زیر مشاهده کنید:کلام آخر:برای مدیریت محتوای وب‌سایت‌هایی که صفحه‌های بسیار زیادی دارند؛ مثل وب‌سایت‌های فروشگاهی یا وبلاگ‌هایی که مقاله‌های روزانه منتشر می‌کنند، حتماً به یک ابزار نیاز داریم. با استفاده از قابلیت دسته‌بندی محتوایی گوگل آنالیتیکس، می‌توانیم تمامی صفحه‌های محصول، مقاله، اخبار و... را در دسته‌بندی‌های مختلف قرار دهیم. یا حتی می‌توانیم محتواهای موجود را براساس نویسنده، نوع محتوا یا ویژگی‌های مختلف دیگر دسته‌بندی کنیم. پس استفاده از این قابلیت، می‌تواند در زمانی که برای پیداکردن یک محتوا در داشبورد گوگل آنالیتیکس صرف می‌کنیم (تا یک عمل خاص را روی آن انجام دهید) صرفه‌جویی بسیار زیادی انجام دهد. حالا می‌توانید به داشبورد گوگل آنالیتیکس مراجعه کنید و با سه روشی که در این مقاله توضیح دادیم، تمام محتواهای خود را در دسته‌بندی‌های جداگانه قرار دهید.

چرا باید آزمایش Usability (کاربردپذیری) را اندازه‌گیری کرد؟

هانیه مجد — Sun, 20 Jun 2021 18:23:45 +0430

قبل از اینکه در رابطه با متریک‌های کاربردپذیری و اهمیت آن‌ها عمیق‌تر بشویم باید بدانیم که اگر می‌خواهید عمر استفاده از یک محصول بالا باشد باید روی سهولت استفاده از آن تا حد زیادی کار کنیم زیرا که کاربران رقبا را به شما ترجیح خواهندداد. به طورکلی سهولت یا قابل استفاده بودن یک محصول به کیفیت تجربه کاربر هنگام تعامل با محصول بر می‌گردد و این کیفیت تجربه خود بر محور سه متریک اثربخشی ، کارایی و رضایت کلی کاربر می‌چرخد.برای اندازه‌گیری متریک‌های کاربردپذیری از کجا شروع کنم؟به طور طبیعی، سوالاتی که به ذهن خطور می‌کنند این است: "کدام متریک را باید استفاده کنم؟ چگونه می‌توان اجزای مورد نیاز برای محاسبه آن را بدست آورد؟ آیا این متریک‌ها به اندازه کافی قابل اعتماد هستند؟ خوب در راستای این سوال‌ها، در این مقاله چند متریک‌ کاربردپذیری را که براساس ISO(سازمان بین المللی استاندارد سازی) به شما معرفی‌ می‌شود:اثربخشی(Effectiveness): اثربخشی این است که آیا کاربران می‌توانند اهداف خود را با درجه بالایی از دقت کامل کند؟کارایی(Efficiency): این متریک نشان می‌دهد که کاربر چقدر سریع می‌تواند به هدف خودش در یک محصول برسد؟رضایت(Satisfaction): این متریک نشان می‌دهد که چقدر کاربر از کار کردن با سیستم مورد نظر ما رضایت دارد؟سهولت یادگیری(Ease of learning):. این متریک نشان می‌ دهد که کاربرانی که برای اولین بار با برنامه کار می‌کنند با چه سرعتی می‌توانند آن را یاد بگیرند.متریک‌های کاربردپذیری برای اثربخشی(Effectiveness):نرخ‌تکمیل(Completion Rate)تعداد خطاها( Number of Errors)نرخ‌تکمیل: اثربخشی را می توان با اندازه گیری نرخ‌تکمیل محاسبه کرد. درصورتی که شرکت‌کننده در آزمون موفق به انجام یک کار شود، میزان تکمیل با اختصاص مقدار باینری "1" محاسبه می شود.و اگر موفق نشود با اختصاص مقدار باینری”0” محاسبه می‌شود. با استفاده از فرمول ساده زیر می‌توان اثربخشی را به صورت درصد نشان داد:Number of tasks completed successfully : تعداد تسک با موفقیت انجام شدهTotal number of tasks undertaken : تعداد کل وظایف انجام شدهنکته: اگرچه همیشه باید درصد تکمیل 100٪ را هدف قرار داد، اما طبق مطالعه‌ای که توسط جف سارو(Jeff Sauro)براساس تجزیه و تحلیل 1100 نمونه تست انجام شده‌است ، میانگین نرخ اتمام یک سناریو و یا تست توسط کاربر تست 78٪ است.مثال:5 کاربر وظیفه‌ای را انجام می‌دهند. در پایان جلسه آزمون‌، 3 کاربر موفق به رسیدن به هدف تسک می‌شوند در حالی که 2 نفر دیگر موفق نمی‌شوند. با استفاده از معادله بالا ، تأثیر کلی کاربر در سیستم به شرح زیر است:تعداد تسک با موفقیت انجام شده = 3تعداد کل وظایف انجام شده = 5درج مقادیر در معادله اثربخشی:مثال گرافیکی: همچنین به راحتی می‌توان “نرخ تکمیل” را به صورت گرافیکی نشان‌داد ، به عنوان مثال؛ می‌توان به صورت نمودار میله‌ای برای چند تسک در یک آزمایش نشان داد.تعداد خطاها: اندازه‌گیری دیگر شامل شمارش تعداد خطاهایی است که شرکت‌کننده هنگام تلاش برای انجام یک کار مرتکب می‌شود. خطاها می‌توانند اقدامات ناخواسته، لغزش‌ها ، اشتباهات یا حذفیاتی باشند که کاربر هنگام انجام یک کار انجام می‌دهد. در حالت ایده‌آل باید یک توصیف کوتاه و یک درجه شدت تعیین کنید و هر خطا را در گروه مربوطه طبقه‌بندی کنید. اگرچه ممکن است زمان‌بر باشد ، اما شمارش تعداد خطاها اطلاعات بسیار خوبی را ارایه می‌دهد.نکته: بر اساس تجزیه و تحلیل 719وظیفه انجام‌شده با استفاده از یک نرم‌افزار،Jeff Sauro(مشاور کاربردپذیری به بیش از 1000 شرکت) نتیجه گرفت که میانگین تعداد خطاها در هر تسک 0.7 است ، از هر 3 کاربر 2 نفر خطا می کنند. فقط 10٪ از وظایف مشاهده شده بدون هیچ گونه خطایی انجام شده‌است، پس نتیجه می‌گیریم که اشتباه در هنگام انجام وظایف برای کاربران کاملاً طبیعی است.متریک‌های کاربردپذیری برای کارایی(Efficiency)کارایی مبتنی بر زمان(Time-Based Efficiency)کارایی نسبی کلی(Overall Relative Efficiency)کارایی بر اساس زمان انجام تسک اندازه‌گیری می‌شود. یعنی چند دقیقه یا چند ثانیه برای انجام یک تسک طول می‌کشد. زمان صرف شده برای انجام یک کار را می‌توان به سادگی با کسر زمان شروع از زمان پایان محاسبه کرد ، همانطور که در معادله زیر نشان داده شده است:زمان کار = زمان پایان - زمان شروعبازده را می توان به یکی از دو روش محاسبه کرد:کارایی مبتنی بر زمانتعریفN : تعداد کل وظایفتعریف R: تعداد کاربرانتعریف nij: وظیفه i توسط کاربر j .اگر کاربر وظیفه را با موفقیت انجام دهد nij = 1 ،در غیر این صورت nij=0 میشود.تعریف tij: زمان صرف شده توسط کاربر j برای انجام وظیفه i . اگروظی با موفقیت انجام نشده باشد،زمان تا لحظه‌‌ای اندازه گیری می شود که کاربر وظیفه را ترک کند.مثال:فرض کنید 4 کاربر وجود دارند که از یک محصول برای انجام همان تسک مثال قبل استفاده می کنند . 3 کاربر موفق به تکمیل آن می شوند - به ترتیب 1 ، 2 و 3 ثانیه طول می کشد. کاربر چهارم 6 ثانیه طول می کشد و موفق به انجام تسک نمی‌شود و انصراف می‌دهد.با توجه به معادله فوق:N = تعداد کل وظایف = 1R = تعداد کاربران = 4کاربر 1: Nij = 1 و Tij = 1کاربر 2: Nij = 1 و Tij = 2کاربر 3: Nij = 1 و Tij = 3کاربر 4: Nij = 0 و Tij = 6کارایی نسبی کلی: راندمان نسبی کلی از نسبت زمان مصرف‌شده توسط کاربرانی که تسک را با موفقیت به اتمام رسانده‌اند نسبت به کل زمان گرفته شده توسط همه کاربران استفاده می کند. بنابراین می توان معادله را به صورت زیر نشان داد:این معادله با جایگذاری اعداد راحت درک می‌شود.مثال:فرض کنید 4 کاربر وجود دارند که از همان محصول برای انجام همان تسک استفاده می کنند (1 کار). 3 کاربر موفق به تکمیل آن می شوند - به ترتیب 1 ، 2 و 3 ثانیه طول می کشد. کاربر چهارم 6 ثانیه طول می کشد و موفق به انجام تسک نمی‌شود و انصراف می‌دهد.با توجه به معادله فوق:N = تعداد کل وظایف = 1R = تعداد کاربران = 4کاربر 1: Nij = 1 و Tij = 1کاربر 2: Nij = 1 و Tij = 2کاربر 3: Nij = 1 و Tij = 3کاربر 4: Nij = 0 و Tij = 6جایگذاری اعداد:معنای فیزیکی کارایی متخصص مبتنی بر زمان بالاترین سرعت ممکن در کار با محصول است.کارایی را می توان از لحاظ گرافیکی به صورت نمودار میله‌ای نشان داد. مثال زیر نتیجه استفاده از معادله کارایی مبتنی بر زمان را برای 11 کاربر برای 5 وظیفه را نشان می‌دهد. از نمودار میله‌ای برای تمایز بین کارایی ثبت شده توسط کاربران برای بار اول در مقایسه با کاربران متخصص برای هر تسک استفاده می‌شود:متریک‌های کاربردپذیری برای رضایت(satisfaction)رضایت کاربر از طریق پرسشنامه اندازه‌گیری می‌شود که می‌تواند بعد از هر کار و یا بعد از جلسه تست کاربردپذیری انجام‌شود.سطح رضایت با چند سوال کوتاه: بعد از اینکه کاربران تست را انجام دادند، صرف نظر از اینکه آیا می‌توانند به هدف خود برسند یا نه؟، بلافاصله باید به آن‌ها یک پرسشنامه داده‌‌شود تا میزان دشواری تسک اندازه‌گیری‌شود.نام محبوب‌ترین پرسشنامه‌ها به شرح زیر است:ASQ: After Scenario Questionnaire (3 questions)NASA-TLX: NASA’s task load index is a measure of mental effort (5 questions)SMEQ: Subjective Mental Effort Questionnaire (1 question)UME: Usability Magnitude Estimation (1 question)SEQ: Single Ease Question (1 question)در واقع از پرسشنامه‌های بالا برای سنجش میزان رضایت کاریر بعد از انجام تست استفاده می‌شود، به عنوان مثال؛ پرسشنامه ASQ شامل سه پرسش زیر است:البته از لیست بالا پرسشنامه SEQ توصیه می‌شود،چون هم کوتاه و هم آسان است:سطح رضایت با پرسشنامه: سطح آزمون با دادن یک پرسشنامه رسمی به هر یک از شرکت‌کنندگان در آزمون در پایان جلسه اندازه‌گیری می‌شود. این به منظور اندازه‌گیری برداشت آن‌ها از سهولت استفاده کلی از سیستم مورد آزمایش است. برای این منظور می‌توان از پرسشنامه‌های زیر استفاده‌کرد :SUS: System Usability Scale (10 questions)SUPR-Q: Standardized User Experience Percentile Rank Questionnaire (13 questions)CSUQ: Computer System Usability Questionnaire (19 questions)QUIS: Questionnaire For User Interaction Satisfaction (24 questions)SUMI: Software Usability Measurement Inventory (50 questions)انتخاب از پرسشنامه‌های بالا بستگی به موارد زیر دارد:بودجه اختصاص یافته برای سنجش رضایت کاربراهمیتی که رضایت ادراک شده کاربر در کل پروژه داردمتریک سهولت یادگیری(Ease of learning):بهترین روش برای سنجش سهولت یادگیری انجام یک تست در دفعات مختلف است.به این صورت که کاربر یک تسک مشخص را انجام می‌دهد و معیارهایی مثل مدت زمان انجام تسک و تعداد خطاهایش درحین انجام تسک ثبت می‌شود.و در یک روز دیگر کاربر باید همان تسک را دوباره انجام دهد و زمان انجام و تعداد خطا ثبت شود.این کار چند بار متوالی انجام می‌شود،اگر کاربر هر بار تسک را بهتر انجام دهد یعنی از تجربه‌ی قبلی خود آموخته و اعدادی که ثبت شده است این میزان یادگیری را نمایش می‌دهند.که میتوان برای نمایش آن از نمودار استفاده کرد.مثال:نمودار زمانی برای انجام یک تستدر نمودار ریر یک تسک 8 بار توسط کاربر انجام شده و زمان‌های آن ثبت شده اند.کلام آخر: در این مقاله سعی کردم که به شما به صورت سرفصل متریک‌ها و انواع پرسشنامه‌ها را معرفی کنم و در مقاله‌های بعدی هر کدام را با جزییات و مثال‌های بیشتری برای شما توضیح‌خواهم داد.

لایو استریمینگ چطور متولد شد؟

فرزاد سید عربی نژاد — Sat, 14 Nov 2020 12:25:32 +0330

سال‌ها پیش به دلیل کمبود فضای اینترنت و سرعت محدود، بیشتر تولید محتواهای موجود به صورت متنی بودند. یکی از پرطرفدارترین نوع محتوا در ابتدای پیدایش اینترنت، وبلاگ بود که به دلیل محدودیت‌های موجود، تولیدکنندگان محتوای وبلاگ‌ها نمی‌توانستند از نوشتن «متن» در بستر اینترنت فراتر بروند. با زیادشدن سرعت اینترنت و رفع محدودیت‌های موجود، «عکس» نیز به عنوان جایگزین و یا مکمل تولیدمحتوای متنی اضافه‌شد و بسترهایی مانند اینستاگرام به وجود آمد. روند رشد بستر اینترنت به صورت افزایشی ادامه پیدا‌کرد و محتواهای ویدیویی نیز به دنیای تولیدمحتوا وارد شدند، به این ترتیب، وبسایت‌هایی مانند یوتیوب و آپارات، شبکه‌های اجتماعی جدید و یا حتی همان شبکه‌های اجتماعی قدیمی مثل اینستاگرام، به دنیای تولیدمحتوای ویدیویی پا گذاشتند.و اما با افزایش سرعت آپلود در بستر اینترنت، تکنولوژی جدیدتری در تولیدمحتوا ارائه شد که به آن «لایواستریمینگ» می‌گویند. فرآیند انتشار این نوع تولید محتوا که به صورت پخش‌زنده انجام می‌شود، به این صورت است که هم‌زمان با ضبط یک ویدیو، این ویدیو به سمت سرورهای سایت موردنظر انتقال داده‌می‌شود و سپس از سمت سرور در اختیار کاربران قرار می‌گیرد و کاربران می‌توانند به صورت زنده محتوای ویدیویی را مشاهده کنند. بازهم مثل هر جهش در دنیای تولید محتوا، وبسایت‌ها و بسترهای قدیمی به سراغ تولید محتوای پخش‌زنده حرکت کردند و بسترهای جدیدی نیز در این فضا به وجود آمد.مخاطب به دنبال محتوای ضبط‌نشده است!امروزه مخاطبان به دنبال دیدن محتوای تازه و دست‌اولی هستند که ازپیش ضبط نشده‌باشد و به صورت زنده به آن‌ها ارائه شود. به همین دلیل پخش زنده به‌خاطر محبوبیت بین مخاطبان، در بسیاری از برنامه‌ها نظیر برنامه‌های تلویزیونی، مسابقات و... وجود دارد. امروزه نیز به دلیل سرعت بالای اینترنت که امکان پخش‌زنده محتواهای ویدیویی را به کاربران می‌دهد، بسیاری از برنامه‌های موجود مثل همایش‌ها، افتتاحیه‌ها، اختتامیه‌ها، مسابقات و... در قالب لایواستریمینگ پخش می‌شوند. بازخورد اصلی که درابتدای به‌وجود آمدن سیستم پخش‌زنده، از این نوع تولیدمحتوا گرفته شد این بود که این بستر به شدت برای تولیدمحتوای بازی (گیم) مناسب است. در حوزه تولید محتوای بازی، گیمرهایی که در گذشته ازصفحه بازی خود ویدیو ضبط می‌کردند و با مخاطب به اشتراک می‌گذاشتند، با انتشار آن‌ها به صورت پخش‌زنده توانستند مخاطبان بسیار بیشتری را جذب کنند. به همین دلیل بسترهای پخش‌زنده متوجه شدند که پخش محتوای زنده از بازی کردن افراد حرفه‌ای یا کسانی که می‌توانند بازی را با فضای جذاب و طنز ترکیب کنند، بیشتر از هر نوع محتوایی می‌تواند مخاطب را به خود جذب کند.شروع لایواستریم‌ در حوزه بازی از سال 2010 بحث لایواستریمینگ در حوزه بازی شروع شد و در سال 2011 توییچ به عنوان یک بستر مخصوص این حوزه فعالیت خود را شروع کرد. اوج فراگیرشدن این حوزه نیز در سال 2014 بود که آمازون توییچ را خرید و با سرمایه‌گذاری مناسب روی این بستر، باعث به‌وجود آمدن استریمرهای بیشتر و درنتیجه مخاطبان بیشتری شد. به مرور بسترهای دیگر نیز وارد این حوزه شدند. مثلاً مایکروسافت نیز ازطریق بستر میکسر وارد این حوزه شد که البته الان از دسترس خارج شده! یوتیوب، فیسبوک و بسیاری از سایت‌های دیگر نیز وارد حوزه لایواستریمینگ شدند. آپارات نیز به عنوان یک بستر پویا در دنیای تکنولوژی از سال 1396 بستر لایواستریمینگ خود را فعال کرد و در سال‌های 97 و 98 به صورت تخصصی‌تر وارد حوزه بازی (گیم) شد. به‌روزرسانی‌های موجود در بستر پخش‌زنده آپارات، هر روز باعث بهبود امکانات موجود در آن شده و در رقابت با بسترهای مشابه خارجی است.لایواستریمینگ بازی، چهارمین صنعت پول‌ساز دنیااگر بخواهیم به طور کلی به حوزه بازی نگاه کنیم، شاخه‌های بسیار متفاوتی وجود دارد. مسابقات الکترونیکی (ESport)، تولید محتوای بازی‌های ویدیویی، تولید بازی و... به عنوان بخش‌های مختلفی از این صنعت بزرگ به شمار می‌روند.امروزه از صنعت بازی به عنوان هنر هشتم یاد می‌کنند.لایواستریمینگ بازی نیز یکی از شاخه‌های اصلی صنعت بازی به‌حساب می‌آید و به کسانی که در این حوزه فعالیت می‌کنند، امتیازهایی می‌دهد. این امتیازها باعث شده کسانی که قبلاً در این حوزه فعالیت می‌کردند، بتوانند از این بستر کسب درآمد کنند و کم‌کم به عنوان یک شغل به آن نگاه کنند. البته که در ایران هنوز تولیدکنندگان محتوا به دلیل عدم حمایت از سوی نهادهای مرتبط و شرایط موجود، نتوانستند درآمدزایی بسیار زیادی داشته باشند. اما این امر اجتناب‌ناپذیر است و حتماً روزی صنعت بازی رایانه‌ای در ایران به چنین جایگاهی می‌رسد. آپارات گیم نیز تمام تلاش خود را می‌کند تا از استریمرهایی که در آپارات درحال فعالیت در حوزه بازی هستند حمایت کند. همچنین امکاناتی که در بسترهای جهانی حوزه بازی ارائه می‌شوند، توسط آپارات نیز به روزرسانی شده و دراختیار استریمرها قرار می‌گیرند.بیشتر بازی‌های آنلاین دارای مسابقات جهانی هستند. از این رو شرکت‌های بزرگ جهانی در حوزه سخت‌افزار و نرم‌افزارهای مربوط به بازی، سرمایه‌گذاری‌هایی را در حوزه مسابقات جهانی بازی انجام می‌دهند که درنتیجه مخاطبان بسیاری را در بر می‌گیرد. رقابت‌های ESport که در سطح جهانی بسیار پرمخاطب هستند، اخیراً در مسابقات آسیایی وارد شدند و همانند رقابت‌های ورزشی، به برندگان مدال و جوایز اهدا کردند. همچنین گمانه‌زنی‌هایی برای واردشدن این حوزه به رقابت‌های المپیک نیز وجود دارد.امسال نیز بخش بازی آپارات (آپارات گیم) مسابقه‌ای با بازی فیفا برگزار کرد که دارای جوایز و مراسم‌های اجرایی بسیار خوبی بود و جهش بزرگی در حوزه برگزاری مسابقات بازی‌های رایانه‌ای در ایران به حساب آمد.چطور از استریم بازی کسب درآمد کنیم؟درآمدزایی از استریمینگ به چند شاخه مختلف تقسیم می‌شود:درآمدزایی ازطریق حامی (اسپانسر): شما با تبلیغ کردن برای یک برند، شخص و... درحین برنامه، می‌توانید درآمدزایی داشته باشید.که متاسفانه این نوع از تبلیغات هنوز در ایران رایج نیست.حمایت مالی کاربران (دونیت): سایت‌های واسطی وجود دارند که به شما درگاه مشخصی را اختصاص می‌دهند و مخاطبانی که درحال مشاهده پخش‌زنده شما هستند می‌توانند درصورت تمایل برای حمایت مالی، مبلغ دلخواهی را به حساب شما واریز کنند. بیشتر درآمدزایی از پخش‌زنده در ایران ازطریق همین سیستم حمایت مالی کاربران است که آپارات این امکان را در اختیار استریمر‌ها قرار می‌دهد.حق اشتراک: این حمایت مالی نیز با خرید حق اشتراک ازطرف مخاطبان شما انجام می‌شود. مخاطبی که به محتوای ارائه‌شده توسط شما علاقمند باشد، می‌تواند حق اشتراک مربوط به شما را از آپارات خریداری کند و قابلیت‌های بخصوصی را دریافت کند. استریمر نیز از مبلغی که مخاطبان به عنوان حق اشتراک خریداری کردند، به صورت ماهانه از آپارات دریافت می‌کند و بخشی به آپارات اختصاص داده‌می‌شود. مخاطب پس از خرید حق اشتراک یک سری ایموت‌های مخصوص همان استریمر (شکلک مخصوص هر استریمر) را دریافت می‌کند که این شکلک مخصوص در قسمت چت، کنار پیام‌های مخاطب نشان داده می‌شود و پیام‌هایش را نسبت به بقیه متفاوت نشان می‌دهد، استریمر نیز می‌تواند قسمت چت را فقط به کسانی که حق اشتراک او را خریداری کردند محدود کند و در صورت وجود تبلیغات روی سیستم پخش‌زنده، به این مخاطب هیچ تبلیغی نشان داده نشود.لایو استریم در آپارات دارای چه بخش‌هایی است؟در آپارات نیز به جز بازی، برنامه‌های دیگری در بستر پخش‌زنده وجود دارد. تلویزیون‌های 24 ساعته، برنامه‌های مذهبی، برنامه‌های سرگرمی و... که می‌توانند از بستر پخش‌زنده آپارات استفاده کنند. همچنین در لایواستریمینگ آپارات دسته‌بندی‌های مختلفی درنظر گرفته شده که باتوجه به نوع تولیدمحتوای زنده شما، امکانات مختلفی در اختیارتان قرار می‌گیرد:یکی از بخش‌های مهم سرویس پخش‌زنده آپارات رویدادها هستند. رویداد، محتوای ویدیویی زنده‌ای است که در قالب کلاس آموزشی، همایش، کنفرانس و...تولیدکننده می‌تواند آن را برنامه‌ریزی کند و به صورت فراخوان و بلیط فروشی (با مشخص کردن مبلغ) و یا به صورت رایگان، محتوای خود را دراختیار کاربران قرار‌دهد.در دسته‌ی بازی(گیم) شما باید ازطریق یک نرم‌افزار مشخص، سیستم موردنظر خود را به قسمت پخش‌زنده آپارات متصل کنید و بازی‌کردن خود را به صورت زنده با مخاطبان به اشتراک بگذارید. رایانه شخصی، کنسول بازی، موبایل و... سیستم‌هایی هستند که می‌توانند ازطریق آن نرم‌افزار مشخص، به آپارات متصل شوند. شما می‌توانید وبکم، صفحه نمایش سیستم و overlay(که همان صفحه ظاهری است که مخاطب مشاهده می‌کند) را به دلخواه خود چینش کرده و با مخاطب به اشتراک بگذارید. سرورهای موجود در آپارات از ویدیوی پخش‌زنده شما کیفیت‌های مختلفی می‌سازند و مخاطبان می‌توانند پخش‌زنده شما را با کیفیت دلخواه مشاهده کنند. شما می‌توانید بخش چت را نیز در نوار کناری پخش‌زنده فعال کنید. این ویژگی مهم در استریم بازی به مخاطبان این امکان را می‌دهد که از طریق همین بستر و با نوشتن پیام دلخواه خود، می‌توانند با شما ارتباط برقرار کنند. آپارات چه امکاناتی را دراختیار استریمرهای بازی قرار می‌دهد؟محدودکردن چت برای کاربران (شماره تلفن، دنبال‌کردن)نشان‌دار کردن پیام در بخش گفتگو (نشان‌کردن پیام به صورت دلخواه استریمر، اخطارھای پشتیبان‌ھا، اعلان عمومی)مدیریت چت توسط مدیران با دسترسی‌ھای متفاوت+ثبت عمل‌کرد مدیرانلیست کاربران حاضر در استریمنشان‌ها و ایموت‌ھا در چتپوشاندن و یا حذف خودکار پیام‌ھای حاوی متن نامناسبسیستم‌ھای مختلف گزارش‌گیریحمایت مالی از طریق خرید حق اشتراکزمان‌بندی شروع استریمربات چت (زمانی و دستوری)افزودن میزان تاخیر در ارسال پیام‌ھای چتاستریم ھم‌زمان چندنفره ( اسکواد استریم)امکان Raidکردن ازطریق دستورات چتلایو بیزینس(ارائه بستری جھت فروش)پخش‌زنده آزمایشی و ارزیابی شبکه جھت شروع استریمرویدادھای پخش‌زندهکلام آخردرحال حاضر روز به روز به تعداد گیمرها و مخاطبان بازی‌های پخش زنده(لایواستریم بازی) اضافه می‌شود. بهترین پیشنهاد به کسانی که درحوزه تولیدمحتوای ویدیویی بازی فعالیت می‌کنند و یا کسانی که در مسابقات بازی‌های رایانه‌ای دارای جایگاه مناسبی هستند، این است که هرچه زودتر به دنیای لایواستریم بازی وارد شوند. بهتر‌است که تمامی کسانی که در حوزه بازی‌های رایانه‌ای فعالیت می‌کنند، به یکدیگر کمک کنند تا این صنعت بسیار پرمخاطب در کشور ما نیز رشد قابل توجهی داشته‌باشد.

الگوهای معماری میکروسرویس بخش اول: بانک اطلاعاتی

علی کاویانی — Tue, 06 Oct 2020 15:20:14 +0330

استفاده از میکروسرویس‌ها بسته به شرایط می‌تواند تاثیرات مثبتی بر کسب‌و‌کار شما داشته‌باشد،‌ اما دانستن نحوه برخورد با این معماری و الگوهای مورد استفاده در آن از اهمیت بالایی برخوردار است. قبل از هر چیزی مروری از مقاله قبلی را در چند سطر بخوانید.اهداف و اصول معماری میکروسرویس‌ها:کاهش هزینه‌ها: هزینه‌های کلی طراحی، پیاده‌سازی و نگهداری سرویس‌های فناور محور کاهش‌ میابد.افزایش سرعت انتشار: سرعت انتشار امکانات جدید از ایده تا انتشار افزایش میابد.بالابردن سطح اطمینان: این معماری باعث بهینه‌کردن قابلیت اطمینان در شبکه سرویس‌های شما می‌شود.دسترس‌پذیری بهتر: دسترسی به سرویس‌های شما ساده‌تر می‌شود.اصول بنیادین معماری میکروسرویس‌ها:توسعه‌پذیری(Scalability‌)دسترسی‌پذیری(Availability)انعطاف‌پذیری(Resiliency‌)استقلالمدیریت غیر متمرکزایزوله سازی در مقابل خطاپراویژنینگ‌(Provisioning) خودکارانتشار پیوسته از طریق ساز‌و‌کار DevOpsالگوهای طراحی در حوزه میکروسرویس‌ها:معماری میکروسرویس علاوه بر مزایای گفته‌شده و راهکارهایی که برای شما فراهم می‌کند، چالش‌ها و مشکلاتی را نیز با خود به همراه دارد، اما باید بدانید که این چالش‌های فنی مانند بسیاری از مشکلات در این حوزه، با انتخاب الگوهای طراحی صحیح و متناسب با صورت مسئله، قابل رفع‌شدن هستند.این الگوها به 5 دسته اصلی تقسیم می‌شوند:الگوهای بانک اطلاعاتیالگوهای جداسازی(Decomposition)الگوهای یکپارچگی(Integration)الگوهای مشاهده‌پذیری‌(Observability)الگوهای مشکلات چند‌جانبه(Cross Cutting Concerns ) آخه من اینو چی بگم به فارسی؟! :دیDesign Patterns for Microservice با توجه به مقدمه‌ای‌ که برایتان شرح دادم، قصد دارم در یک مجموعه مقالات سریالی، هر بار به سراغ یکی از این 5 دسته الگوهای طراحی بروم و مزایا و معایب هر کدام را بررسی کنم، این مقاله نیز به عنوان اولین قسمت از این سری مقالات به حساب می‌آید که تصمیم گرفتم در ابتدا از حوزه بانک اطلاعاتی شروع کنم زیرا که در مورد این حوزه بحث‌ها و گفتگو‌های زیادی وجود دارد.الگوهای بانک اطلاعاتیالگوهای مورد استفاده در بانک‌های اطلاعاتی در میکروسرویس‌ها یکی از موضوعات پر بحث و جدل درباره نحوه جداسازی میکروسرویس‌ها است. باید گفت، الگوهای زیر جز موارد پر‌استفاده هستند:بانک اطلاعاتی جدا به ازای هر سرویسبانک اطلاعاتی مشترکالگوی Sagaالگوی API Compositionالگوی Event Sourcingالگوی CQRSزمانی که درباره معماری بانک اطلاعاتی در میکروسرویس‌ها صحبت می‌شود، باید موارد زیر را گوشه ذهن خود داشته‌باشیم:سرویس‌ها باید تا جای ممکن به همدیگر وابستگی نداشته‌باشند تا بتوانند به صورت جداگانه توسعه پیدا کنند، بارگذاری شوند و تغییر اندازه دهند.برخی از تراکنش‌های مرتبط به کسب‌و‌کار ممکن است نیاز به دریافت اطلاعات از سرویس‌های متعدد داشته‌باشند.بانک‌های اطلاعاتی در برخی از موارد باید در چند نقطه تکراری، نگهداری و یا به اشتراک گذاشته‌شوند.سرویس‌های مختلف، نیازهای مختلفی در حوزه بانک‌های اطلاعاتی دارند.بانک اطلاعاتی جدا به ازای هر سرویسدر این الگو، میکروسرویس اطلاعات مربوط به خود را مدیریت می‌کند. با استفاده از این الگو اطمینان حاصل خواهید‌کرد که، میکروسرویس‌های دیگر اجازه دسترسی مستقیم به بانک اطلاعات سرویس دیگری را ندارند. ارتباط و یا انتقال اطلاعات از طریق API‌های تعیین‌شده از سمت هر سرویس قابل دسترسی‌ است. پیاده سازی این الگو از چیزی که به نظر میاد پیچیده‌تر است، زیرا نرم‌افزارها معمولا خیلی خوب مرز‌بندی نشده‌اند و برای پیاده‌سازی لاجیک خود، به اطلاعات میکروسرویس‌های دیگر نیازمند هستند، در نتیجه منجر به ارتباطات پیچیده بین میکروسرویس‌های مختلف می‌شود.Database per service اگر موفق شوید این الگو را به خوبی پیاده‌سازی کنید،‌ می‌توانید از بزرگترین مزیت آن که همان وابستگی بسیار کم بین میکروسرویس‌ها است، استفاده کنید و نرم افزار خود را از گیر‌افتادن در impact analysis خلاص کنید. موفق بودن این الگو به شدت به تعریف موثر حوزه بانک داده در نرم‌افزار شما وابسته‌است. این کار برای یک نرم‌افزار یا یک سیستم جدید و در حال طراحی، کار ساده‌تری است ولی برای یک معماری مونولیتیک، جدا‌سازی پیچیدگی موجود می‌تواند مشکل ساز باشد!همچنین چالش‌های دیگری نیز در این معماری وجود دارد، که می‌توان به آن اشاره کرد:پیاده‌سازی Business Transaction هایی که چندین میکروسرویس را درگیر می‌کنند و یا پیاده‌سازی query هایی که اطلاعات را از دو یا سه میکروسرویس مختلف دریافت می‌کنند.نکته مفید دیگری در این حالت وجود دارد:نکته مفید امکان اسکیل‌کردن ساده نرم‌افزار و استفاده از بانک‌های مختص به هریک از میکروسرویس‌ها است به طور مثال؛ در میکرسرویس جستجو می‌توانید از ElasticSearch و در میکروسرویس مدیریت کاربران، از قدرت یک دیتابیس RDBM استفاده کنید.بانک اطلاعاتی مشترکاستفاده از یک بانک اطلاعاتی اشتراکی، در زمانی که برای تیم شما چالش‌های پیاده‌سازی بانک اطلاعاتی به ازای هر سرویس، زیادی پیچیده و مشکل ساز شود، گزینه مناسبی است. رویکرد این الگو مانند الگوی قبلی سعی در رفع مشکلات بالا دارد، با این تفاوت که از راه حل ساده‌گیرانه‌تری مانند استفاده از بانک اطلاعاتی مشترک استفاده می‌کند.در اکثر مواقع استفاده از این الگو برای توسعه‌دهنده‌ها کم‌خطرتر است، چون روش مورد استفاده کاملا مشابه روش‌های مرسوم آن‌ها مانند ACID Transaction برای حفظ یکپارچگی اطلاعات است.در این روش اگرچه از بیشتر منافع ذکر‌شده برای میکروسرویس‌ها بهره‌مند می‌شوید، اما توسعه‌دهنده‌ها که در تیم‌های مختلف فعالیت می‌کنند باید تغییرات مورد نظر خود در بانک را با یکدیگر هماهنگ کنند. همچنین به دلیل استفاده چندین سرویس به صورت هم‌زمان از یک بانک اطلاعاتی، امکان وقوع خطاهای ناسازگاری‌های runtime نیز وجود دارد.به طور کلی روش بانک اطلاعاتی مشرک در بلند مدت بیشتر از اینکه مفید باشد برای شما دردسر ایجاد می‌کند.الگوی Sagaالگوی Saga راهکاری برای پیاده‌سازی Business Transaction بین چندین میکروسرویس است. یک Saga به طور ساده زنجیره‌ای از تراکنش‌های محلی است. به ازای هر کدام از این تراکنش‌ها که در یک Saga اتفاق می‌افتد، سرویسی که آن تراکنش را انجام ‌می‌دهد یک event منتشر‌ می‌کند. تراکنش بعدی بر اساس خروجی تراکنش قبلی اتفاق‌می‌افتد و اگر یکی از تراکنش‌های موجود در این زنجیره به خطا بخورد، Saga یکسری از تراکنش‌های اصلاح‌کننده را می‌دهد تا تغییراتی که به واسطه تراکنش‌های قبلی ایجاد‌شده را برگرداند.در الگوی Saga از دو روش برای مدیریت مراحل استفاده می‌شود:روش Choreography : هر کدام از تراکنش‌ها محلی، یک Domain Event را ایجاد می‌کند که باعث ایجاد تراکنش‌های محلی در دیگر سرویس‌ها می‌شود.روش Orchestration : یک ارکستراتور به شرکت‌کنندگان(میکروسرویس‌ها) می‌گوید که چه تراکنشی را باید انجام دهند. روش ChoreographyChoreography-Based Saga در مثال فوق مراحل زیر طی می‌شوند:۱. سرویس `Order Service‍` درخواستی را از POST /orders دریافت و یک order را در حالت Pending ایجاد‌می‌کند.۲. سپس یک event از نوع Order Created ایجاد می‌شود.۳. در سوی دیگر سرویس Customer Service به event از نوع Order Created گوش می‌دهد و هنگامی که این درخواست را دریافت می‌کند سعی خواهد کرد به اندازه هزینه سفارش از اعتبار مشتری به صورت رزرو‌شده نگهداری‌کند.۴. در مرحله بعد نتیجه تلاش خود را به صورت یک event ارسال می‌کند.۵. مدیریت‌کننده event سرویس Order Service در این مرحله event بالا را دریافت و بر اساس اینکه آیا مشتری اعتبار دارد یا خیر؟ سفارش را تایید و یا رد می‌کند.روش OrchestrationOrchestration-Based Saga در مثال فوق مراحل زیر طی می‌شود:۱. سرویس `Order Service‍` درخواستی را از POST /orders دریافت می‌کند و یک Saga Orchestrator از نوع Create Order می‌سازد.۲. این ارکستریتور یک سفارش در حالت pending ایجاد ‌می‌کند.۳. سپس یک دستور Reserve Credit را از طریق Message broker برای Customer Service ارسال‌ می‌کند.۴. در این مرحله Customer Service پاسخ این درخواست را برای ارکستریتور ارسال‌ می‌کند.۵. ارکستریتور براساس اینکه پاسخ سرویس مشتریان چه بوده‌است، سفارش را تایید و یا رد می‌کند.همانطور که می‌بینید، این روش به شدت با روش سنتی ایجاد Transaction در بانک اطلاعاتی متفاوت است. این روش پیچیدگی‌های زیادی را به سیستم اضافه می‌کند، اگر چه این الگو برای حل مشکلات خاص خیلی قدرتمند است ولی به دلیل پیچیدگی‌های بسیاری که دارند فقط در موارد خاص استفاده‌ می‌شوند.الگوی API Compositionاین الگو، راهکاری برای مدیریت Queryهای پیچیده در معماری میکروسرویس‌ها است. در این الگو، یک API Composer، سرویس‌های دیگر را صدا می‌زند و اطلاعات مورد نیاز را براساس ترتیب مورد نیاز دریافت‌می‌کند و پس از دریافت این اطلاعات، آن‌ها را با یکدیگر به صورت in-memory ترکیب و نتیجه را به مصرف کننده API ارایه‌می‌کند.پر واضح است که مشکل این روش هزینه ترکیب اطلاعات به صورت in-memory برای Dataset‌های بزرگ است.الگوی CQRSالگوی CQRS یا Command Query Responsibility Segregation(جدا‌سازی مسئولیت کوئری) تلاش می‌کند مشکل الگوی API Composition را که بالاتر توضیح دادم، رفع کند. در این الگو، یک برنامه به Domain Event‌های ایجاد‌شده توسط همه میکروسرویس‌ها گوش می‌دهد و بر اساس آن یک View را بروز‌رسانی و یا اطلاعات جدید را از میکرسرویس‌های مورد نظر دریافت‌‌می‌کند. با استفاده از این روش شما می‌توانید ترکیب‌های سنگین از query‌ها را انجام‌دهید و حتی در صورت نیاز خود این سرویس query را scale-up کنید تا همیشه این اطلاعات را برای شما آماده ‌داشته‌باشد.CQRSمزایای الگوی CQRS:امکان ایجاد چندین denormalized view را ایجاد میکند که به راحتی قابل scale کردن هستندباعث بهبود قاعده SoC یا Separation of concerns میشود.مشکلات الگوی CQRS:پیچیدگی اجرا را بیشتر می‌کند.دیتابیس مورد استفاده برای View یا بخش Query به جای آنکه همیشه بروز و consistent باشد، بعضی وقت‌ها consistent است.باعث ایجاد کدهای تکراری در سیستم می‌شود.الگوی Event Sourcingروش Event Sourcing سعی می‌کند مشکل بروزرسانی بانک اطلاعاتی به صورت Atomic و انتشار Event مرتبط با آن را حل کند. در این روش شما وضعیت نهایی یک رکورد را ذخیره و یا با جمع کردن مجموعه تغییراتی که از ابتدا روی این رکورد اتفاق افتاده‌است، شرایط نهایی رکورد را محاسبه می‌کنید. هر زمانی که یک رکورد جدید ایجاد شود و یا یک رکورد موجود به روز شود یک Event ساخته‌می‌شود. در این معماری از یک Event store برای ذخیره‌سازی این event‌ها استفاده می‌شود.Event-Sourcingمزایای الگوی Event Sourcing:یکی از مشکلات اساسی معماری event-driven را برطرف می‌کند و به شما این امکان را می‌دهد که هر وقت تغییری اتفاق می‌افتد یک event منتشر کنید.از آنجا که اتفاقات را به جای آخرین وضعیت ذخیره می‌کند، مشکلات object‑relational impedance mismatch را کمتر می‌کند.این روش audit log صد در صد مطمئنی را برای هرکدام از entity‌ها فراهم می‌کند.امکان ایجاد queryهای موقتی بر اساس وضعیت یک entity در هر بازه زمانی دلخواه ایجاد می‌کند. برای مثال وضعیت اعتبار این کاربر ۱ سال پیش چطور بوده‌است؟مشکلات الگوی Event Sourcing:این روش مدلی متفاوت از روش معمول برنامه‌نویسی در بانک‌های اطلاعاتی را دارد و مدت زمان خاص خود را برای آشنایی با آن می‌طلبد.گرفتن Query از Event-Store برای تعیین وضعیت یک رکورد به صورت مکرر، کار پیچیده و غیر کارآمدی است، در‌نتیجه نرم‌افزار باید حتما از روش CQRS در کنار معماری خود استفاده کند که این به معنی کنار آمدن با داده‌هایی است که بعضی وقت‌ها consistent هستند.

چند نکته سئویی مهم برای نوشتن توضیحات یک ویدیو

حمید خوشدست — Tue, 22 Sep 2020 17:01:41 +0330

تحقیقات و آمارهای خوبی وجود دارد که نشان می‌دهند، مخاطبان بعد از دیدن یک ویدیو از برند یا کسب‌وکار شما به طرز چشمگیری افزایش اعتماد دارند و احتمالا خواسته‌های شما را هم بهتر پاسخ می‌دهند. پس شما هم تمایل دارید ویدیوهایتان در آپارات بیشتر دیده شوند؟ تمایل دارید در بین نتایج گوگل رتبه‌ بهتری کسب کنید؟ پس برای توضیحاتی که در مورد هر ویدیو می‌نویسید اهیمت بیشتری قائل شوید چرا که ساده‌ترین روش برای بیان محتوای داخل ویدیو قبل از دید‌ه‌شدن آن، استفاده از متن و کلمات است. این موضوع هم برای موتورهای جستجو مثل گوگل و هم برای کاربران نکته بسیار مهمی است. در واقع توضیحات بهترباعث خواهد شد کاربران درباره ویدیوی شما اطلاعات کامل‌تری داشته باشند و برای گوگل هم یک راهنمای خوب برای درک محتوای ویدیوی شما خواهد بود.شاید در آینده شاهد تغییرات دیگری باشیم اما در این زمان، توضیحات مربوط به هر ویدیو، قوی‌ترین سیگنال گوگل برای درک محتواهای ویدیویی است.ساختار کلی توضیحاتبه تصویر زیر دقت کنید، یک ساختار کلی محتوا از چه بخش‌هایی تشکیل می‌شود؟ساختار کلی توضیحات در ویدیوهای آپارات1. اولین جملات:اولین جملات شما اهمیت کمتری از عنوان شما ندارند!!! زیرا تفاوت این جملات با بدنه اصلی توضیحات در میزان دیده شدن این جملات است. در واقع جذب مخاطب بیشتر با جملات اولیه‌ اتفاق می‌افتد زیرا که این جملات در پیش‌نمایش ویدیوی شما در نتایج گوگل دیده می‌شوند و اولین جملاتی هستند که مخاطبان آن‌ها را می‌بینند.چند اشتباه رایج در بخش ابتدایی محتوای:استفاده‌کردن از لینک‌ شبکه‌های اجتماعی و سایت در اول متنعیننا تکرارکردن عنواناستفاده از توضیحات غیر واقعی برای جذب مخاطباستفاده از توضیحات ویدیو سایر رقباسعی کنید مخاطبان را از ارزشی که پس از دیدن ویدیوی شما کسب می‌کنند، مطلع کنید. تا مخاطب قانع شود ویدیوی شما را تماشا کند.2. توضیحات ویدیودر این بخش سعی کنید ارزش‌های محتوای خود را به طور مفصل توضیح دهید بدان معنی که توضیحات باید دربرگیرنده همه جوانب ویدیو باشد.از عبارت‌های مکمل و هم‌معنی استفاده کنید. عبارت‌هایی که هم تقویت‌کننده مفهوم محتوای ویدیویی شما باشند هم برای گوگل و کاربران ارزشمند باشند.اگر محتوای شما یک محتوای تخصصی است احتمالا استفاده از ترجمه‌های انگلیسی کلمات مهم، هم برای کاربران و هم برای الگوریتم‌های گوگل خوشایند است.از بهینه‌سازی بیش از حد توضیحات برای گوگل خودداری کنید زیرا در قدم اول ما باید محتوای خود را برای مخاطبان بنویسیم. همچنین باید بدانید که الگوریتم‌های گوگل در بلندمدت به دنبال جذب رضایت مخاطبان هستند محتوای کاربرپسند نه محتوای جذاب برای ربات‌ها!!!در صورتی که توضیحات نیاز به معرفی یک منبع دارند، از لینک‌دادن به این منابع دریغ نکنید، لینک‌دادن به سایت‌های مرتبط نشان‌دهنده اعتبار محتوای شما است و در نهایت باعث بهبود رتبه ویدیوی خود می‌شود. این منبع می‌تواند یک سایت خارجی(مثل ویکیپدیا و …) یا حتی یک سایت خوب ایرانی باشد، دقت کنید تا حد امکان از لینک‌دادن به سایت‌هایی که با موضوع محتوای شما مرتبط نیستند و برای مخاطبانتان ارزش افزوده ایجاد نمی‌کنند خودداری کنید.اینکار باعث کمتر دیده‌شدن محتوای ویدویی شما در نتایج گوگل خواهد شد.تصویر زیر، شماتیک و جانمایی کلمات یک توضیح برای ویدیوی با موضوع یک فیلم ترسناک است که با کامل کردن آن یک نمونه بسیار خوب خواهیم داشت:در ساختار توضیحات بالا نکات زیر را رعایت کنید:استفاده از نام بازیگران و کارگردان‌ها و فیلم‌های معروف، تقویت‌کننده مفهوم ده فیلم برتر ترسناک است.لینک‌دادن به صفحات مرتبط در سایت‌های IMDB و ویکی‌پدیا به عنوان منابع معتبر خارجی و لینک‌دادن به نقد و بررسی فارسی این فیلم‌ها( یا بیوگرافی بازیگران) در سایت فیلیموشات، می‌تواند به اعتبار این مطلب اضافه‌کند.برای درک بهتر گوگل و کاربران در بخش‌هایی که نیاز هست، ترجمه انگلیسی موارد ذکر‌شده، می‌تواند گزینه خوبی باشددر ساختار توضیحات از اشتباهات رایج خودداری کنید:کپی‌کردن توضیحات از محتوای دیگراناستفاده بیش از حد از کلمات کلیدیاستفاده از اصطلاحات تخصصی بدون اضافه‌کردن توضیحات مورد نیاز کاربرانغلط املاییتوضیحات بیش از اندازه تبلیغاتی و غیر مفید برای کابران۳. اقدام به عمل CTAدر این مرحله می‌بایست کاربران را دعوت به انجام عملی خاص مطابق خواسته خود کنید.به عنوان مثال:بعد از یک ویدیوی سرگرمی، مخاطب را به دنبال‌کردن محتوا‌هایتان در سایر شبکه‌های اجتماعی دعوت کنید.بعد از یک ویدیوی تخصصی، راه‌های ارتباطی برای گرفتن مشاوره و خدمات را ارائه دهید.بعد از یک ویدیوی نقد و بررسی، از کاربران دعوت کنید تا با شما در تعامل باشند و نظرات و تجربیات خود را مطرح‌کنند.از اشتباهات. رایج زیر خود داری کنید:دعوت به اقدام غیر مرتبط با نیاز مخاطب شما، برای مثال، دعوت به استفاده از خدمات زیبایی در ویدیویی که مربوط به نقد و بررسی موبایل است.تکرار بیش از حد راه‌های ارتباطی مانند شبکه‌های اجتماعی و شماره تماس و …استفاده از وعد‌ه‌های تبلیغاتی غیر واقعی برای جذب مخاطب بیشتر، مثلا برای تماشای رایگان سریال آقازاده کلیک کنید.ارائه دادن راه‌های ارتباطی دشوار برای مثال، ارایه‌دادن لینک ثبت‌نام با ایمیل برای مطلبی که مخاطبان آن سن بالایی دارند.نکته آخر:دقت کنید هنگام نوشتن توضیحات در همه مراحل، اول برای مخاطبان محتوای مفید تولید کنید و بعد به اصول سئو توجه کنید.

میکروسرویس یا مونولیت(خوب، بد، چُخ)

علی کاویانی — Mon, 14 Sep 2020 10:46:46 +0430

تا حالا شده که ویدیوی یک کنفرانس معتبر را ببیند که موضوع آن درباره این باشد که چقدر میکروسرویس‌ها خوب هستند و چطور شرکت‌های بزرگ مشکلات را به وسیله میکروسرویس‌هایی که به صورت کانتینری اجرا شده، حل کردند، بعد با خودتان فکر کنید چرا ما این کار را نکنیم؟واقعیت این است که در مهندسی نرم‌افزار هیچ راه حل طلایی‌ای وجود ندارد! میکروسرویس‌ها به صورت جادویی تمام مشکلات scaling را حل نمی‌کنند و حتی بعضی وقت‌ها مشکلات جدیدی را هم به وجود می‌آورند و من با اینکه به میکروسرویس‌ها به دلیل پیچیدگی کمتر و راه‌گشا بودنشان بسیار علاقه‌مندم و دلم نمی‌خواهد این معماری بکوبم اما معتقدم علاوه بر کارآمد بودن باید هزینه‌های اجرای میکروسرویس را در شرایط واقعی بدانیم و سعی کردم در این مقاله به آن بپردازم.معماری میکروسرویسدر معماری میکروسرویس، به صورت کلی شما Domain Model پروژه را به سرویس‌های کوچکتری که کمتر به هم وابسته هستند و می‌توانند مستقل از هم دیپلوی و اسکیل بشوند تقسیم می‌کنید. هرکدام از این سرویس‌ها به تنهایی یک نرم‌افزار با معماری مخصوص به خودشان هستند.سرویس‌ها در مواردی اندپوینت‌های REST را فراهم می‌کنند که می‌تواند توسط یک API Gateway به کار گرفته‌شوند یا سرویس‌ها ممکن است از طریق یک سیستم پیام‌رسان با یکدیگر صحبت کنند. بعضی از این سرویس‌ها دارای رابط کاربری وب هستند و برخی از آن‌ها فقط و فقط یک API ارائه می‌دهند.در معماری میکروسرویس محور، هر سرویس مسئول مدیریت اطلاعات خود است و ایده‌آل‌ گرایانه نباید ساختار بانک اطلاعاتی خود را با دیگر سرویس‌ها به اشتراک قرار دهد. این معماری فراهم کردن کلاینت‌های موبایل و دسکتاپ را که می‌توانند مستقل و بسته به نیاز Scale بشوند را ساده می‌کند.برای ساخت میکروسرویس‌ها الگوهای مختلفی وجود دارد، هر الگوی انتخاب شده، مسئول انتخاب روش ارتباط که سرویس‌ها با یکدیگر و تجمیع اطلاعات می‌شود.کریس ریچاردسون این لگو‌ها را در مقاله زیر به خوبی توضیح داده‌است که پیشنهاد می‌کنم آن را مطالعه کنید. https://microservices.io/patterns/microservices.html خوب چیزی که در ادامه می‌خواهم به آن بپردازم این است که منافع و مشکلات معماری میکروسرویس‌ها را ببینید تا بدانید که چه زمانی باید به سراغ آن‌ها برویم و چه زمانی باید از آن‌ها فرار کنیم!منافع رایج در معماری میکروسرویسبه صورت کلی، میکروسرویس‌ها بسته به اینکه چطور پیاده سازی شوند منافع زیر را در سه دسته ایجاد می‌کنند و یا حداقل این طور ادعا دارند که می‌توانند ایجاد کنند:وابستگی کماسکیل پذیری عالیدوره های توسعه و انتشار سریعتروابستگی کمکامپوننت‌ها در معماری میکروسرویس‌ها از معماری‌های سنتی، کمتر به هم وابستگی دارند. این سیستم‌ها از معماری‌های پیام محور‌(Message-Driven) و یا اتفاق محور‌(Event-Driven) برای ایجاد ارتباط بین این کامپوننت‌های استفاده می‌کنند که منجر به ایزوله شدن کامپوننت‌های سیستم، تست کردن راحت‌تر و اجرای سریع‌تر آن‌ها می‌شوند. این سیستم‌ها همچنین منافع دیگری را ایجاد می‌کنند، به طور مثال، وجود یک باگ Memory Leak در یک میکروسرویس ایزوله شده، منجر به خرابی کل اپلیکیشن و یا افتادن کل سرویس نمی شود.در یک کلام معماری میکروسرویس باعث کاهش تعداد Single point of failure در سیستم خواهد شد.باید بگویم که کامپوننت‌ها با وابستگی کم، به نسبت یک سیستم مونولیتیک خیلی سریعتر اجرا می‌شوند و در نتیجه با اجرای موازی اجزاي سیستم، می‌توان سرعت استارت را برای سیستم‌های بزرگ‌تر بالا برد. همچنین به دلیل این وابستگی کم، هر کدام از سرویس‌ها می‌توانند انتخاب کنند که از هر دیتابیس و یا دیتا استوری که برای حوزه کار خود مناسب‌تر هستند، استفاده کنند که همانطور که می‌دانید در خیلی مواقع در یک سیستم مونولیتیک توافق می‌شود که فقط از یک نوع دیتابیس استفاده شود. برای مثال در یک سرویس با مقدار زیادی از داده‌های بدون ساختار می‌توانید از یک بانک اطلاعات NoSQL استفاده کنید در حالی که یک سرویس دیگر که با داده‌های ساختارمند و Transaction سر و کار دارد می‌تواند سراغ بانک‌های اطلاعاتی RDBMS برود.دوره های توسعه و انتشار سریعتردر یک معماری میکروسرویس که خوب پیاده سازی شده‌باشد:دوره‌های توسعه نرم‌افزار سریع‌تر و زمان آماده سازی یک ویژگی جدید و یا تغییر ویژگی‌های موجود خیلی کوتاه‌تر می‌شود. یک سیستم با دومین پیچیده به راحتی می‌تواند با تقسیم به سرویس‌های قابل مدیریت و قابل فهم در طولانی مدت بهتر قابل مدیریت باشد.بکارگیری تکنولوژی‌های جدیدتر ساده‌تر است، اجزای سیستم می‌تواند جداگانه به صورت مرحله به مرحله بروزرسانی شوند و در نتیجه می‌توان در هرکدام از این کامپوننت‌ها از stack مختص به خود استفاده کنند.همچنین این امکان وجود خواهد داشت که هریک از این میکروسرویس‌ها از زبان‌های مختص به خود استفاده کنند و با استفاده از ساختارهای معمول ارتباط مثل gRPC و یا Message Queue و یا Pub/Sub با یکدیگر ارتباط بگیرند،‌که در نهایت شما را قادر خواهد ساخت تا از تیم های مختلف با زبان‌های مختلف استفاده کنید و وابستگی مجموعه را به یک زبان خاص کمتر می‌کند.تیم‌های اجرایی کمتر به همدیگر وابسته خواهند بود، زیرا ارتباط بین اجزای سیستم توسط API و یا یک ساختار قراردادی دیگر اتفاق می‌افتد و هر تیم قادر است با حفظ ساختار قراردادی روال‌های داخلی کد خود را تغییر دهد بدون اینکه نگران باشد، این کار منجر به خراب شدن کد تیم دیگر بشود.روال مناسبی برای تیم‌های چابک فراهم می‌سازد، در این ساختار تیم‌ها می‌توانند تمرکز را روی سرویس‌های خود قرار دهند و فقط نگران یک سرویس باشند.اسکیل پذیری عالی یکی از مهمترین منافع از معماری میکروسرویس امکان تغییر اسکیل هریک از اجزا، بسته به بار و فشار روی هریک از آن‌ها است. اگر این بخش به خوبی پیاده‌سازی شود منجر به تقسیم بار ایده‌آل بین اجزای سیستم و کاهش هزینه زیرساخت‌های مورد نیاز می‌شود. سرویس‌ها با تقاضای بیشتر می‌توانند Scale up شوند و سرویس‌های که تقاضای آن‌ها کمتر شده‌، می‌توانند Scale Down شوند بدین‌ترتیب می‌توان منابع را بهتر مدیریت کنیم.دیپلوی کردن سرویس‌ها به صورت مستقل باعث می‌شود کل نرم‌افزار قابلیت اطمینان بالاتری داشته‌باشد و ایجاد اصلاحات جزئی ساده‌تر شود و نیازی به بروزرسانی کل نرمافزار برای رفع مشکل در یک سرویس نخواهیم بود.مدل های پیچیده تری از Scaling قابل اجرا خواهد بود، سرویس‌های حیاتی بطور موثرتری اسکیل خواهند شد.بارگذاری پیوسته در سیستم‌های پیچیده در این معماری به نسبت معماری Monolithic خیلی آسان‌تر است به دلیل کوچکتر بودن اجزا، پیدا کردن و رفع مشکلات در هریک از این کامپوننت‌ها بسیار آسان‌تر می‌شود.مشکلات رایج در معماری میکروسرویسخوب در هر معماری یک سری از مشکلات وجود دارد و میکروسرویس‌ها هم از این قاعده مستثنی نیستند.پیچیدگیپیچیدگی یکی از بزرگترین اثرات جانبی این معماری است. درحالی که میکروسرویس‌ها می‌توانند پیچیدگی‌های دومین را با شکستن به سرویس‌های کوچکتر کاهش دهند، ولی از سمت دیگر منجر به ایجاد پیچیدگی‌های خاص خود از لحاظ سیستم‌های توزیع یافته می‌شوند، که موارد زیر را به همراه دارد:استک‌های استفاده شده مختلف در هریک از اجزای سیستم، تیم اجرایی رو مجبور می‌کند تا زمان بیشتری رو صرف یادگیری این زبان‌ها کنند.اسکیل کردن خیلی موثر‌تر است، اما به امکانات پیشرفته‌تری مانند Service Discovery،DNS Routing و دیگر امکاناتی از این دست نیاز خواهد بود.ارتباط بین اجزای سیستم ممکن است به سیستم‌های پیام‌رسان نیاز داشته‌باشد (Queue, Pub/Sub, Event Store )تراکنش‌ها در این سیستم توزیع یافته پیچیده‌تر است، هرگونه Rollback در این سیستم‌ها به دلیل نیاز به انجام Rollback در بانک‌های اطلاعاتی مختلف در سرویس‌های مختلف می‌توانند پیچیدگی و احتمال ایجاد خطا در آن‌ها بالاتر ببرند.بارگذاری کل نرم‌افزار روال پیچیده‌تری است، پیچیدگی‌هایی مثل کار با Container ها و Orchestration و مجازی‌سازی اضافه می‌شود.به زیر ساخت‌های پیچیده‌تری نیاز داریم‌،‌ در اغلب موارد به کانتینرها (Docker) و سیستم‌های Orchestration مانند Kubernetes نیاز پیدا می‌کنیم.تست‌های Integrationانجام تست‌های End-to-End و Integration Tests به دلیل وجود بخش‌های مختلف، و ارتباطات پیچیده‌تر بین آن‌‌ها پیاده‌سازی زیرساخت‌های تست و بروز نگهداری آن‌ها خیلی مشکل‌تر خواهد بود.اندازه تیم و تجربه آن‌هااستک فنی مورد استفاده در میکروسرویس‌ها پیچیده‌تر هستند و یادگیری ‌آنها مشکل‌تر است و در نتیجه تیم با تجربه‌تری و به تعداد بیشتری از افراد با مجموعه توانایی‌های Senior-level در مقایسه با یک سیستم Monolithic نیاز است. در این حالت شما تیم بزرگتری برای نگهداری نرم‌افزار خود نیاز دارید. زیرا تکنولوژی‌ها و کامپوننت‌های بیشتری وجود دارند.پیاده سازی Feature هایی که منجر به تغییر در سیستم‌های مختلف هستند زمان بیشتری نیاز دارند زیرا زمان بیشتری صرف توافق در مورد قراردادها و API ها خواهد شد.با وجود اینکه اعضای تیم بسته به کامپوننتی که روی آن کار می‌کنند، Skill set گسترده‌ای دارند ولی لزوما دید کلی و جامعی بر کلیت Application ندارند و ممکن است برطرف کردن نیازهای کسب و کار و یا پیدا کردن و رفع مشکل‌هایی را که از ارتباط بین اجزا بوجود آمده‌اند، سخت تر کند.سربارمیکرو سرویس‌های پیچیده، به دلیل پیاده‌سازی روال‌های مانیتورینگ، سیستم‌های پیام رسان، Orchestration و سرویس رجیستری و مواردی از این دست کار سربار بیشتری داشته باشند.توسعه اولیه سیستم ممکن است به دلیل این پیچیدگی‌ها طولانی‌تر باشد و زمان رسیدن به بازار محصول را به عقب بندازد.هزینه اولیه زیر ساخت ممکن است نسبت به معماری Monolithic خیلی بیشتر شود.در ساختارهای میکروسرویس، همیشه مقداری از تکرار کد بین چند سرویس وجود دارد که می‌تواند به عنوان یک سربار در نظر گرفته‌شود.کی نباید از معماری میکروسرویس استفاده کرد‌؟به یاد داشته باشید تا زمانی که مجبور نشدید، از این معماری نباید استفاده کنید. هر نرم‌افزاری نیازمندی‌های Scaling در حد Google،‌Netflix، Amazon و یا Spotify را ندارد. خیلی از منافع میکروسرویس‌ها برای این مجموعه‌ها به دلیل شرایط خاص Scaling آنهاست که شاید برای شرایط شما اصلا محلی از اعراب نداشته باشد.برخی از دلایلی که شاید برای شما بهتر است به ساختارهای Monolithic بچسبید:اگر اسکوپ نرم‌افزار شما کوچک است و قرار نیست در زمان کوتاه به اندازه‌های مثل شرایط فعلی آپارات برسید. برای نرم‌افزارهای با کاربرد مشخص که به خوبی تعریف شده‌باشند، استفاده از monolith همیشه بهترین گزینه هستد مثل:نرم افزار CRUD محوری برای استفاده داخلی شرکتنرم افزارهای کوچک با حوزه استفاده خیلی مشخص، مثل یک سایت فروش آنلاین برای حوزه خاصی از محصولاتوقتی زمان رسیدن محصول به بازار برای نرم‌افزار جدید خیلی حیاتی باشد، باید بدانید که زمان Time to Market برای معماری میکروسرویس‌ها طولانی‌تر خواهند بود.وقتی اندازه تیم شما کوچک یا متوسط است و تجربه تیم کمتر از استاندارد باشد، بهترین گزینه استفاده از monolith خواهد بود.وقتی بودجه زیر ساخت شما محدود باشد. اگر چه در طول زمان شما با استفاده از میکروسرویس‌ها در هزینه صرفه‌جویی می‌کنید ولی باید بدانید که هزینه‌های شروع، خیلی بیشتر هستند.از همه مهتر، هیج وقت میکروسرویس را به دلیل روی بورس بودن و استفاده آن در شرکت های بزرگ و یا پیشنهاد از یک آدم معروف انتخاب نکنید(در یک کلام جو نگیرتتون ). برای خیلی از کاربردها هنوز هم مونولیت‌ها راهکار خیلی خوبی هستند. شما می‌توانید با مونولیت شروع کنید و در ادامه در صورت نیاز آن را با میکروسرویس بشکنید. به یاد داشته باشید اکثر نام‌های بزرگ صنعت بعد از تجربه ۲ تا ۳ باز refactor کردن کد بیس‌های مونولیت، سراغ استفاده از میکروسرویس رفته‌اند.کی باید سراغ معماری میکروسرویس برویم‌؟‌به طور کلی، میکروسرویس‌ها می‌توانند وقتی مفید باشند که شما یکی از سناریوهای زیر را داشته باشید.وقتی دومین‌ کار شما خیلی پیچیده باشد و تیم بزرگ و با تجربه‌ای دارید در این صورت تکه تکه کردن دومین به میکروسرویس‌ها، کار را برای شما آسان‌تر می‌کند.وقتی شما انتظار دارید فیسبوک، نتفلیکس و یا توییتر بعدی، از لحاظ فشار کاربران باشید، به عبارت دیگر وقتی رشد نمایی کاربران را انتظار دارید.اگر نرم افزار شما به عنوان SaaS قرار است تامین کننده API برای نرم افزارهای دیگری با تعداد کاربر بالا باشد. مانند درگاه‌های پرداخت، درگاه‌های ارسال پیام کوتاه و...وقتی شما یک نرم‌افزار تجارت الکترونیک با تعداد کاربران خیلی بالا و با بار نا‌متعادل روی بخش‌های مختلف سیستم خود هستید، باید سراغ میکروسرویس‌ها بروید.( دفعه بعدی که یکی از فامیل ازتون پرسید یه سایت مثل آپارات و دیجیکالا میخوام و انقدر پول داشت و گیر بود که حتما خواست اینکار رو بکنه سراغ میکروسرویس نرو برادر من!)نتیجه گیریبه طور کلی، هیچ وقت یک الگوی معماری را صرف اینکه در جایی کار کرده، انتخاب نکنید. الگویی را انتخاب کنید که برای use case و نیازهای scaling شما مناسب باشد. همه قرار نیست مثل آپارات میلیون‌ها درخواست هم‌زمان کاربران را مدیریت کنند و یا چندین ترابایت از اطلاعات را استریم کنند.

الگوی OUTBOX برای تبادل داده‌ها در میکروسرویس‌ها

سپیده منفرد — Tue, 01 Sep 2020 16:05:34 +0430

outbox patternبا پیشرفت فضای آنلاین و گسترش نرم‌افزارهای پیچیده, معماری‌های مختلفی برای مدیریت پیچیدگی‌ها در طراحی نرم‌افزارها بوجود آمده‌است. یکی از محبوب‌ترین این معماری‌ها، معماری میکروسرویس است که امروزه بسیاری از سیستم‌های بزرگ با تعداد کاربر بالا از آن استفاده می‌کنند. در این مدل معماری، سیستم را براساس برخی ویژگی‌های منتخب به سرویس‌های کوچک با وظایف مستقل تقسیم می‌کنند، که باید طبق پروتکل‌های مشخصی با هم در ارتباط باشند و از آخرین تغییرات همدیگر مطلع شوند بنابراین سرویس‌های مرتبط، تغییرات را باید به یکدیگر اطلاع‌رسانی کنند. فرض کنید یک سرویس موفق به اطلاع‌رسانی به سرویس‌های دیگر نشود و نتواند تغییرات اعمال‌شده در داده‌ها را به آن‌ها اطلاع دهد، در این صورت یکپارچگی داده‌ها در کل سیستم تحت تاثیر قرار می‌گیرد و مشکلاتی را با خود به همراه دارد. در راستای این مشکلات تصمیم گرفتم در این مقاله، الگوی outbox را که تبادل داده‌ها بین سرویس‌ها را تضمین می‌کند، بررسی کنم.مهمترین و شاید دشوار‌ترین بخش در مورد معماری میکروسرویس‌ها مدیریت و تبادل داده‌ها است میکروسرویس‌ها نیاز دارند برای حفظ یکپارچگی داده‌ها، هم‌زمان با بروزرسانی پایگاه داده رویداد یا پیام ارسال کنند، اما سوالی که پیش می‌آید این است که: چطور می توانیم مطمئن شویم که در یک میکروسرویس رویداد(Message/Event)های حاصل از تغییرات، حتما ارسال و تبادل داده‌ها به درستی انجام شده است؟سرویس‌ها اغلب رویدادها را بعد از اتمام تراکنش دیتابیس(Transaction) منتشر می‌کنند، در واقع انجام تراکنش دیتابیس و ارسال رویدادها دو عملیات متفاوت است و باید به شکل اتمی انجام گیرد، چراکه انجام یک تراکنش و عدم انتشار رویداد(Event/Message) می‌تواند یکپارچگی داده‌ها را دچار مشکل کنند. در نتیجه برای جلوگیری از ناسازگاری داده‌ها، به‌روزرسانی پایگاه داده و ارسال پیام باید اتمی باشد. بنابراین، در فراخوانی یک سرویس برای انجام یک فرآیند مشخص، کلاینت یا سرویس‌گیرنده به طور کلی انتظار دارد که سرویس‌دهنده درخواست HTTP را به شکل اتمی(Atomic Transaction) انجام دهد. درخواست‌های HTTP درست همانند تراکنش‌های دیتابیس، انجام یک کار مشخصی در یک واحد(Transactional Unit Of works) با یک آغاز و پایان و نتیجه مشخص هستند، برای توضیح بهتر ما به یک سرویس نمونه خواهیم پرداخت تا ببینیم که چگونه درخواست‌های HTTP و Transaction ها به خوبی روی یکدیگر تطبیق داده می‌شوند و با کمک ACID یک Unit of work را می سازند.سرویس ساده ثبت‌نام کاربر با ایمیلحالا یک سرویس تست ساده با یک EndPoint برای ایجاد کاربر می‌سازیم که کلاینت با پارامتر ایمیل آن را فراخوانی می‌کند و سیستم برای کاربری که می‌سازد با Status ‌Code 201 پاسخ می‌دهد، همینطور در نظر داریم که API ما Idempotent است و زمانی که کلاینت درخواست تکراری با پارامترهای قبلی ارسال می‌کند با پاسخ OK 200 (همه چیز مرتب است) و پیغام "کاربر قبلا ثبت نام کرده‌است" مواجه می‌شود.POST /users?email=jane@example.comحال ما قصد داریم برای پیاده سازی ۳ مورد زیر را انجام دهیم :در صورتی که کاربر موجود باشد ادامه نمی‌دهیم.برای کاربر جدید رکورد ثبت می‌کنیم .یه لاگ از ثبت کاربر جدید با 'شناسه کاربری' و 'زمان' ثبت می‌کنیم.ساختار جدولCREATE TABLE users(id BIGSERIAL PRIMARY KEY,email TEXT NOT NULL CHECK (char_length(email) <= 255));-- our "user action" audit logCREATE TABLE user_actions(id BIGSERIAL PRIMARY KEY,user_id BIGINT NOT NULL REFERENCES users (id),action TEXT NOT NULL CHECK (char_length(action) < 100),occurred_at TIMESTAMPTZ NOT NULL DEFAULT now());پیاده سازیطبق نمونه کد پیاده‌سازی، بررسی می‌کنیم:اگر کاربر موجود باشد، پس فورا پاسخ را به کلاینت ارسال می‌کنیماگر کاربر جدید باشد، کاربر و لاگ را ایجاد و پاسخ را به کلاینت ارسال می‌کنیم.در هر دو حالت تراکنش با موفقیت کامیت می‌شود:POST "/users/:email" do |email| DB.transaction(isolation: :serializable) do user = User.find(email) halt(200, 'User exists') unless user.nil? #create the user user = User.create(email: email) #create the user action UserAction.create(user_id: user.id, action: 'created') #pass back a successful response [201, 'User created'] #Commit End #enqueue a job to tell an external support service, #that a new user's been created enqueue(:create_user_in_support_service, email: email) Endو SQL تضمین می‌کند که درج موفقیت آمیز انجام می‌شود به تصویر زیر توجه کنید:START TRANSACTION ISOLATION LEVEL SERIALIZABLE; SELECT * FROM users WHERE email = 'jane@example.com'; INSERT INTO users (email) VALUES ('jane@example.com'); INSERT INTO user_actions (user_id, action) VALUES (1, 'created'); COMMIT;هم زمانی و محافظت از داده‌هادر نگاه اول ممکن است این سوال پیش بیاید که چرا فیلد ایمیل UNIQUE در نظر گرفته نشده است؟ اگر دقت کنید برای جلوگیری از درج تکراری داده‌ها مدل ("isolation (ACID's "I از نوع SERIALIZABLE در نظر گرفته شده‌است، این مدل تضمین می‌کند تراکنش‌ها یکی پس از دیگری انجام می‌شود و به طور همزمان انجام نخواهند شد و در صورت بروز هم زمانی فقط یکی از تراکنش‌ها موفق خواهد بود. اگرچه که این روش، شما رو از درج تکراری داده‌ها محافظت می‌کند اما اضافه کردن UNIQUE هم به عنوان یک محافظ دیگر، از داده‌های شما در برابر درخواست‌های تداخلی و همزمان و همچنین باگ‌ها محافظت می‌کند که بهتر است در نظر گرفته‌شود.به طور کلی برای کنترل هم‌زمانی بهتر است isolation-level تراکنش‌های دیتابیس را هم در نظر بگیرید. در نتیجه با در نظر گرفتن قوانین بالا در صورت بروز هم‌زمانی دو تراکنش که در آن نتیجه یکی از تراکنش‌ها، دیگری را تحت تاثیر قرار دهد، یکی از آن دو ناموفق و Rollback خواهد شد.ارسال رویدادحالا بعد از درج موفق دیتا قصد داریم با ارسال یک پیام به سرویس دیگر آن را از تغییرات دیتا با خبر کنیم به این شکل که رویداد مورد نظر را به صف ارسال می‌کنیم، سرویس‌های دیگر رویداد‌ها را از صف(MessageBroker) برداشته و پردازش می‌کنند و از تغییرات داده‌ها مطلع می شوند.Service(Publisher) ---Publish---> MessageBroker ---Consume----> Service(Consumer)چه زمانی رویداد را به صف ارسال کنیم؟فرض کنیم که دقیقا بعد از کامیت شدن تراکنش دیتابیس و اعمال تغییرات داده‌ها، Event یا رویداد مربوط به اضافه‌شدن کاربر جدید را ارسال کنیم(مطابق شکل زیر) چه اتفاقی می‌افتد؟در واقع بعد از اجرا شدن خط ۱۲ از نمونه کد بالا و مرحله ۳ که در تصویر مشاهده می‌کنید، تراکنش ما کامیت شده و در خط بعد (مرحله ۴) ما قصد داریم رویداد خود را ارسال کنیم .تصویر شماره ۱ : ارسال رویداد پس از انجام تراکنشممکن است با دو مشکل مواجه شویم:سیستم بعد از کامیت شدن تراکنش و دقیقا قبل از ارسال رویداد دچار مشکل شود!لحظه ی ارسال رویداد(Message Broker) شما برای لحظاتی از دسترس خارج شده و سرویس شما موفق به ارسال رویداد نشده‌است!در نتیجه هر ۲ اتفاق تراکنش ما انجام و کاربر جدید با موفقیت ثبت می‌شود اما اطلاع‌رسانی انجام نمی‌شود!راه حل: اگر ما عملیات ارسال رویداد را قبل از پایان تراکنش(کامیت) انجام دهیم چه اتفاقی می افتد؟POST "/users/:email" do |email| DB.transaction(isolation: :serializable) do ... #enqueue a job to tell an external support service #that a new user's been created enqueue(:create_user_in_support_service, email: email) ... #commit End Endدر این حالت، در صورت rollback شدن تراکنش(مانند حالتی که بالاتر توضیح داده شد)، یک رویداد ارسال می‌شود که در واقع به ازای آن تغییری روی دیتابیس وجود ندارد!!برای افزایش قابلیت اطمینان سیستم، چه کاری می‌توانیم انجام بدهیم؟در الگوی Outbox به جای اینکه رویدادها مستقیم به صف ارسال شوند، یک جدول در دیتابیس در نظر گرفته‌می‌شود و رویدادها در محدوده تراکنش در جدول outbox ذخیره شده و ارسال نمی‌شوند، که در خط ۱۵ نمونه کد زیر در مرحله سوم در تصویر شماره ۲ قابل مشاهده‌است.CREATE TABLE outbox ( id BIGSERIAL PRIMARY KEY, job_name TEXT NOT NULL, job_args JSONB NOT NULL ); POST "/users/:email" do |email| DB.transaction(isolation: :serializable) do user = User.find(email) halt(200, 'User exists') unless user.nil? #create the user user = User.create(email: email) #create the user action UserAction.create(user_id: user.id, action: 'created') #saving data to OUTBOX Outbox.create( user_id: user.id, action: 'create_user', status:'pending') #pass back a successful response [201, 'User created'] #commit End Endتصویر شماره ۲: ذخیره رویداد در جدول outbox به عنوان بخشی از تراکنشهمانطور که مشاهده می‌کنید، ذخیره رویداد در جدول outbox به عنوان بخشی از تراکنش در نظر گرفته شده‌است، در این صورت مطمعن هستیم که در صورت موفق بودن و انجام شدن تراکنش، شما حتما یک رویداد ذخیره شده در جدول outbox خواهید داشت. حالا فقط به یک job یا enqueuer نیاز داریم تا رویداد‌ها از outbox را به صف ارسال کند، در واقع یک فرآیند جداگانه ایجاد می‌کنیم که محتوای outbox را پردازش و پس از ارسال هر رویداد به صف(MessageBroker) آن را علامت گذاری می‌کند تا از ارسال مجدد رویدادهای ارسال‌شده به صف، جلوگیری کند، اگرچه بروز خطا در ارتباط با outbox ممکن است منجر به ارسال مجدد رویدادها شود که در ادامه به شرح آن می پردازیم.تصویر شماره ۳: فرآیند ارسال رویدادها از جدول outboxچگونه ممکن است رویدادها بیش از یکبار ارسال شوند؟همانطور که در تصویر شماره ۳ می‌بینید، فرض کنید توسط فرآیند جدید ایجاد شده(Job)، یکی از رویدادهای جدول outbox را پردازش و آن را به صف(MessageBroker) ارسال کردیم، حالا باید آن را در جدول علامت‌گذاری کنیم و status آن را تغییر دهیم تا از ارسال مجدد آن جلوگیری نماییم ،اگر در همین لحظه ارتباط ما با جدول outbox قطع شود، رویداد علامت‌گذاری نشده باقی می‌ماند و سیستم آن را ارسال‌نشده در نظر می‌گیرد در حالی که در حقیقت ارسال شده‌است، و پس از برقراری، رویداد مجددا ارسال می‌شود، در واقع این الگو تضمین می‌کند که رویدادها حتما یک بار ارسال می‌شوند اما ممکن است بیش از یکبار ارسال شوند.توجه کنید:میکروسرویس دریافت‌کننده رویداد‌ها از صف یا همان consumer (که رویداد‌های ارسالی شما را از صف برداشته و پردازش می کند)، حتما idempotent باشد به این معنی که با تکرار یک درخواست(پردازش رویداد تکراری)، سرویس دچار مشکل در اجرای فرآیند نشده و همواره نتیجه یکسانی داشته باشد.اگرچه به طور کلی در استفاده از Message Broker ها، سرویس‌های دریافت‌کننده پیام یا همان Consumerها باید Idempotent باشند چراکه حتی اگر شما یکبار پیام را به صف ارسال کرده‌باشید ممکن است آن ها پیام شما را بیش از یک بار به Consumer ارسال کنند و اغلب At-Least-Once Delivery هستند، آن‌ها فقط تضمین می‌کنند که پیام شما حتما یک بار را ارسال شود اما تضمین نمی‌دهند که فقط یک بار ارسال شود.در پایانبا توجه به استفاده گسترده از معماری مایکروسرویس‌ها و مشکلات بروزرسانی داده‌های آن‌ها، الگوی outbox می‌تواند به عنوان یک مدل قابل اعتماد برای تبادل داده‌ها مورد استفاده قرار بگیرد و در صورتی که Message-Broker شما به هر دلیلی (به روز رسانی،بروز مشکل، restart و ...)از دسترس خارج شود این الگو این اطمینان را به شما می‌دهد که Event(رویداد)های شما از دست نرفته و در outbox موجود است و بعدا با استفاده از یک job پردازش شده و ارسال خواهند شد. برای پیاده سازی آن می توانید از MessageBrokerهای قابل اعتمادی همچون Apache Kafka, RabbitMQ استفاده کنید.