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

חמשת השלבים של עיצוב מכוון-משתמש

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

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

התרשים הזה שהופיע בעבר באתר של חברת הייעוץ הלונדונית Flow Interactive מתאר בצורה ברורה את השלבים השונים והפעילויות שמבוצעות בכל אחד מהם. כפי שניתן להתרשם, המילים testing ו-evaluation מפוזרות לאורך כל התהליך וזאתי למעשה מהות המתודולוגיה.

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

החלוקה לשלבים מאוד ברורה וכך גם הקשר בינהם:

1. מחקר

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

2. ניתוח וגיבוש גישה ראשונית

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

3. תכנון

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

4. יישום

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

5. השקה

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

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

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

6 תגובות על “חמשת השלבים של עיצוב מכוון-משתמש”

  1. 19/08/2007 בשעה 16:27 Islay

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

  2. 19/08/2007 בשעה 16:30 אמיר דותן

    אני מקליד עם יד אחת וביד שניה מחזיק את הוריד שמתנפח לי ברקה השמאלית. תודה. לפחות עכשיו המיני-פאניקה שלי קיבלה הצדקה נוספת :)

  3. 21/08/2007 בשעה 20:40 דנה

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

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

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

  4. 21/08/2007 בשעה 21:21 אמיר דותן

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

  5. 21/08/2007 בשעה 22:32 דנה

    צודק מאה אחוז.. הנה קצת יותר פירוט על הספר:
    Preece J., Rogers, Y., Sharp, H. (2002) Interaction design.

    ובאמזון

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

  6. 21/08/2007 בשעה 23:10 אמיר דותן

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

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

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

RSS לתגובות לפוסט זה

הוספת תגובה