בחרו משתמש, בעיה ורגע שימוש
רעיון למוצר מתחיל לעיתים ברשימה: אזור אישי, לוח ניהול, התראות, תשלומים וחיבור למערכות אחרות. לפני שמעריכים פיתוח, כדאי לנסח למי המוצר מיועד ומה הוא מאפשר לעשות. MVP הוא גרסה ראשונית ומצומצמת שאפשר להשתמש בה כדי ללמוד על צורך אמיתי. כדי שהלמידה תהיה שימושית, צריך להגדיר מראש איזו הנחה רוצים לבדוק.
למשל, עסק שנותן שירותים בשטח רוצה לאפשר ללקוחות לשלוח בקשת שירות מסודרת. משתמש ראשון יכול להיות לקוח קיים שצריך לדווח על תקלה, והבעיה היא שפרטים חשובים חסרים בהודעות שהוא שולח. כתבו משפט מדויק: 'לקוח קיים יכול לפתוח בקשה עם הפרטים הדרושים ולקבל אישור שהיא התקבלה'. המשפט הזה יהיה בסיס להחלטות ההיקף.
תארו מסלול אחד שמגיע לתוצאה
שרטטו את המסלול שהמשתמש צריך לעבור כדי להשלים את המשימה. בדוגמה הזאת: כניסה לטופס, הזנת פרטים, צירוף תמונה אם נחוצה, שליחה וקבלת אישור. בצד העסק, הבקשה צריכה להגיע לאדם שיוכל לטפל בה. מסלול כזה מאפשר לזהות את החלקים ההכרחיים ואת המקומות שבהם עדיין אין החלטה לגבי התנהגות המוצר.
עברו גם על מצבים פשוטים שאינם הצלחה מלאה. מה קורה כשחסר פרט? כשהקובץ לא עולה? כשהמשתמש לוחץ שוב על שליחה? יש להגדיר הודעות ברורות ודרך להמשיך. גרסה מצומצמת עדיין צריכה להיות מובנת ואמינה במשימה שבחרתם. אם המשתמש אינו יודע שהבקשה התקבלה או שהעסק אינו יכול למצוא אותה, המסלול עדיין לא שלם.
מיינו יכולות לפי השאלה שהן פותרות
לכל יכולת מוצעת שאלו: האם בלעדיה המשתמש יכול להשלים את המשימה? האם היא נחוצה כדי לבדוק את ההנחה המרכזית? האם אפשר לטפל בצורך הזה ידנית בתקופת הניסיון? בדוגמה של בקשת שירות, שמירת הבקשה והעברתה לאחראי הן חיוניות. התאמה אישית של צבעי האזור האישי כנראה אינה נחוצה כדי ללמוד אם הטופס משפר את קבלת הפרטים.
אפשר להתחיל כשחלק מהפעולות מאחורי הקלעים מבוצעות ידנית, כל עוד מי שמפעיל את השירות יודע מה עליו לעשות וההבטחה למשתמש מדויקת. לדוגמה, איש צוות יכול לשייך בקשות במקום מנגנון שיוך אוטומטי. רשמו את העבודה הידנית ואת האחריות עליה. אל תציגו עדכון בזמן אמת או טיפול אוטומטי אם השירות עדיין אינו מספק אותם.
הגדירו הצלחה וקבלה לפני הקוד
כתבו מה תרצו לראות בשימוש הראשוני. במקרה של טופס שירות, אפשר לבדוק אם לקוחות מצליחים לשלוח בקשה בלי עזרה ואם הצוות מקבל מידע שמספיק להתחלת טיפול. בחרו תצפיות שמחוברות לבעיה, לצד שאלות קצרות למשתמשים. עצם פתיחת החשבון או הכניסה למסך אינן בהכרח עדות לכך שהמשימה הושלמה או שהפתרון מתאים.
לצד הלמידה, הגדירו תנאי קבלה לפיתוח: אילו שדות נדרשים, היכן הבקשה נשמרת, מי רואה אותה ומה מופיע לאחר השליחה. ודאו שההיקף כולל גם הרשאות מתאימות, טיפול במידע הדרוש ודרך לאתר כשל. הסכמות כתובות עוזרות לבעל העסק ולצוות הפיתוח לבדוק את אותה תוצאה ולזהות מתי בקשה חדשה משנה את מה שסוכם.
תכננו גם את הניסיון הראשון
לפני פיתוח מלא, אפשר להציג אבטיפוס לחיץ כדי לבדוק אם המסכים והניסוחים מובנים. אבטיפוס כזה מתאים לבדיקת המסלול, אך אינו מוכיח שהשירות פועל בפועל. כשהגרסה עובדת, בחרו קבוצת משתמשים מתאימה, הסבירו מה זמין והגדירו למי פונים כשנתקלים בקושי. דאגו שגם בצד העסק יהיה מי שיטפל בתוצאות השימוש ובמשוב שיגיע.
בסיום הניסיון, חזרו להנחה המקורית. האם הבעיה הופיעה כפי שציפיתם? היכן נדרש הסבר? אילו פרטים עדיין חסרו לצוות? השתמשו בממצאים כדי לבחור את השינוי הבא, ועדכנו את ההיקף בהתאם. בקשות חדשות ראויות לתיעוד, אבל אין צורך להוסיף את כולן מיד. MVP ממוקד נותן בסיס ללמידה ולהחלטה, ולא רק רשימת מסכים שהושלמה.