خلاصه: رویکرد «استارتاپ ناب» در حال کسب محبوبیت در سازمان‌هاست، این یعنی تیم‌ها باید فرایندهایشان را با این رویکرد وفق بدهند. هر روز از تعداد بیشتری از کارشناسان UX (تجربه کاربری) خواسته می‌شود که آزمایش های ناب را انجام بدهند –که این موضوع خیلی خوب است- اما با روش تحقیق قدیمی تجربه کاربری کمی تفاوت دارد. این راهنما به شما کمک می‌کند که از چرخه‌ی آزمایش هایتان بهترین بهره را ببرید و متوجه شوید که باید محصول حداقلی پذیرفتنی‌تان را تغییر بدهید یا به تولید آن ادامه بدهید.
به صورت خلاصه، «استارتاپ ناب» یک رویکرد کسب‌وکاری است که به دنبال آزمون‌های سریع برای کاهش دادن ریسک ساختن محصولات جدید است. این چارچوب از متدولوژی «تولید ناب» ریشه می‌گیرد و روش علمی را منعکس می‌کند. این روش نیازمند فرایندهایی با تجربه کاربری بالا مانند جمع‌آوری بازخوردهای تکرارشونده و تمرکز روی ارزیابی تجربی و شاخص‌های عملکرد است.
یکی از اصول مهم این روش این است که در چرخه‌ی «بساز-بسنج-بیاموز» حرکت کنید؛ یعنی یک محصول پذیرفتنی حداقلی (MVP) را بسازید و آن را آزمایش کنید، اتفاقاتی که رخ می‌دهد را ارزیابی کنید، و بعد تصمیم بگیرید که می‌خواهید با این راه‌حل یافته شده پیش بروید (استمرار) یا آن را عوض کنید (تغییر).
این فرضیه ساده به نظر می‌رسد. اما این که بفهمید چه محصول حداقلی‌ای را بسازید، داده‌های جمع‌آوری‌شده را چطور تفسیر کنید و قدم بعدی پس از به پایان رسیدن آزمایش ناب چه باشد، می‌تواند کاری چالش برانگیز باشد. این راهنما به شما کمک می‌کند که از چرخه‌ی آزمون‌تان بهترین بهره را ببرید و بفهمید که باید در مسیرتان استمرار داشته باشید یا تغییر.
شرایط را در نظر بگیرید
مهم‌ترین بخش تحلیل اطلاعات پیش از جمع‌آوری اطلاعات شروع می‌شود. برای این که تصمیم بگیرید چه نوع تحقیقاتی را باید انجام بدهید ابتدا باید ببینید که در کجای فرایند پیشرفت محصول‌تان هستید، چه اطلاعاتی را از قبل در اختیار دارید، و بزر‌گ‌ترین و پرمخاطره‌ترین پرسش‌های عمومی کدام‌ها هستند.
در مراحل مفاهیم اولیه‌ی یک ایده‌ی کسب‌وکار یا ویژگی محصول، ابتدا باید به اندازه‌ی کافی در مورد کاربران احتمالی و نیازهای آن‌ها اطلاعات کسب کنید تا بتوانید در مورد مشکلاتی که دارند و راه‌حل‌هایتان برای این مشکلات در آینده فرضیه‌های آگاهانه داشته باشید. هر ایده‌ی جدیدی در ابتدا تنها یک فرض است، و انجام تحقیقات کلی باعث می‌شود که بتوانید به این فرضیات شکل بدهید و آن‌ها را اولویت‌بندی کنید.
رویکرد استارتاپ ناب پیشنهاد می‌دهد که کار را با فرایند GOOB – Getting out of the Building (از ساختمان بیرون آمدن) – شروع کنید و بسیار شبیه به نسخه‌ی فشرده‌ای از قوم‌نگاری سنتی و مصاحبه است. هدف این است که با تعداد کمی از افرادی که فکر می‌کنید در گروه مخاطبان هدف شما قرار می‌گیرند صحبت کنید و در مورد نیازهای کنونی، شکاف تجربه، نقاط ضعف و روش‌هایشان برای حل مسئله‌های موجود که به ایده‌ی شما مربوط است اطلاعات کسب کنید.
این مصاحبه‌ها را درست مانند هر مصاحبه‌ی تجربه کاربری دیگری انجام بدهید و از اطلاعات به دست آمده برای ساختن لیستی از حدسیات‌تان در مورد کاربران هدف، مشکلات احتمالی که باید حل کنید، و راه‌هایی برای شناخت این مشکلات استفاده کنید. پیش از ساختن یک محصول، کارتان را با یک دوره‌ی تحقیق و یادگیری شروع کنید.
اولویت‌بندی چیزهایی که باید در مورد آن‌ها تحقیق کنید
لیست حدسیات شما می‌تواند به عنوان مجموعه‌ی کارهای انباشته‌ی شما عمل کند. به جای ساختن لیستی از ویژگی‌هایی که باید ساخته شود، به هر آیتم به عنوان فرضیه‌ای جداگانه نگاه کنید که باید در مورد آن تحقیق کنید و آن‌ها را تأیید یا رد کنید. سپس، فرضیات‌تان را اولویت‌بندی کنید و پرمخاطره‌ترین‌ها و آن‌هایی که در صورت اشتباه بودن حدسیات شما بیشترین تأثیر را دارند در اولویت قرار دهید. حدسیات در مورد این که چه مشکلاتی داریم و این مشکلات برای چه افرادی اتفاق می‌افتد باید نسبت به حدسیاتی که در مورد حل مشکلات یا ساختن ویژگی‌های جدید هستند در اولویت باشد.
حدسیات معمولاً باید چیزی شبیه به این لیست باشد:
- معتقدم این افراد [—] با این [—] چالش‌ها مواجه شده‌اند.
- معتقدم این راه حل [—] بهتر از روش کنونی کاربرها می‌تواند به حل این مشکل [—] کمک کند.
- معتقدم این راه حل [—] می‌تواند از این راه [—] پول‌ساز باشد.
برای مثال شما می‌خواهید اپلیکیشن جدیدی برای والدین پرمشغله بسازید که بتوانند برای وعده‌های غذایی برنامه‌ریزی کنند. با چندین والد پرمشغله مصاحبه کرده‌اید و متوجه شده‌اید که دو مشکل بزرگی که با آن مواجه می‌شوند این است که تصمیم بگیرند چه غذایی بپزند و فرصت مناسب برای خریدن مواد اولیه را پیدا کنند. ممکن است حس کنید که باید در چه مسیری پیش بروید، اما اولین تست شما باید روی پیدا کردن این که کدام یک از این مسائل برای کاربران شما مناسب‌تر است متمرکز باشد.
پیدا کردن فرضیات
قدم بعدی این است که یک فرضیه‌ی دقیق بسازید که باعث شود تأیید یا رد حدس‌های شما کاری راحت‌تر شود.
من از چارچوب زیر برای ساخت فرضیات استفاده می‌کنم:
بخش انجام دادن، ساختن، ارائه کردن
به راه حل اشاره می‌کند. این بخش از کار می‌تواند به اندازه‌ی تصمیم‌گیری برای نوع اپلیکیشنی که می‌خواهید بسازید گسترده باشد، و یا به اندازه‌ی نوع ارتباطی که می‌خواهید برای یک رابط خاص بسازید خاص باشد.
این افراد
می‌توانند نماینده‌ی مشتری‌های فرضی شما باشند که حاصل مصاحبه‌های اولیه شما و سایر داده‌هاست.
نتیجه‌ي مطلوب
می‌تواند چیزی مربوط به موفقیت کسب‌وکار باشد، مانند فرستادن یک پیام یا سفارش دادن یک آیتم. به یاد داشته باشید که رسیدن به نتیجه‌هایی که خوب به نظر می‌رسند اما واقعاً اطلاعات خوبی به شما نمی‌دهند ساده است. این نتیجه‌ها معیارهای پوچ نامیده می‌شوند. برای مثال، اگر می‌خواهید که افراد در یک سایت تجارت الکترونیکی خرید کنند، خیلی مفید نیست که بدانید چند نفر تصمیم گرفته‌اند شما را در فیسبوک دنبال کنند. به جای آن روی شناسایی اطلاعاتی که به شما در تصمیم‌گیری کمک می‌کنند و نشانه‌ی واقعی موفقیت تجاری هستند تمرکز کنید.
معیار عملی
معیاری است که به شما می‌گوید سرمایه‌گذاری‌تان در ساختن این آیتم ارزشش را داشته است یا نه. معیارهای عملی، به‌خصوص در اوایل کار، می‌توانند کمی پیچیده باشند اما من به این معیارها به عنوان معیارهایی برای حداقل میزان موفقیتی که لازم دارید تا بفهمید که سرمایه‌گذاری‌تان ارزشمند بوده یا نه نگاه می‌کنم. شما برای اندازه‌گیری این میزان می‌توانید به هزینه‌های سرمایه‌گذاری و ارزش دریافت شده نگاه کنید.
فرض کنیم شما در یک شرکت تجارت الکترونیکی کار می‌کنید و می‌خواهید یک ویژگی جدید برای محصول‌تان پیشنهاد بدهید که امیدوارید باعث شود آمار اضافه شدن محصول به سبد خرید در لحظه‌ی آخر را افزایش بدهد. برای این کار می‌توانید از تیم توسعه بخواهید که تخمین بزند برای ساخت این ویژگی چقدر باید تلاش کنید، و سپس ببینید که میزان سفارش‌ها چقدر باید افزایش داشته باشد تا هزینه‌ها جبران شود.
اگر تیم توسعه تخمین بزند که انجام دادن کاری 5 هفته طول می‌کشد و 25 هزار دلار هزینه دارد، شما باید محصول را طوری تغییر بدهید که در این بازه‌ی زمانی همین مقدار پول دربیاورید. بنابراین فرض کنیم که شما می‌دانید کمپانی معمولاً 1000 فروش در هفته دارد و میانگین سفارش‌ها 20 دلار است. این یعنی کمپانی در حال حاضر 20 هزار دلار در هفته درآمد دارد. برای این که بتوانید هزینه‌ي 25 هزار دلاری پیش‌بینی‌شده توسط تیم توسعه را طی 5 هفته جبران کنید، باید تغییری که در محصول ایجاد می‌کنید باعث شود که درآمد هفتگی‌تان 5 هزار دلار افزایش داشته باشد. این یعنی باید میانگین سفارش‌ها از 20 دلار به 25 دلار افزایش پیدا کند. تمام پول‌های اضافه‌ای که بعد از جبران هزینه‌ها به دست می‌آورید، سود کمپانی خواهد بود.
این کار محاسبات زیادی دارد و شما همیشه به این میزان از اطلاعات دسترسی ندارید، به‌خصوص اگر در ابتدای فرایند توسعه‌ی محصول باشید.
ممکن است مجبور باشید که حدس بزنید چه عددی «به اندازه‌ی کافی خوب» است. نکته‌ی مهم این است که معیاری را انتخاب کنید که در واقع به شما در تصمیم‌گیری برای سرمایه‌گذاری در تغییر جدید کمک می‌کند.
گاهی اوقات راحت‌تر است که شرایط را به عنوان شرایط شکست و یا نقطه‌ای که در آن دیگر حرکت رو به جلو ارزشمند نیست تصور کنید. به بیان دیگر، می‌توانید تصور کنید: «اگر در هر سفارش حداقل X درصد رشد نداشته باشیم، نباید نسخه‌ی کامل این ويژگی جدید را اجرا کنیم.» سپس می‌توانید به عقب برگردید تا یک فرضیه‌ی قابل آزمایش بسازید.
البته این چارچوب می‌تواند بر حسب نیاز تغییر کند، اما باید بتوانید پرسشی که در مورد آن تحقیق می‌کنید و موفقیت را دقیق و واضح تعریف کنید. اگر فرضیه‌ي واضحی به ذهن‌تان نرسید، به عقب برگردید و حدسیات‌تان را دوباره ارزیابی کنید و آن‌ها را محدود کنید تا بتوانید آزمایشی موفق را اجرا کنید.
آزمایش تان را طراحی کنید
زمانی که به یک پرسش و فرضیه‌ی واضح رسیدید، تصمیم‌گیری در مورد این که باید چه نوع آزمایشی را انجام بدهید ساده خواهد بود.
بیایید به مثال اپلیکیشن برنامه‌ریزی غذایی برگردیم. شما به این نتیجه رسیدید که پرمخاطره‌ترین حدس این است کدام یک از دو مشکل اساسی برای کاربران‌تان جالب‌تر است.
یک فرضیه می‌تواند به این شکل باشد:
اگر ما اپلیکیشنی بسازیم که در هفته به صورت خودکار 5 دستور غذا بسازد
والدین پرمشغله
به دانلود این اپلیکیشن علاقه‌مند خواهند شد.
زمانی متوجه می‌شویم که این حدس درست است که به آن‌ها مجموعه‌ای از اپلیکیشن‌های مربوط به غذا ارائه کنیم و برای مثال، آن‌ها برنامه‌ی ساخت دستور تهیه غذا را 15 درصد بیشتر از بقیه انتخاب کنند.
حالا می‌توانید روی طراحی راهی برای آزمایش این موضوع که کاربران به استفاده از کدام اپلیکیشن علاقه‌ي بیشتری دارند تمرکز کنید. هیچ راه دقیق و مشخصی برای انجام این کار وجود ندارد. می‌توانید برای هر راه حل احتمالی یک صفحه فرود غیرواقعی بسازید و ببینید که چه تعدادی از افراد برای استفاده از هر محصول ثبت نام کرده‌اند، یا می‌توانید برای اپلیکیشن‌های متفاوت تبلیغاتی را بسازید و ببینید که کدام یک از آن‌ها تأثیر بیشتری دارد. باید روی پیدا کردن کوچک‌ترین چیزهایی که تیم‌تان می‌تواند بسازد تا فرضیه‌ي شما –یعنی محصول پذیرفتنی حداقلی‌تان– را آزمایش کند تمرکز کنید.
در این شرایط، محصول پذیرفتنی حداقلی خوب می‌تواند صفحه‌ای شبیه‌سازی شده از چندین اپلیکیشن غیرواقعی که هنوز آن‌ها را آزمایش نکرده‌اید باشد. سپس شما می‌توانید از یک ابزار کلیکی مانند usabilityhub استفاده کنید و از کاربران‌تان بخواهید که یک اپلیکیشن را انتخاب کنند تا به آن‌ها در برنامه‌ریزی غذایی کمک کند، و بعد ببینید که روی هر ایده چند بار کلیک می‌شود. در این روش دیگر حتی نیازی ندارید که صفحات فرود یا کمپین‌های تبلیغاتی راه‌اندازی کنید، فقط باید یک صفحه‌ی شبیه‌سازی شده بسازید.
انواع آزمایش های نابی که معمولاً از آن‌ها استفاده می‌شود عبارتند از:
- تست صفحه فرود
- تست دود؛ مانند ویدیوهای توضیحی، ویژگی سایه، یا صفحات «به زودی»
- تست دربان
- تست جادوگر از
- تست تبلیغات
- تست کلیک
این‌ها تنها چند پیشنهاد هستند و ایده‌های آزمایش بسیار بیشتری وجود دارد که می‌توانید آن‌ها را بسته به شرایط و چیزی که می‌خواهید متوجه شوید اجرا کنید. از این پیشنهادها به عنوان جایی برای شروع استفاده کنید، نه به عنوان راهنمای قدم‌به‌قدم، تا بتوانید آزمایش مناسب تیم‌تان را پیدا کنید.
“۱۲ مسئله در مورد تناسب محصول و بازار”
تحلیل نتایج
اگر یک فرضیه‌ي واضح و کوتاه داشته باشید و یک طرح آزمایشی خوب را اجرا کنید، تأیید یا رد شدن فرضیه‌تان واضح خواهد بود.
دوباره به مثال برنامه‌ریزی غذایی برمی‌گردیم. فرض کنید که تست 1000 کلیک را اجرا کردید. 4 ایده‌ی اپلیکیشن را در تست گنجاندید، و به این فرضیه رسیدید که ایده‌ی A جالب‌ترین ایده است.
اگر ایده‌ی A 702 کلیک ، ایده‌ی B 98 کلیک، ایده‌ی C 119 کلیک، و ایده‌ی D 81 داشته باشد، واضح است که توانسته‌اید فرضیه‌تان را ثابت کنید. می‌توانید استمرار داشته باشید و با ایده‌ی A جلو بروید، و بعد روی آزمایش کردن حدسیات بعدی‌تان حین تحقیق بیشتر در مورد ایده‌تان تمرکز کنید. شاید حالا وقتش رسیده که در مورد مجموعه‌ی ویژگی‌های اپلیکیشن حدسیات جدید داشته باشید.
از طرف دیگر اگر ایده‌ی A 45 کلیک، ایده‌ی B 262 کلیک، ایده‌ی C 112 کلیک، و ایده‌ی D 581 کلیک داشته باشد، واضح است که فرضیه‌تان رد شده است. ایده‌ی A جالب‌ترین ایده‌ی شما نیست، و باید مسیرتان را از این ایده تغییر بدهید.
در این نمونه، حالا نشانه‌ی واضحی دارید که باید مسیرتان را به چه سمتی تغییر بدهید. ایده‌ی D برنده است. حدس جدیدتان باید بر این اساس باشد که ایده‌ی D مسیری جالب توجه است و برای اثبات این فرض آزمایشی دیگر، مثل اجرای یک تست مشابه که این ایده را با ایده‌ای دیگر مقایسه می‌کند و یا با راه انداختن یک صفحه‌ی فرود، را اجرا کنید. یا می‌توانید مصاحبه‌های بیشتری با مشتریان‌تان داشته باشید تا بفهمید که چرا این ایده برای افراد جالب بوده است.
(با این‌که گاهی اوقات برنده مشخص است، همیشه معلوم نیست که کدام طرف ترازو سنگین‌تر است.)
اما اگر ایده‌ی A 351 کلیک، ایده‌ی B 298 کلیک، ایده‌ی C 227 کلیک، و ایده‌ی D 124 کلیک داشته باشد جه اتفاقی می‌اقتد؟ در این صورت هیچ برنده یا مسیر واضحی وجود ندارد. آیا تست شما خوب نبوده است؟ آیا هیچ‌کدام از ایده‌هایتان جالب نیست؟ یا تمام آن‌ها جالب‌اند؟ حالا چه می‌شود؟
پاسخ کوتاه این است که نمی‌توانید پاسخ درست را بفهمید. اما نکته‌ی خیلی خوبی که در مورد آزمایش ناب وجود دارد این است که این سیستم به شکلی طراحی شده که قدم بعدی شما انجام دادن آزمایش‌های بیشتر است. در یافتن مسیر برنده شکست خورده‌اید، اما در فهمیدن نادرست بودن فرضیه‌ی اولیه‌تان موفق شده‌اید و برای فهمیدن این موضوع نیازی به سرمایه‌گذاری زیادی نداشته‌اید. حالا می‌دانید که باید مسیرتان را تغییر بدهید، فقط ممکن است که ندانید باید مسیر به کدام سمت تغییر بدهید.
به کدام سمت تغییر مسیر بدهیم؟
اگر می‌دانید که باید مسیرتان را تغییر بدهید اما نمی‌دانید باید به چه سمتی بروید، اولین پیشنهاد من این است که یک آزمایش دیگر انجام بدهید تا یافته‌های اولیه‌تان را ثابت کنید.
در مثال اپلیکیشن غذا می‌توانید یک تست را با 3 گزینه‌ی مختلف امتحان کنید و ببینید که نتایج تغییر می‌کنند یا نه، یا می‌توانید تست صفحه فرود را برای تمام 4 ایده اجرا کنید. با این که نباید خیلی خوش‌بین باشید، باید مطمئن شوید که چیزی در تست اشتباه پیش نرفته بوده و یا اشتباهی در جمع‌آوری داده‌ها به وجود نیامده بوده که شما را به نتیجه‌ی اشتباه برساند. از آن‌جایی که آزمایش های ناب سریع هستند و خیلی قدرتمند نیستند، ممکن است گاهی اوقات آن‌قدر دقیق نباشند که بتواند به شما اطمینان کافی بدهند. اگر یافته‌ی شما درست باشد، باید بتوانید آن را از نتایج تست‌های دیگر هم دریافت کنید.
اگر تست دیگری را اجرا کردید و همان داده‌های پراکنده را به دست آوردید یا واقعاً نمی‌دانید که بعد از انجام تست باید در چه مسیری حرکت کنید، سعی کنید از روش‌های آزمایش ناب فاصله بگیرید و به روش‌های تحقیق اکتشافی برگردید.
یک تغییر مسیر موفق می‌تواند هر نوع تغییری در مدل محصول و کسب‌وکار باشد؛ مثل تغییر کامل به یک محصول یا خدمات جدید، تمرکز روی یک ویژگی خاص از یک محصول، هدف‌گذاری روی گروه کاربران جدید، تغییر پلتفرم یا کانال، یا استفاده از یک مدل درآمدزایی یا بازاریابی جدید. یک آزمایش با ساختار مشخص به شما نمی‌گوید که در چه مسیری حرکت کنید، بنابراین باید جمع‌آوری داده را به شکلی وسیع‌تر و کمی‌تر انجام بدهید.
من انجام مصاحبه با دو گروه از افراد را پیشنهاد می‌کنم. اول، با افرادی صحبت کنید که محصول یا خدمات شما را دوست دارند و معمولاً از گزینه‌ای که مد نظر شماست استفاده می‌کنند، مثلاً مدام از شما خرید می‌کنند، و بفهمید که چه چیزی را در مورد شما دوست دارند و چرا. سپس اگر ممکن است با افرادی صحبت کنید که از گزینه‌های مد نظر شما استفاده نمی‌کنند و بفهمید که چرا از این گزینه‌ها استفاده نمی‌کنند و به جای آن به دنبال چه چیزهایی هستند. این نوع مصاحبه‌ها مانند هر مصاحبه‌ي اکتشافی دیگری هستند، و شما باید به دنبال شرکت‌کننده‌هایی باشید که شما را به سمت اطلاعات جدیدی می‌برد که می‌تواند شما را به فرضیه‌های جدید برای تست کردن هدایت کند.
نتیجه
آزمایش های ناب برای هر سازمانی راهی بسیار خوب است که از مشتری‌هایشان یاد بگیرند و تغییرات ارزشمندی ایجاد کنند. عادت کردن به وارد کردن و رد کردن فرضیات واضح و فهمیدن این که باید مسیر را تغییر دهید یا به راهتان ادامه بدهید می‌تواند کمی وقت‌گیر باشد، اما خوشبختانه افرادی که با تجربه کاربری کار می‌کنند مهارت‌های لازم را برای انجام موفق این آزمایشات دارند. پس پیش بروید و آزمایش کنید!
