עיצוב UX לאפליקציות Windows - סדר עדיפויות לפי סביבת שימוש

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

ב-Windows desktop, UX לא נקבע לפי המראה בלבד.

• עד כמה אפשר להשלים הכול במקלדת
• האם יוצאים מנקודת הנחה של עכבר או של touch
• האם משתמשים לאורך זמן, או רק לכמה דקות מדי פעם
• monitoring, קלט, או field terminal
• איזו השפעה או נזק נוצרים כשעושים טעות
• האם אפשר להפעיל גם עם text scaling, contrast theme, ו-assistive technology כמו screen reader

כל אלה יחד הם ה-UX.

flowchart TB
    accTitle: UX לא נקבע לפי המראה בלבד
    accDescr: תרשים שמראה שאמצעי הקלט ומידת השלמת הפעולה, זמן השימוש והייעוד, ועלות הטעות והעמידות מול assistive technology - כולם יחד מרכיבים את ה-UX.
    a1["אמצעי קלט והשלמת פעולה"] --> a4["הכול יחד הוא UX"]
    a2["זמן שימוש וייעוד"] --> a4
    a3["עלות טעות ו-assistive technology"] --> a4
    a4 -.-> a5["להתחיל מ'האם זה נראה מודרני' זה סדר שגוי"]

איור 1: UX ב-Windows desktop נקבע קודם מצירוף הקשרי השימוש, ורק אחר כך מהמראה.

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

למשל, גם באותו B2B, בין

• אפליקציות משרדיות כמו הזנת הנהלת חשבונות או ניהול הזמנות
• field terminals כמו מפעל, מחסן, קבלה ומכשירי בדיקה
• מסכי operations ל-monitoring 24 שעות ותמיכה תחזוקתית

התנאים ל-UX טוב שונים מאוד.

ולהפך, גם ב-B2C, בין

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

צפיפות ה-UI ודרישת ה-shortcuts שונות לגמרי.

flowchart TB
    accTitle: אותו label, תנאים שונים
    accDescr: תרשים שמראה שגם תחת ה-label B2B, אפליקציות משרדיות, field terminals ומסכי operations שונים מאוד בתנאי UX טוב, וגם תחת B2C, utility וכלים למתקדמים שונים בצפיפות ובדרישת shortcuts.
    b0["ה-label B2B"] --> b1["משרדי · field terminal · operations"]
    b1 --> b2["תנאי UX טוב שונים מאוד"]
    c0["ה-label B2C"] --> c1["utility · כלי למתקדמים"]
    c1 --> c2["צפיפות ו-shortcuts שונים"]

איור 2: תחת אותו label של B2C/B2B, תנאי ה-UX הטוב מתפצלים.

גם הנחיות ה-design של Microsoft ל-Windows מדגישות ש-design של אפליקציית Windows צריך להיות אינטואיטיבי ונגיש, ולעבוד באופן עקבי בין אמצעי קלט ו-form factors שונים.¹²

במאמר הזה מסדרים את ה-UX של אפליקציות Windows כטבלת החלטה לפי ייעוד. המטרה: ב-design review או בשלב מוקדם של תכנון מסך, לזהות בקלות “מה האפליקציה הזו צריכה לתעדף”.

קהל היעד וההנחות של המאמר

מונחים שהמאמר משתמש בהם

1. קודם המסקנה

בקצרה, זה נראה כך:

• ב-B2C, מתעדפים קודם הבנה בפעם הראשונה, תחושת ביטחון, מעט הגדרות ו-flow ישיר
• ב-B2B, מתעדפים קודם יעילות לאורך זמן, מניעת טעויות הפעלה, תמיכה במקלדת ופריסה יציבה
• אבל ב-field terminal מסוג B2B, מתעדפים בהירות, יעדי הפעלה גדולים ו-flow קצר לפני צפיפות
• אבל ב-כלי למתקדמים מסוג B2C, מתעדפים צפיפות מידע, shortcuts והתאמה אישית לפני פשטות
• באפליקציות Windows כדאי לחשוב על UX כולל מקלדת / עכבר / touch / text scaling / contrast theme / assistive technology, כי כך ה-design פחות נשבר בהמשך¹³⁴⁵⁶⁷

מה שבאמת צריך להחליט קודם הוא לא רק B2C מול B2B. כדאי לנסח מראש את חמשת אלה:

1. מי משתמש (מתחיל, מנוסה, מעורב)
2. איפה משתמשים (שולחן, חדר ישיבות, שטח, מפעל, קבלה, בחוץ)
3. במה מפעילים (מקלדת, עכבר, touch, עט, ברקוד, assistive technology)
4. כמה משתמשים (בעיקר בפעם הראשונה, מדי פעם, כל יום, כל היום)
5. מה עלות הטעות (קלה, כבדה, מסוכנת, כפופה לביקורת)

כשחמשת אלה ברורים, הרבה יותר קל לקבוע סדר עדיפויות לצפיפות ה-UI, ל-navigation, ל-shortcuts, ל-dialog אישור ולהתאמה אישית.

flowchart TB
    accTitle: חמש שאלות לנסח מראש
    accDescr: תרשים שמראה שכשמנסחים מראש מי משתמש, איפה, במה מפעילים, כמה משתמשים ומה עלות הטעות, קל יותר לקבוע סדר עדיפויות לצפיפות UI, navigation ו-dialog אישור.
    q1["1. מי משתמש"] --> q2["2. איפה משתמשים"]
    q2 --> q3["3. במה מפעילים"]
    q3 --> q4["4. כמה משתמשים"]
    q4 --> q5["5. מה עלות הטעות"]
    q5 --> q6["נקבע סדר עדיפויות: צפיפות · navigation · dialog"]

איור 3: לפני B2C מול B2B, מנסחים חמש שאלות שקובעות את סדר העדיפויות.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 23, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. B2C/B2B הם נקודת כניסה, לא התשובה

החלוקה ל-B2C/B2B נוחה כנקודת כניסה ראשונה. אבל הכוח שקובע את הפתרון הנכון ל-UX חזק יותר בסוג השימוש מאשר בסוג הקונה.

למשל, בגסות, שני הצירים נראים כך:

כלומר,

• B2C = תמיד UI קליל
• B2B = תמיד UI צפוף

זה לא נכון.

גם הנחיות ה-design של אפליקציות Windows מדגישות שימוש עקבי בין מכשירים, סוגי קלט ו-form factors שונים, וגם מבחינת accessibility חשוב לחשוב לא רק על מוגבלות אלא גם על אילוצי סביבה כמו שמש חזקה בחוץ, מרחב משותף, מקום שקט או רועש.¹²

flowchart TB
    accTitle: סוג השימוש קובע, לא סוג הקונה
    accDescr: תרשים שמראה שהמשוואה B2C=UI קליל ו-B2B=UI צפוף אינה מתקיימת, ושהכוח שקובע UX נכון חזק יותר בסוג השימוש מאשר בסוג הקונה.
    e1["B2C = תמיד UI קליל"] --> e3["המשוואה לא מתקיימת"]
    e2["B2B = תמיד UI צפוף"] --> e3
    e3 --> e4["סוג השימוש קובע את הפתרון הנכון"]
    e4 -.-> e5["כולל אילוצי סביבה"]

איור 4: את הפתרון הנכון ל-UX קובע סוג השימוש, לא סוג הקונה.

לכן, אחרי B2C/B2B, מומלץ לחתוך גם לפי הציר הבא.

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

3. טבלת החלטה אחת לפי ייעוד

קודם כול, הטבלה הכי שימושית לעבודה בפועל.

רק מהטבלה הזו כבר רואים בערך את הכיוון. מה שחשוב במיוחד: גם ב-B2B, field terminal לא צריך UI צפוף, וגם ב-B2C, בכלי למתקדמים יעילות חשובה יותר מקלילות.

flowchart TB
    accTitle: שני מקרים שבהם ה-label מוליך שולל
    accDescr: תרשים שמראה שגם field terminal מסוג B2B לא צריך UI צפוף, וגם כלי למתקדמים מסוג B2C יעילות חשובה בו יותר מקלילות, ושבשני המקרים הפתרון הנכון הפוך מהצפוי לפי ה-label.
    f1["field terminal (B2B)"] --> f2["UI צפוף אינו הפתרון"]
    f3["כלי למתקדמים (B2C)"] --> f4["יעילות חשובה מקלילות"]
    f2 --> f5["מחליטים לפי ייעוד, לא לפי label"]
    f4 --> f5

איור 5: שתי השורות הכי חשובות בטבלה, שבהן ה-label והפתרון הנכון הפוכים.

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

4. מדיניות design לפי ייעוד

4.1 utility ל-B2C / אפליקציה לצרכן פרטי

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

מה שכדאי להדגיש במיוחד:

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

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

גם ב-navigation design של Windows אין פתרון אחיד לכל האפליקציות, ובראש סדר העדיפויות עומדים עקביות, פשטות ובהירות. שימוש ב-standard controls ובמיקומים סטנדרטיים הופך את ה-UI לצפוי יותר.⁸

לכן, באפליקציות B2C, לרוב מספיק סידור כזה:

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

flowchart TB
    accTitle: כיוון הסידור עבור B2C
    accDescr: תרשים שמראה שבאפליקציות B2C, סביב הציר של שימוש מיידי, מסך יחיד אם קטן, top navigation אם הסקציות מקבילות, והצגת הגדרות בהדרגה, לרוב מספיקים.
    g1["אפשר להשתמש מיד"] --> g2["מסך יחיד אם קטן"]
    g1 --> g3["top navigation אם מקביל"]
    g1 --> g4["הגדרות בהדרגה"]
    g4 -.-> g5["פעולה מרכזית בהירה, השאר שקטות"]

איור 6: ב-utility קליל מסוג B2C מסדרים סביב “אפשר להשתמש מיד”, לא סביב ריבוי פיצ’רים.

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

4.2 data entry משרדי ו-back office (B2B)

באפליקציית B2B משרדית, מה שחשוב הוא לא קלילות המראה אלא שהעבודה לא נעצרת.

משתמש שעובד עם המסך כל יום מתרגל ל-UI תוך ימים ספורים. מה שמשפיע אחר כך הם דברים כמו:

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

גם בהנחיות ה-keyboard accessibility של Microsoft, חשוב שהאפליקציה תאפשר להגיע לכל הפיצ’רים במקלדת, ומומלץ לממש Tab order, focus, הפעלה עם Enter/Space ו-shortcuts.³

בנוסף, access key יעיל לא רק ל-accessibility, אלא גם לשיפור היעילות של power users שמעדיפים מקלדת. מומלץ לתמוך ב-access key, כולל ב-custom controls, במקומות המתאימים.⁹

ב-data entry משרדי, list/details יציב כ-navigation. גם במדריך ה-navigation של Windows, list/details מתאים לייעוד של החלפת פריטים בתדירות גבוהה תוך הצגה או עדכון פרטים, ומתאים למקרים כמו תיבת דואר נכנס, רשימת אנשי קשר, הזנת נתונים.⁸

כלומר, המבנה הישיר הוא:

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

flowchart TB
    accTitle: המבנה הישיר של data entry משרדי
    accDescr: תרשים שמראה מבנה ישיר של אפליקציית data entry משרדית: למעלה חיפוש, סינון ופקודות מרכזיות, משמאל חלוקת פונקציות, במרכז רשימה, ומימין או למטה פרטים ועריכה, עם shortcuts לפעולות שכיחות.
    h1["למעלה: חיפוש · סינון · פקודות"] --> h2["משמאל: חלוקת פונקציות"]
    h2 --> h3["במרכז: רשימה"]
    h3 --> h4["מימין/למטה: פרטים ועריכה"]
    h4 -.-> h5["פעולות שכיחות - shortcuts"]

איור 7: המבנה הישיר של data entry משרדי, סביב ציר list/details.

ולהפך, הנה גם תבניות שכדאי להימנע מהן:

• dialog לכל פעולה
• מעט מדי עמודות, overview נמוך
• פעולה מרכזית קיימת רק מאחורי קליק ימני
• מנסים להעביר משמעות רק דרך אייקונים
• Tab order מבולגן, Enter/Space לא עובדים

גם לגבי שגיאות קלט, טבעי יותר להציג שגיאת validation שקשורה לשדה בתוך המסך ולא ב-dialog. גם מדריך ה-dialog של Windows ממליץ לא להשתמש ב-dialog לשגיאות validation תלויות-הקשר כמו שדה סיסמה, אלא בתצוגה inline.¹⁰

4.3 monitoring ו-operations (B2B)

ב-UX של מסך monitoring ו-operations, לפני “נוח לשימוש” חשוב לא לפספס, לא לטעות, לא להיעצר.

סדר העדיפויות כאן בערך כך:

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

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

flowchart TB
    accTitle: ייצוג מצב בכמה אלמנטים
    accDescr: תרשים שמראה שייצוג מצב רק בצבע מגביר פספוס וטעות זיהוי במסכי monitoring, ולכן במקום זאת מייצגים מצב בצבע, טקסט, אייקון ושעה יחד, ומפחיתים פספוס וטעות.
    i1["ייצוג מצב בצבע בלבד"] --> i2["פספוס וטעות זיהוי"]
    i2 -.->|"במקום זאת"| i3["צבע+טקסט+אייקון+שעה"]
    i3 --> i4["פחות פספוס וטעות, בטוח יותר"]

איור 8: במסך monitoring מייצגים מצב בכמה אלמנטים יחד, לא רק בצבע.

ב-navigation, סידור נוח הוא: אם יש הרבה יעדי monitoring, left navigation; חפירה ליעד בודד, drill-down; פרטים, לוג וציר זמן. גם במדריך ה-navigation של Windows, left navigation מתאים למקרה שיש הרבה פריטים ברמה העליונה, או למבנה שלא מחליף עמוד ברצף.⁸

בצד הפעולה, מסוכן גם להציב פקודה במקום אחד בלבד. מדריך ה-command design של Windows ממליץ שהפקודה תהיה זמינה מכמה משטחים: כפתור, context menu, shortcut, gesture ושכל הפקודות הרלוונטיות ייכנסו ל-context menu או ל-CommandBarFlyout. הסתמכות על פעולה שנפתחת רק ב-hover גורמת לכך שהיא לא תעבוד ב-terminal מבוסס touch או ב-assistive technology.¹²¹³

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

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

¹⁰

flowchart TB
    accTitle: שלושת עקרונות dialog האישור
    accDescr: תרשים שמראה שמאשרים רק פעולות בלתי הפיכות, כותבים בשורה הראשונה מה עומד לקרות, מנסחים כפתורים באופן ספציפי, ומציבים תמיד כפתור בטוח, ולעומת זאת אישור גורף פוגע ביעילות.
    j1["מאשרים רק פעולות בלתי הפיכות"] --> j2["שורה ראשונה: מה יקרה"]
    j1 --> j3["כפתורים בניסוח ספציפי"]
    j1 --> j4["תמיד כפתור בטוח"]
    j2 -.-> j5["אישור גורף פוגע ביעילות"]

איור 9: dialog אישור מוגבל לפעולות בלתי הפיכות, ושומר על שלושה כללי מינימום.

4.4 field terminal, UI לציוד, kiosk (B2B)

field terminal הוא סוג שונה למדי, גם בתוך עולם ה-UX של אפליקציות Windows.

התנאים הרגילים כוללים:

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

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

בנוסף, ב-touch design יש הבדלים כאלה:

• ל-touch אין hover
• אצבע או יד מסתירות (occlusion) חלק מה-UI
• חלק מהמסך קשה ללחוץ מבחינת מנח היד
• משוב חזותי חשוב

⁴

flowchart TB
    accTitle: ארבעה הבדלים ב-touch design
    accDescr: תרשים שמראה שב-touch אין hover, האצבע או היד מסתירות את ה-UI, יש מקומות שקשה ללחוץ עליהם מבחינת מנח היד, ומשוב חזותי הופך חשוב מאוד.
    k1["פעולת touch"] --> k2["אין hover"]
    k1 --> k3["האצבע/היד מסתירות UI"]
    k1 --> k4["מקומות שקשה ללחוץ עליהם"]
    k4 -.-> k5["משוב חזותי חשוב"]

איור 10: ל-touch הנחות שונות מ-hover והסתרה, ולכן המשוב החזותי מרכזי.

לכן, ב-field terminal בדרך כלל נוטים לכיוון הזה:

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

ולהפך, כדאי להימנע מ-

• טקסט קטן
• hit area קטן
• הסתמכות על tooltip שדורש hover
• מדרג עמוק
• הרבה מידע במסך אחד
• קלט חופשי ארוך

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

flowchart TB
    accTitle: ב-field terminal, בהירות קודמת
    accDescr: תרשים שמראה שב-field terminal מתקרבים למסך אחד מטרה אחת, מטים קלט לבחירה, סריקה וטופס קבוע, ומראים בבירור תגובה אחרי פעולה, וזהו עולם שבו בהירות עדיפה במיוחד.
    l1["field terminal, UI לציוד"] --> l2["מסך אחד, מטרה אחת"]
    l1 --> l3["קלט: בחירה · סריקה · טופס קבוע"]
    l1 --> l4["תגובה ברורה אחרי פעולה"]
    l2 --> l5["בהירות עדיפה במיוחד"]
    l3 --> l5
    l4 --> l5

איור 11: field terminal מתעדף לא צפיפות אלא בהירות, יעד גדול ו-flow קצר.

4.5 כלי עריכה וניתוח למומחים

בכלי למומחים, לפעמים “שלא יעצור לי את העבודה” מנצח את “שיהיה מובן”.

למשל:

• CAD
• ניתוח גלים
• עריכת וידאו
• עיבוד תמונה
• יצירת מוזיקה
• כלי פיתוח
• ניתוח נתונים
• כלי ביקורת/אבחון

באפליקציות מהסוג הזה, האלמנטים האלה יעילים:

• צפיפות מידע
• כמה panes
• tabs
• context menu
• shortcuts
• שמירת layout
• התאמה אישית של עמודות ופריטי תצוגה
• Undo/Redo
• שחזור מצב העבודה

גם במדריך ה-navigation של Windows, tabs מתאימים למקרה שרוצים לפתוח, לסגור ולסדר מחדש כמה עמודים או מסמכים.⁸ גם ב-command design של Windows, מומלץ לחלוק פקודה בין כמה משטחי UI, כך שגם עם אמצעי קלט שונים אפשר להגיע לאותה פעולה.¹²

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

לכן, למשתמשים מתקדמים, יעיל design כזה:

• פעולה בתדירות גבוהה, קרוב
• פיצ’ר עזר, קצת רחוק
• פיצ’ר מתקדם, לא מוחקים, מסדרים
• שומרים layout של התצוגה
• מעבים את ההפעלה במקלדת

flowchart TB
    accTitle: סידור פיצ'רים למשתמש מנוסה
    accDescr: תרשים שמראה שמשתמש מנוסה חוזר מאות פעמים ביום על אותה פעולה, ולכן פעולות בתדירות גבוהה קרובות, פיצ'רי עזר קצת רחוקים, ופיצ'רים מתקדמים מסודרים ולא נמחקים, לטובת פחות עייפות אחרי 100 שעות לעומת קלות בחמש הדקות הראשונות.
    n1["חזרה מאות פעמים ביום"] --> n2["פעולה שכיחה, קרוב"]
    n1 --> n3["פיצ'ר עזר, קצת רחוק"]
    n1 --> n4["פיצ'ר מתקדם, מסודר, לא נמחק"]
    n2 -.-> n5["פחות עייפות אחרי 100 שעות, לא קלות בחמש דקות"]

איור 12: כלי למומחים ממקם פיצ’רים לפי תדירות הפעולה.

4.6 כלי resident ו-tray app

באפליקציה שרצה ברקע, דווקא לא להבליט את הקיום הוא ה-UX.

למשל, באפליקציות כמו

• מצב סנכרון
• מצב חיבור
• גיבוי
• החלפת שמע/מצלמה/מכשיר
• VPN / agent / launcher
• notification hub

המסך הראשי לרוב אינו הכוכב.

מה שכדאי לתעדף:

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

מה שכדאי להימנע ממנו:

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

באפליקציה מהסוג הזה, לא להפריע משפיע על ה-UX יותר מ”כמה פיצ’רים יש”.

flowchart TB
    accTitle: לכלי resident, לא להפריע הוא UX
    accDescr: תרשים שמראה שכלי resident מעדיף נגישות מיידית מ-system tray, הבנת המצב הנוכחי, והתראה רק כשצריך, ושיותר מדי התראות גורמות להתעלמות כללית.
    r1["נגישות מיידית מ-system tray"] --> r4["לא להפריע, זה ה-UX"]
    r2["המצב הנוכחי ברור"] --> r4
    r3["התראה רק כשצריך"] --> r4
    r4 -.-> r5["יותר מדי התראות, מתעלמים מהכול"]

איור 13: בכלי resident, אי-הבלטת הקיום היא עצמה ה-UX.

5. טבלת החלטה ל-navigation

מדריך ה-navigation של Windows קובע שאין navigation design יחיד שמתאים לכל האפליקציות, ומעמיד כעקרונות עקביות, פשטות ובהירות. בנוסף, הצבת standard controls במקום שהמשתמש מצפה לו הופכת את ה-UI לצפוי יותר.⁸

flowchart TB
    accTitle: עקרונות navigation design
    accDescr: תרשים שמראה שאין תבנית navigation אחת שמתאימה לכל האפליקציות, אלא עקרונות של עקביות, פשטות ובהירות, ושהצבת standard controls במקום הצפוי הופכת את ה-UI לצפוי יותר.
    s0["אין תבנית אחת נכונה"] --> s1["עקביות"]
    s0 --> s2["פשטות"]
    s0 --> s3["בהירות"]
    s3 -.-> s4["standard controls במקום צפוי"]

איור 14: ל-navigation אין פתרון יחיד, אלא שלושה עקרונות ומיקום סטנדרטי צפוי.

בעבודה בפועל, קל יותר לחשוב על זה דרך הטבלה הזו.

מדריך ה-navigation של Windows מציג במיוחד את החלוקה הבאה.⁸

• top navigation: כשרוצים להציג את כל פריטי ה-navigation על המסך
• left navigation: כשיש הרבה פריטים ברמה העליונה, ולא מחליפים עמוד בתדירות גבוהה
• list/details: כשהחלפת פריטים תכופה ודרושה תצוגה או עדכון פרטים
• tabs: כשרוצים לפתוח ולסגור באופן דינמי כמה מסמכים או עמודים
• breadcrumbs: במדרג עמוק, כשרוצים להבהיר את דרך החזרה

5.1 שלד בלבד: wireframe

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

[ top navigation ]  כשרוצים להציג את כל העמודים באותה רמה
+-------------------------------------------------------------
| AppName        בית | המרה | היסטוריה | הגדרות
+-------------------------------------------------------------
|
|    תוכן ראשי
|    מתקרב ל"מסך אחד, מטרה אחת"
|
+-------------------------------------------------------------


[ left navigation ]  כשיש הרבה פריטים ברמה העליונה
+-------------------------------------------------------------
| AppName                                 חיפוש [           ]
+-------------------------------------------------------------
| Dashboard       |
| רשימת ציוד      |    תוכן ראשי
| Alerts          |
| Jobs            |
| Reports         |
| הגדרות          |
+-------------------------------------------------------------


[ list/details ]  מחליפים פריט, רואים ומעדכנים פרטים
+-------------------------------------------------------------
| חיפוש [          ]  סינון: לא מטופל / הכול      [חדש] [מחק]
+-------------------------------------------------------------
| רשימה            |  פרטים / עריכה
|  > תעודה 1001    |    מספר תעודה   1001
|    תעודה 1002    |    לקוח          ...
|    תעודה 1003    |    שורות פירוט   ...
|    תעודה 1004    |
|                  |    [ שמור ]   [ בטל ]
+-------------------------------------------------------------


[ dashboard + drill-down ]  מוצאים חריגה וחופרים לתוכה
+-------------------------------------------------------------
| כללי   תקין 22    שים לב 3    חריגה 1     עודכן לפני 0.5 שנ'
+-------------------------------------------------------------
| חריגה: 1 פריט
|   ! קו B מכשיר בדיקה     אין תגובה    לפני 48 שנ'   [ פרטים ]
| שים לב: 3 פריטים
|   - קו A מצלמה           ערך ישן       לפני 12 שנ'   [ פרטים ]
|   ...
+-------------------------------------------------------------
              |
              |  לוחצים [ פרטים ]
              v
+-------------------------------------------------------------
| < חזרה לרשימה       קו B מכשיר בדיקה / אין תגובה
+-------------------------------------------------------------
| ערך נוכחי | גרף ציר זמן | לוג אירועים | פעולה
+-------------------------------------------------------------

כשמציבים את ארבעתם זה לצד זה, ציר הבחירה מתבהר.

• הגבול בין top navigation ל-left navigation הוא מספר הפריטים ברמה העליונה. אם אפשר לפרוס הכול לרוחב, עליון; אם לא, בצד
• הכוכב ב-list/details הוא הרשימה משמאל, לא הצד הימני. אם כמות המידע ברשימה לא מספיקה, נאלצים לפתוח את הפרטים שוב ושוב
• ב-dashboard, העיקר הוא להציג “כמה חריגות יש” בשורה הראשונה. כשחופרים פנימה, תמיד מכינים דרך חזרה

בקיצור, navigation הוא לא “טעם חזותי” אלא שיקוף של מבנה המידע ומבנה העבודה.

flowchart TB
    accTitle: הגבול בין top navigation ל-left navigation
    accDescr: תרשים שמראה שהגבול בין top navigation ל-left navigation הוא מספר הפריטים ברמה העליונה, וש-navigation הוא שיקוף של מבנה המידע ומבנה העבודה, לא טעם חזותי.
    t1{"אפשר לפרוס הכול לרוחב"} -->|"כן"| t2["top navigation"]
    t1 -->|"לא"| t3["left navigation"]
    t2 -.-> t4["navigation משקף מבנה מידע ועבודה"]
    t3 -.-> t4

איור 15: הבחירה בשלד אינה טעם חזותי, אלא נקבעת ממבנה המידע.

6. טבלת החלטה ל-input devices ול-command design

אפליקציית Windows גמישה ונוחה יותר לשימוש ככל שהיא תומכת ביותר אמצעי קלט. גם המדריך של Microsoft ממליץ להביא בחשבון כמה שיותר סוגי קלט, כמו gestures, קול, touch, touchpad, עכבר, מקלדת.¹⁴

בנוסף, מכיוון שה-platform controls של Windows סופגים במידה מסוימת כמה אמצעי קלט, שימוש ב-standard controls כמו שהם הוא קודם כול חזק.⁴⁸

flowchart TB
    accTitle: standard controls חזקים קודם כול
    accDescr: תרשים שמראה שהתאמה למגוון אמצעי קלט מומלצת, ושה-standard controls של הפלטפורמה סופגים חלק מהם, ולכן שימוש בהם כמו שהם חזק קודם כול.
    u1["התאמה למגוון אמצעי קלט"] --> u2["standard controls סופגים חלק מזה"]
    u2 --> u3["שימוש בהם כמו שהם חזק קודם כול"]

איור 16: standard controls סופגים מגוון אמצעי קלט, ולכן הם הדרך הקצרה.

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

מה שחשוב במיוחד בתחום המקלדת:³⁹

• אפשר להגיע לכל הפיצ’רים במקלדת בלבד
• Tab order לא סוטה משמעותית מהסדר החזותי
• אפשר ללחוץ ב-Enter/Space על אלמנטים שצריכים להיות לחיצים
• לפיצ’רים חשובים יש shortcut
• לפעולות בתדירות גבוהה יש access key או accelerator

לתחום ה-touch יש מאפיינים כאלה:⁴

• אין hover
• אצבע או יד מסתירות את ה-UI
• מקום לחיץ מרגיש צר יותר ממה שנראה
• דרוש משוב חזותי
• UI שמתאים לפעולה ישירה שונה מ-UI שמתאים לקלט עקיף

6.1 לא “מספיק גדול”, קובעים במספרים

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

כשיש מספר קבוע, גם אופן הדיבור ב-review משתנה. במקום “הכפתור הזה לא קטן?”, אפשר לומר “הכפתור הזה הוא 32px, אז הוא לא מגיע לתקן ה-7.5mm”, וההחלטה אם לתקן נגמרת שם ואז.

flowchart TB
    accTitle: קביעה במספרים מזרזת review
    accDescr: תרשים שמראה שעצירה במילים כמו "מספיק גדול" גורמת למחלוקות ב-review, ושבמקום זאת שימוש במספר מהמדריך כקריטריון עובר/נכשל מסיים את ההחלטה במקום.
    v1["עצירה ב'מספיק גדול'"] --> v2["מחלוקות ב-review"]
    v2 -.->|"במקום זאת"| v3["המספר מהמדריך כקריטריון"]
    v3 --> v4["מדברים לפי הגעה לתקן"]
    v4 --> v5["ההחלטה נגמרת במקום"]

איור 17: קביעה לפי מספר מסיימת את הדיון על גודל במקום.

בנוסף, ה-standard controls של WinUI בנויים כברירת מחדל כך שהם עומדים בגודל היעד הזה.¹⁵ כלומר להפך, רק controls בבנייה עצמית וציור מותאם אישית מסוכנים.

ב-command design, מדריך הפקודות של Windows הוא מקור טוב. מה שחשוב במיוחד הוא לאפשר גישה לפקודה ממספר משטחי UI.¹²

• אפשר ללחוץ מכפתור
• קיימת גם ב-context menu
• אפשר לקרוא גם עם shortcut
• במידת הצורך, גם swipe או gesture

ומומלץ להכניס את כל הפקודות הרלוונטיות ל-context menu או ל-CommandBarFlyout. הסתמכות על פעולה שנראית רק ב-hover נתקעת ב-terminal ייעודי ל-touch.¹²

flowchart TB
    accTitle: פקודה זמינה ממספר משטחים
    accDescr: תרשים שמראה שאותה פקודה זמינה מכפתור, מ-context menu וגם מ-shortcut, כך שאפשר להגיע אליה בכל אמצעי קלט, ושהסתמכות על hover נתקעת ב-touch.
    w1["אותה פקודה"] --> w2["כפתור"]
    w1 --> w3["context menu"]
    w1 --> w4["shortcut"]
    w2 --> w5["נגישה בכל אמצעי קלט"]
    w3 --> w5
    w4 --> w5
    w1 -.-> w6["הסתמכות על hover, נתקע ב-touch"]

איור 18: פקודות חשובות מונחות בכמה משטחי UI, ולא תלויות ב-hover.

7. פריטי UX שלא כדאי לוותר עליהם באפליקציית Windows

מכאן מסכמים דברים שכדאי לתפוס לכל הפחות, בלי תלות בייעוד.

7.1 האם אפשר להשלים הכול במקלדת

ב-Windows desktop, מקלדת אינה רק “נוח שיש”, אלא אמצעי הקלט המרכזי.

גם במדריך ה-keyboard accessibility של Microsoft כתוב שתמיכה במקלדת חשובה לא רק למשתמשים עם מגבלת ראייה או תנועה, אלא גם למשתמשים שבוחרים במקלדת לצורך יעילות.³

חמישה דברים לבדוק לכל הפחות:

• Tab order טבעי
• קיים ייצוג חזותי ל-focus
• ניתן ללחוץ עם Enter/Space
• קיימים shortcuts
• אפשר לקרוא גם במקלדת לפעולה שקולה לקליק ימני

זה עניין דל תשומת לב, אבל אם הוא נשבר, ה-UX של B2B נפגע משמעותית.

7.2 text scaling, contrast theme ו-accessibility

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

המדריך של Microsoft ממליץ על יחס ניגודיות של טקסט גלוי לפחות 4.5:1, ודורש שכאשר הטקסט מוגדל, גם ה-controls והמכולות ישתנו בגודל ויסודרו מחדש בהתאם.⁵⁶

ובנוסף, ב-contrast themes מומלץ:

• לא לקבע צבעים בקוד
• להשתמש במשאבי SystemColor/Brush
• לבדוק בארבע contrast themes שונות

⁷

מה שנשבר בקלות כאן:

• label מבוסס רוחב קבוע
• גובה כפתור קבוע בפיקסלים
• design שמעביר משמעות רק בצבע
• UI שלא עוקב אחר theme, בגלל ציור מותאם אישית

מתאים יותר לחשוב על זה לא כ”תמיכה ב-accessibility” אלא כעבודת יסוד לבניית UI ל-Windows שלא נשבר לאורך זמן.

flowchart TB
    accTitle: עבודת יסוד לעמידות בהגדלה וב-themes
    accDescr: תרשים שמראה ש-label ברוחב קבוע, גובה קבוע בפיקסלים, משמעות בצבע בלבד וציור מותאם אישית שלא עוקב אחר theme נשברים בקלות, ולכן משתמשים במשאבי צבע ובודקים בארבע contrast themes.
    y1["רוחב/גובה קבוע בפיקסלים"] --> y3["נשבר בהגדלה או ב-theme"]
    y2["משמעות בצבע בלבד · ציור עצמאי"] --> y3
    y3 --> y4["משאבי צבע במקום קיבוע"]
    y4 --> y5["בדיקה בארבע contrast themes"]
    y5 -.-> y6["עבודת יסוד ל-UI עמיד"]

איור 19: מעקב אחר text scaling ו-contrast themes הוא עבודת יסוד, לא תוספת.

7.3 לא להשתמש ב-dialog יתר על המידה

dialog נוח, אבל שימוש יתר בו הופך לאויב העבודה.

מדריך ה-dialog של Windows מגדיר dialog כ-UI מודלי לצורך התראה, אישור או קלט מידע נוסף, וממליץ להציב לפחות פעולה בטוחה ולא-הרסנית אחת (כמו Close, Cancel). בנוסף, מומלץ שטקסט הכפתורים יהיה תגובה ספציפית.¹⁰

חשוב לא להפוך הכול ל-dialog.

בפרט,

• שגיאת קלט ברמת שדה
• שגיאת פורמט שאפשר לתקן במקום
• הערה זמנית

טבעי יותר להטות לתצוגה inline.¹⁰

7.4 לפקודה חשובה יש כמה מסלולים

ב-command design של Windows, חשוב שפקודה חשובה תהיה זמינה ממגוון אמצעי קלט ומשטחי UI.¹²¹³

זה גם מאוד יעיל בעבודה בפועל.

למשל, עבור “מחיקה”:

• toolbar
• context menu
• מקש Delete
• swipe במידת הצורך

אם יש כמה מסלולים כאלה, השימוש יציב יותר.

ולהפך,

• מופיע רק בקצה הימני ב-hover
• מופיע רק בקליק ימני
• אף פעם לא נגיש במקלדת

design כזה נחלש בפתאומיות כשאמצעי הקלט משתנה.

7.5 בודקים בעזרת כלי בדיקה

מהיר יותר לבדוק accessibility בכלי, מאשר לחשוב בראש “בטח בסדר”.

מדריך בדיקת ה-accessibility של Microsoft מציג Live Inspect, FastPass ו-Troubleshooting באמצעות Accessibility Insights for Windows, ובנוסף אפשר לבדוק מאפייני UI Automation ומבנה navigation עם Inspect מה-SDK.¹⁷

לכל הפחות, כדאי לבצע:

• סריקה כללית עם Accessibility Insights
• אימות name, role ו-pattern של אלמנטים עיקריים עם Inspect
• מעבר על הזרימות העיקריות רק במקלדת
• בדיקת text scaling ו-contrast theme

וכך פחות חוזרים אחורה.

flowchart TB
    accTitle: הליך בדיקת accessibility
    accDescr: תרשים שמראה סריקה עם Accessibility Insights, אימות name, role ו-pattern עם Inspect, מעבר על הזרימות במקלדת בלבד, ובדיקת הגדלה ו-contrast theme.
    z1["סריקה עם Accessibility Insights"] --> z2["אימות name/role/pattern ב-Inspect"]
    z2 --> z3["זרימות עיקריות במקלדת בלבד"]
    z3 --> z4["בדיקת הגדלה ו-contrast theme"]
    z4 -.-> z5["מהיר יותר מ'בטח בסדר' בראש"]

איור 20: בודקים accessibility תחילה בכלים, ואז ידנית בזרימות עיקריות.

7.6 להכניס יכולת התאוששות

זה פחות רשימת בדיקה חד-שורתית של Microsoft, ויותר עניין שמאוד יעיל בעבודה בפועל ב-Windows desktop.

UX לא נקבע רק לפי “כפתור נעים ללחוץ עליו”, אלא לפי היכולת לחזור גם אחרי תקלה.

למשל,

• Undo/Redo
• שמירה אוטומטית
• שמירת מצב עריכה
• שחזור סינון/מיון/רוחב עמודה
• הפסקה וחידוש
• התקדמות וביטול בתהליך ארוך

משפיעים על ה-UX הרבה יותר מהמראה.

בפרט ב-B2B ובכלים למומחים, התסכול מחזרה על פעולה הופך ישירות ל-UX גרוע.

flowchart TB
    accTitle: יכולת התאוששות קובעת UX
    accDescr: תרשים שמראה ש-UX נקבע לא רק לפי נעימות הלחיצה אלא לפי היכולת לחזור אחרי תקלה, וש-Undo, שמירה אוטומטית, שחזור מצב, והתקדמות עם ביטול מפחיתים תסכול מחזרה על פעולה.
    ba1["Undo/Redo · שמירה אוטומטית"] --> ba4["אפשר לחזור אחרי תקלה"]
    ba2["שחזור מצב עריכה ותצוגה"] --> ba4
    ba3["התקדמות וביטול"] --> ba4
    ba4 -.-> ba5["תסכול מחזרה, UX גרוע"]

איור 21: UX נקבע לא רק לפי נעימות לחיצה, אלא לפי יכולת חזרה אחרי תקלה.

8. טעויות design נפוצות

8.1 חושבים ש”כי זה B2B, אפשר צפוף”

נכון רק בחלקו.

למשתמש מנוסה שמשתמש כל יום, צפיפות אכן יכולה לעבוד. אבל ב-field terminal, מסוף קבלה, או UI לציוד, הצפיפות דווקא אויב.

עדיף להסתכל על רמת המומחיות, אמצעי הקלט וסביבת השימוש, לא על ה-label B2B.

8.2 חושבים ש”כי זה B2C, מסתירים פיצ’רים יותר מדי”

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

אם מטים הכול לכיוון “להראות פשוט”, מתחילה שחיקה שקטה:

• פעולה בתדירות גבוהה רחוקה
• חופרים בתפריט בכל פעם
• ממשיכים להחליף מסכים

flowchart TB
    accTitle: שתי מלכודות של הנחת ה-label
    accDescr: תרשים שמראה שההנחה כי B2B=צפוף נכשלת ב-field terminal, וההנחה כי B2C=מוסתר מרחיקה את הפעולה השכיחה למשתמש המנוסה, ולכן מסתכלים על רמת מומחיות, אמצעי קלט וסביבת שימוש.
    ca1["B2B = צפוף"] --> ca2["ב-field terminal, צפיפות אויב"]
    ca3["B2C = מוסתר"] --> ca4["למנוסה, פעולה שכיחה רחוקה"]
    ca2 --> ca5["מסתכלים במומחיות, קלט וסביבה"]
    ca4 --> ca5

איור 22: שתי הנחות שגויות לפי label, ששתיהן מתבררות כלא נכונות בפועל.

8.3 בונים פעולה שמניחה hover

ל-touch אין hover. בנוסף, UI שנחשף רק במצביע נוטה גם להתאים פחות ל-assistive technology.⁴¹²

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

לפני: רק בשורה שעליה hover, מופיעה פעולה בקצה הימני
  תעודה 1001   2026-03-18   לא מטופל                    <- לא רואים כלום
  תעודה 1002   2026-03-18   לא מטופל     [ עריכה ][ מחיקה ] <- רק שורה עם עכבר מעליה

אחרי: נראה תמיד + הוספת מסלולים
  תעודה 1001   2026-03-18   לא מטופל     [ עריכה ][ מחיקה ]
  תעודה 1002   2026-03-18   לא מטופל     [ עריכה ][ מחיקה ]
     קליק ימני   -> עריכה / מחיקה
     מקלדת       -> Enter לעריכה, Delete למחיקה

8.4 מציינים מצב רק בצבע

נפוץ במיוחד במסכי monitoring, אבל מסוכן להעביר משמעות רק באדום/צהוב/ירוק.

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

8.5 הופכים כל שגיאת validation ל-dialog

נפוץ ב-data entry משרדי. אם dialog מופיע בכל הזנה, קצב העבודה נשבר לגמרי.

טבעי יותר להציג שגיאה תלוית-הקשר במקום, בתוך המסך.¹⁰

לפני: modal לכל שדה
  מיקוד     [ 1234        ]        +------------------------------+
  כתובת     [             ]        | פורמט המיקוד אינו תקין
                                   |                       [ אישור ]
                                   +------------------------------

אחרי: inline במקום
  מיקוד     [ 1234        ]
            ! יש להזין 7 ספרות. לדוגמה 1234567
  כתובת     [             ]

8.6 בונים layout בגודל קבוע

גם אם זה נראה יפה בסביבת הפיתוח בתצוגת 100%, זה נשבר בקלות עם

• text scaling
• DPI גבוה
• contrast theme
• localization

⁶⁷

לפני: label ברוחב קבוע + כפתור בגובה קבוע. עם text scaling
  [ תאריך מש... ][ 2026-03-1  ]      <- ה-label נחתך, גם הערך גולש
  [ רש ][ בי ]                        <- טקסט הכפתור נחתך מלמעלה ומלמטה

אחרי: layout שמתמתח לפי התוכן
  תאריך משלוח משוער
  [ 2026-03-18              ]
  [ רישום ]   [ ביטול ]               <- הגובה נקבע לפי תוכן + רווח

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

8.7 יוצרים יותר מדי custom controls

ל-standard controls של Windows יש הרבה יותר התנהגות ממה שנראה למראית עין.

הם מטפלים גם ב-

• focus
• מקלדת
• מעקב אחר theme
• UI Automation
• חיבור ל-assistive technology

ולכן, אם בונים הכול לבד בלי סיבה, החוב ב-UX וב-accessibility גדל.⁸³

9. שמונה שאלות לפני שמתחילים

לבסוף, שמונה שאלות שנוח להציב בתחילת design review.

אם עונים על שמונה השאלות האלה מראש,

• האם ה-navigation צריך להיות רדוד
• האם רשימה + פרטים מתאים
• האם צריך להעמיק shortcuts
• איפה כדאי להשתמש ב-dialog
• עד כמה לאפשר התאמה אישית

נקבעים באופן טבעי.

flowchart TB
    accTitle: מה נקבע משמונה השאלות
    accDescr: תרשים שמראה שמענה מראש על שמונה השאלות קובע באופן טבעי את עומק ה-navigation, מבנה הרשימה והפרטים, כמות ה-shortcuts, ומקום השימוש ב-dialog ובהתאמה אישית.
    da1["עונים על שמונה השאלות"] --> da2["עומק navigation ומבנה רשימה/פרטים"]
    da1 --> da3["כמות shortcuts"]
    da1 --> da4["מקום ה-dialog וטווח ההתאמה"]
    da2 --> da5["נקבע באופן טבעי"]
    da3 --> da5
    da4 --> da5

איור 23: מענה מראש על שמונה השאלות קובע באופן טבעי את עיקרי ה-design.

10. סיכום

מה שחשוב ב-UX design לאפליקציית Windows הוא לקבוע, לפני “האם זה יפה”, את “האם האדם הזה, במקום הזה, באמצעי הקלט הזה, יכול להשתמש בלי להיעצר”.

flowchart TB
    accTitle: מה קובעים לפני "האם זה יפה"
    accDescr: תרשים שמראה שב-UX design קובעים לפני היופי את השאלה האם האדם, במקום, באמצעי הקלט, יכול להשתמש בלי להיעצר, וש-UX הוא חוזה של פעולה ולא קישוט.
    ea1["האדם הזה"] --> ea2["במקום הזה"]
    ea2 --> ea3["באמצעי הקלט הזה"]
    ea3 --> ea4["משתמש בלי להיעצר"]
    ea4 -.-> ea5["UX הוא חוזה פעולה, לא קישוט"]

איור 24: לפני “האם זה יפה”, קובעים אם האדם, במקום ובאמצעי הקלט, משתמש בלי להיעצר.

בגסות, זה מסתכם כך:

• B2C, עדיפות להבנה ראשונית ותחושת ביטחון
• B2B משרדי, עדיפות ליעילות לאורך זמן ותמיכה במקלדת
• B2B monitoring, עדיפות למניעת פספוס ופעולה בטוחה
• B2B field terminal, עדיפות ליעד הפעלה גדול ו-flow קצר
• כלי למומחים, עדיפות לצפיפות, shortcuts והתאמה אישית
• כלי resident, עדיפות לאי-הפרעה

ומה שיעיל בכל ייעוד, ללא תלות בסוג, הם שישה אלה:

1. שימוש ב-standard controls כמו שהם
2. הפעולה המרכזית מושלמת במקלדת
3. לא נתקע ב-touch או ב-assistive technology
4. לא נשבר ב-text scaling או ב-contrast theme
5. לפקודות חשובות כמה מסלולים
6. אפשר לחזור גם אחרי תקלה

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

11. מקורות

מאמרים קשורים

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

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

האם אפליקציה עסקית מסוג B2B צריכה UI צפוף ומלא מידע?

רק חלקית. ב-data entry משרדי למשתמשים מנוסים שעובדים עם המסך כל יום, overview צפוף והשלמת פעולות במקלדת באמת משפרים יעילות לאורך זמן. אבל ב-field terminals במפעל, במחסן או בקבלה, וב-UI של ציוד, צפיפות היא דווקא בעיה: צריך לתעדף יעדי הפעלה גדולים, flow קצר ובהירות. עדיף להסתכל על רמת המומחיות, אמצעי הקלט וסביבת השימוש, לא על ה-label B2B. ולהפך: גם ב-B2C, בכלים למתקדמים כמו עריכת תמונות או ניתוח השקעות, צפיפות מידע, shortcuts והתאמה אישית קודמים לפשטות.

מה צריך להחליט קודם ב-UX design של אפליקציית Windows?

B2C או B2B לבד לא מספיק. קודם מנסחים חמש שאלות: מי משתמש (מתחיל, מנוסה, מעורב), איפה משתמשים (שולחן, שטח, בחוץ, קבלה), במה מפעילים (מקלדת, עכבר, touch, סורק, assistive technology), כמה משתמשים (בעיקר בפעם הראשונה, כל יום, כל היום), ומה עלות הטעות (קלה, כבדה, מסוכנת, כפופה לביקורת). כשחמשת אלה ברורים, קל יותר לקבוע סדר עדיפויות לצפיפות ה-UI, ל-navigation, ל-shortcuts, ל-dialog אישור ולהתאמה אישית.

איך בוחרים תבנית navigation?

אין navigation design אחד שמתאים לכל האפליקציות. העקרונות הם עקביות, פשטות ובהירות. כקווים לבחירה: top navigation מתאים כשרוצים להציג את כל פריטי ה-navigation על המסך; left navigation מתאים כשיש הרבה פריטים ברמה העליונה; list/details מתאים ל-data entry שמחליפים פריט בתדירות גבוהה תוך הצגה או עדכון של הפרטים; tabs מתאימים כשרוצים לפתוח ולסגור כמה מסמכים באופן דינמי; breadcrumbs מתאימים כשמדרג עמוק גורם לאבד את המיקום הנוכחי. Navigation אינו עניין של טעם חזותי, אלא שיקוף של מבנה המידע ומבנה העבודה.

עד כמה כדאי להציג dialog אישור?

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

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.