חמישה טיפים להדגמת תוכנה נהדרת

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

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

נהל את הציפיות של הקהל שלך

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

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

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

תפוח אחד רע מקלקל את כל החבורה

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

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

הנה כמה דרכים להערים על תפוחים רעים שלא להשתתף בהדגמה שלך:

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

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

עשה ריצת תרגול

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

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

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

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

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

שימו לב לפרטים

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

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

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

הצביעו על הבאגים (המובנים מאליהם).

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

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

במקרה שבאג ברור אכן מציג את עצמו במהלך ההדגמה שלך, ציין אותו!

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

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

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

סיכום

הנה לך. חמישה טיפים להדגמת תוכנה מעולה.

  1. נהל את הציפיות של הקהל שלך
  2. ודא שתפוחים רעים לא יהרוס את החבורה
  3. תעשה ריצת תרגול
  4. שימו לב לפרטים והשתמשו ב-Lorem Ipsum
  5. ציין את הבאגים הברורים

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

כתיבת תגובה

האימייל לא יוצג באתר.