קטגוריה שבה הכלל הראשון הוא אמינות
אפליקציות שנועדות להציל חיים – קריאת חירום, התראת נפילה, זיהוי מצוקה, ניהול מתנדבים רפואיים, בטיחות עובדים – נמדדות בסטנדרט אחד שאינו קיים בקטגוריות אחרות: הן חייבות לעבוד ברגע הגרוע ביותר. משתמש בפאניקה, סוללה חלשה, רשת עמוסה, מסך רטוב, ולעיתים משתמש שאינו מסוגל להפעיל את המכשיר בעצמו. כל החלטת תכן נגזרת מהמצב הזה, לא מהמצב הרגיל.
מכאן נובע כלל שקשה ליזמים לקבל: בקטגוריה הזו פחות פונקציות זה מוצר טוב יותר. אפליקציה שעושה דבר אחד ותמיד מצליחה בו עדיפה על אפליקציה עשירה שנכשלת אחת מעשרים פעם.
הפעלה בלחץ – עיצוב שונה לגמרי
מחקר על התנהגות בלחץ מלמד שהיכולות הקוגניטיביות והמוטוריות מצטמצמות: קשה לקרוא טקסט, קשה לפגוע בכפתור קטן, וקשה לזכור רצף. ההשלכות המעשיות:
- פעולה אחת, גדולה, במסך הראשון. לא תפריט, לא הזדהות, לא אישור כפול.
- אין תלות בקריאה. צורה, צבע וקול מעבירים את המידע.
- אפשרות הפעלה בלי המסך: לחיצה על כפתור פיזי, ניעור, או פקודה קולית – למצבים שבהם המשתמש אינו יכול להסתכל.
- ביטול קל ומהיר: אזעקות שגויות הן מחיר שיש לשלם על נגישות. אם הביטול מסובך, המשתמשים יכבו את התכונה כולה.
מה אסור לתלות ברשת
הנחת עבודה הכרחית: ברגע החירום אין ודאות לחיבור. לכן פונקציית הליבה חייבת לפעול בכמה ערוצים במקביל, בסדר יורד של אמינות – מהאינטרנט להודעת טקסט, ואם צריך לשיחה. אפליקציה שמציגה "אין חיבור, נסה שוב" ברגע כזה נכשלה בתפקידה. הגישה הזו דומה לעקרון שתיארנו לגבי אפליקציות תחבורה, אך כאן היא קריטית ולא מטרידה.
כשיש חומרה בתמונה
חלק ניכר מהפתרונות המצליחים בקטגוריה משלבים רכיב פיזי: לחצן מצוקה, תג לביש לזיהוי נפילות, חיישן במקום עבודה. הסיבה הנדסית פשוטה – טלפון אינו תמיד ביד, ואינו תמיד נגיש. במקרה כזה מדובר בפרויקט מערכת שכולל חומרה, קושחה ואפליקציה, ובעיקר החלטה קריטית: הפונקציה המצילה חיים יושבת בחומרה, והאפליקציה היא ממשק. הרחבנו על חלוקת האחריות בפיתוח אפליקציה עבור המוצר שלי.
הגבול הרגולטורי – שאלה שחייבת תשובה מוקדמת
כאן נמצא הסיכון הגדול ליזמים. אפליקציה שמסייעת לקרוא לעזרה היא כלי; אפליקציה שמאבחנת מצב רפואי או מנטרת פרמטר קליני עשויה להיכנס לקטגוריה של מוצר רפואי, עם דרישות הוכחה ותיעוד כבדות. הפער בין השניים בעלות ובלוחות זמנים עצום, וההגדרה נקבעת בין השאר לפי הניסוח השיווקי – מה המוצר מבטיח.
העצה המעשית: לברר את הסיווג לפני הפיתוח, ולא אחריו, ולהיזהר מהבטחות שמעלות את הקטגוריה. אם המוצר אכן רפואי, כדאי לעבוד מההתחלה בשיטה שתיארנו בהנדסת מוצרי רפואה.
אחריות, פרטיות והציפייה של המשתמש
מוצר בקטגוריה הזו מייצר ציפייה שהוא יעבוד, ולכן גם חשיפה. שלוש המלצות:
- לנסח בבירור מה המוצר עושה ומה לא. "שולח התראה לאנשי הקשר שהגדרת" הוא ניסוח נכון; "מגן עליך" אינו.
- לטפל בפרטיות בכבוד: מיקום, נתוני בריאות ואנשי קשר הם מידע רגיש. שמירה מינימלית והצפנה הן ברירת המחדל.
- לבדוק בשטח, בתנאים גרועים. בדיקה במשרד אינה בדיקה. סוללה על 5%, רשת חלשה, כפפות, גשם.
לסיכום
אפליקציות שמצילות חיים נבנות לפי היגיון הפוך מהמקובל: מעט פונקציות, אמינות מוחלטת, הפעלה בפעולה אחת, וכמה ערוצי תקשורת חלופיים. לרוב הן דורשות גם רכיב חומרה, כי טלפון לבדו אינו נגיש בזמן אמת. בפרוג'קטס האוס בע"מ אנו מלווים פרויקטים כאלה – חומרה, קושחה ואפליקציה כמערכת אחת – ומסייעים לזהות מוקדם היכן עובר הגבול הרגולטורי של הרעיון שלכם.
רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.
