בית  >  כתבות  > איך בונים "בית" לחוויית משתמש בישראל?

איך בונים "בית" לחוויית משתמש בישראל?

אורן שמיר, 1/3/2010. 2 תגובות.

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


הלוח שליווה אותנו בכל הפגישות

UXI נולד, כמו הרבה רעיונות טובים, במוחו של איש אחד שזיהה צורך.

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

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

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

אז איך בכל זאת יצא מזה אתר?

אדמינסטרציה

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

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

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

בנוסף, אנחנו גרים בערים שונות, עובדים בחברות אחרות, ואחד מאתנו (אמיר) בכלל עושה את שניהם בארץ אחרת.

איך מנצחים על תזמורת קקופונית שכזאת?

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

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

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

השתמשנו ב- BaseCamp כדי לנהל דיונים, לוחות זמנים וחלוקת משימות.

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

השתמשנו ב- Google Documents כדי לערוך ביחד מסמכים ולצ'טט תוך כדי.

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

פרקטיקה

מה עשינו, תכל'ס?

תכנון קונספטואלי

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

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

תכנון פונקציונאלי

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

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

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

סקיצות, שלד ואבטיפוס

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

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

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

עיצוב

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

פיתוח

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

כתיבת תוכן

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

מתודולוגיה

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

ננסה לתאר כמה מהן ואת היתרונות של השימוש בהן.

סיעור מוחות

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

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

  • נגדיר נושא לכל מפגש
  • נגדיר מסגרת זמן
  • נמנה מבוגר אחראי (מנהל דיון)
  • ננהל את הדיון באווירה מקדמת שבה כולם שווים והרשות נתונה

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

פרסונות

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

פרסונות צריכות להיות מפורטות, עם זהות, רקע, מניעים וצרכים שונים.

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

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

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

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

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

טקסונומיה

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

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

"שילוד" (wire-framing)

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

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

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

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

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

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


אב-טיפוס

הליכה דרך אבטיפוס (cognitive walk through)

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

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

מגבלות

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

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

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

זמן

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

נכון שהיה לנו דד-ליין יחסית גמיש אבל מצד שני, כמות שעות האדם שיכולנו לדחוס עד אותו דד ליין לא היתה גדולה במיוחד.

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

תקציב

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

הוצאות רבות (עיצוב, תכנות, אכסון…) מממנת חברת UniqUI שבבעלותו של ברק.

טכנולוגיה

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

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

אנחנו מקווים שהצלחנו להתקרב למטרה זו ומקווים שהאתר יצליח לשרת כמה שיותר אנשים.

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

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



תגובות

2 תגובות לכתבה

כתיבת תגובה

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

לא חובה

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

שלח