دسته بندی: 

طراحی خوب چیست؟ شاید پاسخ این سوال در اعداد نهفته باشد نه در خلاقیت. Michel Ferreira با نگاه عمیق‌تری به تست A/B می‌پردازد

احتمالا چیزهایی درباره‌ی تست‌های A/B شنیده یا خوانده‌اید. هرچند مثل اغلب چیزهایی که ما به شکل آن‌لاین مشاهده می‌کنیم سوء‌تفاهم‌های زیادی وجود دارد. در این مقاله من قصد دارم نگاهی به بهترین روش‌های تست A/B، اشتباهات رایج و این که آزمایش و تجربه چگونگه می‌تواند مهارت‌های شما را به سطح بالاتری رهنمون شود بیندازم. بیایید همه‌ی چیزهایی که قبلا می دانستیم فراموش کرده و کارمان را از ابتدا آغاز کنیم. یک تست A/B مقایسه‌ای اتفاقی از دو نسخه از یک صفحه‌ی وب است. این بدان معنا است که 50 درصد از ترافیک شما به شکل اتفاقی با نسخه‌‌ی A صفحه‌ی وب و 50 درصد دیگر با نسخه‌ی B تست می‌شود. ما از یک کنترل (نسخه‌ی A) برای مقایسه‌ با یک واریاسیون (نسخه‌ی B)، که پیش‌بینی می‌نمائیم تاثیری بر روش اندازه‌گیری ویژه‌ی ما دارد استفاده می‌کنیم. این روش‌های اندازه‌گیری می‌توانند هر چیزی، از نرخ تبدیل یا زمان صرف شده برروی صفحه تا تعداد کلیک‌ها یا مدت زمانی که یک وظیفه به اتمام می‌رسد باشد. برای نمایش این‌، من کارم را با یک مثال ساده آغاز می‌کنم. یک صفحه‌ی landing دربردارنده‌ی یک فراخوان آبی برای یک اَکشن است. این کنترلی است که تست ما براساس آن انجام می‌گیرد. در نسخه‌ی واریاسیون، این فراخوانی به رنگ سبز تغییر پیدا خواهد کرد. یک تست A/B اجرا خواهد شد و پس از آن داده‌ها به ما نشان خواهند داد که آیا هر یک از نسخه‌ها یک تاثیر مثبت یا منفی دارند. هرچند، اگر این تست را بدون فرضیه انجام داده و تلاش کرده باشید داده‌ها را مشاهده نمائید در بسیاری از روش‌های اندازه‌گیری تفاوت‌های زیادی را دیده‌اید. متاسفانه این به شما کمک نمی‌کند هیچ چیزی را اثبات کنید. بهترین راه به دست آوردن نتایج خوب و قابل اطمینان با توسعه‌ی آزمایش و تجربه‌تان با روش اندازه‌گیری دقیقی که در سر دارید حاصل می‌شود. در این مورد خاص، فرضیات شما می‌تواند این باشد که انتظار دارید دکمه‌ی سبز درصد بیش‌تری از کلیک‌ها را در مقایسه با دکمه‌ی آبی دریافت کند. بیایید در این موضوع دقیق‌تر شویم.

طراحی آزمایش‌ها

من به عنوان طراح در Booking.com کار می‌کنم، جایی که گاهی اوقات درباره‌ی این که طراحان ما باید designentists (دانشمند علم طراحی) باشند با دیگران شوخی می‌کنم. دقیقا به همین علت است که ما به تست هر چیزی که می‌سازیم به شدت باور و اعتقاد داریم. ما این کار را از طریق چیزی که design of experiments (طراحی آزمایش‌ها)  یا DOE نام دارد انجام می‌دهیم. این یک روش سیستماتیک برای مشخص کردن رابطه‌ی بین عواملی که بر یک فرآیند اثر می‌گذارند و خروجی آن فرآیند است. به عبارت دیگر، از این برای پیدا کردن ارتباطات علت-تاثیر استفاده می‌کنیم. با استفاده از DOE، ما از آزمایش‌هایی برای تست یک ایده و برای حصول اطمینان از این که تاثیر آن‌ها به صورت شانسی یا به علت وجود عوامل خارجی ایجاد نشده است استفاده می‌کنیم. از آن جایی که ما دانشمند علم دیتا نیستیم شاید فکر کنید DOE بیش از حد پیچیده است. اما هر آزمایشی را می‌توان فقط با دنبال کردن پنج گام زیر طراحی کرد:

  • مشاهده کنید.
  • یک فرضیه ایجاد نمائید.
  • برای تست فرضیه‌ی خود، یک آزمایش طراحی و اجرا کنید.
  • نتایج آزمایش را ارزیابی کنید.
  • فرضیه‌ی خود را قبول یا رد کنید.

بیایید با جزئیات بیش‌تری هر یک از این گام‌ها را بررسی نمائیم.

مشاهده کنید

ما کارمان را با مشاهده‌ی رفتار کاربر ، یا از طریق تحقیق برروی کاربر و یا با نگاه کردن به داده‌هایی که از طریق وب سایت گردآوری نموده‌ایم آغاز می‌کنیم. شما می‌توانید داده‌های تاریخی را به منظور مشاهده‌ی گرایش‌های رفتاری مشتریان خود بازبینی و بررسی کنید، یا به Google Analytics و هر نوع ابزار دیگری که در دسترس دارید نگاه کنید. تلاش کنید نقاط مشکل‌ساز کاربر یا هر چیز دیگری که باورد دارید می‌تواند تجربه‌ی کلی آن‌ها را ارتقا ببخشد شناسایی نمائید.

یک فرضیه ایجاد کنید

فرضیات می‌توانند ایده‌های ساده‌ای مثل "اگر ما کپی دکمه‌ی Register را تغییر دهیم انتظار داریم کاربران به علت این که درک پیام جدید بسیار ساده‌تر می‌شود حساب‌هایی ایجاد کنند" و یا "اگر ما سایز یک دکمه‌ را افزایش دهیم کاربران بیش‌تری را وا می‌داریم تا خرید خود را تکمیل کنند زیرا این کار خوانایی دکمه را افزایش می‌دهد" باشند. شما می‌توانید آزمایش‌های خود را با هر چیزی که دوست دارید انجام دهید، البته تا وقتی که بتوانید آن را اندازه‌گیری نمائید. بنابراین توسعه‌ی تکنیکی چه می‌شود؟ "اگر ما تصویر اضافی را از یک صفحه حذف کنیم، زمان بارگزاری را کاهش می‌دهیم، کاربر را تشویق می‌کنیم سبد خرید را سریع‌تر تکمیل کند و تبدیل را افزایش دهد". وقتی ایده‌ها را فرموله می‌کنید، داشتن دلیلی روشن و واضح برای تغییر اهمیت زیادی دارد. بهترین روش شما تست سوال‌های "SMART" است: آن‌هایی که مهم، قابل اندازه‌گیری، قابل دسترس، مبتنی بر نتایج و محدود به زمان هستند. با استفاده از سوال‌های SMART (هوشمند)، شما پاسخ‌های بهتری دریافت می‌کنید. و این پاسخ‌ها در آخر اهمیت زیادی پیدا می‌کنند.

ایده‌ی خود را طراحی و ایجاد کنید

شما باید تست خود را اجرا و منتشر کنید. من در این مقاله طراحی را به شما آموزش نمی‌دهم اما اشاره می‌کنم که اجرا می‌تواند آزمایش شما را بسازد یا خراب کند. انتخاب چیزی که بتوانید اندازه‌گیری کنید، با احتمال بالایی از تاثیر، واقعا می‌تواند تفاوت ایجاد کند. اگر کار را با قبول این که اکثر آزمایش‌ها شکست می‌خورند شروع کنید، قادر خواهید شد تست‌های بیش‌تر و سریع‌تری ایجاد کرده و از شکست‌های خود درس یاد بگیرید.

نتایج را ارزیابی کنید

برای کمک به توسعه‌ی آزمایش‌های قدرتمند، به کمی درک و آگاهی درباره‌ی سایز نمونه و سایز موثر احتیاج دارید. هر چه سایر نمونه بزرگ‌تر باشد زمان کم‌تری صَرف دستیابی به اعتماد برروی اهمیت آماری فرضیه‌ی شما می‌شود. اگر تاثیر اندکی وجود داشته باشد (مثلا یک دهم درصد افزایش در نرخ تبدیل) شما به یک سایز نمونه‌ی بسیار بزرگ برای مشخص کردن این که تفاوت‌ها بزرگ هستند یا به واسطه‌ی شانس رخ می‌دهند نیاز دارید. تاثیرات بزرگ‌تر می‌توانند با یک سایز نمونه‌ی کوچک‌تر ارزیابی شوند. اما نکته‌ی دیگری هم وجود دارد. شما اعداد و هر چیز دیگری که نشان می‌دهد فقط به یک هفته نیاز دارید چک کرده‌اید-بیایید آن را سیکل کاری بنامیم- تا با اطمینان مورد نیاز به نتایج دست پیدا کنید (شما می‌توانید از ماشین‌ حساب‌های آن‌لاین برای مشخص کردن آن استفاده کنید: netm.ag/calculate-286). اما ماشین حساب فقط به اعداد نگاه می‌کند. سپس من این سوال را می‌پرسم: آیا می‌توانید به یاد بیاورید روز جمعه چه اتفاقی رخ داد؟ حالا این را با پنجم آگوست 2016، اولین روز المپیک تابستانی در ریو مقایسه کنید. آیا فکر می‌کنید رفتار مشتریان وب سایت شما با آن زمان مشابه خواهد بود؟ پاسخ کوتاه: نه است. رفتار کاربران با اَشکال غیر منتظره‌ و  رویدادهای طرح‌ریزی شده و طرح‌ریزی نشده تحت تاثیر قرار می‌گیرد. و به همین علت، شما باید آزمایش‌های خود را حداقل در دو سیکل کاری کامل اجرا کنید. با این روش، شما نه تنها به یک نمونه‌ی بزرگ‌تر دست پیدا می‌کنید بلکه چنان‌چه اتفاق کاملا غیر مترقبه‌ای در هفته‌ای که تست خود را اجرا می‌کنید رخ دهد می‌توانید اصول بنیان‌گذاری شده‌ی خود را تحت پوشش بگیرید. قبل از این که سیکل آزمایش به پایان برسد آن را متوقف نکنید و همیشه آن را در سیکل‌های کامل اجرا نمائید (دو هفته‌ یا ماه کاری کامل). برای انجام آزمایش‌های معتبر، شما در عین حال باید اطمینان حاصل کنید که هر دو نسخه‌ی صفحه‌تان را به طور همزمان و با کاربران اتفاقی اجرا می‌کنید و نه به شکل نسخه‌ی A برای 100 درصد ترافیک و سپس نسخه‌ی B برای 100 درصد ترافیک. این بدان معنا است که شما راه‌حل خود را در مقابل دو مبنای کاربری متفاوت اجرا می‌کنید و نتایج واقعی را به دست نمی‌آورید.

داده‌ها صحبت نمی‌کنند

وقتی سوال‌های خود را توسعه می‌دهید، این نکته را در نظر بگیرید که این سوال‌ها چگونه موفقیت‌شان را اندازه‌گیری خواهند کرد زیرا وقتی زمان تحلیل داده‌ها فرا می‌رسد، پاسخ‌ها نمی‌توانند تشریحی باشند. همه‌ی چیزی که می‌بینید "بله"، "نه"، یا "خداحافظ" (نتایج بی‌ معنی) خواهد بود. از خودتان بپرسید آیا سوال شما می‌تواند به راحتی و از طریق این عکس‌العمل‌ها پاسخ داده شود؟ به عنوان مثال، بیایید فرض کنیم شما می‌پرسید:"آیا آیکون یک منوی همبرگری برای وب سایت من بهتر از "منوی" حرفی کار می‌کند؟" با بررسی داده‌ها شما "نه" را مشاهده می‌کنید. آیا می‌توانیم سوال بهتری مطرح کنیم که درک پاسخ آن ساده‌تر باشد؟ بیایید همین سوال مشابه را با استفاده از فرمت SMART فرموله کنیم و چند هدف قابل اندازه‌گیری اضافه نمائیم. نظرتان درباره‌ی این چیست: براساس داده‌های گردآوری شده، ما اعتقاد داریم آیکون منوی همبرگری برای کاربران ما بد است و از حرکت مناسب در اَکشن‌های ثانویه‌ی وب سایت ما جلوگیری می‌نماید. ما این را با فرض این که درک یک نسخه‌ی جدید با "منوی" حرفی به جای آیکون همبرگری ساده‌تر است و استفاده از منو را ارتقا می‌بخشد (کلیک برروی منو و کلیک برروی همه‌ی لینک‌های درون آن منو) تست کردیم. آیا این نشان‌گر یک پیشرفت یا تفاوتی مثبت است؟ آیا تاثیری منفی بر چیزی که هدف شما بوده دارد؟ یا هیچ نتیجه‌ی مهمی را نشان نمی‌دهد، و باعث بی‌معنی شدن نتایج می‌شود؟ یک اشتباه رایج، باور این است که نتایج بی‌معنی بدان معنا است که تاثیری خنثی وجود دارد و در نتیجه باید آن را یک تغییر قابل قبول در نظر گرفت. هوشیار باشید: این واقعیت که شما نمی‌توانید یک واریاسیون را ببینید به این معنا نیست که آن ویژگی قابل قبول یا برای کاربران شما بهتر است. این فقط بدان معنا است که شما نمی‌توانید تاثیر چیزی که تست می‌کنید اندازه‌گیری نمائید. شما یا می‌خواهید راه‌حل را بازبینی کنید و ببینید آیا روش‌های دیگری برای مشکل وجود دارد، یا کل آن ایده را به دست فراموشی می‌سپارید.

در برخی از موارد، شما تفاوتی در اندازه‌گیری‌هایی که مرکز توجه شما نیستند مشاهده می‌کنید. تلاش کنید بفهیمد چرا این رخ می‌دهد. اگر یک تاثیر منفی وجود دارد، علت آن واضح و روشن است؟ به عنوان مثال، بیایید فرض کنیم شما تلاش کردید فروش‌ها را از طریق انتقال disclaimerها به یک برگه‌ی جدید برروی صفحه‌ی محصول افزایش دهید اما حجم عظیمی از کالاهای برگشتی یا لغو خریدها را مشاهده کردید. بیایید فرض کنیم شما یک آیتم navigation برروی یک هِدِر وب سایت را تغییر داده‌اید و کاربران جدید فرم‌های نظرسنجی را بیش‌تر پُر می‌کنند. در این مورد خاص، طراحی شما کلید درک چیزی که داده‌ها می‌گویند به شمار می‌رود. این مثل تلاش برای درک چیزی که کاربران شما می‌گویند، فقط با نگاه کردن به زبان بدن آن‌ها است. از این مهم‌تر، هیچ تاثیر مثبتی را فقط به علت این که مثبت است قبول نکنید، خصوصا اگر برای‌تان بدیهی و روشن یا مربوط به فرضیات‌تان نباشد (هری، معجزه وجود ندارد). مطمئنا شما به دنبال مثبت بودن نتایج‌تان هستید اما مهم‌تر این است که باید به دنبال دُرُست بودن آن نتایج باشید.

در Booking.com، ما وب سایت خود را با گام‌های کوچک بهینه می‌کنیم. اما نه به علت این که می‌خواهیم اسیر تمام جزئیات کوچک شویم؛ ما می‌خواهیم گام‌های قابل اندازه‌گیری داشته باشیم که وقتی معتبر می‌شوند ما را به بهتر ساختن محصول هدایت می‌نمایند. به جای ارتقای 10 درصدی چیزی (که واقعا در یک وب سایت با فعالیت فوق‌العاده زیاد دشوار است)، ما برای ارتقای کسری از یک درصد هزاران نکته را بررسی می‌کنیم. این قابل دسترس و ساده‌تر است. تلاش نکنید در هر زمان بیش‌تر از یک چیز را بهینه نمائید. این کار نه تنها نتایجی ایجاد نمی‌کند، اما وقتی هم این کار را بکند، دانستن علت و یاد گرفتن از آن غیرممکن است. فرض کنیم شما یک تست اجرا کردید که در آن یک تصویر اضافه نموده و رنگ دکمه را نیز به طور همزمان عوض کرده‌اید، و این نتایج مثبتی ایجاد کرده است. شما نمی‌توانید بفهمید خودِ تصویر یا تغییر رنگ آن چنین تاثیری به وجود آورده و درنتیجه غیرممکن است بتوانید چیزهای جدیدی از این تغییرات فرا بگیرید. با در نظر گرفت این که بیش‌تر تست‌ها با شکست مواجه می‌شوند، اگر به نتیجه‌ای منفی دست پیدا کرده باشید آیا می‌توانید با اطمینان بگوئید که کاربران صفحات را بدون تصاویر و بدون دکمه‌های آبی ترجیح می‌دهند؟ همان‌گونه که Colin McFarland می‌گوید: طراحی یعنی شما دُرُست می‌گوئید. تست یعنی شما غلط می‌گوئید.

پیدا کردن ارزش

چرا تست کردن عامل کلیدی یک طراحی خوب است؟ زیرا "خوب" از هر منظری سوبژکتیو است، اما بدتر از آن، این است که تلاش کنیم "طراحی خوب" را تعریف نمائیم. طراحان درباره‌ی تعدادی از چیزها با هم موافق نیستند و آن‌ها را قبول ندارند. آیا Helvetica یک فونت خوب است یا نه. کاری نکنید که با Comic Sans کارمان را انجام دهیم. این مباحث هرگز پایان نمی‌گیرند و حق با هیچکس نیست. تست A/B، گزینه‌ها را از این معادله حذف می‌کند. شما به ایده‌ای می‌رسید؛ یک حدس عالمانه از چیزی که باور دارید برای کاربران وب سایت شما خوب است. و کاربران پاسخ شما را می‌دهند. این یک دموکراسی متشکل از ایده‌های خوب به شمار می‌رود. ایده‌هایی که اعتقاد دارید ارزش خوبی به اساس کاربری شما اضافه می‌کنند اما درنهایت کاربر است که آن‌ها را قبول یا رد می‌کند. در نتیجه وظیفه‌ی شما استفاده از طراحی خودتان و به کارگیری مهارت‌های حل مشکل برای بهتر ساختن ایده‌های‌تان است. کل هدف فرآیند طراحی شما برای یافتن راه‌حل‌های بهتر درجهت برطرف کردن مشکلات کاربران همواره در حال تغییر و عوض شدن است و پالایش آن ایده‌ها و راه‌حل‌ها، بهترین تجربه‌ی کاربری ممکن را در اختیار کاربران قرار می‌دهد. ساده به نظر نمی‌رسد، این طور نیست؟ اما چه کسی گفته طراحی خوب قرار است ساده باشد؟

چرا تست‌ها شکست می‌خورند؟

Erin Weigel، طراح ارشد در Booking.com

"ما تست کردیم و شکست ‌خوردیم". این بهانه در دنیای تست A/B شایع است اما می‌تواند این واقعیت را نادیده بگیرد که خود یک مفهوم اساسا با اجرای آن مفهوم تفاوت دارد. ایده‌ها اغلب در طول زمان بازتولید می‌شود. آن‌هایی که قبل از این که به عنوان شکست در نظر گرفته شوند شکست می‌خورند و آن‌هایی که هرگز از درگاه جدیدی متولد نمی‌شوند. از آن جایی که Booking.com بیش از 10 سال تجربه در تست A/B دارد، تلاش‌های زیادی در این زمینه انجام داده است. ما بارها و بارها شکست خوردیم و در عین حال پیروزی‌هایی نیز به دست آورده‌ایم، اما همیشه فضایی برای پیشرفت وجود دارد. به همین علت است که عکس‌العمل من در مقابل عباراتی که به مفاهیم صُلب اشاره می‌کنند "OK" است... دقیقا چه کاری انجام داده‌اید و چه زمانی این کارها را کرده‌اید؟ این کنجکاوی از تجربه‌ی من نشات می‌گیرد که براساس آن اعتقاد دارم روش‌های بسیار بیش‌تری برای شکست خوردن در مقایسه با پیروزی وجود دارد. این عقیده‌ای بدبینانه است- اما برای آن دلایل خوبی دارم. من به اندازه‌ی کافی تست انجام داده‌ام، از ایجاد مفهوم و نظریه تا پیاده‌سازی تکنیکی تا درک پیچیدگی که می‌تواند منجر به از بین رفتن ایده‌های خوب شود. در این‌جا به چند نکته اشاره می‌کنم که باعث شکست خوردن یک ایده‌ی خوب می‌شود (شما لیست کامل آن را در netm.ag/fail-286 پیدا می‌کنید):

  • اندکی افزایش در زمان بارگزاری صفحه
  • باگ‌های Edge-case
  • سایز نمونه‌ی پائین
  • ترجمان ضعیف یا انتخاب کپی

یک ضعف عمده در پیاده‌سازی شما می‌تواند تاثیری منفی بر میزان تاثیر مثبت داشته باشد. بنابراین به خاطر داشته باشید یک نتیجه‌ی منفی یا کم اهمیت همیشه به معنای "نه" نیست، گاهی اوقات به معنای "زیاد دُرُست نیست" است.

 

افزودن دیدگاه جدید