לא מזמן, כששאלנו את צ’ט GPT שאלה שהוא לא אמור לדעת (או שלא קיימת תשובה עבורה) - כמו “תרשום את 40 הנשיאים הראשונים של מדינת ישראל” - המודל היה מתחיל את הרשימה נכון, ומהר מאוד מתדרדר. 11 הנשיאים הראשונים ברשימה היו נכונים, ואז נגמר לו הידע, והוא סוג-של מייצר רעש. המודל ממציא תשובות שנראות הגיוניות על פני השטח, אך למעשה אינן מבוססות על ידע אמיתי או עקביות פנימית.
לעצור לרגע ולהגיד “אני לא יודע” זה משהו שלקח למודל שפה המון זמן ללמוד. להגיד “אני לא יודע” זה לא דבר רע - להפך, זה דבר חיובי מאוד. אנחנו צריכים להכיר בכך שהיכולת להגיד “אני לא יודע” היא אחד הדברים הכי מעצימים שיש. זו הזמנה להתפתחות - רק כשאנחנו אומרים “אני לא יודע” אנחנו מודים בכך שיש משהו שעלינו ללמוד ולהשלים.
דניאל כהנמן מדבר על נושא דומה בספר “Noise: A Flaw in Human Judgment” - הרעש הוא האקראיות בקבלת החלטות (בניגוד להטייה שהיא לכיוון מסוים, רעש הוא אקראי) שמהווה כשל בשיפוט האנושי. מדובר על הערכות שונות של אנשים כשמוצגים בפניהם נתונים זהים. נגיד, עשינו יוזר טסטינג לממשק מסוים, לכולנו מראים את אותם הנתונים - אבל בהתאם לרקע שלנו, לנסיון שלנו וההבנה שלנו של הממשק - יכול להיות לנו פידבק שונה לגמרי. אבל זה לא ממש קשור למה שאני רוצה לדבר עליו, אז עזבו.
זו תופעה מרתקת שקשורה לאיך שהמודל עובד: נגמר לו מה להגיד, אין יותר תוכן - אבל הפרומפט מחייב אותו למנות 40 כאלה, והוא עושה את מה שמצופה ממנו - לחרטט בביטחון את 29 הנשיאים הבאים של ישראל.
וזו בדיוק הנקודה שאני רוצה לדבר עליה - מה קורה לנו כשאנחנו מתבקשים לתת ביקורת על עיצוב ללא ידע מוקדם.
בואו נחלק את הפידבק ל-2 סוגים - צוות הוריזונטלי (
Review) וצוות ורטיקלי (
Critique). הצוות ההוריזונטלי - מעצבי מוצר שעובדים במחלקות מקבילות לשלי - יכולים לתת פידבק מסוג מאוד מסוים, דברים שהם יותר בגדר Review. יש חוקים שאני אמור לעמוד בהם או סטנדרטים שאני לא יכול לסטות מהם, והתהליך הזה של Peer Review הוא חשוב למטרות האלה.
ביקורת כמו
“הצבע טקסט לא נראה נגיש”, “הפונט קטן מדי”, “הצבעים לא מזמינים”, “שווה לבחון את זה על משתמשים”, “מה יקרה כשיש הרבה טקסט?”, “איך נראה ה-empty state?”, “מה יקרה כשנמיר את הממשק ל-DARK MODE?”, “זה רכיב שאין בדזיין סיסטם”, “הטאב הזה לא נראה SELECTED”, “מה יקרה אם עושים על זה HOVER?” - כל הדברים האלה יכולים להיות נכונים במידה כזו או אחרת, אבל הם לא נוגעים לתוכן, אלא מסתובבים סביב פורמליזם עיצובי.
הביקורת הלכאורה “שטחית”, שאפשר לקבל רק ממעצבים אחרים, היא לא פחות חשובה, אבל שונה מאוד ממה שאנחנו לפעמים רוצים לקבל. אם אנחנו רוצים לקבל קריטיק טוב ממעצבים או קולגות אחרות, אנחנו צריכים לדאוג שיהיה להם את
הידע המינימלי הנדרש כדי להגיב על מה שהם רואים מעבר להערות דזיין סיסטם שטחיות.
הצוות הורטיקלי, לעומת זאת, אמור להכיל את כל הידע הזה. הם כבר שוחים בנבחי המוצר שעליו אנחנו עובדים, ויכול להיות שתהליך עמוק של critique זה משהו שהרבה יותר נוח ונכון לעשות מולם. להבין באמת מה המשתמשים צריכים ומה יעזור להם, איפה אפשר לחתוך פינות, מקרי קצה משונים ועל מה אי אפשר להתפשר - אלה מחייבים ידע מוקדם שיכול להיות שיש רק להם.
בגדול,
יש ביקורת חשובה שאני יכול לקבל רק מהצוות הורטיקלי, ויש ביקורת חשובה שאני יכול לקבל רק מהצוות ההוריזונטלי.
אז, איך בכל זאת נוכל לקבל קריטיק טוב מחברים מעצבים?
כשאני מבקש ממישהו לתת ביקורת על ממשק, אני צריך לדאוג שיהיה לו המון ידע מוקדם על הפרויקט - למי הממשק מיועד, מה המגבלות שלו, מה אנחנו מצפים שהמשתמשים יעשו ואיך מתנהגים ממשקים דומים. בלי כל אלה, אין דרך שבה הוא יכול להגיב בצורה אינטיליגנטית ומעמיקה על הפתרון. במילים אחרות,
אנשים מחרטטים אם אין להם מספיק ידע. צריכים להגדיר בצורה ברורה מה המינימום ידע שלמישהו צריך להיות כדי לתת ביקורת על העבודה.
אחד הפתרונות שאני ממליץ עליהם הוא הכנה מוקדמת של המשתתפים. לפני כל Design Review, חשוב לוודא שכולם מבינים את המטרות של הפרויקט, המשתמשים, היוזקייסים והמגבלות הטכנולוגיות. זה יכול להיות דרך מיילים, מצגות הכנה (לא 400 סליידים, משהו שמכוון אותי לידע שאני צריך בצורה מהירה ותמציתית), ובמקרים מיוחדים אפילו סרטון LOOM שמסביר את הפרויקט.
לדוגמה, בפגישות באמזון (לא בטוח כמה זה נכון היום) כולם הקדישו את החלק הראשון של הפגישה לקריאה שקטה של מסמך תיאור (האגדה מספרת שאין להם מצגות בכלל) ורק בחלק השני של הפגישה העלו שאלות. זה עוזר לאנשים לפנות זמן לקריאה מעמיקה של החומרים לפני שהם בכלל פותחים את הפה. במיוחד בסביבות עבודה מרחוק, שהזמן הסינכרוני שלנו מאוד חשוב, צריך לאפשר פורמטים של ביקורת עיצוב שלא תלויים בזמן מסוים.
יותר מזה, חשוב לשים דגש על בניית תרבות של פידבק בונה ומעמיק. להגדיר בכלל למה עושים את הפגישות האלה. יותר מזה- פר פרויקט שווה להגיד על מה אני רוצה לקבל ביקורת ואיזו ביקורת. דרך אלו משקפיים הצוות אמור להסתכל על הפרויקט. למעצבים ב-Figma יש כמה מטרות מאוד ממוקדות לתהליך - המטרה של DESIGN CRITUQUE היא להוריד חסמי עבודה למעצבים, להעלות את איכות התוצרים, להבטיח עקביות ולחלוק ידע קונטקסטואלי מרחבי המוצר. אין כמעט דיון על החלקים הטכניים של עיצוב המוצר. אם יש בעיות של עיצוב גרפי או Design system אפשר לתעד אותן אוף-ליין ולהתמקד בנושאים שיש להם השפעה גדולה יותר על חווית המשתמש.
בסופו של דבר, המטרה של Design Review היא לאפשר שיתוף פעולה, פיקוח, למידה ושיפור מתמשך. זה לא אמור להרגיש כמו ביקורת טכנית אלא כמרחב לשיחה בונה ומעשירה. עם הכנה מוקדמת ומתן הקשר נכון לכל המשתתפים, אנחנו יכולים להעלות את איכות הפידבק, לשפר את המוצר, ולהבטיח שהוא יענה על הצרכים של המשתמשים בצורה הטובה ביותר. יצירת תרבות של פידבק בונה ומעמיק היא המפתח להפיכת Design Review לתהליך חיובי ופרודוקטיבי.
שיהיה בהצלחה ורק בשורות טובות ✨
ת