מתודולוגיות עיצוב מקבילי – לתוצרים טובים עוד יותר

גם למעצבים יש מגבלות

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

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

הפסיכולוג והמדען הרברט סימון חקר את אופן קבלת ההחלטות של מנהלים, מפקדים ואנשים בסיטואציות מכריעות. הוא הציג טענה לפיה אנו, מקבלי ההחלטות, סובלים ממגבלה אשר מונעת מאיתנו, בזמן של הכרעה, לשקול ולבחור את האפשרות הטובה ביותר מבין מספר אפשרויות. במילים אחרות, כאשר אנו נמצאים אל מול החלטה, במרביתם של המקרים נסתפק במענה הראשון שיצוץ במוחנו ויספק מענה סביר לבעיה. גישה זו נקראת גישת ה-Good Enough, או בניסוח של סימון – 'Satisficing'. שילוב של Sufficient (מספיק) ו-Satisfying (משביע רצון).

"Good enough is not good enough"

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

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

שני קווים מקבילים מתחברים

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

אחד ועוד אחד שווה שלוש

ראו איזה פלא. הרך הנולד יהיה כמעט בוודאות טוב משמעותית מכל אחד מהרעיונות הראשוניים. נסו ותיווכחו. המונח Parallel Design הוא אמנם מונח מרשים, אך מסתבר שרחוק מלהיות חדשני. במתודולוגיית Extreme Programming  לפיתוח מערכות מידע שהוצגה בשנת 1999, הוצג הרעיון של פיתוח בזוגות (Pair Programming), שנחקר והוכיח הקטנה משמעותית בכמות התקלות. אם נלך עוד אחורה בזמן, מזה שנים רבות מקובל בלימודי גמרא לבצע לימוד בצוות, אם זה בזוגות או 'בחברותא'. זאת מתוך דינאמיקה קבוצתית היוצרת הפריה הדדית, ומחדדת את החשיבה וההבנה.

חשבתם שסיימנו בזה?

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

באמצעות כלים כמו Google Optimizer, נוכל להעלות לאוויר שני דפי בית מקבילים ולפצל את האוכלוסייה ביניהם. בהתאם ליעדים העסקיים שלכם ולמדידת יחס ההמרה (היחס בין הנכנסים לאתר לבין אלו המגיעים למקום שהגדרנו כיעד), נוכל לקבל תשובה חד משמעית מגוגל על איזה פתרון עובד טוב יותר. בדיקה מקבילה כזו של שני פתרונות נקראת A/B testing.

קיימת אפשרות נוספת לבצע בדיקה עם מספר גדול יותר של אפשרויות, הנקראת Multi-Variate Testing (ולא Multi-Variant כמו שכולם אומרים). למרות האפשרות לבדוק יותר משני פתרונות מקבילים, מומלץ לבנות מודל בדיקה מתגלגל, אשר בו בכל שלב תתבצע השוואה בין שני פתרונות לכל היותר.

"אל לנו לנוח על זרי השמרים"

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