אנחנו דוברי העברית לפעמים מוצאים את עצמנו בחסרון בעולם ניהול המוצר. באופן כללי הרבה מהשיח הטכנולוגי בעולם מתנהל באנגלית. אני נתקל במכשול הזה לעיתים קרובות כשהסטודנטים שלי נתקלים בקשיים שהמקור שלהם הוא בבעיות במונחים באנגלית. דוגמה אחת שחוזרת על עצמה היא כאשר אנחנו מדברים על עיצוב ממשק המשתמש של המוצר וקשה לאנשים להבין את ההבדלים בין wireframe, Mockup ו-prototype. אז בואו נחדד את ההבדלים בין שלושת המושגים הללו. לי היה הכי קל להבין את ההבדלים בין שלושת המושגים הללו באמצעות הדימוי של תהליך הבנייה של בנין או דירה.
לפני שנצלול פנימה אולי שווה להזכיר את המונח “Fidelity”. אני חושב על Fidelity כמו על המונח “נאמן למקור”. רק שלא למקור, אלה לתוצאה הסופית. בעצם השאלה היא עד כמה העיצוב תואם את המוצר הסופי שלנו. כשאנחנו מתחילים עיצוב של מוצר וכל מה שיש לנו זה רשימה של רעיונות אז נאמר שהעיצוב הזה הוא מאוד low fidelity. אם לעומת זאת יש לנו עיצוב מפורט ביותר של המוצר הסופי אזי נאמר שהוא high fidelity. שלושת השלבים שאנחנו מדברים עליהם מתקדמים מ-low fidelity ל-high fidelity.
עיצוב Wireframe
ובכן, ה-wireframe היא המקבילה לשרטוט של מהנדס. מדובר בשרטוט מאוד כללי וטכני שמטרתו יותר מהכול לראות שלא פספסנו שום דבר מהדברים החשובים (דלתות, שירותים, חלונות). כאשר אנחנו מסרטטים wireframe חלק מהרעיון הוא שלא להשקיע בעיצוב עצמו. כי אנחנו צריכים להיות מסוגלים לעשות שינויים מאוד בקלות כל פעם שאנחנו מוצאים בעיה. יש סט ברור מאוד של תבניות בעיצוב wireframe, הרעיון הוא שלא נצטרך להמציא את הגלגל מחדש.
יש מגוון כלים שמאפשרים לנו לעצב wireframe. אחד מהחביבים עלי הוא draw.io כי הוא חינמי וממש פשוט להתחיל לעבוד איתו.
אחרי שאני משרטט wireframe למוצר חדש אני מדפיס את המסכים שעיצבתי ועושה עליהם “ריצה יבשה”. כלומר מביט בתרשים המודפס ומנסה לבצע את הפעולות הנפוצות במוצר שלי. למשל באפליקציה של Business travel אני אומר “עכשיו אני רוצה לבצע הזמנה של חדר במלון”, אז אני מצביע על המסך הראשי “פה אני לוחץ על הכפתור הזה, והוא מעביר אותי למסך הזה” ואני עובר למסך הבא וכן הלאה עד שהגעתי לסוף התהליך. אם נקלתי בבעיה אני מתקן את הבעיה בעיפרון על התרשים וממשיך את הבדיקה. אחרי שסיימתי לעבור את כל הפעולות הנפוצות אז אני מעדכן חזרה את האיפיון במחשב וחוזר חלילה.
עיצוב Mockup
אם ה-wireframe היו שרטוטי המהנדס של של הדירה שלנו אזי ה-mockup הוא ההדמייה התלת מימדית של הדירה. פה אנחנו כבר רואים את הסגנון של העיצוב, את הטיפוגרפיה הרלוונטית עם הצבעים הנכונים וגם תוכן אמיתי ולא רק Lorem Ipsum. המטרה פה היא לקבל את ה-look & Feel של האפליקציה שלנו. כאן אנחנו בודקים יותר את העיצוב ופחות את הפונקציוניות.
מעבר למובן מאליו כמו לבדוק שלא שכחנו להעביר משהו מה-wireframe ל-Mockup פה אנחנו נבדוק גם מקרי קצה עיצוביים. מה המשתמש רואה בכניסה הראשונה? מה קורה כשיש ממש מעט מידע להצגה? מה קורה כשיש הרבה מאוד מידע להצגה?
עיצוב Prototype
בדימוי הדירה שלנו Prototype יהיה אחד מהדירות לדוגמה שאפשר לראות באיקאה. ממש אפשר להיכנס פנימה, לפתוח את הארונות, לסובב את הברזים. לא יקרה כלום מהפעולות הללו, הארונות יהיו ריקים, הברזים לא מחוברים לצנרת אבל אנחנו לגמרי מקבלים את ההרגשה של המוצר המוגמר. בצד הטכנולוגי של הדימוי הזה מדובר בממשק משתמש שלא מחובר ל-backend או שמחזיר ערכי ברירת מחדל או hard coded. הצגה של prototype למשתמש מאפשרת לנו לגלות אם אנחנו בכיוון הנכון מבחינת עיצוב הפתרון שלנו מבלי לעשות את כל העבודה הקשה של לבנות לגמרי מוצר מתפקד.
מסקנות
כמו בכל תהליך עיצוב, ככל שנגלה בעיות בשלב יותר מוקדם אז יהיה לנו יותר קל בחיים. שרטוטי wireframe הם קלים מאוד לשינוי ולעומתם שינויים ב-prototype דורשים יותר מאמץ.
כמובן שההתקדמות שאני מתאר פה היא לא חובה. יש חברות\מפתחים שמעדיפים לפתח ישר prototype כי הכל קל להתקדם ממנו למוצר, או כי הם מייצרים רכיב במוצר קיים ורוב עבודת העיצוב כבר קיימת ומוגדרת. בסופו של דבר כל אחד מייצר מוצר בדרך שלו. הסיבה שאני כן ממליץ לעבוד בשיטה הזו היא שלכל אחד מהשלבים הללו יש מטרה מובחנת אחרת. Wirframes מטרתם להיות חלק מתהליך העיצוב, האפיון ובדיקת העיצוב. ה-Mockup מטרתו לראות שהעיצוב עובד, וה-Prototype מאפשר לנו לתת למשתמש משהו אמיתי למחצה כדי לקבל משוב אמיתי. לוותר על אחד מהשלבים הללו מקשה עלינו להיות עם בסיס איתן שמאפשר לנו לקבל ודאות לגבי חלקים ספציפיים מהעיצוב. אם עשיתי בדיקות מקיפות ל-wireframes שלי אז אני יודע שבעיות עתידיות הם סוגיה של עיצוב ולא לא פונקציונליות.
מקווה שעשיתי לכם סדר בראש.
נעים מאוד,
אורי ליפשיץ
