סטיבן אנדרסון רשם עוד ב-2012 על חוויית משתמש: “נמאס לי לדון בחוויית משתמש. נמאס לי להגיד מה זה ומה זה לא. נמאס לי לדבר על wireframes נגד prototypes. נמאס לי מדיונים סביב agile-lean-waterfall. אני עייף משיחות על פרסונות ומפות אתר…”. סטיבן ממשיך לציין דברים שאינו אוהב, אך אני בהחלט יכולה להבין למה הוא מתכוון כשהוא רוטן כך.
עיני נחה דווקא על הסעיף בו הוא ציין את Agile-lean.
במידת מה, אני מסכימה איתו. הדיון סביב הנושא מזמן גלש מהמישור העקרוני, ובתוך הקהילה הקטנה ממילא של מעצבי UX מתחילות להתהוות תתי קבוצות, הדוגלות בצורות העבודה ה”מוזרות” הללו.
היות ונשאלתי מספר פעמים בנושא (“איך את אישית עובדת?”, “האם יצא לך לעבוד בצורה X?”, “גישה? מה, יש גישות?!”), החלטתי לרכז עבורכם בפוסט קצר את עיקרי הדברים.
Taken from Pixabay.com
מה זה בעצם Lean UX?
במשפט אחד: מתכננים ומבצעים את כל המוצר בשלמותו מההתחלה, ולאחר מכן מתקנים ומשנים.
המדד: אם זה נוח לשימוש.
Lean היא גישת הפיתוח שנחשבת “מסורתית”. בפועל, מדובר בעיצוב מונחה בדיקות, מדידה והתאמה גם לאחר שהמוצר מושק. עיצוב חוויית משתמש בשיטה זו תדרוש שיתוף פעולה בין מספר גורמים תוך פיקוח “עסקי” מלמעלה (על מנת לוודא שהמוצר עומד ביעדים) וכאן בפועל גם קיימת האופציה של להשיק מוצר מלוטש ולהמשיך לשפר אותו לאורך זמן, על ידי איסוף וקבלת מידע ממשתמשי קצה או קבוצת ביקורת מסויימת.
כאן מושקע זמן רב במחקר שוק, הבנת הצורך, שיחות ודיונים וכן הלאה.
המחקר כאן, למעשה, הוא גולת הכותרת. בגישה זו ככל הנראה מעצב חוויית המשתמש יבלה את חלק הארי של זמנו בחשיבה ולאו דווקא בעיצוב.
ומה עם Agile UX?
במשפט אחד: מגישים מוצר מינימלי מתפקד במהירות הגבוהה ביותר שניתן.
המדד: אם זה מתפקד ומישהו היה משלם על זה.
ההבדל בין שתי הגישות ניכר כשמשווים את גישת ה- Lean לחברתה Agile. השם עצמו מרמז על זריזות, וכאן בעצם נעוץ השורש להבנת המונח.
כבר שמעתי דוגמא לפיה Agile UX מושווה להזמנת אוכל מהיר: מדובר בפיתוח שנועד לענות על צורך “בוער”, במהירות שיא. לכן – מהירות היא אכן שם המשחק.
כגישה שהותאמה במקור למפתחים, כאן יש יותר דגש על עבודה בצוות, איטרציות רבות וחשוב מכל – זמני שיא. לכן, במקרים רבים השאיפה היא להשיק את המוצר כמה שיותר מהר, במטרה שהמוצר פשוט יתפקד, ולהמשיך לשפר אותו ללא הרף.
גישה זו, שמקורה בתחילת ימי הסטארטאפים העליזים, טובה מבחינת יכולת להציג תוצר במהירות (לפני שמתחרה יציג, למשל), אך גם עשויה להקשות על אדם שנמדד למעשה ביצירתיות ומחשבה על הפרטים הקטנים.
מה יותר טוב?
התנסיתי בשתי הגישות, ואף על פי שאני נוטה להשקיע את הזמן הראוי במחקר והבנה, גם עבודה תוך מתן דגש על מהירות היא מאוד פרודוקטיבית.
אני לא חושבת שניתן ליצור כלל אצבע לפיו ניתן יהיה להתבונן על פרוייקט ולהחליט “או! לכאן מתאים Agile UX” או “גישת ה-Lean פשוט תפורה על הפרוייקט הזה”, זה לא כל כך פשוט. הבחירה תלויה במספר גורמים – מי הם השותפים לפרוייקט, מהו המניע הכלכלי, מהם הדדליינים, מיהו קהל היעד וכן הלאה. כמובן שלהשיק אפליקציה לחובבי טכנולוגיה תאפשר עבודה זריזה ותיקון באגים בהמשך (הם אנשים טכניים, הם יבינו), ואילו משהו שפונה לקהל יעד כללי יותר אמור להיות מעט יותר מלוטש ומחושב.
חשוב לציין כי לעיתים מתקיים שילוב כלשהו של שתי הגישות – נושא שרוב המקצוענים יבחרו להצניע. מה זאת אומרת? למשל – לאפיין במשך חודש, אך את הביצוע עצמו לסיים ב”מרתון” של יומיים. גם זה קורה וכולנו מכירים זאת.
הידע להתנהל בשתי הגישות מעניק כלים נוספים לארסנל. אם אתם טובים במה שאתם עושים ולקוחות/מעסיקים בוחרים לשלם לכם על כך – מה טוב! שלבו את המונחים הללו בלקסיקון שלכם, כך שבמידה ותגיעו לפרוייקט שידרוש מכם את אחד המושגים, תדעו במה מדובר.
גם כמישהי שעבדה בצוותים שפעלו בשתי הדרכים, לא הייתי מגדירה את עצמי כמעצבת בגישה X או Y, שימו דגש ומחשבה על המשתמש ובעיקר על התועלת הניתנת לו.
ובסופו של דבר
לא משנה באיזו גישה תעבדו – אפילו אף אחת מהן – המשיכו לייצר תוצרים טובים!
שום גישה או מילה מפוצצת אינם תחליף לעבודה איכותית, ובסופו של דבר השאיפה האישית שלי היא לייצר תוצרים שאהיה גאה בהם, גם אם ביצעתי אותם תוך דקות בודדות או חודשים ארוכים, לבד או בצוות.
אם המשתמש לא יאהב את מה שהוא יראה, אין למלחמה בין הגישות שום משמעות.