ב-28/7/2010 התכנסנו למפגש השני, UXI02. זו הפעם השניה שהאתר/ארגון יוצא מהתחום הוירטואלי ונפגשים פנים אל פנים. הנושא הפעם היה אבות טיפוס.
עדכון 11/8: ההרצאות צולמו בוידאו, אתם מוזמנים לצפות.
סיכום כללי:
- אב טיפוס הוא חשוב כדי למקד את כל האנשים בתהליך
- אפשר לעשות בדיקות שמישות עם אב טיפוס, או לפחות למשש את הדופק של המשתמשים לגבי המוצר
- בחירת התוכנה ליצירת אבות-טיפוס צריכה להיעשות לפי פרמטרים שונים, ביניהם התאמת הנאמנות של אב הטיפוס שהיא יוצרת למוצר הסופי (אינטראקציה, עיצוב, קוד ותוכן)
- כל תוכנה ליצירת אבות-טיפוס היא טובה אם אתה שולט בה
אפשר לראות גם טוויטים מהאירוע, וצילומים בפייסבוק. וידאו מלא של שתי ההרצאות – בקרוב.
האירוע התקיים בחסות ג'ון ברייס ויוניק יו איי.
ברק דנין פתח את המפגש אחרי מפגש קפה והיכרות שהחל מעט מוקדם מהרגיל (במקום ב18:30 אנשים הגיעו כבר ב18:00. זה טוב).
בסקירה של ברק על ההישגים של UXI עד עכשיו, הוא גם הזמין את הקהל לכתוב כתבות ל-UXI. יש לכם משהו מעניין להגיד? שלחו ל-[email protected]. ככל שיש יותר דברים בעברית כולנו מרוויחים.
אבות-טיפוס: רקע ומתודולוגיה. ליאור יאיר, נטקראפט
ליאור יאיר סקר בהרצאה שלו את היתרונות שהוא רואה בשימוש באב טיפוס בתהליך האיפיון והעיצוב של המוצר. ליאור הגדיר את האב טיפוס בתור:
- מייצג גרסה ראשונית של המוצר
- מדגים צורה ופונקציונליות בדרך ויזואלית
- יכול להכיל רק חלק מההתנהגות של המוצר האמיתי
- לעיתים שונה מהמימוש הסופי
- זול לייצור
בנושא הרמות השונות של הנאמנות (fidelity), כדאי לקרוא את המאמר של פרד ביצ'ר כאן באתר. בקצרה, כשאומרים נאמנות בהקשר של אבות-טיפוס, הכוונה היא לשאלה עד כמה האב-טיפוס דומה למוצר הסופי. ליאור הזכיר שני אספקטים של נאמנות: נאמנות גראפית ונאמנות לאינטראקציה. בהמשך ליאור הסביר את ההעדפה שלו ל-Axure בתור תוכנה שיכולה בקלות לייצר אב טיפוס עם נאמנות בינונית-גבוהה למוצר הסופי, בשני האספקטים האלה – אינטראקציה ועיצוב. זאת בניגוד לאב טיפוס עם נאמנות נמוכה כמו אב טיפוס על לוח מחיק או מנייר.
בסרט הבא ליאור הדגים מה קורה כשלוקחים את הרעיון של אבות-טיפוס מנייר קצת רחוק מדי – ב-Axure הרבה יותר קל לייצר אינטראקציות מורכבות כמו זו שפה:
לאחר מכן ליאור הראה דוגמאות לאבות טיפוס שהם מייצרים בנטקראפט. Axure מהבחינה הזו מאוד נוחה: לפי ליאור גרף הלימוד של Axure הוא נמוך ומי שמכיר את ויזיו יוכל לייבא אובייקטים וקטוריים בקלות.
המגרעה של אב טיפוס בAxure וגם בהרבה תוכנות אחרות היא שלמרות שהאב-טיפוס הוא אינטראקטיבי, אי אפשר לעשות איתו כלום מבחינת פיתוח – צריך לזרוק אותו בסוף התהליך, ולפתח את המוצר מאפס. היתרון הגדול הוא שכל צוות הפיתוח מתואם לגבי סוג האינטראקציה והתהליכים שצריך ליצור במוצר, כי אב-הטיפוס מתקשר אותם בצורה מצויינת: פשוט מפעילים אותו ומגלים מה התגובה הנדרשת על כל פעולה.
סרטוני הדגמה
ליאור הראה דוגמאות מעניינות של תהליך יצירת אב-טיפוס בעזרת Axure עבור אתרים וגם עבור iPhone ו-iPad, והראה סרטונים שמדגימים את השימוש באבות-טיפוס על-גבי מכשיר היעד שלהן.
תודה לנטקראפט שאיפשרו לנו להציג את הסרטים האלה כאן.
נאמנות גראפית בינונית, נאמנות אינטראקטיבית גבוהה – אפליקציית iPhone
נאמנות גראפית גבוהה, נאמנות אינטראקטיבית גבוהה – כמעט כמו הדבר האמיתי – אפליקציית אייפון
נאמנות גראפית בינונית, נאמנות אינטראקטיבית גבוהה – אפליקציית אייפד
אבות טיפוס: כלים, כללים וטיפים מעשיים. רן לירון, מטריקס/ג'ון ברייס
ישנם כלים רבים ליצירת אב-טיפוס. איזה כלי מתאים לכם? בתחילת ההרצאה רן נתן רשימה של פרמטרים שלפיה אפשר לבחון כלים לאב-טיפוס, ביניהם רמת המהימנות של האב-טיפוס. בנוסף לחלוקה של ליאור לפי רמת הנאמנות הגראפית והאינטראקטיבית למוצר הסופי, רן הציע עוד שני אספקטים של נאמנות: תוכן וקוד.תוכנות שונות תספקנה כל אחד מהדברים הללו באופן שונה. אם ברצוננו לקבל נאמנות גבוהה לקוד, למשל, נשתמש ב-Dreamweaver.
לעומת ליאור, רן צידד באב טיפוס עם נאמנות גרפית נמוכה לעיצוב. לפי רן אב טיפוס צריך להיות 'מקושקש', לא מהוקצע. זה מונע מהלקוח והמתשמש מלהיקשר לאב טיפוס לפני העיצוב. בנוסף, ככל שהאב טיפוס נאמן יותר גרפית צריך להשקיע בו יותר זמן. גם כך אנחנו נשקיע מין הסתם הרבה זמן בלהיות נאמנים לאינטראקציה כדי שנוכל להתשמש באב טיפוס למבחני שמישות.
רן המשיך לסקור את היתרונות והחסרונות של הרבה תוכנות שנמצאות שם בחוץ, ממתינות שנאפיין בהן. הוא הוביל אותנו לבחירה המתבקשת מבחינתו: Powerpoint. עונה על רוב הדרישות, נמצא שם ממילא ומספק את הכלים הדרושים להדגמת האינטראקציה, להצגה מול הלקוח מאחר וסביר ויש לו את התוכנה.
רן המשיך והדגים בשארית הזמן איך הוא מכין אב טיפוס מהיר בעזרת Powerpoint שכולל תפריט נגלל ומעבר בין אופציות, וכל זאת בלי להשתמש בשום כלי חיצוני, רק במה שמגיע עם Powerpoint.
סיכום
- אב טיפוס עוזר להעביר את המסר שאנחנו רוצים ללקוח או למשתמשים
- אפשר לבנות את האב טיפוס בצורה כזו שתאפשר בדיקת משתמשים
- קיבלנו רשימת פרמטרים שתעזור לנו להחליט באיזה כלי ליצירת אב-טיפוס להשתמש
- קיבלנו טיפים לשימוש ב-Powerpoint ככלי ליצירת אב-טיפוס
דיעה אישית
אני מכיר את רן וליאור פחות משנה, ולשניהם יש הרבה עיטורים מהתחום. היה מרתק לשמוע את ההשקפות השונות שלהם על אב טיפוס. רן צודק כשהוא אומר שאב-טיפוס 'סכמטי' מונע היקשרות של הלקוח לאב-טיפוס. ההיקשרות עלולה להיות בעוכרינו כשהלקוח יראה את העיצוב הגראפי. הסכמטיות גם יכולה לגרום ללקוח או המשתמש להיות יותר מעורב ו'להעז' להביע דיעה: אחרי הכל, זה רק שרטוט, לא הדבר האמיתי. 'זה לא יעליב אותם, הם רק בתחילת הדרך'.
ליאור שאומר שאב טיפוס צריך להיות כמה שיותר קרוב ומהוקצע. יש בזה משהו: כשאתה מראה משהו שנראה טוב, מקצועי ומושקע יש בזה משהו מאוד משכנע. זה נראה כאילו איש מקצוע עבד על זה, השקיע את המחשבה והזמן שמשלמים לו. אתה גם שולט בכלי מקצועי. לדעתי יש סיכון בשימוש בפאוארפוינט כי כל מיני בעלי תפקידים יכולים לשנות את הקובץ כדי לקדם איזו דיעה שלהם – זה יותר מדי קל לעשות את זה. נכון שגם על PDF אפשר לעשות כל מיני פעולות, אבל זה פחות קל למשתמש הפשוט.
נוסף על כך, כשמשתמשים באב-טיפוס לבדיקת משתמשים, כדאי שתהיה לו נאמנות גבוהה לאינטראקציה. להרבה משתמשים קשה לדמיין אינטראקציה. הם צריכים לחוות אותה באמת כדי להבין אותה. אנשי מקצוע יכולים לעתים לעשות את הקפיצה המחשבתית בין אפיון בנייר או במסכים סטטיים, אבל גם הם יבינו את האינטראקציה יותר טוב אם יחוו אותה ולא ידמיינו אותה.
כשעבדתי באינטראקטיב בהולנד והגשתי איפיון של אתר, התעכבו איתי במשך 20 דקות להבין למה בחרתי בפונט מסויים ולמה הפינות מעוגלות או לא מעוגלות. אולי אם זה היה מעט יותר מקושקש, לא הייתי נכנס לזה. מצד שני, אפיינתי אפליקציה לאייפון עכשיו, והיה חשוב להראות שכפתור מסויים הוא נייטיב, הכפתור הסטנדרטי של האייפון, ולא משהו שמעצבים באופן ייחודי לאפליקציה. אם זה היה איפיון בקוים מרושלים, אולי המפתחים או אנשי השיווק היו מחליטים לתת את הפרשנות שלהם.
כך שמסקנותיי הן:
- אב טיפוס הוא חשוב כדי להעביר את המסר, וכדאי שהתוכנה שלך או אתה תדעו להדגים את האינטראקציה של המוצר. כפרילאנס אני יודע שכדאי שזה ייקח כמה שפחות זמן.
- שלוט בכלי שלך. לא היית מקבל את המלה של רופא לבוש בגופייה שמודד לך חום עם יד על המצח.
- סוג אב-הטיפוס ורמות הנאמנות שלו תלויים בקהל היעד. להציג למורות זה לא כמו להציג למפתחים של מיקרוסופט או למנהלי מחלקות בבנק. כל אחד צריך אב טיפוס שונה.
- שאל את עצמך האם האיפיון שלך הוא באמת נכון או שפשוט היה לך סטנסיל של קרוסלת תוכן, אז שמת אותו כבר שם. רמז: ככל שהאיפיון כולל יותר אלמנטים שכבר היו לך מפרוייקט אחר, כך גדל הסיכוי שאפיינת לפי השליטה שלך בתוכנה.
המפגש היה מוצלח מאוד, והסיכום מעולה, תודה!
עוד מחשבה שעלתה בי במהלך המפגש בעקבות הדיון והשאלות היא "מי הלקוח שלך". אני חושבת שהרבה מההתיחסויות השונות והדרישות השונות שיש מאב טיפוס נובע מהלקוח שאליו האב טיפוס מיועד.
האב טיפוס שליאור מדבר עליו, עם הנאמנות מאוד גבוהה, מיועד בדרך כלל ללקוח שמזמין את האפליקציה, שהוא לא בהכרח המשתמש הסופי (ואז יש מוטיבציה מסוימת לעשות אב טיפוס די גמור, כמו שהסברת), או למבחני שימושיות מתקדמים (אז המוטיבציה היא אחרת, אבל התוצאה דומה).
מצד שני, לי כל הזמן ישב בראש תסריט אחר – של חברה שמאפינת מוצר מתגלגל, כלומר בכל שלב מאפיינים פיצ'רים נוספים, אבל הלקוח נשאר אותו לקוח, שהוא גם המשתמש הסופי. מצד אחד – אין קשר ישיר עם הלקוחות ואי אפשר לשלב אותם בשלב מאוד ראשוני של תכנון, ומצד שני – האב טיפוס צריך לא רק לשמש לבדיקות שימושיות, אלא גם להיות הבסיס לאיפיון שאחר כך עובר למתכנתים.
בקיצור – השאלה מי הלקוח שלך, ומה תהליך הפיתוח שלך, היא שאלה שאולי שווה דיון נפרד, אבל מהדיון הנוכחי נראה לי שאין ספק שיש לה משמעות בבחירת פורמט לאב טיפוס.
בוקר טוב הדס.
השאלה היא תמיד מי המשתמש שלך, ולפי זה אתה תראה לו את המוצר. זה תקף גם לגבי האב טיפוס. לזה התכוונתי בסעיף 3 של הדיעה האישית.
אני חולק עלייך לגבי האפשרות שהלקוח הוא המשתמש.המשתמשים הם בד"כ לא אלו שמשלמים. גם אם מדובר במוצר מתגלגל, ואולי דווקא אז, כדאי שהא טיפוס יתורגם למשהו יותר משרטוטי לוח מחיק. אם עובדים רק עם לוח מחיק, או רק עם נייר, דברים עלולים ללכת לאיבוד. מישהו עלול לקחת את האינטרפציה שלו לדברים. וגם: עבודה על האב טיפוס גורמת לתהליך שבמהלכו דברים שנאמרו בע"פ שוקעים וניתנת עליהם עוד מחשבה.
היי ישי,
כנראה לא הבהרתי את עצמי – אני לחלוטין לא חושבת שלוח מחיק או רק נייר הם מספיקים! להיפך, אני חושבת שהדרישה שלי מכלי לאב טיפוס היא עוד יותר מורכבת, כי הייתי רוצה שהוא גם יהיה בסיס לאיפיון שהולך למתכנתים. את החלק הזה קצת הזנחנו במפגש, אבל לדעתי הוא חשוב.
ובקשר למי משלם – זו בדיוק הנקודה שעליה רציתי להרחיב את הדיון.
אני חושבת שהדיון התרכז מנקודת המבט של מאפיין/יועץ, שם הלקוח לא משלם. אני מנהלת מוצר בחברה שמוכרת מוצר אחד, אצלנו ללא ספק הלקוח הוא המשלם.
אגב, ספר מוצלח בתחום:
http://rosenfeldmedia.com/books/prototyping/
באנגלית אומרים The right tool for the right job. אני חושב שהדיון הזה עומד בדיוק על הנקודה הזו.
בכנס קיבלנו "טעימות" של שני כלים לפרוטוטייפינג. כל אחד מהם מתאים לסוג אחר של פרוטוטייפינג, למשימות אחרות, קהלי יעד אחרים וכו'.
לכן, אני אישית מאוד אהבתי את החלק הראשון של ההרצאה של רן, שעסק בדיוק בהנחיות כיצד לבחור כלי מתאים לצרכים של כל ארגון.
בדיון שאחרי, וגם כאן, שמנו דגש רב על הצגת הפרוטוטייפ ללקוח. רובנו אכן עושים הרבה מזה, אבל אבות טיפוס נבנים גם כדי לבדוק אותם על משתמשים, כדי להציג אותם למפתחים ו/או מעצבים ואפילו כדי לנהל עליהם דיון פנימי בתהליך הפיתוח בתוך החברה.
לכל אחד מהצרכים האלה מתאימים כלים אחרים.
אולי זו ההזדמנות להמשיך את הדיון הזה לכיוון של איסוף המידע, כדי שבסופו של דבר מדור ה"כלים" כאן באתר יכלול פירוט מירבי על היתרונות והחסרונות של כל כלי בכל משימה.
אני חושב שרן הוכיח שהכלי הכי טריוויאלי בתפריט ה'התחל' שלנו יכול להיות חרב סמוראים בידיים הנכונות. ואני יודע על כאלו שהצליחו לייצר שייסה עם ויזיו למרות שהיו עליו כל המקרואים שצריך. מה שאני מנסה לאמר הוא שפירוט כמו שהצעת של יתרונות וחסרונות הוא מאוד סובייקטיבי.
שאלה שלדעתי לא נענתה היא כמה הכלי הופך לאיפיון: הרבה חברות מחפשיםמאפיינים שעבדו עם WPF או סילברלייט. לדעתי זו לא שיטה נכונה מאחר והאיפיון הוא הבנה של המשתמש ואז הבנה מה הטכנולוגיה יכולה להציע ומה היא יכולה לשפר.
ישי, תודה על הסיכום המעניין (עבור מי שלא נכח, כמוני).
רציתי להדגיש שימושים / יתרונות נוספים של כל סוגי האב-הטיפוס:
1. סנכרון של כל העוסקים במלאכה.
אורן נגע בנקודה זו. במצגות דובר על "הלקוח", בגוף ראשון יחיד. בפועל, לרוב לא מדובר על אדם בודד אלא על מגוון אנשים: מנהלי מוצר, מפתחים, מעצבים, אנשי שיווק, הנהלה בכירה, בודקי תוכנה, תומכים טכניים, וכתבים טכניים ועוד…
לאנשים אילו יש לרוב רקעים ויכולות שונים. אותו משפט במסמך הדרישות "זוכה" למגוון פרשנויות. יש חברות המפתחות על סמך מסכים כתובים ומצגות בלבד (וללא הצגת ממשק משתמש). בתום הפיתוח מגלים שהמוצר שפותח אינו עונה לצרכי השיווק או ליכולות המשתמשים…
במקרים אחרים דנים בפתרונות אפשריים באמצעות דיון (ובנפנופי ידיים..). ללא ממשק משתמש קשה להעריך חלופות ומשמעויות.
אב-הטיפוס מאפשר, ואף מאלץ, את כל הנוגעים בדבר לדבר באותה שפה.
2. הערכת עלויות.
הצגת ממשק המשתמש מאפשרת הערכה מדויקת יותר של זמנים ומשאבים. המתפתחים הם המרווחים העיקריים. מחלקות נוספות – דוגמת בדיקות, תמיכה טכנית – יוכלו להעריך בשלב מוקדם את המשמעות עבורם.
באחת החברות בהן עבדתי שגופי הפיתוח לא יתנו הערכות זמנים אם לא יספקו להם מסכים עיקרים. ההחלטה התקבלה אחרי מספר ניסיונות כושלים להעריך משאבי פיתוח באמצעות מסמכי דרישות ללא ממשק משתמש.
היה מאוד מעניין.
עדיין לא ברור איזה כלים לפרוטוטייפינג ממש צרכים לעבודה…
היי דנה,
הספר הזה אחד הפרסים בכנס באוקטובר. רציתי להגיד שאני מקווה לזכות, אבל נראה לי שההשתתפות אסורה על צוות UXI…
http://uxilive.co.il
שי – תודה ואתה צודק. לאנשים שונים בתפקידים שונים ומרקעים שונים יש הבנה שונה של התהליכים. זה גם משנה גם האם אנחנו נשתמש ב'לורם איפסום', או ב'[פה יבוא טקסט פה יבוא טקסט], או בטקסט שמתאר את התוכן הסופי. לדעתי אתה למדת אותי על הפיל ששלושה עיוורים ממששים אותו: זה של הזנב תיאר את הפיל כחיה דקה וקצרה, זה שליד החדק תיאר את הפיל כחיה עבה וארוכה וזה שליד הבטן תיאר את הפיל בתור חיה עצומה ועגולה. אבטיפוס היה מאפשר לנו לתת להם למשש את כל הפיל בקטן, אם ללכת על המשל הזה.
וברק – מה הטעם בלכתוב את הכלים אם אתה לא יכול לרמות ;).
מיכאל – אני חושב, כמו שכתבתי לאורן, שהשאלה היא כמה אתה שולט בכלי.
ok.ישי
הבעיה היא שבתוכנות הקיימות לא נותנות אפשרות ללכת עד הסוף של פרויקט.
רק התחלה וזהו – זורקים הכל לפח.
אני מדבר על כל שלבים פיתוח: פרוטוטייפ – עיצוב – קוד
למשל, למנהל אין כלים לשליטה לכל אורך הפרויקט…
רק לכתוב מכתבים כמו: "תוסיף קצת אדום למלא…"
אני מדבר על אפשרות לעבוד לכל צוות לעבוד בשדה אחד, גם עם לקוח
נא לראות: פרוטוטייפ
https://coutline.com/coside/designer/page/mockup/r?page_id=0477ddd03bbea72b
עיצוב:
https://coutline.com/coside/designer/page/mockup/r?page_id=1b7f58dcc0edf864
זה עובד רק עם מוזיללה
רוצה להעיר \ לשאול שתי שאלות למרות (ואולי בגלל) שלא הייתי בכנס
1- האם דיברתם על הבעייתיות של פרוטוטייפ בשלב האפיון \ עיצוב?
בעיני השימוש בכלי (ולא כל כך חשוב איזה) הרבה פעמים מוביל אותנו לפתרונות שמתאימים לכלי או שאנחנו יודעים איך להציג אותם בעזרת הכלי ולא מאפשר לנו חופש פעולה מלא. צריך להזהר מלהתחיל שם
2- מי מכין פרוטוטייפ , במיוחד כאשר מדובר ב- high fidelity הכולל גם עיצוב גרפי? האם זו פונקציית ה- UX? הבעיה שלי עם זה היא הנחיתות המספרית שלנו במרבית החברות ואז אם זמן המאפיין \ מעצב הולך על פיתוח פרוטוטייפ מפורט מה הסיכוי להגיע למודולים אחרים הנמצאים בפיתוח? יש שאלה של 20-80 ואיפה כדאי להשקיע את הזמן שלנו. התשובה לזה היא שוב כמובן תלוי – תלוי מי הלקוח ומה מטרת הפרוטוטייפ, אין לי תשובה פשוטה, אבל צריך גם לשים לב מה המחירים…
נורית
נורית, נהדר למצוא אותך כאן. חבל שלא היית. אבל נעשה שוב.
לשאלותייך:
1. ראי את הערה מספר 4 שלי ואת התגובה שלי מתחת לתגובה של אורן שמיר. זה סיכון. בשביל זה צריך לעשות פרסונות ואיפיון מתוך המשתמש, ואז לקבל סקירה של הטכנולוגיה, מה היא יכולה לעשות או מה היא נדרשת לעשות במקרה והיא לא נבחרה עדיין.
2. זה מאוד תלוי ביכולותיו של המאפיין. כאלו מבינינו שהם one stop shop יכולים לעשות באמת גם את העיצוב וגם את הפרוטוטייפ. הם בד"כ הראשונים שיפלו במלכודת ה'לאפיין מה שאני יכול לפתח'. אני מכיר לפחות שניים שעושים איפיון, עיצוב ופיתוח בפלאש/פהפ/פלקס או כל דבר בצורה מעוררת קנאה. שניהם אפילו לא מתרברבים בכך, שזה בכלל מרתיח.
ואמירה כללית: צריך להיותת אוונגליסטים. להגיד – רוצים להצליח, אין חצי דרך.
הי נורית.
אם פספסת את הכנס תוכלי לראות את ההרצאות בוידאו ב- http://uxi.org.il/pages/3070
בשלבים שונים של תהליך העבודה (החל בגיבוש הדרישות והתשתית ראשונית, ועד בדיקות השימושיות וכל מה שבדרך') יש ל"Prototype" משמעות שונה ו-best practice שונים.
אני מסכים שיש נטייה "לחפש את המטבע מתחת לפנס" ולייצר בכל כלי מה שנוח וזמין באותו כלי. זו, אגב, אחת הסיבות שאני מצדד בכלים גמישים, שלא גורמים למאפייני ומעצבי הממשק להסתמך יותר מדי על הספריות המובנות של הכלי.
שאלת מי אחראי על ה- high fidelity prototype
התייחסתי לנושא ה- fidelity(מהימנות, התאמה למקור) בקצרה בהרצאה, וציינתי שיש מספר סוגים שונים של מהימנות שיש לקחת בחשבון – מהבחינה הגרפית, מבחינת האינטראקציה, מבחינת הקוד ומבחינת התוכן.
אני מניח שאת מתכוונת ל-Graphic fidelity, אולי בשילוב עם Interaction fidelity. בעיקרון, אמור להיות אחראי אליהם מי שמופקד על הנושאים הללו במוצר. אם יש מעצב גראפי, תפקידו יהיה ליצור את המסכים (על סמך תשתית אפיון הממשק שהוגדרה קודם לכן). אם יש בפרויקט מישהו שתפקידו מוגדר כ- Interaction design, הוא אמור להיות מופקד על הצד הזה באב הטיפוס. במסגרות בהם יש צוות UX של איש אחד או שניים (ויש חברות מכובדות שמעסיקות "צוות" כזה) שמטפלים בכל נושא ה-UX, כולל העיצוב הגראפי, זה יהיה מן הסתם תפקידם.
כפי שציינתי בהרצאה, חשוב להתאים את אב הטיפוס לצורך, וממש מזיק להשקיע בכל סוג שהוא של high fidelity prototype בשלבים מוקדמים מדי של תהליך האפיון.
זה כמובן על רגל אחת – אני עוסק בנושאים אלו ואחרים בהרחבה בסדנת ה-Prototype שנפתחת בעוד מספר שבועות (לפרטים – http://alturl.com/bwris )
[…] של המפגשים כולל סרטונים שהוצגו שם. אז לנוחיותכם – תקציר המפגש שעלה היום (08.08.2010) לרשת וכמה מילים על ההרצאה […]