לא צריך להגיע עם מסמך אפיון מושלם, מסמך טכני או החלטה באיזו טכנולוגיה להשתמש. כן כדאי להגיע עם החלטות בסיסיות, דוגמאות ושאלות פתוחות כדי להבין את ההיקף, את המורכבות ואת הדרך הנכונה להתחיל.המטרה היא להפריד בין מה שחייב להיבנות עכשיו, מה שאפשר לבדוק בגרסה ראשונה, ומה שכדאי להשאיר להמשך אחרי שימוש אמיתי.
1. הגדירו למי האפליקציה מיועדת ומה הבעיה
התחילו בתיאור קצר של המשתמשים: מי הם, באיזה מצב הם נמצאים, ומה הם מנסים לעשות כשהם פותחים את האפליקציה. ככל שהתיאור ממוקד יותר, קל יותר לבחור מסכים, פעולות ותעדוף.נסחו גם את הבעיה במילים פשוטות. למשל: משתמשים צריכים להזמין שירות מהר, לעקוב אחרי סטטוס, לקבל תזכורות, או לנהל מידע שלא נוח לנהל היום בכלים קיימים.
- מי המשתמש המרכזי?
- מה הפעולה החשובה ביותר שהוא צריך לבצע?
- מה קורה היום בלי האפליקציה?
- מה ייחשב שימוש מוצלח בגרסה הראשונה?
2. תארו את תהליך המשתמש המרכזי
לפני שמפרטים את כל המסכים, כדאי לתאר את המסלול העיקרי מקצה לקצה: מאיפה המשתמש מתחיל, אילו פרטים הוא מוסר, מה הוא מקבל בסיום, ומה קורה אם משהו חסר או נכשל.תהליך אחד ברור עדיף על רשימה ארוכה של רעיונות. הוא מאפשר להבין מה צריך להיות באפליקציה, מה שייך לבקאנד, ומה דורש מערכת ניהול או חיבור לשירות חיצוני.
- מהו המסך הראשון שהמשתמש רואה?
- אילו פעולות הוא מבצע לפי הסדר?
- אילו הודעות, אישורים או התראות נדרשים?
- מי מטפל בצד השני של התהליך, אם יש כזה?
3. בחרו את תכולת הגרסה הראשונה
גרסה ראשונה טובה אינה חייבת לכלול את כל הרעיונות. היא צריכה לכלול את המסלול שמוכיח שהמוצר שימושי, יחד עם מה שנדרש כדי להפעיל אותו בצורה אמינה.בשלב הזה כדאי להפריד בין חובה להשקה, חשוב להמשך, ורעיונות שאפשר לבדוק רק אחרי שיש משתמשים או משוב.
- אילו פעולות חייבות לעבוד ביום הראשון?
- מה אפשר לבצע ידנית מאחורי הקלעים בהתחלה?
- איזה מידע חייב להישמר במערכת?
- אילו יכולות אפשר לדחות לגרסה הבאה?
4. אספו מסכים, דוגמאות וחומרים קיימים
חומרים קיימים לא חייבים להיות סופיים, אבל הם מקצרים את הדרך להבנת המוצר.גם דוגמאות למה לא רוצים יכולות לעזור: ממשקים עמוסים מדי, תהליך הרשמה מסורבל, או אפליקציה שהזרימה שלה אינה מתאימה לקהל היעד.
- סקיצות או תרשימי זרימה, גם אם הם לא מעוצבים.
- דוגמאות לאפליקציות או מסכים שממחישים כיוון.
- לוגו, צבעים, טקסטים או חומרים קיימים אם יש.
- מידע לדוגמה שהאפליקציה אמורה להציג או לשמור.
5. פרטו דרישות התחברות, תשלום ואינטגרציות
הרבה החלטות טכניות תלויות בשאלה האם המשתמשים צריכים להתחבר, לשלם, לקבל התראות, או לעבוד מול מערכות חיצוניות. אלה לא פרטים קטנים; הם משפיעים על אבטחה, בדיקות, חנויות האפליקציות והיקף הפיתוח.אין צורך לבחור מראש כל ספק או שירות, אבל חשוב לדעת אילו יכולות נדרשות ומה כבר קיים אצלכם.
- האם צריך התחברות באימייל, טלפון, Google, Apple או דרך ארגון?
- האם יש תשלום חד-פעמי, מנוי, סליקה או רכישה בתוך האפליקציה?
- האם יש צורך בהתראות Push, מיילים או SMS?
- אילו מערכות חיצוניות צריכות להתחבר לאפליקציה?
6. כתבו אילוצים ושאלות פתוחות
אילוצים עוזרים לתכנן נכון: תאריך יעד, תלות בספק חיצוני, חנות אפליקציות, תקציב שצריך להיבדק, רגולציה, צוות פנימי או מערכת קיימת.שאלות פתוחות אינן בעיה. להפך, הן מסמנות איפה צריך לקבל החלטה לפני שמתחייבים להיקף עבודה.
- האם יש תאריך יעד או אירוע שצריך להגיע אליו?
- האם קיימת מערכת שצריך להתחבר אליה?
- מי מאשר החלטות מוצר ועיצוב?
- אילו נושאים עדיין לא הוחלטו?
7. מה חייבים לדעת מראש ומה מחליטים יחד
לפני שיחת אפיון לא חייבים לדעת איך תיראה הארכיטקטורה, באיזה שירות ענן להשתמש או אם האפליקציה תפותח בטכנולוגיה מסוימת. אלה החלטות שמתקבלות אחרי שמבינים את הצורך, הקהל, האילוצים והמערכות שצריך לחבר.מה כן כדאי להביא לשיחה, גם אם התשובות חלקיות:
- חייבים לדעת: הבעיה, המשתמשים והתהליך המרכזי.
- חייבים לדעת: יכולות חובה, מערכות קיימות, תקציב משוער ומגבלות זמן.
- מחליטים יחד: מבנה מסכים, סדר עדיפויות, שלבי פיתוח ובדיקות.
- מחליטים יחד: טכנולוגיות, תשתיות, ספקי צד שלישי ואופן ההשקה.
דוגמה היפותטית בלבד
אפיון קצר לאפליקציית הזמנת שירות
- בעיה: העסק מקבל הזמנות שירות בהודעות ובשיחות, וקשה לדעת מי כבר טופל ומה הסטטוס של כל בקשה.
- קהל יעד: לקוחות פרטיים שרוצים להזמין שירות לבית בלי שיחת טלפון, וצוות תפעול שמעדכן סטטוסים.
- התהליך המרכזי: בחירת סוג שירות, הזנת כתובת, בחירת חלון זמן, אישור בקשה וקבלת עדכון סטטוס.
- גרסה ראשונה: אפליקציית לקוח, התחברות בסיסית, יצירת בקשה, אזור סטטוס ומערכת ניהול פנימית לטיפול בבקשות.
- מערכות קיימות: יש גיליון הזמנות ומערכת סליקה, אבל עדיין צריך לבדוק אם מחברים אותן בגרסה הראשונה.
- שאלות פתוחות: האם נדרש תשלום בתוך האפליקציה, מי מעדכן זמינות, ומה חייב להיות אוטומטי כבר בהשקה.
רשימת הכנה לשיחה
אפשר להגיע לשיחה גם עם תשובות חלקיות. הרשימה עוזרת להבין מה כבר ברור ומה צריך לברר יחד.- הבעיה העסקית שהאפליקציה אמורה לפתור.
- קהל יעד מרכזי ומשתמשים נוספים אם יש.
- תהליך משתמש מרכזי לפי שלבים.
- רשימת יכולות חובה לגרסה הראשונה.
- מסכים, סקיצות, קובצי עיצוב או דוגמאות אם קיימים.
- דרישות התחברות, תשלום, התראות ואינטגרציות.
- מערכות קיימות, ספקים או מגבלות שצריך לקחת בחשבון.
- תקציב משוער, מגבלות זמן ושאלות פתוחות שעדיין לא הוכרעו.
רוצים לבדוק איך מתחילים?
שלחו כמה מילים על הרעיון, הקהל והגרסה הראשונה שאתם מדמיינים. נחזור עם שאלות המשך וכיוון עבודה ראשוני.רוצים לבדוק איך מתחילים?
שלחו כמה מילים על הרעיון, הקהל והגרסה הראשונה שאתם מדמיינים. נחזור עם שאלות המשך וכיוון עבודה ראשוני.