הגדרת סיפורי משתמשים ופיתוח זריז
עיקרון ליבה של תהליכי פיתוח מודרניים הוא פיתוח זריז . מתודולוגיית פיתוח זו מדגישה שימוש בסיפורי משתמשים קטנים וגדולים כדי להגדיר מה המערכת עושה מנקודת מבט של משתמשים, ולא טכנית. למשתמש אכפת אם המוצר מהיר, קל לשימוש, ופותר את הבעיה שלו. לא אכפת להם אם הוא עוקב אחר ארכיטקטורה בת 3 שכבות, יש לו Mongo DB או שהוא משתמש ב- Rails או Asp.net.
סיפורי משתמש:
- קל להבנה, וכל אחד יכול להשתתף
- עבודה איטרטיבית; ניתן וצריך לשנות או לתקן אותם לעתים קרובות
- יישר מפתחים, משתמשים ומומחים עסקיים סביב מטרות וציפיות משותפות
- הרבה יותר קל לקריאה ממסמכי דרישה של 400 עמודים
Storyboard That המספק פלטפורמה אידיאלית ליצירת סיפורי משתמשים זריזים ולעורר שיחה בפורמט שהוא הרבה פחות מחייב מקיר טקסט.
אפוס
בהקשר של סיפורי משתמשים, "אפי" הוא פשוט סיפור רחב מאוד, שיתפרק בהמשך לסיפורי משתמש ספציפיים רבים. החל מאפוס מיישר את כולם עם ראייה אחת ברמה גבוהה. הסיפור האפי מעגן פרויקט מלמעלה למטה, ואם אין טעם לבנות אפוס, עבודה תומכת תהיה גם בזבוז מאמץ.
בסיפור זה, ברור מאוד מהו החזון לטווח הארוך וכיצד צריכה להיראות הצלחה. סיפור אפי טוב צריך לכלול:
- הגדרה או הקשר
- שחקנים או משתמשים
- מטרות ויעדים
- פעילויות ואירועים
הגדרת משתמשים
במיוחד בעת עיצוב תוכנה, חשוב שיהיה לך ראייה טובה של איך יהיו המשתמשים. לא כל משתמש יתאים את החזון הזה במדויק, וייתכן שישנן מספר קטגוריות של משתמשים, אך חזיונות נפרדים אלה זקוקים לביטוי. המחשבה על המשתמשים קודם כל שומרת על הנדסת יתר וסיבוכי יתר, מונעת ממוצר חדש שיהיה משהו לכולם ואינה מועילה לאף אחד.
יצירת סיפור
לאחר שהוקם אפוס והוגדרו משתמשים, ניתן לבנות סיפורים קטנים יותר וספציפיים יותר על חוויות משתמש מסוימות. הסיפורים להלן מפרקים את המתואר למעלה לשני נרטיבים: חיפוש סדר והזמנה מחדש של מוצר.
נרטיבים אלה אינם מכילים מידע טכני; למשתמשים לא אכפת כיצד התוצאות מושגות, כל עוד הוא מבצע את המשימות הרצויות. באופן דומה, ה- UX מתואר באופן כללי, כדי להימנע מחניקה של חדשנות או מכריחת דרך. באופן כללי, סיפורים צריכים להיות:
- קטן - פחות מ -10 ימי עבודה
- בעל ערך - לאחר השלמתם הם אמורים לספק משהו שמיש
- הערכה - מסוגלת ליצור הערכה של מגרש כדורים לכמה מאמץ מדובר
מחפש הזמנה
ביצוע סדר מחדש
שיחה ותכנון לבדיקה
סיפורים אלה צריכים להזמין שיחה ושאלות, כגון:
- האם אלה הסיפורים הנכונים שיתאימו לאפוס שלנו?
- אילו עוד סיפורים צריך ליצור?
- האם סיפורים אלה תואמים את מה שאנו יודעים על המשתמשים שלנו?
סביר בהחלט ליצור סיפורים רבים; למעשה, יש לעודד זאת. חלק מהסיפורים הללו לעולם לא ישמשו, אך חשוב לראות את הדרך שהם הניחו. אוסף הסיפורים הזה ישטוף דרישות נוספות ויבחן את ההשפעות.
הסיפורים צריכים לעורר וליידע דיון על האופן בו התוכנה תיבדק ועל אילו כללים עסקיים צריך להגדיר במפורש. לדוגמה:
- עד כמה חיפוש צריך להיות מהיר?
- האם יש הגבלת זמן להזמנות חוזרות?
- מה המערכת צריכה לעשות אם זו ההזמנה המחודשת השנייה? חמישי?
- אילו בדיקות ושאלות מעקב יהיו לך?
© 2024 - Clever Prototypes, LLC - כל הזכויות שמורות.
StoryboardThat הוא סימן מסחרי של Clever Prototypes , LLC , ורשום במשרד הפטנטים והסימנים המסחריים בארה"ב