המדריך האולטימיטיבי לעבודה מרחוק

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

הערכת מומחה ככלי לשיפור המוצר

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

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

 

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

 

1.     שקיפות סטטוס המערכת
המשתמשים תמיד צריכים להיות מיודעים לגביי מה המערכת/המוצר עושים בפרק זמן סביר.

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

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

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

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

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

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

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

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

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


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

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

 

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

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

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

כיצד למדוד את השפעת העיצוב שלנו על המוצר

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

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

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

פירוק העיצוב הנמדד לפרויקטים קטנים
בשלב הזה תהליך העיצוב צריך להכיל חשיבה בהיבט של צמיחה. כדי לבחון את השפעת העיצוב על המוצר עלינו לפרק את העיצוב לחלקים קטנים ומדידים, לבודד את השינוי ולתעד אותו באופן ברור לכל הצוות.
לדוגמא:
הנחה1: הצעת חבילת הזמנות (קנו 4 קבלו 5) מגדילה את מספר ההזמנות.מבחינה איפיונית עלינו לכוון את המשתמשים לרכוש חבילת הזמנות בתדירות גבוהה יותר, זה יכול להיעשות כupsell/add on או עיצוב מחדש של דף הבית.
הנחה 2: הגדלת מספר הפעמים שהמשתמשים קוראים ביקורות משתמשים והגדלת זמן השהיה שלהם בדף הביקורות, תגדיל את הרכישה.

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

מאמר מקור: https://uxplanet.org/a-practical-example-of-how-to-measure-the-impact-of-design-a939a2ae5864

KPI ולמה זה חשוב

כתבה על חשיבות ה-KPI
Key Performance Indicator (או בעברית מדדי הצלחה) לאפיון מוצרים.
קיי. פי. איי הוא ערך מדיד אשר מתאר עד כמה החברה הצליחה להגיע ליעדים העסקיים שלה.
הצלחה מבוססת על השאלה: מה המטרה? שהיא בעצם התוצאה שאנחנו רוצים להשיג
 המדד מבוסס על השאלה: כמה? שימוש בשאלה הזו יוצר בסיס להשוואה, כלומר האם הבחירות שבצענו שירתו את המטרה.
מדוע קיי .פי. איי הוא כלי נחוץ לאפיון?
1. ביסוס תקשורת משותפת
בעזרת קיי .פי. איי ניתן לבסס שפה משותפת בין כל המחלקות.כחלק מהעבודה עם צוותים שונים עלינו לוודא שאנחנו תופסים את ההצלחה באותו האופן.  כשיש קיי. פי. איי מוסכם קל יותר להבין האם הצלחנו להשיג את המטרה.
בעבודה מול הנהלה הגדרת מדדים מקלה עלינו לבצע את ההשוואה בין לפני ואחרי. שימוש בשפה מוגדרת ערכים תהפוך את התקשורת שלנו ליותר אובייקטיבית.

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

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

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

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

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

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

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

חשיבותן של מיקרו אינטראקציות בממשק

אז מה הן בעצם מיקרו אינטראקציות?

מיקרו אינטראקציות הן אנימציות קטנות וקצרות שקורות כאשר המשתמשים מסיימים לבצע משימה מסוימת, מטרתן לייצר רגעים של מעורבות ולתת פן אנושי יותר לממשק (דילייט).
למיקרו אינטראקציות יש ארבעה מרכיבים עיקריים:
טריגר – הטריגר מתחיל את מיקרו האינטראקציה, הוא יכול להיות מופעל ע”י המשתמשים או ע”י המערכת (כאשר המערכת מזהה תנאים להפעלת האנימציה).
חוק – ההגדרה למה שקורה אחרי שהאנימציה הופעלה
פידבק – נותן למשתמשים להבין מה קרה, כל דבר שהמשתמש רואה, שומע, מרגיש בזמן האנימציה.
לופ – כיצד משתנה האנימציה כשמשתנה החוק והתנאים שמפעילים אותה.
מדוע מיקרו אינטראקציות חשובות?
מיקרו אינטראקציות עושות את ההבדל בין אתר/מוצר מובן ומהנה לבין כזה שהוא לא. הן מוכיחות שנעשתה חשיבה עמוקה על המוצר ועל המשתמש עד לפרטים הקטנים ביותר.
מיקרו-אינטראקציות עוזרות ב:
• ניווט באתר
• מקלות על האינטראקציה בין המשתמשים למוצר
• נותנות מידע על אלמנטים בממשק והאם הם לחיצים או לא
• מכוונות את תשומת לב המשתמשים
• הופכות את הממשק ליותר אנושי
מתי להשתמש במיקרו אינטראקציות
דוגמאות לשימוש נכון במיקרו אינטראקציות
Swipe- אנימציות מהסוג הזה מפחיתות לחיצות והופכות את החוויה להרבה יותר חלקה ואינטראקטיבית. הן עוזרת למשתמשים לעבור בין טאבים על מנת לקבל עוד מידע. מדובר בהתנהגות מאוד מוכרת ומקובלת כך שניתן לבצע אותה באופן כמעט אוטומטי ולהבין מה יהיה הפידבק.
Data Input -כולנו מכירים את התסכול של להכניס לקבוע (למחוק) סיסמא שעשויה להיות לא נכונה בשדה
.אמנם אנימציה של חוזק הסיסמא היא מוכרת וידועה אך אנימציה שמעדכנת את חוזק הסיסמא תוך כדי ההקלדה, נותנת פידבק חזק יותר למשתמשים.
• טוטוריאליים –שימוש במיקרו אינטראקציות בטוטוריאליים הופך אותם ליותר אינטראקטיביים, ועוזר לכוון טוב יותר את המשתמשים לעבודה נכונה עם המוצר ע”י הפשטת התהליך והדגמתו.
• הנעה לפעולה- מיקרו אינטראקציות דוחפות קלות את המשתמשים לאינטראקציה עם הממשק. הן מספקות תחושת הישג, ומחזקות את האמפטיה של הממשק ביחס להתנהגות המשתמש.
• כפתורים מאונמצים-כפתורים מאונמצים מכוונים את דרכם של המשתמשים במוצר, והן דרך טובה למקד את תשומת ליבם של המשתמשים למידע. חוויות קטנות כמו מעברים בין מסכים או הדגשה של פיצ’רים מסוימים יכולים לעשות הבדל ענק בחוויה הכללית.
כיצד לעצב מיקרו אינטראקציות
• שימו את עצמכם בנעלי המשתמשים- השתמשו בכל הכלים שלכם כדי לעזור למשתמשים להבין את המוצר.
• צרו אנימציות פונקציונליות- אנימציות שהן לא רק יפות אלא גם מגבירות את החוויה במוצר.
• תהנו- ההנאה שלכם תעזור לייצר מוצר כיפי יותר, מה שיגרום למשתמשים להפוך למשתמשים חוזרים.
• אל תעצבנו את המשתמשים- יותר מדי אנימציות יכולות להשיג את האפקט ההפוך ממה שאנחנו רוצים ולעצבן את המשתמשים.
• שימוש בשפה אנושית- השתמשו בשפה אנושית ולא טכנית. קופי אירוני או משעשע יכול לגרום למשתמשים לשכוח כמה זה מתסכל להגיע לדף ריק.

 

ההבדל בין מוצרים מכוונים משימות משתמש למוצרים מוכוונים מטרות משתמש

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

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

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

מאמר מקור: https://uxdesign.cc/start-designing-with-goals-in-mind-4723df5f8e88

מפת אמפטיה, מפת מסע משתמש וההבדלים ביניהם

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

רפואה ומוצרים דיגיטליים

הפעם אמל”ק בנושא סופר מעניין וקרוב לליבי, רפואה ומוצרים דיגיטליים.
שני הסנט שלי ממספר מאמרים שקראתי בנושא, רפואה דיגיטלית או מכשור רפואי נמצאים באזור בו הטכנולוגיה היא סופר חדשנית אך נוחות הממשק והנראות שלו, לא תמיד מהווים את המילה האחרונה בתחום UX/UI.
לשמחתי הרבה ישנה מגמת שיפור בעניין ומוצרים רפואיים מתחילים ליישר קו עם עולם ה UX/UI.
הכותב מספר בכתבה על משפט שאמר לו אחד הרופאים במחקר המשתמשים שלו:
הדרך להפוך את מלאכת התיעוד לקלה יותר היא לזרוק את המחשבים מהחלון.
אמירה זו נובעת מהתסכול שחש אותו רופא מהמאבק שלו בתיעוד הערות המטופל- דבר שלקח לו מספר דקות כשהוא היה צריך לכתוב את זה באופן ידני.
רופאים בארצות הברית משקיעים 4 שעות אקסטרה בכל שבוע בתיעוד אלקטרוני של רשומות רפואיות.
הבעיה טמונה בכך שרפואה דיגיטלית בדרך כלל מפותחת כטכנולוגיה והן נועדו לענות על שאלות כמו איך אנחנו יכולים לחבר את כל המערכות האלו? איך להבטיח את סודיות המידע הרפואי?
1. צאו מנקודת הנחה שאנשים לא מקבלים הכשרה
תוכנות בתחום הרפואה מגיעות עם מדריך של מעל 100 עמודים מנוסחים בסגנון לחץ על X כדי לבצע Y. הציפיה מהעובדים בתחום הרפואה היא לשבת ולעבור את ההכשרה הזו אך בפועל אין להם את הזמן. המרפאה עמוסה בחולים אז הם מלמדים את עצמם ומנסים למצוא לבד את הדרך בחשכה. במקרים אחרים הקורס מתבצע חודשיים לפני שהם משתמשים במוצר בפועל לכן:1) צאו מנקודת הנחה שהעובדים לא מקבלים הכשרה. תכננו את המוצר באופן אינטואטיבי מספיק כדי שהם יוכלו לבצע פעולות בסיסיות כמו הוספת מטופל ומדדים, ואז למדו אותם לעשות את הדברים המורכבים יותר בהקשר שבו הם צריכים או עפ”י דרישה.
2) השתמשו בשפה שלהם ואל תמציאו שפה ייחודית לתוכנה שלכם.

2. עזרו להם לתעד באופן נפלא ומהר.
זמן התיעוד הוא הכאב הגדול ביותר ברשומות אלקטרוניות. אחות מבלה 2-3 שעות כל סופ”ש בסגירת הערות התיק מאחר וזה לוקח זמן רב מדי לבצע במהלך המשמרת. לא רק שזה מתיש זה גם יכול לגרום לפערי מידע שהיא נותנת לצוות הבכיר. זה לוקח כל כך הרבה זמן כי כדי שהמידע יהיה שמיש למישהו אחר הוא צריך להיות מובנה (נכתב כמו קוד) במקום בשפה הטבעית שלה, כך שצריך ללחוץ על המון כפתורים בשביל להבנות את המידע. כתוצאה מכך אנשים פשוט כותבים בשפה שלהם ומוסיפים למערכת מידע לא שמיש
.1) צרו דרך פשוטה להבנות מידע. באותה הקלות שאנחנו מתייגים חברים בפוסטים עובדי הרפואה צריכים להפוך את המידע למובנה.
2) תמיכה בפלואו לא רציף. עבודת האחיות נקטעת כל 6 דקות. צרו דרך בה האחיות יכולות לחזור להערות ולטבלאות שלהן מאוחר יותר.
3) אמצו את המובייל וכל דבר שתומך בממשק קול/טקסט, תמונות, ושירותי מיקום לעזור להם להוסיך מידע “על הדרך”.

3. היו נוקשים עם היררכיית מידע
רשומות רפואיות מאפשרות גישה טובה למידע על המטופל אך לרוב זה הרבה יותר מדי מידע בבת אחת. ההיסטוריה הרפואית של המטופל מרכבת ממידע חיוני כמו שבץ ומידע קצת פחות חשוב על הבעיות בקיבה. רוב המערכות מתייחסות לכל המידע באותו האופן מה שמצריך מהרופא לעבור על כל המידע.
1) הציפו את המידע החשוב 
אנשים צריכים גישה לכל המידע אבל הם לא צריכים לראות הכל בבת אחת.
2) “תרגיעו” עם הערות האזהרה
ככל שאנשים מקבלים יותר הערות אזהרה כך הם פחות מתייחסים אליהם. זה די דומה לעיוורון באנרים.
3) ספקו חיפוש ופילטרים מהממים.
באותה הקלות שאנחנו מחפשים ערך בגוגל אנחנו צריכים לחפש אסטמה ולקבל את כל המידע.
4. עזרו לאנשים לקבל החלטות
עזרו להם לזהות טרנדים בבדיקות. אנחנו יודעים באיזה טווחים יכולה להיווצר סכנה, הדגישו את הפרמטרים האלו בשלבים מוקדמים כדי למנוע אסון
.1) זהו והדגישו שינויים חשובים או דפוסים בבריאות המטופל
.2) אפיינו יחד
זהו עקרון שתקף לכל מוצר דיגיטלי, בד”כ אנשים לא אוהבים לאמץ תוכנות חדשת בעיקר כי הם לא היו חלק מתהליך העיצוב. אנחנו לא אחים ואנחנו לא מכירים את העבודה שלהם, לכן בלי לשתף אותם בתהליך אנחנו לא יכולים ליצור מוצר שהם ירצו לאמץ.

הצד האפל של הUX

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

Dark patterns הן לא טעות, הן תבניות שמכוונות באופן מובהק תוך שימוש בהבנה של הפסיכולוגיה האנושית לפעולות שהמוצר מרוויח מהן ולא המשתמש.
הארי בריגנל טבע את המונח הזה והוא ריכז באתר DarkPattners.org שעושים שימוש בתבניות כאלו. הוא טוען שבמבדקי A/B התבניות האלו דווקא מוכיחות ביצועים טובים ואחוזי המרה גבוהים לא כי הן מועילות למשתמש אלא כי הן מוליכות אותו שולל ולא עוזרות לו לקבל החלטות מושכלות. אלו תבניות לא אתיות.
כיצד תבניות אלו פועלות?
האם אי פעם הרגשתם שאתם צריכים לבצע פעולה שאתם לא לגמרי שלמים איתה רק כי לא מוצגת לכם אופציה טובה יותר? כנראה שמצאתם dark pattern . למרות שרוב האנשים מאמינים שהתבניות האלו הן טריקים פסיכולוגיים, לרוב אין להם שום קשר לפסיכולוגיה של המשתמש והן פשוט דרך זולה לנצל את העובדה שמשתמשים לא קוראים את הטקסטים עד הסוף מאחר והם מעוניינים לסיים את המשימה שלהם במהירות האפשרית.
העניין ב Dark patterns שהן נבנות על אותם עקרונות שאנחנו בונים ממשקים שמעצימים משתמשים.
דוגמאות ל Dark patterns 
Forced Continuity
התבנית הזו מצויה בשירותים שבהם נדרש מנוי. כשאר משתמשים נרשמים לתקופת נסיון חינם הם מתבקשים למלא את פרטי האשראי שלהם וכשאר תקופת הנסיון מסתיימת כרטיס האשראי מחוייב באופן אוטומטי בלי שהמשתמש יזכור שהוא נתן את הרשות כך. לרוב למשתמשים אין דרך קלה לבטל את המנוי ולהספיק לשלם.
Bait and Switch
הדוגמא המפורסמת לכך היא הגישה המטעה של מיקרוסופט לגרום לאנשים לשדרג את המערכת שלהם מWindows OS לWindows 10. מיקרוסופט הציגו שני כפתורים: upgrade now or upgrade tonight במצב כזה במידה והמשתמש לא מעוניין לשדרג לווינדוס 10, איזו ברירה יש לו? בנקודה מסוימת גם הסגירה של חלון ההודעה גרמה לשדרוג המערכת.

Roach Motel
בתבנית הזו קל מאוד ליצור חשבון אבל קשה מאוד למחוק אותו.
דוגמא טובה לכך היא אמאזון, ניסיתם פעם לסגור את חשבון האמזון שלכם? זה כל כך קשה עד שזה כמעט בלתי אפשרי.
Privacy Zuckering
נקראת על שם מארק צוקרברג ומתארת את התופעה בה המוצר אוסף ומשתף הרבה יותר מידע ממה שהמשתמש מודע אליו.
פייסבוק מקשים מאוד מאוד על ניהול הפרטיות של החשבון. אין שקיפות אמיתית בנוגי למה שהחברה יכולה לעשות עם המידע שלנו, והפרטים נמצאים בתנאי השימוש שאף אחד לא קורה.
יותר מזה ישנם תנאי שימוש שבאופן דיפולטיבי מוגדרים מראש בלי שהמשתמש ידע כמו שכולם יכולים לחפש את מספר הטלפון שסיפקנו. מעט מאוד אנשים מודעים לכך ויודעים איך לשנות את זה.
הארי בריגנל יצר 12 קטגוריות של Dark pattern שכדאי להימנע מהן וריכז אותן באתר שלו.

Design Thinking

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

  • מטרות: מה המשתמש רוצה להשיג?
  • רצונות: מה המשתמש רוצה? מה נכנס תחת ההגדרה נחמד שיהיה?
  • צרכים: מה הכרחי למשתמש?
  • הקשר: מה הן הנסיבות/הסביבה שעשויים להשפיע על העיצוב?
  • נקודות כאב: מה הדברים המעצבים או הקשיים שיש למשתמש?

2. הגדרת הבעיהכאשר יש לנו הבנה טובה על המשתמשים שלנו, נשתמש במידע שלנו שצברנו ונגדיר את הבעיה.הצהרת הבעיה צריכה להיות לא צרה מידי(שעלולה להגביל את היצירתיות שלנו) ולא רחבה מדי(שעלולה להיות בלתי פתירה).מתודה להגדרת הבעיה היא כיצד אנחנו נפתור את… (How might we).HMW עוזר לנו לנסח הצהרת הבעיה כשאלה שמעודדת פעולה.דוגמא טובה לשאלה כזו היא כיצד נוכל למשוך יותר את תשומת ליבם של המשתמשים לכפתור ה”קנה” על מנת להגדיל את המכירות?
3. העלאת רעיונותבהתאם לבעיה ולמה שאנחנו מנסים לפתור יש שיטות שונות של סיעור מוחות.שיטה נפוצה היא לכתוב על לוח מחיק את הבעיה בגדול ולקשקש מספר רעיונות על פתקיות דביקות (כן כן…אמרתי פתקיות דביקות ולא sticky note 😊 ) , המטרה פה היא שהסקיצות יהיו מהירות ומביעות את הרעיון המרכזי.אחרי שאנחנו כבר רוויים מרעיונות, ניקח צעד אחורה נסתכל על כולם ונקבץ לתמות רעיונות.שיטה נוספת היא לקפל דף לשמונה חלקים ולצייר את הסקיצות הכי פרועות שלנו על כל אחד מהחלקים.4. עיצובאחרי שהתמקדנו ב3-4 רעיונות נבחר את הפתרון שנראה לו הטוב ביותר ונעצב אותו.5. פרוטוטייפהשלב הזה הוא שלב אחד לפני הבדיקות ומטרתו להפוך את העיצובים שלנו לאינטרקטיביים כדי שנוכל לקבל פידבק על הפתרון.6. בדיקותבדיקות הן חלק חשוב בתהליך, באופן הזה אנחנו יכולים לקבל את המשוב שלהם, ולשפר את המוצר על פיו.