בית  >  כתבות  > נסיעת מבחן: בדיקת שמישות ב-iPad

נסיעת מבחן: בדיקת שמישות ב-iPad

עילי שריג, 22/8/2011. אין תגובות.

פורסם במקור בבלוג שמונים:עשרים ב-24 ביולי 2010

לאחרונה הובלתי תהליך של בדיקת usability על אפליקציית-iPad שהיה לי את הכבוד לעצב. היות שקהל היעד של המוצר הוא אמריקאי, השתמשנו בשירותיה של חברת בדיקות חיצונית בארה״ב. תכנית הבדיקות ודרישות הגיוס נכתבו כאן בארץ ונשלחו לביצוע בחברה. התהליך היה מרתק וסיפק תובנות חשובות על הבעיות של המוצר, חלקן צפויות וחלקן מפתיעות.

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

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

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

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

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

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

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

גיוס האנשים הנכונים

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

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

הצבת הבעיות והשאלות העיצוביות במרכז

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

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

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

נטרול מעטפת הדיבורים

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

מכשולי שמישות חיצוניים לממשק

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

לא לקפוץ למסקנות

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

מסקנות לסיכום

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

כתבות בנושאים דומים



תגובות

אין תגובות עדיין.

כתיבת תגובה

לא יוצג בשום מקום

לא חובה

רוצים שהתמונה שלכם תופיע עם התגובה? העלו אותה ל-Gravatar.

שלח