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