בנו אב טיפוס עובד לאפליקציה עם AI והעמידו אותו מול אנשים
שווה לבנות אב טיפוס כשהוא עונה על שאלה שמוקאפ לא יכול לענות עליה: האם מישהו באמת מבין את התהליך כשהוא צריך להשתמש בו? Anticode כותב אפליקציה עובדת מהתיאור שלכם, מלאה בנתוני דוגמה שמסומנים ככאלה, שבודק יכול לפתוח בטלפון שלו. העמוד הזה עוסק במה כדאי לבנות כאב טיפוס, איך לתאר אותו, ואיפה נגמר אב טיפוס שפועל בדפדפן אחד.
למה אב טיפוס עובד מלמד יותר ממוקאפ
מסכים סטטיים בודקים אם אנשים אוהבים את המראה. הם כמעט אף פעם לא בודקים אם אנשים מצליחים להשתמש במוצר, כי הבודק צריך לדמיין מה קורה אחרי כל הקשה, ומי שמנחה את הסשן מוצא את עצמו מספר את המוצר בקול. אב טיפוס לחיץ שבאמת מגיב מבטל את הסיפור הזה. הבודק מקליד בשדה אמיתי, רואה סכום אמיתי משתנה, ומקבל מצב ריק אמיתי כשהוא מוחק את הפריט האחרון. הבלבול שלו נוגע לעיצוב שלכם, לא לחורים באב הטיפוס.
זה גם משנה את השאלות שאפשר לשאול. עם מוקאפ שואלים "הייתם משתמשים בזה?", ואנשים עונים בנימוס. עם משהו שעובד אפשר לתת משימה ("הוסיפו את המשמרת של יום שלישי הבא ותראו מה זה עושה לשעות השבועיות שלכם") ולראות איפה הם מהססים.
החליטו מה אב הטיפוס צריך להוכיח
לפני שמתארים משהו, כתבו את השאלה האחת או השתיים שהבדיקה צריכה לענות עליהן. כך הבנייה נשארת קטנה והסשנים ממוקדים. שאלות נפוצות:
- הבנה: האם אנשים מבינים בתוך שניות למה משמש המסך הראשי?
- המשימה המרכזית: האם הם מצליחים להשלים לבד את המשימה האחת שהמוצר קיים בשבילה?
- הרגע המביך: מה קורה בקצה שאתם לא בטוחים לגביו: רשימה ריקה, טעות שצריך לבטל, שם ארוך שנשבר לשורה חדשה?
- נכונות: אחרי השימוש, האם הם היו מחליפים בזה את הגיליון, המחברת או האפליקציה שהם משתמשים בהם היום?
כל מה שלא משרת את השאלות האלה אפשר להשמיט או לזייף. עמוד הגדרות שאף אחד לא יפתח בסשן של עשרים דקות הוא מאמץ מבוזבז, גם אם קל מאוד לייצר אותו.
איך לתאר את זה ל־Anticode
תארו את האדם, את המשימה ואת המסכים בכמה משפטים, וכתבו איך נתוני הדוגמה צריכים להיראות. לדוגמה: "אב טיפוס של אפליקציה להחלפת משמרות לצוות של בית קפה. מסכים: סידור העבודה של השבוע, בקשה להחליף משמרת, ורשימת בקשות החלפה פתוחות. השתמשו בשמונה עובדים לדוגמה ובשבוע מציאותי. סמנו הכול כנתוני הדגמה." ה־Architect עונה בתוכנית קצרה (שם, מסכים, מראה, יכולות) ועשוי לשאול עד שלוש שאלות במקומות שבהם התשובה משנה את הבנייה, כל אחת עם תשובות מוצעות שאפשר להקיש עליהן.
כשאתם בוחרים Build it, המודל כותב את כל האפליקציה כמסמך HTML אחד, ואפשר לראות את הקוד נכתב בזמן אמת. בניות חדשות של אפליקציות אפשר גם לפתוח בדפדפן ללא ממשק ברוחב של טלפון ושל מחשב נייד, לצלם מסך וללחוץ עליהן, כשהשגיאות מוחזרות לתיקון, כאשר שירות הבדיקה הזה זמין.
שהחלקים המזויפים יהיו גלויים
אפליקציות של Anticode רצות בסביבה מבודדת בלי רשת, כך שכל מה שבדרך כלל דורש שרת מדומה בתוך העמוד: משתמשים אחרים הם אנשי דוגמה, הודעות "שנשלחו" נוחתות ברשימה מקומית, ומסך התחברות מקבל כל קלט. האפליקציה מסמנת אותם כנתוני הדגמה היכן שזה חשוב. השאירו את הסימון הזה גלוי במהלך הבדיקות. בודקים שחושבים שהם משתמשים במערכת חיה מקבלים החלטות שונות ומסוכנות יותר מבודקים שיודעים שזה מודל, ובשלב הזה אתם רוצים את המשוב מהסוג השני.
מה שכן נשמר הוא כל מה שהאפליקציה שומרת בדפדפן של הבודק עצמו. אם מישהו מוסיף שלושה פריטים, סוגר את הלשונית וחוזר מחר, הפריטים עדיין שם באותו מכשיר. זה מספיק למחקר יומן לאורך שבוע, כל עוד כל בודק נשאר עם טלפון או מחשב אחד.
להריץ את הסשנים ולשנות את הבנייה
- פרסמו את אב הטיפוס בכתובת שלו ב־anticode.dev ושלחו לבודקים את הקישור. אין מה להתקין.
- לבעלי עניין, שלחו במקום זאת קישור לבדיקת לקוח: הם יכולים לפתוח את התצוגה המקדימה הנוכחית בלי חשבון ולהשאיר הערות שמשויכות לאזור בעמוד. הקישורים פגים אחרי 14 יום כברירת מחדל, ואפשר לבטל אותם.
- אחרי כל סבב, בקשו שינויים במילים פשוטות ("תעבירו את כפתור ההחלפה לכל כרטיס משמרת"). השמירות האחרונות נשמרות בהיסטוריית הגרסאות (עד מספר שנקבע לפי התוכנית שלכם), כך שאפשר להציג את הסבב הראשון ואת השלישי זה לצד זה או לחזור אחורה.
מה אב טיפוס בדפדפן אחד לא יכול לבדוק
היו ברורים עם עצמכם לגבי הגבול. אב טיפוס בסביבה מבודדת פועל במכשיר אחד בכל פעם, ולכן הוא לא יכול לבדוק:
- שום דבר שקורה בין אנשים: התראות אמיתיות, רשימות משותפות, שני בודקים שרואים זה את השינויים של זה.
- התחברות אמיתית, הרשאות או שחזור חשבון.
- נתונים חיים מבחוץ, תשלומים או יכולות AI בתוך האפליקציה (אפשר רק לחקות אותם בתשובות דוגמה קבועות).
- ביצועים עם נפחי נתונים אמיתיים או רשתות איטיות.
כשהרעיון שורד את הבדיקות, הייצוא ל־Next.js הוא הצעד לעבר מוצר אמיתי. הוא מכסה בניות של אפליקציות ונותן לכם פרויקט App Router סטנדרטי ב־TypeScript עם Postgres דרך Prisma, התחברות במייל, תפקידי לקוח וצוות ואזור ניהול. זו נקודת התחלה שמפתח ירחיב, לא אפליקציה מרובת משתמשים גמורה, ואפשר לדחוף אותה למאגר GitHub שתבחרו. המדריך לייצוא ל־Next.js מפרט מה יש בו. אם אתם צריכים יכולות מרובות משתמשים לייצור בלי לכתוב קוד, כלי ללא קוד עם צד שרת עשוי להתאים לכם יותר משניהם.
שאלות נפוצות
זה מחולל אבות טיפוס עם AI או כלי עיצוב?
הוא בונה קוד עובד, לא פריימים על קנבס. אתם מקבלים אפליקציה אמיתית בדפדפן, שמתאימה לבדיקות שמישות; אם אתם צריכים קובצי עיצוב מדויקים לצוות עיצוב, השתמשו בכלי עיצוב לצדו.
הבודקים יכולים להשתמש בזה בטלפון?
כן. האפליקציה שמתפרסמת היא עמוד אינטרנט שעובד בדפדפן של הטלפון, וכל מה שהיא שומרת נשאר באותו טלפון.
אפשר לראות מה הבודקים הזינו?
לא את מה ששמרו בתוך האפליקציה, שנשאר במכשיר שלהם. אם תוסיפו טופס משוב או יצירת קשר, הפניות האלה יגיעו אליכם במייל ובלוח הבקרה.
אב הטיפוס הופך לאפליקציה האמיתית?
הוא יכול להיות נקודת ההתחלה. הייצוא ל־Next.js הופך אותו לפרויקט עם מסד נתונים והתחברות שמפתח יכול להמשיך לבנות עליו.