MVP اپلیکیشن؛ کدام صفحه را اول بسازیم

MVP اپلیکیشن یعنی کوچک‌ترین نسخهٔ موبایلی که یک کار مشخص را برای کاربر واقعی تمام می‌کند و به شما دادهٔ تصمیم می‌دهد؛ نه فهرست بلندی از صفحه‌هایی که «بعداً لازم می‌شوند». تعریف کلی حداقل محصول در مقالهٔ جدا آمده است. اینجا مسئله این است: روی گوشی کدام صفحه را اول بسازیم، چه چیزی را حذف کنیم، تست استور را کجا بگذاریم و بعد از نسخهٔ اول چه کنیم.

جست‌وجوهایی مثل «MVP اپلیکیشن»، «نسخه اول اپلیکیشن»، «صفحات ضروری اپ»، «چه فیچری را حذف کنیم» و «تست استور قبل از انتشار» معمولاً از تیمی می‌آید که بین ساخت همهٔ نقش‌ها و ساخت هیچ مسیر کاملی گیر کرده است. این راهنما نیت اجرایی محدودهٔ اپ را پوشش می‌دهد و وارد کوئری تجاری «طراحی اپلیکیشن» یا «ساخت اپلیکیشن موبایل» نمی‌شود؛ آن مسیر در خدمات طراحی اپلیکیشن روبینش است. تعریف مفهوم را در مقاله MVP چیست بخوانید و برآورد هزینه را در عوامل قیمت طراحی اپ جدا نگه دارید.

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

MVP اپلیکیشن یعنی کدام کار را تمام کنیم؟

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

کار را با نقش قاطی نکنید. نسخهٔ اول معمولاً یک نقش دارد: مشتری، فروشنده یا اپراتور. ساخت هم‌زمان پنل مدیر، گزارش مالی و چت پشتیبانی مسیر را پاره می‌کند. نقش دوم را وقتی اضافه کنید که نقش اول واقعاً کار را تمام کرده و داده نشان داده کدام اصطکاک بعدی ارزش دارد. مسیر رزرو را در راهنمای اپلیکیشن رزرو نوبت جدا ببینید اگر کار اصلی شما تقویم است؛ اینجا فقط تصمیم محدوده است.

پروتوتایپ قابل کلیک یادگیری ارزان می‌دهد، اما جایگزین نسخهٔ اول روی دستگاه نیست. کاربر باید با حساب واقعی یا حساب تست، شبکهٔ ضعیف و کیبورد فارسی همان کار را تمام کند. اگر وسط مسیر به «به‌زودی» می‌رسد، فرضیه آزمایش نشده است. جزئیات جریان را پیش از کد در راهنمای یوزر فلو قفل کنید تا صفحه از روی عادت اضافه نشود.

صفحات ضروری نسخه اول کدام‌اند؟

صفحه ضروری صفحه‌ای است که بدون آن کار اصلی ناقص می‌ماند. الگوی تکراری برای خیلی از اپ‌های خدماتی این است: ورود یا مهمان کنترل‌شده، صفحهٔ انجام کار، نتیجه یا فهرست، جزئیات همان مورد، و یک مسیر تنظیم یا خروج. صفحهٔ بازاریابی داخل اپ، کیف پول، باشگاه امتیاز، چت زنده و داشبورد تحلیلی معمولاً نسخهٔ بعد هستند مگر خودِ کار اصلی همان‌ها باشند.

ورود را تا وقتی هویت لازم نشده عقب بیندازید. اجبار ساخت حساب پیش از دیدن ارزش، نرخ رها شدن را بالا می‌برد. اگر ورود لازم است، یک روش کافی است: شماره و کد، یا ایمیل، نه هر دو به‌اضافه شبکه اجتماعی. جزئیات نشست امن را در راهنمای احراز هویت اپلیکیشن بخوانید؛ در نسخهٔ اول همان حداقل پایدار را پیاده کنید، نه همهٔ لایه‌های سازمانی.

چه چیزی را از نسخه اول حذف کنیم؟

حذف را با حس «ساده بودن» اشتباه نگیرید. چیزی را حذف کنید که به فرضیهٔ این هفته جواب نمی‌دهد. اعلان تخفیف، اشتراک‌گذاری اجتماعی، تم تاریک، چندزبانه، گزارش مدیریت و همگام‌سازی آفلاین کامل اگر کار اصلی را جلو نمی‌برند، هزینه و باگ می‌سازند. آفلاین را فقط وقتی نگه دارید که محیط کار واقعاً بدون شبکه است؛ آن تصمیم محصولی جداست.

پرداخت را هم با دقت ببرید یا نبرید. اگر فرضیه «آیا کسی برای این خدمت پول می‌دهد» است، مسیر پرداخت آزمایشی یا بیعانه ممکن است ضروری باشد. اگر فرضیه فقط «آیا مسیر رزرو بدون تماس تمام می‌شود» است، پرداخت را مرحلهٔ بعد بگذارید و وضعیت را دستی تسویه کنید. قاطی کردن دو فرضیه در یک نسخه، داده را مبهم می‌کند: نمی‌فهمید مشکل قیمت بوده یا اصطکاک صفحه.

• چت و تیکت تا وقتی کانال پشتیبانی بیرونی کار می‌کند
• جست‌وجوی پیشرفته وقتی فهرست کوتاه است
• چند نقش هم‌زمان بدون داده از نقش اول
• شخصی‌سازی ظاهر و انیمیشن غیرضروری
• اتصال به همهٔ درگاه‌ها و پیامک‌ها قبل از یک مسیر پایدار

تست استور را قبل از انتشار عمومی بگذارید

تست استور یعنی نسخه را روی مسیر واقعی توزیع ببینید، نه فقط روی کابل توسعه‌دهنده. در Google Play معمولاً از Internal testing با گروه کوچک شروع می‌شود، بعد در صورت نیاز Closed و Open testing. هدف این مرحله کشف کرش، مشکل ورود، مجوز، و ناسازگاری دستگاه است؛ نه جمع‌کردن امتیاز فروشگاه. گوگل تأکید می‌کند پیش از انتشار تولیدی باید تست انجام شود و لینک تستر ممکن است چند ساعت بعد در دسترس باشد. جزئیات مسیر را از راهنمای رسمی Play Console دربارهٔ تست داخلی، بسته و باز بخوانید.

برای اپل، TestFlight همان نقش را دارد: حساب تست، یادداشت بازبین و مسیر اصلی بدون بن‌بست. بازبین و تستر غریبه‌اند؛ فرض نکنید محصول را می‌شناسند. اگر ورود دارد، حساب آماده بگذارید. اگر پرداخت دارد، حالت آزمایشی را مشخص کنید. انتشار عمومی و ریجکت را در راهنمای انتشار اپ در گوگل پلی و اپ استور دنبال کنید تا این صفحه روی محدودهٔ نسخهٔ اول بماند.

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

بعد از نسخه اول چه تصمیمی بگیریم؟

بعد از انتشار محدود، سه خروجی بیشتر از ده ایدهٔ جدید ارزش دارد: چند نفر کار اصلی را تمام کردند، کجا رها کردند، و آیا حاضرند هفتهٔ بعد برگردند. اگر تمام کردن نزدیک صفر است، صفحهٔ جدید نسازید. اگر تمام می‌کنند اما برنمی‌گردند، مسئله ممکن است ارزش باشد نه رابط. اگر برمی‌گردند و یک اصطکاک تکراری می‌گویند، همان یک مورد اسپرینت بعد است.

نسخهٔ دوم را با همان جملهٔ فرضیه بازبینی کنید. گاهی باید کانال را عوض کنید: وب کافی است و اپ زود بوده. مقایسه را در تفاوت اپ و سایت ببینید. گاهی باید نقش دوم اضافه شود چون عملیات بدون پنل می‌شکند. گاهی باید متوقف شوید چون بازار فرضیه را رد کرده. ساختن ادامهٔ محصول از روی فهرست رقیب، نسخهٔ اول را بی‌معنی می‌کند.

اشتباهات رایج محدوده اپ

• شروع از صفحهٔ خانهٔ شلوغ به‌جای مسیر کار
• ورود اجباری پیش از دیدن ارزش
• کپی همهٔ صفحات سایت داخل اپ
• تست فقط روی شبیه‌ساز و یک مدل گوشی
• انتشار عمومی بدون مسیر تست داخلی
• اضافه کردن چت و اعلان قبل از اتمام کار اصلی
• سنجش موفقیت با تعداد صفحه نه با کار تمام‌شده

چک‌لیست قبل از ساخت نسخه اول

1. یک نقش و یک کار کامل روی کاغذ نوشته شده است.
2. هر صفحه به همان کار وصل است یا حذف شده است.
3. ورود فقط وقتی هویت لازم است در مسیر آمده است.
4. حالت خطا، خالی و شبکهٔ ضعیف برای مسیر اصلی طراحی شده است.
5. حساب تست و سناریوی تستر آماده است.
6. معیار یادگیری نسخهٔ اول قبل از کد مشخص شده است.
7. مسیر تست استور از انتشار عمومی جدا شده است.
8. فهرست «نسخهٔ بعد» مکتوب است تا وسط اسپرینت برنگردد.

جمع‌بندی: صفحه را از کار بسازید، نه از الگو

MVP اپلیکیشن فهرست حداقل صفحه نیست؛ حداقل مسیری است که روی گوشی تمام می‌شود و فرضیه را با کاربر واقعی می‌سنجد. صفحات ضروری از کار می‌آیند، حذف از فرضیه، و تست استور از نیاز به دیدن محصول در توزیع واقعی. نسخهٔ بعد را با داده بسازید نه با ترس از ناقص دیده شدن.

اگر می‌خواهید محدودهٔ نسخهٔ اول را روی محصول خودتان ببندید، از صفحه طراحی اپلیکیشن روبینش شروع کنید. برای هم‌راستا کردن فرضیه و اولویت فیچر، منتورینگ محصول مکمل این متن است. درخواست بررسی محدوده را از فرم تماس روبینش بفرستید؛ این مقاله تعرفه و زمان تحویل نمی‌سازد.