דיאגרמת OSD: המפה שלכםן למסע המשתמש

בואו נזמין מונית 🚕

דמיינו שאתם מעצבים אפליקציה להזמנת מונית. המשתמש פותח את האפליקציה בבוקר, רוצה להגיע לפגישה חשובה, וכל מה שהוא צריך לעשות הוא להקיש יעד והאפליקציה תמצא לו נהג. אבל בפועל, מאחורי הקלעים, לא מדובר רק ב”מסך” עם כפתור. זהו מסע מורכב המערב מספר שחקנים, מידע שעובר ממערכת למערכת, ותהליכים שפועלים אחד אחרי השני.

מי השחקנים שלנו?

• הנוסע / המשתמש (User): האדם שמבקש מונית.

• האפליקציה (App): ממשק המשתמש הדיגיטלי שדרכו המשתמש יזין את יעדו ויקבל חיווי על נהגים זמינים.

  • שירות המפות (GPS Service): מערכת חיצונית המספקת נתונים על מיקום, זמינות נהגים, וחישוב זמן הגעה.

  • ספק התשלום (Payment Gateway): שירות צד שלישי שבודק האם ניתן לחייב את הנוסע או לשמור אמצעי תשלום לביצוע החיוב בסיום הנסיעה.

• נהג המונית (Driver): האדם שיקבל את הקריאה מהאפליקציה, יאשר אותה ויגיע לאסוף את הנוסע.

מהלך האירועים:

1. הנוסע מזין כתובת יעד באפליקציה.

2. האפליקציה שולחת בקשה לשירות ה-GPS כדי למצוא נהגים זמינים בקרבת הנוסע.

3. שירות ה-GPS מחזיר רשימה של נהגים באזור, לצד זמני הגעה משוערים.

4. האפליקציה בוחרת נהג מתאים ושולחת בקשה ל-ספק התשלום כדי לוודא שהחיוב אפשרי.

5. לאחר אישור התשלום, האפליקציה שולחת התרעה לנהג.

6. הנהג מאשר ומקבל פרטי נסיעה.

7. הנוסע מקבל הודעת אישור ויכול לראות את פרטי הנהג וזמן ההגעה.

עד כאן נשמע פשוט, אבל האמת היא שהנוסע חווה כאן לא רק מסך אחד. הוא עובר מסע רצוף צעדים – לחיצה על כפתור, המתנה קצרה, קבלת מידע, אישורים מאחורי הקלעים, ולבסוף עדכון שהכול הסתדר.

כדי להבין את המסע הזה לעומק, ולמפות אותו באופן חזותי, נשתמש בכלי שנקרא תרשים הרצף התפעולי (Operational Sequence Diagram - OSD).

להפוך שרשרת פעולות למפה ויזואלית עם OSD

בואו ניקח את הדוגמה של הזמנת המונית ונתאר אותה כ-OSD.

תרשים רצף תפעולי מציג באופן חזותי את כל האינטראקציות בין השחקנים לאורך ציר הזמן. הוא מאפשר לנו להבין:

1. מי פועל מתי?

2. איך מידע עובר מגורם אחד לאחר?

3. מה סדר הפעולות הנדרש?

4. היכן עלולים להופיע עיכובים, כשלים או נקודות תורפה.

איך נראה OSD להזמנת מונית?

ממש ככה:

בואו נצלול.

• ראשית, התרשים נע משמאל (מהנוסע) לימין (עד לנהג).

• בראש התרשים אנו רואים עמודות (Swim lanes) עבור כל שחקן: נוסע, אפליקציה, שירות GPS, ספק תשלום, נהג.

• נצייר חיצים המייצגים הודעות, בקשות ותגובות. כל חץ מסביר בדיוק מה קורה (לדוגמה: “האפליקציה שולחת בקשת זמינות” ל-GPS).

• הציר האנכי (מלמעלה למטה) מתאר את כרונולוגיית האירועים.

פירוט OSD להזמנת מונית (במילים):

1. הנוסע ← האפליקציה: הנוסע מזין יעד ולוחץ “חפש מונית”.

2. האפליקציה ← ה- GPS: האפליקציה מבקשת מ-GPS רשימת נהגים זמינים.

3. ה- GPS ← האפליקציה: GPS מחזיר רשימת נהגים וזמני הגעה משוערים.

4. האפליקציה ← תשלום: האפליקציה מבקשת אישור חיוב.

5.תשלום ← האפליקציה: התשלום אושר (או יש עניין לחייב רק בסוף? גם זה יופיע כאן).

6. האפליקציה ← נהג: האפליקציה בוחרת נהג מתאים ושולחת אליו הזמנה.

7. נהג ← האפליקציה: הנהג מאשר את ההזמנה.

8. האפליקציה ← נוסע: האפליקציה מציגה לנוסע את פרטי הנהג וזמן ההגעה.

כעת, התרשים ממחיש את התלות בין השלבים בצורה ברורה. אנחנו רואים בדיוק מי עושה מה, מתי, ובאיזה רגע המשתמש מקבל מידע או צריך לחכות למידע כדי להתקדם. קל מאוד להבין עכשיו שכפתור “הזמן מונית” הוא רק חלק קטן מאוד במסע מורכב של הזמנת מונית בצורה דיגיטלית.

מה עשינו כאן בעצם?

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

אבל למה זה חשוב בעצם?

• ה- OSD עוזר לנו להבין שאנחנו מאפיינים ”מסע” – לא מסך בודד, אלא רצף פעולות התלויות זו בזו.

• בעזרת ה-OSD נוכל לזהות היכן בתהליך המשתמש עלול להיתקע, איפה המערכת מבזבזת זמן או מאטה, והאם יש שלבים מיותרים.

• רק לאחר שנכיר את המציאות לעומק, נוכל לתכנן את השיפור העתידי: בין אם זה קיצור זמן ההמתנה, הצגת הודעת משוב במהלך החיפוש, או ייעול תהליך התשלום.

אז מהו תרשים רצף תפעולי (OSD)?

ה- OSD הוא כלי ויזואלי המשמש מעצבי מוצר, מנהלי מוצר, מפתחים ובעלי עניין נוספים, להבנת התהליכים כפי שהם מתרחשים בשטח. הוא דומה ל-Sequence Diagram מעולם ה-UML, אך מתמקד בהיבט האופרטיבי והחווייתי, ולא רק באינטראקציות שבין אובייקטים תוכנתיים. ה- Sequence Diagram (תרשים רצף ב-UML) מציג אובייקטים (Actors), מסרים ביניהם (Messages) וסדר כרונולוגי לאינטראקציות. הוא משמש מהנדסי תוכנה, צוותי DevOps, ומנהלי מוצר כדי להבין ולשפר מערכות מורכבות.

נקודות השקה בין OSD ל-Sequence Diagram:

• בשניהם רואים Actors ופעולות מסודרות בציר זמן.

• בשניהם נשתמש בחצים להראות אינטראקציה.

• בשניהם ניתן להציג תרחישים חלופיים (מה אם אין נהגים זמינים? מה אם התשלום לא מאושר?).

הבדל מרכזי:

בעוד Sequence Diagram UML קלאסי מתמקד במבנה הפנימי של התוכנה, OSD מרחיב את המבט גם לגורמים אנושיים ומערכות חיצוניות, תוך דגש על חוויית המשתמש והמסע השלם. OSD הוא יותר “מרקם הסיפור” מכלל האינטראקציות, ולא רק תרשים טכני.

מתי הכי נכון להשתמש ב-OSD?

מודל העבודה שלי הוא כידוע ״מודל הדגים״ המבוסס על הדאבל דיאמונד. כזכור הדאבל דיאמונד נפתח בשלב הדיסקברי ומבחינתי זהו המקום המתאים ביותר לשלב OSD בתהליך. למה?

• ככה נוכל להבין את התהליך הקיים לפני שמעצבים פתרונות חדשים.

• ככה נזהה צווארי בקבוק, עיכובים, או מצבים שהמשתמש מאבד בהם פוקוס.

• ככה נוכל לתכנן פיצ’רים חדשים על בסיס המציאות הנוכחית.

כמו בדוגמה של המונית: לפני שנוסיף פיצ’ר של “צ’אט עם הנהג” או “תשלום מראש בהנחה”, כדאי להבין איך התהליך עובד כיום. בעזרת OSD אפשר לראות היכן הגיוני להכניס את השיפורים הללו, ומה האפקט על המסע הקיים.

איך בונים OSD מעולה?

1. התחילו מהמשתמש: הגדירו את המטרה שלו – למשל, להזמין מונית ולהגיע ליעד.

2. מפו את כל השחקנים: לא רק המשתמש והאפליקציה, אלא גם שירותים חיצוניים, ספקי תשלום, נהגים, נציגי שירות, וכל גורם שמשפיע על התהליך.

3. פרטו את הפעולות בסדר כרונולוגי: גם אם זה נראה מובן מאליו, רשמו כל שלב. לעיתים הפרטים הקטנים מגלים בעיות.

4. הציגו תרחישים חלופיים: מה אם אין נהגים זמינים? האפליקציה צריכה להחזיר הודעה למשתמש. מה אם התשלום לא מאושר? יש להציג אפשרות לאמצעי תשלום אחר.

5. בחנו את התרשים עם הצוות: מפתחים, מנהלי מוצר ומעצבי UX יכולים יחד לעיין בתרשים ולזהות נקודות לשיפור.

וכדי לעשות את זה פשוט יותר, החבריםות ב- Figma הכינו לכםן דיאגרמות מבעוד מועד:

זכרו, במקום להסתכל על כפתור “הזמן מונית” כפעולה מבודדת, ה-OSD עזר לנו להבין את ההקשר המלא: משתתפים מרובים, זרימות מידע, ותהליכים מותני-מצב. OSD מייצג חשיבה על מסע ולא על מסך – הוא קובע מסגרת להבנת התהליך הקיים, מזוהה עם “צילום מצב” יסודי, ומאפשר לנו כמעצבי מוצר (וכן כמנהלי מוצר, מפתחים ובעלי עניין נוספים) לבנות חוויות טובות יותר.

בהצלחה.