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