פורסם במקור בבלוג של Anders Ramsay. תורגם על-ידי אנה בולייבסקי
לאחרונה אני נתקל בדיונים רבים על ההבדלים בין חוויית משתמש בשיטת Agile לבין חוויית משתמש בשיטת Lean. אני מודה באשמה, השתמשתי במונחים הללו בצורה חליפית, שכן נראה לי כי שניהם מדברים על תהליכים דומים. עם זאת, לאחר שנתבקשתי לאחרונה להשתתף בפאנל מומחים בנושא Lean UX , חשבתי שזאת תהיה הזדמנות טובה להראות כי שני אלה, לדעתי, בעצם אינם זהים.
זאת השקופית בה השתמשתי להסביר את השוני בין שתי השיטות (הוספתי את כל המצגת בהמשך):
חוויית משתמש מסורתית – זה לא שהיא פשוט נעלמה
נראה לי שקל להניח כי רק בגלל שאנו מאמצים גישה שהיא Agile או Lean לתהליך העבודה שלנו, כל שיטות ה-UX המסורתיות והעקרונות הרווחים פשוט נעלמים בדרך פלא. דבר לא יכול להיות רחוק יותר מן האמת. ככל שחוויית המשתמש הופכת לגורם קריטי וקבוע בהצלחת המוצר (כלומר, אם יש לך 10 אפליקציות לבחירה שבעקרון עושות את אותו הדבר, באיזה לדעתכם יבחרו האנשים?), כך כל מה שמעצבי UX הטיפו אליו במשך שנות אור בנוגע לשמישות ועקרונות עיצוב, ראויים וחשובים מתמיד. עיצוב טוב הוא עיצוב טוב, וזה לא משנה אם אנו חיים ביקום Agile, Lean או [הכניסו כאן מונח חדש כרצונכם]. ההבדל היחיד המשמעותי באימוץ השיטות הללו הוא באיך, וזוהי בדיוק המהות של ההבדל בין השיטות .
חוויית משתמש בשיטת Agile – שיתוף פעולה וביצוע
Agile נוצר על-ידי מפתחים בשביל מפתחים כדי לפתור בעיות של מפתחים. כפי שאמר ווארד קאנינגהאם (Ward Cunningham), אחד החתומים המקוריים של מניפסט ה-Agile: "Agile הוא מזון חם המוגש במהירות". בסופו של דבר, Agile עוסק בפיתוח של תכנה פועלת באיכות ובמהירות גבוהות. בעולם של Agile זהו המדד האולטימטיבי להצלחה. עם זאת, דבר משעשע קרה בדרך אל מניפסט ה- Agile. התברר כי בניית תכנה טובה במהירות דורשת שיתוף פעולה יעיל ביותר בין הישויות הלא-בינאריות הנקראות אנשים. בלי לדון בעיצוב חוויית המשתמש, חשיבת Agile מציעה שינוי פרדיגמה מהותי בנוגע לדרך בה יש לתקשר ולהתנהל בתוך צוות הפרוייקט.
עם כל זה שיש בהחלט דברים רבים שמעצבי חוויית משתמש יכולים ללמוד מחשיבת Agile בנושא תכנה (למשל כיצד לעשות אוטומיזציה לכל מה שאפשר לעשות לו אוטומיזציה), הכדאיות האמיתית לעוסקים בחוויית המשתמש נמצאת בחלק של שיתוף הפעולה. שיטות Agile כגון Design Studio וCross-Functional Pairing מסייעות לעוסקים בחוויית המשתמש להמיר מסמכי אפיון איטיים וכבדים בעיצוב אינטראקטיבי. במילים אחרות, תהליך אפיון חוויית משתמש בשיטת Agile מאפשר למעצבי חוויית משתמש להמיר שיטת עיצוב ממוקדת מסמכים בשיטת עיצוב ממוקדת שיתוף פעולה. לשינוי הקטן הזה יש משמעות גדולה מאוד עבור מעצבי חוויית משתמש שעובדים עם צוותי Agile, מכיוון ששינוי זה מאפשר להם לשלב את שיטת העבודה שלהם עם זאת של מפתחי Agile.
חוויית משתמש בשיטת Lean – מדידה ומתן תוקף להתאמה לשוק/מוצר
מגניב, אז עכשיו יש לנו את מכונת ה-Agile הזאת המאפשרת לנו להיות יעילים ביותר בפיתוח תוכנה. אך האם מישהו עצר לבדוק האם אנחנו מעבירים את התכנה הנכונה? חוויית משתמש בגישת Lean מדגימה לנו ששלב ה-shipping, המהווה את גולת הכותרת של עולם ה-Agile הוא למעשה רק ההתחלה. בזמן ששיטות Agile מסייעות למעצבי חוויית משתמש לשנות את דרכי העיצוב והתקשורת הישנות, Lean UX מסייע לנו להפוך גישות ישנות למדדים של איכות בפרויקט.
במודל המסורתי, מחקר הוא משהו שעושים לפני שמתחילים ליצור את המוצר על-מנת לברר מהם החומרים מהם נבנה את המוצר. בגישת Lean אנו בונים ומלקטים נתונים בנוגע למה שבנינו באופן רציף. הדוגמא הטיפוסית ביותר לכך היא עמוד נחיתה, שנוצר ומושק ממש בתחילת הפרוייקט, הרבה לפני שהפרויקט ה"גמור" יוצא לאוויר העולם. אנו הופכים את מה שפעם נתפס כשטויות שיווקיות, לניסוי ממשי של ההיפותזה אשר בבסיסה עומדת השאלה: האם משתמשים יאהבו את הרעיון שלנו כמו שאנחנו אוהבים אותו. לאחר מכן, הנתונים שנאספו מתוך אותו עמוד הנחיתה (שיכול גם להתפתח לאתר גדול ובוגר האוסף מידע) מוזנים חזרה אל תוך תהליך עיצוב המוצר.
אך עמוד נחיתה הוא רק דרך אחת בה ניתן להשתמש ב-Lean UX. דפוס מקובל אחר הוא ליצור פרוטוטייפ פשוט. כן, לצאת מהבניין, מתוך הקיוביקלס הנוחים שלכם והמשרדים וממש לקחת את הרעיון שלכם למקום בו נמצאים המשתמשים שלכם. אנחנו, במודל הזה, לא מבצעים מחקר לפני או אחרי שהמוצר נבנה, אלא במהלך התהליך בו המוצר מתעצב ונבנה. בזמן שבמודל Agile , בנייה היא עיצוב היא בניה, במודל Lean בניה היא מחקר היא בניה, וקל לראות כיצד שני אלה שלובים זה בזה. כמו עם Agile UX מודל זה מאפשר לשלב בקלות רבה יותר מחקר יחד עם שיטת העבודה של צוותי Agile מכיוון שהוא מתמשך ולא נקודתי.
בשורה התחתונה: בשיחות יום יום, בין אם אנו משתמשים במונח "Lean" או " Agile" או מה שזה לא יהיה, זה לא באמת חשוב. מה שיותר חשוב הוא ההבנה כיצדLean ו- Agile יכולים לסייע לנו בהפיכת חוויית משתמש מסורתית לפרקטיקה יותר הוליסטית.
אה, והנה המצגת השלמה מתוך הרצאת הפתיחה בת העשר דקות שנתתי בפאנל בנושא Lean UX.
למרות שאני מסכים עם השורה התחתונה, אני חושב שהאבחנות לא מדויקות.
אחד העקרונות הבסיסיים של Agile (פיתוח) הוא בדיקת המוצר מול העולם ובדיקה עצמית כל ספרינט. כלומר כל שבועיים עד חודש. זה כולל – העמדת גרסה עובדת, הצגה ובדיקה שלה מול "בעלי המוצר", לקוחות, משתמשים, ושאר בעלי עניין. בנוסף, (בניגוד למצגת) הספרינטים והשיפורים לעולם לא נגמרים. אפשר לשחרר גרסה ממשית פעם בשבועיים, חצי שנה או שנה. עם זאת וללא קשר, המעגל של פיתוח ובחינה כל ספרינט לעולם ממשיך. קל מאוד לראות איך זה מתורגם מפיתוח לחוית משתמש ואיך זה נופל בדיוק להגדרות של Lean כפי שהן מופיעות כאן.
בקיצור, Agile הגיע מעולם הפיתוח, Lean מעולם הביזנס. מבחינתנו, אנשי חווית המשתמש זה אמור להתפרש לאותו הדבר פחות או יותר.