top of page

כאן נרשמים לקבל עדכונים לגבי פוסטים חדשים

תודה, נתראה בספאם (:

  • Snapchat
  • Facebook
  • Twitter
  • LinkedIn

על דגים מוזרים ויהלומים כפולים

Tal Solomon

עודכן: 26 בנוב׳ 2024

נתחיל בתודות

ביום שלישי האחרון הצגתי בכנס COM.PLEX 2024 את מודל הדגים שהמצאתי במהלך התקופה שלי בחברת רדיס (Redis).

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

  1. ברק דנין, סר הכנסים של קהילת ה- UX,

  2. שירלי ארמלנד-חן, נסיכת המצגות והמבקרת הראשית של ההרצאה שלי,

  3. ויטלי מיז'יריצקי, אולי אחד הא.נשים שאני הכי מעריך במקצוע שלנו שהיה המבקר החיצוני הראשון של ההרצאה ועזר לי להעיף חלקים מיותרים,

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

  5. וכמובן נועה אשתיייי המהממת שהייתה הקהל הכי אובייקטיבי ומקצועי שיכולתי לבקש מבת-זוג.


ותודה ענקית לכל מי שנכחו בכנס 🙏


יאללה, לעניין

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


במידה ואתםן מעוניינים/ות לשמוע יותר על ההרצאה או לעבור סדנה בנושא ביחד עם הצוותים שלכםן (לאו דווקא רק המעצביםות!) אנא פנו אליי במייל או בלינקדאין.


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


אוקיי, אז למי שאין מושג על מה אני מדבר בכלל, בהרצאה הצגתי את המודל שלי שנקרא מודל הדגים. מודל הדגים מבוסס על גישת היהלום הכפול (the Double Diamond) בה אני משתמש בערך עשור, תוך שאני מייעל אותה לכדי תהליכים מאוד מוגדרים עבור 4 סוגי פרויקטים שונים המיוצגים על ידי 4 דגים.


יהלומים כפולים

כשהגעתי לרדיס במטרה להקים את צוות עיצוב המוצר (תוך שאני יורש מעצבת ומעצב קיימים) נתקלתי בכמה נקודות שהרגשתי שהגבילו את היכולת של הצוות לדלוור עיצובים בצורה אג׳ילית ויעילה:

  1. המעצבים/ות לא היו מעורבים בספרינטים של צוותי הפיתוח ובגדול לא היו מעורבים במה שמכונה באג׳ייל Squad.

  2. חוסר בשפה משותפת בין הפיתוח למעצבים/ות, עם טלפון שבור בדמות מנהלי/ות מוצר שמעבירים את המידע מצד לצד תוך עדכון שוטף של PRD מפלצתי.

  3. מיקבול לא נכון של משימות עיצוב. אמנם המעצבת המובילה מיקבלה משימות בעל-כורחה (מעצם העובדה שעד חצי שנה לפני שהצטרפתי היא הייתה המעצבת היחידה) אולם האופן בו משימות מוקבלו היה על-בסיס רודמאפ ולא על בסיס זמינות או לוגיקה שתמקסם את היכולת של המעצבת.


רדיס מפתחת מוצר מאוד טכני, דאטהבייסים, שלי אישית (ולכל המעצבים/ות שגייסתי) לא היה ניסיון מוקדם בתחום. המשתמשים העיקריים של רדיס הם Dev-ops, אותםן חבר׳ה שדואגים שכל היבטי הפיתוח ינגנו יפה יחד (כולל הדאטהבייסים הנדרשים לשמור את המידע שיושב או נכתב באפליקציה שמחוברת לאותו דאטהבייס).


כשהגעתי, לא היה לשותפים שלנו (מפתחות, מנהלי מוצר וכו׳) ניסיון עם תהליכי עיצוב מוכווני-משתמש. עיקר העבודה (אז) הייתה להוריד לנייר (בצורה שמישה לחלוטין) את הפתרונות של מנהלי המוצר לחוסרים ביכולות שמשרתים בעיקר את ה- Design partners של רדיס. שלב קריטי בחיים של כל סטרטאפ שאי פעם הוקם. אממה, ניכר היה שבשיחות שלנו עם השותפים אנחנו בעיקר מדברים על פתרונות או צרכים טכנולוגיים ופחות על צרכי משתמשים הנובעים מחוויית משתמש (UX) לא טובה (לעומת חוסרים פונקציונליים יבשים).


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


המקום היחיד שתראו דאבל דיאמונד מימין לשמאל

הגישה משתמשת ב- 2 יהלומים המייצגים 2 ״מרחבים״:

  1. מרחב הבעיה, בו נרצה להבין למה משהו קורה.

  2. מרחב הפתרון, בו נרצה לייצר את הפתרון הטוב ביותר לבעיה שמצאנו ביהלום הראשון.


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


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

חלק מהשיטות הן המצאות שלי שפיתחתי במהלך הדרך (ט.ס.)

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


עובדה חביבה (fun fact)

ה- UK Design Council העומדים מאחורי הדאבל דיאמונד, למעשה ביססו את המודל שלהםן על מודל ה״פתיחה-סגירה״ (the divergence-convergence model) שהוצג לעולם על-ידי Béla H. Bánáthy, איש תנועת הצופים (וחוקר שפה) אמריקאי-הונגרי, שהמציא את המודל שלו עבור קורסי הדרכה בתנועת הצופים האמריקאית. כבוגר ומרכז לשעבר בתנועת הצופים, אני מוצא את זה משעשע במיוחד. הייה נכון!

דגים מוזרים

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


כאמור, את הבעיה הראשונה יכולתי לפתור ״על המקום״ באמצעות הדאבל דיאמונד:


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


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

אח״כ ביצעתי יחד עם הצוות HMW (How Might We) מהיר שעזר לנו להבין טוב יותר את מוקד הבעיה ולג׳נרט פתרונות ״מעוצבים״ עוד לפני שגיבשנו הגדרת בעיה סופית.


שיטת ה- HMW מאפשרת לדמיין פתרונות אפשריים לבעיות הנכונות על-ידי שאילת השאלה How Might We שהמשכה מסנתז בעיה ופתרון. למשל (בעברית): ״איך נוכל לגרום למשתמשיםות להרגיש בטוחים בזמן שהם מכניסים את פרטיהםן לאתר שלנו בתהליך ההרשמה אליו״.

הצעת הפתרון שלי הסתמכה על יצירת Tooltip שישמש כמעין ״שלט״ שמצביע (או צועק) הי! זה השלב הבא! תלחצי פה! וזה נראה משהו כזה:


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


כאתגר UXי, זה אתגר מאוד פשוט:

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


הפרויקט השני, לעומת זאת, היה שונה בתכלית.

זה היהה פרויקט שהתחיל עבורי בללמוד מושג חדש (שהיווה את שם הפרויקט, משהו עם Access Control) והמשיך עם עוד עשרות מושגים חדשים שמעולם לא שמעתי (או קראתי) בחיי, כמוgeo-distribution, regions, replicas, active-passive, ועוד.


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

יש פה הרבה יותר שלבים עד שנוכל להתחיל לדבר על ״פתרונות״:


ואז מנהל המוצר אמר את המשפט שהיה כל מה שחסר לי כדי לארוז את המודל שלי:

״אז זה בעצם... וואחד יהלום?!״

כן, וואחד יהלום indeed.

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


פה הבנתי שאני יכול לחלק את כל הפרויקטים שעשיתי ושנעשה בהמשך ל- 2 צירים מרכזיים:

היכרות מוקדמת והיקף.

צד שמאל למעלה: פרויקט קטן (היכרות גבוהה והיקף מצומצם) צד ימין למטה: פרויקט גדול( היכרות נמוכה והיקף רחב)


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


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

פנצ׳ר בגלגל? בעיה לוקלית, ברגע שנחליף את הגלגל הספציפי (הנקור) הבעיה תיפתר.

זיהום אוויר? בעיה גלובלית, גם אם נטפל במיכלי האמוניה שבעיר חיפה, עדיין יהיה זיהום גבוה מאוד בישראל ובשאר העולם (שככל הנראה לא יושפע מאוד מהשיפור באיכות האוויר החיפאי).


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


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



נשארו לנו כרגע 2 רבעונים במודל שטרם הזכרנו.


נתחיל עם הרבעון הימני העליון (בעיה מוכרת + היקף מסכים צפוי גדול). שוו בנפשכםן הוספה או עיצוב מחדש של מערכת תשלומים חדשה (billing system). מערכת תשלומים היא פתרון שקיים בכל מערכת SAAS ולכן סביר להניח שכבר עיצבתםן כזה בחייכםן המקצועיים, וחשוב מכך - סביר שהמשתמשים שלנו כבר פגשו מערכת כזו באחד המוצרים האחרים שהם עובדים איתו. למעשה, מכיוון שאנחנו יודעים שמדובר על סוג של פיצ׳ר שיהיה נוכח בכל מערכת SAAS, אנחנו נרצה לא להמציא את הגלגל מחדש ולהשתמש במה שאנחנו קוראים לו קונבנציה. אנחנו נעצב את מערכת התשלומים שלנו על בסיס אלו שהמשתמשים שלנו כבר ראו ופגשו. משמע שתהליך המחקר המקדים יהיה ממוקד מאוד וככל הנראה גם קצר, שכן אנחנו בעיקר נסקור את המערכות שהמשתמשים עובדים איתן ונוודא שהן עונות על כל צרכי המשתמשים שלנו.


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




וברבעון האחרון (שמאלי-תחתון) אנחנו נמצא את הפרויקטים הפותרים בעיה מקומית שלנו כמעצבים יש רמת היכרות מאוד נמוכה איתה, מה שידרוש מאיתנו לבצע לא מעט מחקר מקדים.


דוגמה טובה תהיה פרויקט שקראנו לו - Maintenance window, ובעברית - חלון תחזוקה.

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


אבל! תהליך תחזוקה כולל זמן Down-time בו האפליקציה של הלקוחות שלנו תהיה מושבתת (זו הסיבה שאת רוב חלונות התחזוקה עושים בסופי-שבוע או בשעות הקטנות של הלילה). בשל זאת ועוד, אנחנו רצינו לוודא שאנחנו ״מחקים״ את התהליך של ה- CSעם מול הלקוחות שלנו ובכך מונעים השבתה לא מתוכננת של האפליקציות שלהםן.


ומרגע שסיימנו ללמוד על התהליך, תהליך העיצוב יהיה מהיר, משום ש

  1. מדובר על בעיה לוקלית, ומשום כך גם הפתרון יהיה לוקלי.

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




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


ואז הסתכלתי עליו ופשוט ראיתי את זה..


דגים.


הכל הזכיר לי דגים פתאום.



מודל הדגים

במודל הדגים יש לנו 4 דגים שמייצגים 4 סוגי פרויקטים: 



נמו.

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


טונה.

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


סלמון.

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


ווילי.

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




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

איך? 

אה, כי אני יודע (כמעט) בדיוק איך יראה תהליך העבודה עליהם. לכל דג יש את המתודות שלו שהופכות אותו לדג שהוא:


נמו.

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


טונה.

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



סלמון.

בפרויקטים מסוג סלמון שאותם תוביל החוקרת שלנו, נשים דגש על הפן המחקרי:

נדבר עם משתמשים, עם שותפים לא-מעצבים ולמעשה עם כל stakeholder שנוכל.

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



ווילי.

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

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




תסתכלו על השקף הזה:


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

לא המון משימות. האמת, משימות בודדות שרובן המוחלט מתוכננות מראש, כלומר חלק מהרודמאפ.


אבל תראו מה קרה ברבעון שאחריו:


לא רק שהצלחנו להכניס יותר משימות רודמפאיות (מתוכננות) אלא גם הצלחנו להתמודד עם המון משימות שלא היו מתוכננות בכלל או משימות איטרציה - שלבי ב׳ של משימות שלא הצלחנו להגיע אליהן עד כה…!



יוצאים מהמים

זוכרים איך התחלתי? עם כל הבעיות שזיהיתי כשהגעתי לרדיס? אז חשוב להגיד שכמובן לא לי כל הפתרונים וכמובן שיש עוד המון בעיות שצריך לפתור כשניגשים לייצר תהליכי עיצוב איכותיים (וכמובן לא רק ברדיס) אבל כשעזבתי את רדיס:


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

  2. שפה משותפת: מרגע שכולנו דיברנו באותה שפה, השותפים ידעו להתכונן בהתאם - בין אם בלגייס צוות שיבנה ספריית קומפוננטות עבורנו (component library) - אגב, בלי שביקשנו אפילו, ובין אם להפנות משתמשים לחוקרת ה- UX או לפגוש את המעצביםות כדי לרדת לעומקן של נקודות טכניות שהקשו עלינו לייצר עיצובים ״מתקדמים״ ובכך הם בעצם הפכו להיות שותפים מלאים שלנו לתהליך העיצוב.

  3. רק מיקבול משימות: ברגע שיש שפה משותפת ואנחנו עובדים באג׳ייל, מאוד קל להכניס עוד משימות נמו קטנות, למשל לטובת growth או כל מיני ניסויים, מה שבתורו מאפשר גם להגדיל את הקשר עם לקוחות ה- Low touch ובכך לתמוך עוד יותר במה שאנחנו קוראים לו עיצוב מוכוון-משתמשים 💪.



ונסיים עם איך אתםן יכולים לקחת את מודל הדגים אליכם למוצר.


חשוב שתבינו - במודל כזה תקשורת היא המפתח שלנו להצלחה. אנחנו צריכים לעשות הכל כדי להיפטר מכל תהליך שלא מעודד תקשורת פתוחה וגמישה. למשל להחליף את ה- PRDים שלנו בבריפים קצרים (micro-brief) וישיבות ייעודיות לפרויקט.

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


כדי להטמיע מודל בחברה שלכםן, אתם צריכים חברות חזקה עם השותפים הלא-מעצבים שלכם

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


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





 


ולסיום, שאלת בונוס:

למה קראתי להרצאה ״דגים מוזרים״ ואיך זה מתקשר ללהקה האהובה עליי בתבל?



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



בשורות טובות לכםן ולכל עם ישראל 🙏

4 Comments


Itamar Serfaty
Itamar Serfaty
Nov 24, 2024

הרצאה מעולה. מחכים למצגת 🙏

Like
Tal Solomon
Tal Solomon
Nov 26, 2024
Replying to

הי איתמר, תודה!

לא אעלה את המצגת, אבל רוב השקפים פה (:

בהצלחה

Like

Nir Hosha Alon
Nir Hosha Alon
Nov 21, 2024

דבר ראשון, תודה על הרצאה מעולה.

אהבתי מאוד ללמוד צורת חשיבה חדשה לאבחון וניהול משימות.


מתי תוכל להעלות את המצגת?



Like
Tal Solomon
Tal Solomon
Nov 26, 2024
Replying to

הי ניר, תודה!

לא אעלה את המצגת, אבל רוב השקפים פה (:

בהצלחה

Like

מחפשים עוד דואר זבל להתעלם ממנו? הירשמו והגשימו את חלומכם!

תודה אלוף/ה! נתראה ב- Spam 🫶

© 2024 by Gestalt UX. All rights reserved to Tal Solomon

bottom of page