כשאנחנו באים לאפיין מוצר כלשהו או אפילו איזו פונקציה בתוך מוצר, אנחנו מחפשים כלים שיעזור לנו בשלב האיפיון. כלי שאני מצאתי כיעיל הוא טבלה שקיבלתי בזמן הלימודים למלא ומאז אני ממלא אותה יחד עם בעלי תפקידים שונים בצוות המוצר. יחד עם כלים כמו פרסונות, תסריטי שימוש ועוד, הטבלה שמיד אביא נותנת, מעבר ליכולת חיזוי כלשהיא של המוצר ושל החוויה שלו, גם איזשהו מצפן שמכוון את הצוות שמעצב את החוויה.
את הטבלה הזו אני אישית נוהג למלא בתחילת הפרוייקט, בשלב שבו מנסים לקבוע רעיונות מרכזיים, ואפילו כיוונים. הפרוייקט, דרך אגב, יכול להיות גם פיצ'ר במוצר.
במקור השם הוא ISGVO שהם ראשי תיבות בהולנדית, שהאנס וולטרס, דיקן המגמה לעיצוב אינטראקציה בHKU פיתח. בעברית אנחנו נקרא לזה מידע, מבנה, שימוש, צורה וסביבה. צר לי, זה לא יוצא ראשי תיבות מלהיבים.
סביבה – למרות שבמודל המקורי הסביבה היא העמודה האחרונה, אני נוהג למלא אותה ראשונה (זהירות: דיעה אישית): בייחוד היום כשהמוצרים שלנו יכולים לרוץ בכל מיני פלטפורמות ובכל מיני מכשירים, החשיבות לאיפה המשתמשת נמצאת היא מכריעה (ועל זה כתב גרג נודלמן, תרגם את זה יפה ברק דנין). זה ישפוך אור על הכוונות שלה, יעלה לנו דגלים אדומים של מה מותר ומה אסור בקלות וייתן לנו ממש תחושה של מצב הגוף שלה, המשימות המקבילות שעליה למלא וכיו"ב – לפעמים בשתי מילים. לדוגמא: נסיעה באוטובוס; ישיבה באוטו – נהיגה. אם זה עובד טוב, יש לכם תמונה עכשיו בראש.
שימוש – מה המשתמשת עושה עם המוצר באותו רגע. זה יכול להיות הוצאת שיחה או שזה יכול להיות קבלת מידע ראשוני.
צורה – גם כאן הפכתי את הסדר מעט, וגם התרגום אולי לא קולע לגמרי, מאחר שאנחנו יכולים למלא כאן גם את המכשיר בתור הצורה, וגם את הדרך שבה ניגשים למוצר. צורה יכולה להיות טלפון מסך מגע או יכולה להיות מסך במצג רוחבי.
מבנה – מהו המבנה ההיררכי של של המוצר או מהו השלב שבו המשתמשת נמצאת בתוך המוצר? איך היא הגיעה לשם? המבנה בכללותו יבוטא בד"כ בתוך תרשים הזרימה ולכן אפשר פשוט לתת הפניה לאזור מסויים בתרשים, אבל אפשר לציין גם כאן מה השלבים שקדמו לכך, מהן המטרות שלה. הראציונל הוא שאנחנו יודעים את שאר העמודות ויכולים להבין האם יש מקום לשילוב הזה בתוך המבנה ההיררכי של המוצר.
מידע – מה יוצג או יושמע למשתמשים כשהם מול המוצר או בשלב הזה של המוצר. לא צריך להסביר מה המשתמשת רצתה לראות או לדעת, אלא מה המערכת מציגה. בייחוד כשאנחנו מעצבים ומאפיינים למדיות ומכשירים שמוגבלים מבחינות כלשהן, אנחנו יכולים לצמצם את המידע שיוצג בהתאם לעמודות שכבר מילאנו, מאחר ואנחנו יודעים מה המשתמשת עושה, מה הצורה של המכשיר או של המוצר, ואילו שלבים במבנה ההיררכי היא כבר עברה – ומכאן להסיק מה היא כבר יודעת כדי לא להציג מידע מיותר.
יתרונות וחסרונות
היתרון הגדול של התהליך הזה הוא אם ממלאים אותו יחד (מנהלי המוצר,התוכן, הפיתוח וכך הלאה): כולם שותפים, כולם יכולים לתרום ידע. במציאות זה יהיה יותר משהו שאפשר להתווכח עליו (ובישראל יהיו ויכוחים), ואפשר לטפוח על המצח בעדינות כשמתגלה ששכחנו חלק מהותי במבנה. נוסף על כך, כשממלאים את הטבלה אפשר להסיק ממנה שאלות ומשימות לבדיקות משתמשים (את עומדת באוטובוס [סביבה] והמכשיר אצלך בכיס [ שימוש]. הוא רוטט [צורה] שיש לך הודעה חדשה [מבנה]. לפי הטקסט שאת רואה כאן, האם את יודעת ממי ההודעה?)
החסרון הגדול של הטבלה הזו היא שאחרי שכולם ממלאים ואתה ועוברים עליה, ובייחוד אם זה פרוייקט קצר של סטארט אפ או משהו שצריך 'לעשות מהר', עלולים לחשוב שזה מספיק בתור תהליך איפיון. זה לא. זה לא מחליף ארכיטקטורת מידע, זה לא מחליף מסמכי wireframe שיתארו את המסכים אחד אחרי השני.
תחשבו על זה בתור הגלגל הרזרבי הקטן שמותר לסוע איתו 80 קמ"ש. זה מספיק כדי שכולם יכנסו לאוטו ויתחילו לנוע באותו כיוון.
דוגמה
אני אתן כאן דוגמה לטבלה מלאה. הטבלה מציגה את השלבים של בחירת מתכון לבישול לאירוח, יישום שרשת מזון רוצה להשיק.
|
סביבה |
שימוש |
צורה |
מבנה |
מידע |
|
בית – תכנון אירוח |
בחירת מתכון ורשימת קניות. המשתמשת רוצה לתכנן ארוחה לכמה מבוגרים |
מחשב שולחני במשרד או בבית |
אתר הבית של הרשת הצעות למתכונים הגדרת אופציות מיון בחירה |
רשימת מצרכים; הכנה; תמונות השלבים; לינק למתכונים משלימים |
|
ברשת עצמה
|
בחירת מתכון כרשימת קניות |
סלולרי בפונטים גדולים, רצוי בפונט ברירת המחדל של המערכת |
אפליקציה לסלולרי מתכונים מיון ואופציות בחירה אופציה: בחירת סניף |
רשימת מצרכים. אם נבחרה האופציה של הסניף, לפי מסלול קניות הגיוני |
כבר כאן אפשר לראות ויכוח ראשון שיקום, וזה טוב: האם מסלול הקניות הוא מסלול שיוביל אותה דרך המבצעים במעברים מיוחדים (טוב יותר לרשת, יותר זמן פיתוח) או בדרך הקצרה ביותר (טוב למשתמשת וכנראה נוח יותר לפיתוח). מה שבטוח הוא שבעזרת הטבלה עלה העניין של 'מסלול הגיוני' ומישהו יקבל את ההחלטה. בזכות הטבלה אנחנו יכולים להגיד: "היא עכשיו ברשת, יש לה יד אחת על העגלה ואולי איזה ילד… היא תביט לשניה על המסך ואז תלך לקחת מהמדף. אז למה להראות לה את כל המרכיבים של המוצר, במקום כבר לרמוז לה על המוצר הבא שהיא צריכה? זה סתם יעכב אותה".
לסיכום
הטבלה שהצגתי כאן היא כלי שעוזר בתהליכים שונים של פיתוח המוצר, לקבל החלטות הנוגעות לחוויית המשתמש. הטבלה תעזור לכל העוסקים בפרוייקט להבין את/להתווכח לגבי היחס בין המוצר לבין האדם ברגע נתון של שימוש בו.
מילוי הטבלה הוא לא תחליף למסמכים מסודרים ומפורטים כמו פרסונות, אבות טיפוס, מסכים שלדיים (Wireframes), וכמובן מסמך אפיון מפורט. וכמו בחשמל: להחליף נורה אפשר לבד – להתקין מערכת כדי שהפקק לא יקפוץ, כדאי שיהיה לכם בעל מקצוע.
ישי, איך אתה משלב בין הטבלה והפרסונות, בהנחה שהן קיימות בפרוייקט? האם אתה משתמש בטבלה כמעט כסוג של הרחבה בשביל לנתח את התסריטים השונים של כל פרסונה? נראה לי מתבקש. אני מתאר לעצמי שאפשר לראות בטבלה הנגשה שלה הפרסונות שמכילות יותר מידע שלא תמיד קל לעכל ולנתח.
התשובה היא כן. 😉 וברצינות:
המשפט הראשון שלך הוא המפתח: בהנחה שהן קיימות בפרוייקט. אם יש פרסונות, אז הטבלה תבוא אחרי שיש לנו פרסונה ולפני שיש לנו תסריטים של הפרסונה. הפרסונה תעזור לנו למלא את ה'צורה' (המשתמשת היא [אבג] ומכאן שהיא תעשה [123]); למלא את הסביבה (פרסונה כזו קונה במכולת השכונתית) וכיו"ב.
מצד שני, הטבלה יכולה לשמש בתור כלי להראות את הצורך בפרסונה. כלומר: אם נתחיל למלא אותה, ואז ירבו הויכוחים, זה המקום שלנו כאנשי מקצוע להגיד 'אוקיי, יש לנו בעיה להגדיר את הסביבה, את הצורה וכו'. בואו נעשה תהליך של פיתוח פרסונות…' ואז הטבלה היא כלי שיווקי להוריד את ההתנגדות של בעלי תפקידים שונים ששואלים את עצמם 'למה צריך בכלל את איש הUX? הרי אנחנו יודעים את זה…'
מסכים 🙂 נקודה ששווה לעלות לדעתי היא היכולת שלנו ושל הצוות למלא את הטבלה או חלקים ממנה כאשר מדובר בפרוייקט בתחום מאוד מקצועי או תחום שזר לנו. מקרה כזה אין מנוס מביצוע מחקר ושיתוף בעלי עניין כמו הלקוח במילוי החללים.
אהבתי את הטבלה, זו נראית לי דרך טובה להגיע להסכמות עם האנשים השונים הרלבנטים למוצר ואולי יותר מזה דרך טובה לסכם את הדברים ולשמור על הכיוון.
מבחינתי הקושי לקבץ את כולם (כללומר לא אנשי UX אלא אנשים מתחומים שונים) לתהליך האפיון הוא משהו שחוזר שוב ושוב, כשעובדים עם אנשים לאורך זמן זה משתפר, אבל כל פעם שמגיע מישהו חדש זה קצת מתערער… נראה שהטבלה עשויה לעזור.
מצטער – כנראה פספסת אותי בגדול.
אני מסכים שטבלה טקסטואלית היא כלי עזר יעיל לסיכום ושיתוף מידע.
אני מבטיח לנסות אותה – אבל יש לי תחושה שיהיה קשה למלא את הטבלה ואני חושש שיהיה עוד יותר קשה לאנשים אחרים להבין אותה.
נראה לי שהצגת תרחישים/ניתוח תהליכים בצורת תרשימי זרימה (ויזואלי – כל תהליך בנפרד) יהיו מובנים יותר. הם גם יעזרו לנתח את התהליך ולוודא שזהו התהליך מול בעלי העניין האחרים (יש לי תחושב שממילא קוראים את הטבלה על פי השורות בלבד).
הדוגמא בלבלה אותי – נראה כאילו יש יותר ממערכת אחת (סלולארית ואתר אינטרנטי) וכל תרחיש הוא של מערכת אחרת. יש גם פער גדול ברמות העומק – מ hi-level (כמו מחשב שולחני) ועד גודל פונטים…
לדעתי, יש להתמקד בשלבים ראשוניים אלו ב"מה" ולא ב"איך".
מלבד הגדרת הסביבה (שחלק ממנה היא גם המכשיר שבשימוש, אפליקציות נוספות במכשיר ועוד) הגדרת המשתמש (פרסונה אם תרצו) ואת תרחישי השימוש (מה המטרה, מה מעוניינים להשיג בפעולה וכו'). הייתי מצפה שגם עמודת המידע תהיה ברמת ה"מה" ולא ה"איך". לדוגמא "מה לבשל", "איך לבשל", "מצרכים וכלים נדרשים" וכו' (או למעשה – מה השאלות שיהיו למשתמש, איזה החלטות עליו לקבל ולספק את המידע בצורה שתענה בצורה הטובה ביותר). אני חושב ש"תמונות השלבים", "לינק למתכונים משלימים" הם פתרונות ספציפיים ("איך להציג") לשאלה גדולה יותר ("מה להציג").
אני בטוח שאם אתה משתמש בשיטה בנוסף לכלים אחרים וממליץ עליה – יש דברים בגו וכנראה פספסתי את הערך המוסף. אולי פשוט אנסה אותה בפרוייקט הבא ואראה בעצמי…
אבשלום – זו תגובה מאתגרת שמאלצת אותי לחשוב. אז כבר תודה
לגבי הדוגמא: זהו מקרה של תחילת פרוייקט; כפי שאמרתי את הטבלה אפשר גם למלא לכל פיצ'ר
הטבלה הזו נותנת יכולת על רגל אחת, כמו העטיפה האחורית של ספר, וכך צריך להתייחס אליה.כפי שכתבתי, הטבלה לא מחליפה את התהליכים העמקים והארוכים יותר. שמתי לב שבתרשים זרימה, למשל, אין מקום לכתוב את כל הדברים. כותבים היררכיה או שכותבים מידע, אבל קשה לתפוס את הכל בבת אחת.
נכון שבשלבים ראשוניים הטבלה תתמלא יותר ב'מה' מאשר ב'איך' אבל זה גם ייתן כיוון לאיך. מצד שני, ישנם מצבים שבהם תו"כ מילוי הטבלה עולות מגבלות. כלומר, בניגוד לפרסונות, שחייבות להיעשות בתחילת הפרוייקט כדי שבאמת תהיינה דמויות מול העיניים, הטבלה היא משהו שאפשר להפעיל בכל שלב, אפילו בישיבות שצריכות לרכז אנשים. הפירוט שאתה נתת הוא עמוק יותר, ("מה השאלות שיהיו למשתמש, איזה החלטות עליו לקבל ולספק את המידע בצורה שתענה בצורה הטובה ביותר"). הרבה פעמים בעלי תפקידים שונים אינם יכולים או אינם מעוניינים לחכות. במקרה כזה הטבלה יכולה לחשוף את המורכבות שבפרוייקט, את חוסר הבהירות לגבי תהליכים, שתוביל ל'הצדקה' של התהליכים הארוכים יותר.
דעתך?