RSS לפוסטים RSS לתגובות 228 מאמרים ו- 1,988 תגובות עד כה מאז 2005

איפיון הסכם תנאי שימוש – כשעורך דין הופך למאפיין וצריך לקבל את זה

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

"תחתום בבקשה על הקו המקוקו"

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

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

לאלץ את המשתמש

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

עורך דין כמאפיין ממשק

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

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

עניין של סדרי עדיפויות

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

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

נ.ב

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

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

  1. 12/05/2011 בשעה 13:49 אמיר דותן

    שאלה שנשאלה על ידי עורך הדין יורם ליכטנשטיין מ-http://www.y-law.co.il: "השאלה היא – האם זה הפסד? כלומר, מטבע הדברים כולנו עובדים יחד להשיג תוצאה אופטימלית לבעל האתר, וסיכונים משפטיים הם עניין שחייבים לטפל בו. האם "הפסד" של איש ממשק המשתמש הוא באמת הפסד?"

    תשובתי: היי יורם,

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

טראקבק לפוסט זה | RSS לתגובות לפוסט זה

הוספת תגובה