27/04/2023
כאשר אנו עוסקים באפיון מתקדם למערכות מורכבות, לעיתים קרובות אנו נתקלים במצבים בהם אין לנו יכולת לעשות מחקרים מעמיקים שיוכלו לאמת את ההנחות האפיוניות שלנו.
בנוסף, רוב אם לא כל המתודולוגיות האפיוניות בשנים האחרונות שמות את המשתמשים במרכז (UCD) מה שמגביר את הבעיה האיפיונית הניצבת בפנינו. עלינו לאפיין מערכת מורכבת, לעיתים ללא גישה למשתמשים או למערכות של המתחרים. לצערנו, המצב הזה אינו מצב נדיר בעבודה היום יומית ועל מנת לאפיין נכונה מערכות מורכבות שבהן אין לנו גישה למספיק משתמשים, עלינו להשתמש גם בידע המדעי והמקצועי שצברנו אבל גם במתודולוגיות אפיון אחרות, כאלו שאינן שמות את המשתמש במרכז.
לפיכך, אם אין לנו אפשרות לאפיין לפי ניתוח משתמשים או מתחרים, נשארה בידינו האופציה כמעט היחידה והיא לאפיין לפי ניתוח של המערכת. מתודולוגיית EOUX פותחה על ידי ד"ר עופר מונר מתוך מתודולוגיה אחרת, קרובת משפחה אם תרצו שנקראת OOP – Object Oriented Programing.
ישנה עוד מתודולוגיה דומה בשם OOUX המשמשת לאפיון אך היא מדברת יותר על מטרות גדולות ולא על אפיון הלכה למעשה.
הרעיון העומד מאחורי OOP הנו שישנו ציר מרכזי לתכנות אפליקציה או מוצר דיגיטלי כלשהו וסביב ציר זה מסתובבות כל הפעולות אותן ניתן לבצע במוצר. הציר הזה נקרא ב OOP בשם ישות Entity.
על מנת להבין לעומק את היחסים המורכבים הנוצרים באינטראקציה בין משתמש למערכת, עלינו גם להבין את הקשרים השונים בין מרכיבי המערכת עצמם ובינם לבין המשתמש.
הבנת היחסים של מרכיבי המערכת בינם לבין עצמם ולאחר מכן בינם לבין המשתמש תאפשר לנו:
ההבדל העיקרי בין מתודולוגיית EOUX לבין מתודולוגיית UCD
הוא שב EOUX אנחנו לא חושבים על המשתמשים ומה הם רוצים אלא מנתחים את המערכת ואת מה שהיא מאפשרת למשתמשים לעשות בה.
אז כיצד משתמשים במתודולוגיית EOUX בפועל? ובכן זה מעט מורכב ודורש לא מעט תרגול, אך אני מאמין שברגע שמבינים כיצד המתודולוגיה "עובדת" – כל תהליך האפיון הופך להיות ברור הרבה יותר, גם ללא משתמשים. אנו למעשה מעוניינים לעבור מהתרשים הזה של UCD:
לתרשים הזה של Entity Oriented UX
למתודולוגיית EOUX יש שלושה שלבים שמטרתם בסופו של דבר לחלץ שלושה מרכיבים:
מטרתנו הסופית היא למפות את מרחב האפשרויות הלוגי של הפעולות אותן ניתן לבצע במערכת. איננו יכולים לדעת אילו פעולות יתבצעו מתי, אבל אנחנו יכולים לדעת מה המרחב האפשרי שלהן.
אם לתת דוגמא מעולם אחר, נניח שיש לנו שתי קוביות, אנחנו לא יודעים מה יצא כשמישהו יזרוק אותן אבל – אנחנו כן יודעים מה מרחב האפשרויות הלוגי האפשרי, יש לנו דרך למפות את כל האפשרויות. במקרה של קוביות, אפשר גם לחשב הסתברויות לכל תוצאה. בגלל שאין לנו משתמשים – אין לנו יכולת "לזרוק את הקובייה" כמה פעמים ולראות מה יוצא באמת, מה שהיה נותן לנו להבין גם מה המשתמשים רוצים לעשות וגם מה הם צריכים. אבל, כשאין לנו גישה למשתמשים, או יכולת לערוך מחקר – כל מה שנותר הוא מיפוי של מרחב האפשרויות – בלי לחשב הסתברויות של כל אפשרות – כי כרגע עוד אי אפשר.
את זה נעשה בעזרת ניתוח תפקידים וניתוח משימות מאוחר יותר.
מה שאנחנו כן יכולים בשלב זה הוא להבין את עולם ההתרחשות ולמפות את מרחב האפשרויות באופן לוגי – ללא מחקר.
זהו מרחב ההסתברויות של הטלת שתי קוביות.
באותו האופן, מטרתנו ב EOUX היא למפות את מרחב האפשרויות הלוגי של הפעולות במוצר.
במידה ונעשה זאת נכון, נוכל לאפיין ולמפות מוצרים שלמים – או לפחות לדעת מה מרחב ההסתברויות השלם הלוגי של הפעולות שלהם.
ישות היא משהו ש"חי" בתוך המערכת וסביבו כל המערכת מתקיימת. לישויות, כמו לדברים חיים, יש מאפיינים והן משתנות עם הזמן או עם פעולות שמבצעים עליהן.
אם ניקח אפליקציית יומן למשל – הישות שם היא האירוע.
לאירוע יש מאפיינים:
השם שלו, היכן הוא מתרחש, מי המשתתפים, מתי (שעה ותאריך) וכו'.
על האירוע ביומן ניתן לבצע פעולות שונות – לערוך אותו, למחוק אותו, לייצר אירוע חדש ועוד. הפעולות האלו שאנו מבצעים על האירוע, משנות אותו והשינוי הזה מקבל ביטוי בשדות שונים במערכת.
לדוגמא – אלו הישויות המרכזיות באפליקציות שונות:
כיצד נזהה את הישות בכל מוצר עליו אנחנו עובדים? על מנת לעשות כן, יש לעשות רשימה ארוכה ככל הניתן של כל התוכן ואפשרויות המניפולציה על התוכן שניתן לעשות במוצר ולשאול את עצמו מה כולל את האפשרויות הללו – מהו הציר המרכזי סביבו סובבת כל האפליקציה.
למשל, באפליקציית קופת חולים נשאלת השאלה מהי הישות המרכזית:
הפעולות אותן ניתן לעשות על מנת לשנות ישויות נקראות CRUD
CRUD – Create, Read, Update, Delete
באמצעות ביצוע פעולות על אובייקטים ניתן:
לדוגמא, נניח שאנחנו מאפיינים מערכת אשר מטרתה היא ביצוע פעולות שונות על תצלומי אוויר מודיעיניים (תצ"א)
נשאל עצמנו מה אפשר לעשות עם תצ"א – לא מה המשתמש היה רוצה לעשות אלא מה אפשר לעשות מבחינה לוגית, מה מרחב האפשרויות הלוגי – כמו בהטלת הקוביות.
וכדומה.
הרשימה הזו היא למעשה כל מרחב האפשרויות הלוגי שניתן לעשות עם תצלומי אוויר מודיעיניים.
נזכיר, אנחנו לא מדברים על מה המשתמשים היו רוצים לעשות כי זה שוב חזרה למתודולוגיית UCD, אנחנו מדברים על מה ניתן בכלל לעשות מבחינה לוגית.
אובייקטים הם בפשטות מרכיבי ה UI בהם "מתגוררת" הישות. על האובייקטים אנו מבצעים פעולות כאלו ואחרות, פעולות אשר משנות את הישות. לפיכך, אפשר לחלק אובייקטים לשני סוגים – אובייקטים שרק מציגים מידע על הישות ואובייקטים המאפשרים לבצע עליה פעולות ובכך לשנות אותה.
אובייקטים המאפשרים לשנות את הישות נקראים "אובייקטי ישות" ואילו אובייקטים אשר רק מציגים מידע על הישות נקראים "אובייקטי תצוגה".
למעשה – בסיכומו של דבר ובנוגע לכל מוצר דיגיטלי באשר הוא מוצר דיגיטלי –
"משתמשי המערכת עושים פעולות על אובייקטים על מנת לשנות את הישות"
כבר בפגישת ה kickoff אפשר להתחיל לשאול את עצמנו את השאלות:
זיהוי הישות בשלב מוקדם זה מאפשר לנו לא להתמקד בפיצ'ר כזה או אחר אלא להתמקד בערך אותו המוצר מספק למשתמשים ומענה ראשוני על השאלה כיצד הם הולכים להשתמש בו.
לפני שדיברנו עם משתמש אחד – אנחנו יכולים להתחיל למפות את מרחב הפעולות של כל המשתמשים.
לסיכום, ניתן לבצע את מתודולוגית EOUX עם משתמשים ובלי משתמשים, בשימוש ב B2B או ב B2C , לבד או בצוות.
המתודולוגיה הזו מאפשרת וולידציה ראשונית למרחב הפעולות האפשרי במוצר גם אם אין כלל גישה למשתמשים וצריך לאפיין מהיום למחר, גם ללא מחקר.
מה שכן, חשוב לציין כי זיהוי הישות אינו תהליך פשוט ויש לדייק אותו בעזרת תרגול רב. ככל שתתרגלו יותר, אני סמוך ובטוח שתמצאו את הערך שיש בשיטת EOUX.
בהצלחה.
