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