בית  >  כתבות  > דרך קלה ומהירה להניע פרוייקטים עם ממשק: מודל ISVGO

דרך קלה ומהירה להניע פרוייקטים עם ממשק: מודל ISVGO

ישי כהן, 11/5/2010. 6 תגובות.

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

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


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

סביבה –  למרות שבמודל המקורי הסביבה היא העמודה האחרונה, אני נוהג למלא אותה ראשונה (זהירות: דיעה אישית): בייחוד היום כשהמוצרים שלנו יכולים לרוץ בכל מיני פלטפורמות ובכל מיני מכשירים, החשיבות לאיפה המשתמשת נמצאת היא מכריעה (ועל זה כתב גרג נודלמן, תרגם את זה יפה ברק דנין). זה ישפוך אור על הכוונות שלה, יעלה לנו דגלים אדומים של מה מותר ומה אסור בקלות וייתן לנו ממש תחושה של מצב הגוף שלה, המשימות המקבילות שעליה למלא וכיו"ב – לפעמים בשתי מילים. לדוגמא: נסיעה באוטובוס; ישיבה באוטו – נהיגה. אם זה עובד טוב, יש לכם תמונה עכשיו בראש.

שימוש – מה המשתמשת עושה עם המוצר באותו רגע. זה יכול להיות הוצאת שיחה או שזה יכול להיות קבלת מידע ראשוני.

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

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

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

יתרונות וחסרונות

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

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

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

דוגמה

אני אתן כאן דוגמה לטבלה מלאה. הטבלה מציגה את השלבים של בחירת מתכון לבישול לאירוח, יישום שרשת מזון רוצה להשיק.

סביבה

שימוש

צורה

מבנה

מידע

בית – תכנון אירוח

בחירת מתכון ורשימת קניות. המשתמשת רוצה לתכנן ארוחה לכמה מבוגרים

מחשב שולחני במשרד או בבית

אתר הבית של הרשת

הצעות למתכונים

הגדרת אופציות

מיון

בחירה

רשימת מצרכים; הכנה; תמונות השלבים; לינק למתכונים משלימים

ברשת עצמה

בחירת מתכון כרשימת קניות

סלולרי בפונטים גדולים, רצוי בפונט ברירת המחדל של המערכת

אפליקציה לסלולרי

מתכונים

מיון ואופציות בחירה

אופציה: בחירת סניף

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

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

לסיכום

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

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

כתבות בנושאים דומים



תגובות

6 תגובות לכתבה

כתיבת תגובה

לא יוצג בשום מקום

לא חובה

רוצים שהתמונה שלכם תופיע עם התגובה? העלו אותה ל-Gravatar.

שלח