תבנית אפיון להעתקה

איך משתמשים בתבנית

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

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

סעיף 1: פרטי הפרויקט ומטרות

מטרות

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

רקע והנחות

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

סעיף 2: קהל ותרחישים

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

סיפורי משתמש

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

• בתור [ ], אני צריך [ ], כדי ש[ ]
• בתור [ ], אני צריך [ ], כדי ש[ ]
• בתור [ ], אני צריך [ ], כדי ש[ ]

סעיף 3: מפת אתר

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

סעיף 4: אפיון עמוד-עמוד

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

עמוד: [שם העמוד] (מזהה [ ])

רכיבים לפי סדר הופעה

מצבים מיוחדים

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

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

סעיף 5: רכיבים חוזרים

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

החלטות כיווניות ועברית

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

סעיף 6: תוכן

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

סעיף 7: חיבורים למערכות אחרות

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

סעיף 8: נגישות

אתר שנותן שירות לציבור בישראל צריך לעמוד בתקנות שוויון זכויות לאנשים עם מוגבלות (התאמות נגישות לשירות), התשע"ג-2013. לפי כל זכות, התקן הישראלי ת"י 5568 מחייב מכוח תקנה 35 לתקנות אלה. לפי נוהל הנגישות של משרד החינוך לספקים, בישראל חייבים בקריטריונים של WCAG 2.0 ברמות A ו-AA, ואין כרגע חובה ליישם את הקריטריונים שנוספו ב-WCAG 2.1 וב-2.2. כדאי לבדוק את המצב העדכני לפני ההשקה; הרחבה בנגישות אתרים בישראל.

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

סעיף 9: מדידה ואנליטיקס

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

• הסכמה לעוגיות: [האם נדרש באנר, ואילו כלים נטענים רק אחרי הסכמה]
• דוח: [מי מקבל דוח, באיזו תדירות, ומה הוא כולל]

סעיף 10: קריטריוני קבלה

לכל סיפור משתמש או דרישה מרכזית, כתבו מתי הם "גמורים". בבלוג הטכנולוגי של ממשלת בריטניה מומלץ לכתוב קריטריוני קבלה כתרחישים בתבנית Given, When, Then (בהינתן, כאשר, אז), בשפה פשוטה ובלי להכתיב פתרון טכני.

בדיקות כלליות לפני השקה

• [כל העמודים במפת האתר קיימים ונגישים מהתפריט או מקישור]
• [כל ההפניות מהכתובות הישנות עובדות]
• [האתר נבדק בטלפון ובמחשב, בדפדפנים שהוגדרו]
• [סעיף הנגישות נבדק והצהרת הנגישות פורסמה]
• [כל אירועי המדידה מסעיף 9 נשלחים]

נספח: מחוץ לתחום, שאלות פתוחות ויומן החלטות

מחוץ לתחום בגרסה הזו

• [פיצ'ר או עמוד שהוחלט לא לכלול, ולמה]
• [ ]

שאלות פתוחות

יומן החלטות

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