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

 

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

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

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

1. שרטוט הממשק (Wireframe) – תרשים (לרוב "שלד" אפור ובלתי מעוצב, אלא אם מדובר בתהליך מזורז של "אפצוב" הכולל גם את העיצוב הגרפי) של כל המסכים, המצבים והתהליכים שמהם מורכב הממשק (של מוצר / אתר / אפליקציה / פלטפורמה דיגיטלית זו או אחרת).

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

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

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

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

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

ב. שמור על הסדר

כאמור, יש אלף שיטות לבנות תיק אפיון, וקשה למצוא שניים זהים במבנה. לא משנה באיזו שיטה כללית בחרתם (למשל – לארגן את התיק לפי מסכים, רכיבים או תהליכים), יש שני עקרונות שיהיו תקפים תמיד: קודם כל, כמו כל ממשק, גם תיק האפיון צריך להיות סריק וברור ככל האפשר – ולכן כדאי לעשות שימוש מירבי בכותרות, בסעיפים ממוספרים ובמידת הצורך בתת-סעיפים ותת-תת-סעיפים, ולוודא שכל סעיף מקושר בצורה ברורה לרכיב בשרטוט הממשק. אם משפט שכתבתם נראה לכם ארוך מדי – מצאו את הדרך לפרק אותו לכמה סעיפים קצרים; שנית: שמרו על אחידות ועל קונבנציות קבועות. זה נכון גם לגבי שיטות העימוד והמספור, וזה נכון לגבי ניסוח ההתנהגויות – מנקודת מבט המשתמש או מנקודת מבט הממשק ("view pop-up" או "display pop-up"). בחרו בשיטה אחת, והתמידו בה.

ג. לא תתחכם

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

On <user action>, <interface action>

למשל: "On click, display tooltip"

ד. לא תכביר מילים

"Over-spec'ing" היא מחלה שבה לוקים מאפיינים רבים. הסעיף הקודם אמור כבר לדאוג לכך שתותירו מחוץ לתיק האפיון את כל המילים המיותרות, ותסתפקו במשפטים קצרים ופשוטים. נוסיף כאן גם שלעתים יש אפילו פרקים שלמים בתיק האפיון שעלולים להתברר כמיותרים (זכרו עבור מי אתם עובדים!), ונחתום בכלל אצבע קריטי: אל תכתבו שום דבר יותר מפעם אחת! אם התנהגות כלשהי מתרחשת ביותר ממקום אחד בממשק, תארו אותה במקום מרוכז אחד, והפנו את הקורא אליו מכל המקומות הרלוונטיים. ככל שהממשק גדול ומורכב יותר, תצטרכו לרכז יותר ויותר הסברים "רוחביים" במקום אחד, ומשלב מסוים מומלץ לרכז אותו בצורת "Style-guide" של תיק האפיון, שבו ירוכזו כל ההסברים על התנהגותם של רכיבים גנריים. מלבד החיסכון בזמן עבודה ומקום בתיק האפיון, הקפדה על הכלל הזה גם תחסוך מכם את הבלגן הבלתי נמנע שיתעורר כשתצטרכו לערוך שינוי ברכיב זה או אחר, ולערוך את אותו התיקון בכמה מקומות שונים בתיק.

ה. לא תצבע (ולא תקשט)

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

ו. לא תכתוב את מה שאתה יכול לשרטט

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

ז. זכור את מקרי הקצה

זו אחת המנטרות החשובות ביותר במקצוע שלנו: עבודת האפיון לא הסתיימה עד שטופלו כל הנקודות הנידחות ביותר. איך מוצאים אותן? אחרי שסיימתם את האפיון הבסיסי של פיצ'ר זה או אחר, חזרו אחורה אל מקרי השימוש השונים (use cases), נסו "להיכנס לראש" של המשתמש (לא בהכרח המשתמש המבריק ביותר…), עקבו אחר צעדיו באופן מתודי, וכך תגלו את כל המקומות שהוא עשוי "להיקלע" אליהם – האם אכן כיסינו את כולם? מעבר לכך, זה גם הזמן לבדוק ענייני רוחב, גובה וריווח על המסך (נכון שהדברים האלה ייקבעו סופית בשלב העיצוב הגרפי – אבל צריך כבר כעת להגדיר עבור המעצב גבולות גזרה יחסית צרים). לבסוף: במקרה שהממשק כולל תוכן דינמי (תוכן שמוזן על ידי הגולש, למשל בטפסים, או תוכן שמקורות במערכת ניהול תוכן – CMS), חשוב לברר מה המגבלות על הזנת התוכן (כגון מספר תווים) ולבדוק אם הממשק עדיין שמיש גם במצב המקסימלי.

ח. לא תשאיר מקום לספק

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

ט. עקוב אחר שינויים

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

י. שמור על גמישות מחשבה

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



לכתוב תגובה

(חובה לפחות לרשום שם!!!)

(...אף אחד לא יראה את זה)

(תפרסם/י את עצמך! שידעו מאיפה את/ה!)