כתבה: יעל בן דוד, UX Writer ב-Fundbox
תורגם באדיבות צוות העיצוב של Fundbox: נעמה הירש ונדב ירון
כתיבת UX לא נעשית בחלל ריק.
ככותבים וכותבות אנחנו שואפים שהטקסט שכתבנו בעמל ובדיוק רב – אחרי שחקרנו, שאלנו, ניסחנו, ערכנו, התייעצנו, ערכנו שוב וניסחנו מחדש – יישאר בדיוק כמו שכתבנו אותו ואף אחד לא ישנה לנו כלום עד שנעלה לאוויר.
אבל המציאות רחוקה מזה.
אנחנו לא עובדים לבד (וטוב שכך), והמיקרו-קופי שיעלה בסוף לאוויר הוא הרבה פעמים תוצר של עוד המון שיקולים, דעות, אילוצים ומגבלות שהגיעו מכמה גורמים ומחלקות. למעשה, זה חלק בלתי נפרד מהעבודה שלנו להביא את כל השיקולים האלה בחשבון ולתת להם מקום בטקסט הסופי.
לכן המילים שמשתמשים רואים בסוף הן רק קצה הקרחון.
כדאי מאוד לזכור את זה גם כשאנחנו נכנסים ונכנסות לתפקיד ומתחילים לשתף פעולה עם צוותים אחרים (כן, השיקולים שלהם חשובים ממש כמו השיקולים שלנו), וגם כשאנחנו מעבירים ביקורת על מיקרו-קופי בצילומי מסך שאין לנו שום ידע על מה שקרה מאחורי הקלעים שלהם.
אני נזכרת בזה שוב ושוב כשאני רואה צילומי מסך של מיקרו-קופי ברשתות החברתיות, שמהם משתלשלים שרשורים ארוכים של ביקורת נוקבת. המבקרים טוענים בפסקנות שהקופי לא עומד בכללים הבסיסיים ביותר או שיש דרכים הרבה יותר טובות לכתוב את זה.
אבל האמת היא שיש 101 סיבות לצורה הסופית של הקופי במוצר, וייתכן מאוד שזו כן הייתה הבחירה הטובה ביותר שיכלו לעשות כאן.
הינה ארבע דוגמאות קלאסיות:
כשהמחלקה המשפטית נכנסת לתמונה
ככותבת בחברה פיננסית, זה אתגר שאני נתקלת בו כמעט מדי יום: דרישה רגולטורית מאלצת אותי להשתמש בצורת הסביל (passive voice) במקומות שבהם הכותבת שבי זועקת שצריך להשתמש בצורת הפעיל (active voice). יכול להיות שצורת פעיל תהיה נכונה יותר למוצר ולמשתמשים, אבל זה עלול להביא להטלת קנסות (או אפילו לתוצאות חמורות יותר) לחברה שבה אני עובדת, ולכן אני נאלצת להיות יצירתית סביב זה.
במייל הזה למשל, כתוב you've been approved. הייתי מעדיפה לכתוב we approved you (כלומר החלטנו לתת לך מימון), אבל בפועל המימון לא באמת שלנו, אלא של הבנק שאיתו אנחנו משתפים פעולה. אם נגרום למשתמשים לחשוב שאנחנו הגוף המממן, ניכנס לקלחת של צרות.
הרי בקלות אני עלולה למצוא צילום מסך של מיקרו-קופי שכתבתי מתנוסס בפייסבוק או בטוויטר ומלווה בשלל השגות ובביקורת על כך שלעולם אסור להשתמש בסביל, או במגוון הצעות ודרכים לכתוב את זה טוב יותר, או אולי אפילו בטענות שזה נכתב ברשלנות או בעצלות ומעיד על חוסר כישרון או חוסר השקעה. יש בזה משהו, הטרולים לא תמיד טועים, ובאמת מוטב בדרך כלל להימנע מצורת הסביל, אבל ממש לא בכל מחיר.
אני עובדת בתעשיית ה-fintech הידועה ברגולציה הקפדנית שלה, אבל גם לכותבי מוצרים שאין להם אילוצים רגולטוריים מחמירים יש שלל מכשולים אחרים לנווט סביבם. תפקידנו לוודא שכל מה שאנחנו כותבים הוא ללא רבב וללא פשרות, אבל לעיתים קרובות פשוט אין לנו ברירה.
כשהפונקציונליות מכתיבה את הקופי
כתיבת UX עוזרת למשתמשים להשתמש במוצר — היא לא מגדירה את המוצר.
לדוגמה, לאחרונה שיתפתי מצב אפס (empty state) שאהבתי:
ומישהו הגיב: למה אין כפתור ''Create a spreadsheet''?
אני לא יודעת למה אין כפתור, אבל אין.
הפוסט שלי היה על הקופי ביחס לפונקציונליות הקיימת. אני נותנת קרדיט לכל המעורבים ביצירת המסך הזה ומניחה שהיו שיקולים רבים שהביאו להחלטה שלא לשים פה כפתור, ושכותב או כותבת ה-UX התבקשו לכתוב לרכיב הזה כמו שהוא ולא להציע לו שיפורים.
יצא לי לכתוב שפע של קופי מצוין שפשוט לא התאים בסוף לפונקציונליות הקיימת במוצר. קופי שנשמע נחמד, כתוב היטב, אך היה בלתי אפשרי להשתמש בו במוצר. לבסוף נאלצתי לכתוב קופי שאולי היה פחות אלגנטי, אך עשה עבודה הרבה יותר טובה בלעזור למשתמשים להגיע למטרה במוצר.
שעות פיתוח זה עסק יקר
העברתי כמה הרצאות על ה-ROI של מיקרו-קופי. ככלל, חשוב להשקיע בכתיבת UX כי בסופו של דבר, קופי טוב מכניס כסף לעסק! אבל כל מקרה לגופו, וזה לא תמיד שווה את ההשקעה.
לדוגמה, קופי שמתחשב באזור הזמן של המשתמשים ייצור להם כמובן חוויה אישית טובה יותר. אבל לפעמים חוויה מותאמת אישית דורשת המון משאבי פיתוח.
לפעמים יש לנו רעיון לקופי נהדר שיכול לקחת שבוע של פיתוח ולא יזיז את המחט (לפחות לא באופן מדיד). זה אולי ישפר את ההנאה במעט, זה אולי ייתן למשתמשים אקסטרה-נחת, ואולי זו תוספת יפה לפורטפוליו שלי, אבל זה לא יחזיר את ההשקעה. בסופו של יום החברה לא תרוויח. אז בפעם הבאה שמגרד לך להעביר ביקורת על קופי, חשוב לזכור שהפתרון שלך אולי לא הגיוני מבחינה עסקית.
ברור שלא צריך לוותר מראש על הפרטים הקטנים האלה, הרי בסוף הם אלה שיוצרים הבדל גדול, אבל לפעמים אין ברירה וצריך לדחות אותם לגרסה הבאה. או לתמיד. הכל עניין של סדרי עדיפויות.
זה פשוט באג
ראיתי גם הרבה פוסטים שבהם הקופי נראה רע, אבל הבעיה היא בכלל לא בקופי עצמו, זה פשוט באג. אנשים יורדים על קופי שלמעשה בכלל לא נכתב כך. אף כותב או כותבת UX לא ישבו ויצרו את מה שאתם רואים בצילום המסך הזה. באג טכני פגם בחוויה, משתנה נשלף בצורה שגויה, או שהוא מעולם לא נשלף מה-backend ולכן שומר המקום נחשף לעיני כל.
זה ממש לא אומר שצריך להימנע מביקורת
בכלל לא. הנקודה שלי היא שכדאי לראות את הדברים מנקודת מבט הרבה יותר מורכבת והוליסטית. כשאנחנו רואים קופי שאנחנו חושבים שנוכל לשפר, שווה לנסות לשער מה היה מערך השיקולים שהביא לתוצאה הזאת. אילו אילוצים נעשו מאחורי הקלעים כשנכתב הקופי הזה? ואז אפשר לשאול - מה אני הייתי כותבת תחת אותם אילוצים?
לא רק שזו גישה מציאותית ורלוונטית יותר, היא גם מאתגרת יותר, ולכן מהנה יותר.
על הכותבת
יעל בן דוד היא כותבת UX ב-Fundbox ודוקטור לנוירוביולוגיה(!). היא הייתה עיתונאית ומדענית ונעשתה כותבת UX למערכות מורכבות בתחומי הגנטיקה, הקריפטו ומוצרים פיננסיים אחרים.