עיצוב ארנק קריפטו: היכן הכניסה הראשונה נשברת
הכניסה הראשונה לארנק היא הנקודה היקרה ביותר במוצר: המשתמש עדיין לא קיבל ערך, אך כבר חייב לקבל החלטות בלתי הפיכות. מסך ריק בלי יתרה והיסטוריה הוא קורא כ״שום דבר לא עובד״ והולך לבדוק אם עשה הכול נכון.
מכאן מתחילות נקודות הנשירה ברישום, שאותן מאוחר יותר יקר יותר לסגור באמצעות שיווק מאשר לתכנן בשלב העיצוב.
הניסוח לגבי מפתחות הוא הקרע השני. ״שמרו את הצירוף הסודי״ בלי הסבר של ההשלכות מוביל לשני תוצאות רעות: חלק מהאנשים מדלגים על השלב בלי לקרוא, וחלק מעתיקים את הצירוף להערות או ללוח.
בשני המקרים המסלול של משתמש חדש בארנק מסתיים באובדן גישה, שאי אפשר לשחזר לא באמצעות תמיכה ולא באמצעות רישום מחדש.
אישורים מיותרים הורגים את המשפך. הזנה חוזרת של סיסמה, מסך נפרד לבחירת רשת, אישור לכל פעולה — בכל שלב נושרים חלק מהאנשים, ולתמיכה מגיעות פניות זהות: ״אני לא רואה יתרה״, ״הכספים לא הגיעו״, ״לאן נעלם המפתח״. פניות כאלה לא נפתרות בסקריפט — הן אוכלות זמן של הצוות ולא מביאות אף משתמש חדש.
עיצוב ארנק קריפטו פותר זאת לא בקוסמטיקה, אלא ברצף: קודם להראות מצב פעיל של החשבון, אחר כך להסביר את תפקיד המפתח בשפה אנושית, ורק לאחר מכן לבקש אישורים. בהמשך נבחן כיצד תכנון ממשק הארנק מסיר נקודות נשירה בכניסה ומפחית את העומס על התמיכה.
מה משתנה אחרי עיבוד מחדש של הממשק: אפקט מדיד
האפקט של עיבוד מחדש של הממשק נמדד, ולא מתואר במילים ״נהיה מובן יותר״. אנחנו מודדים לפני ואחרי לפי אנליטיקת מוצר: משפך יצירת הארנק, זמני השלבים, נושאי הפניות לתמיכה. בהמשך — הכיוונים שלפיהם רואים את השינוי.
זמן עד לעסקה הראשונה
הבלימה העיקרית היא לא החתימה עצמה, אלא הדרך אליה: בחירת רשת, הוספה ידנית של RPC, עמלה לא קריאה. אחרי עיבוד מחדש הרשת מוזנת לפי קישור מהשירות, העמלה מוצגת ביחידות מובנות עם הגדרות מוכנות מראש, והחתימה נכנסת למסך אחד.
החציון של ״התקנה → עסקה מאושרת״ מתקצר פי כמה, ושיעור הנשירה בשלב האישור יורד בצורה בולטת יותר מאשר בכל האחרים.
שיעור הרישומים שהושלמו
אנחנו מודדים לפי אירוע ״ארנק נוצר וגיבוי אושר״. גישת גיבוי נשארת חובה, אבל מפסיקה להיות מבוי סתום: הגיבוי מאושר בבדיקה, לא בסימון וי, ומוסבר בשפת ההשלכות, לא בשפת המונחים. שיעור היצירות שמובאות עד הסוף עולה, כי המשתמש לא נוטש את התהליך בשלב לא מובן.
פניות לתמיכה בנושא גישה
בנפרד אנחנו מפרידים בין ״שכחתי סיסמה מקומית״ לבין ״איבדתי צירוף שחזור״ — את השני לא פותרת התמיכה, והגון יותר לומר זאת בממשק מיד מאשר לענות במכתבים. בנוסף, תרחישי שחרור נעילה מובנים וחיווי ברור היכן נשמרים המפתחות. מספר הפניות לשחזור גישה יורד, והעומס על קו ראשון עובר מבדיקות ידניות לשירות עצמי.
סוג השגיאות שנעלם
רשת שגויה, חוסר באמצעים לעמלה, בקשה שנדחתה, ניתוק סשן בעת התחברות לשירות — מצבים אלה מפסיקים להיות ״מסך לבן״. תמיכה ב־WalletConnect ובחתימות חומרה אנחנו סוגרים ברמת הממשק, כך שחיבור מחדש ובחירת התקן יהיו תרחיש שגרתי. שיעור הסשנים הקטועים יורד, והשגיאות שנותרו מקבלות רמז עם פעולה קונקרטית.
גישות לעיצוב ארנק קריפטו: שלוש סכמות עובדות
את סכמת הארנק מגדירים שני צירים בלתי תלויים: כמה רשתות אנחנו תומכים והיכן נמצאים המפתחות של המשתמש. זה לא פרט מימוש, אלא צומת שממנה תלוי היקף העבודה — תמיכה ברשתות בארנק היא לא שורה בקונפיג, אלא פורמטים שונים של כתובות, מודלים של עמלות, זמן אישור וכללי חתימת עסקאות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| רשת אחת | מוצר סביב אפליקציה או טוקן אחד, נדרש ריליס מהיר | את שכבת העבודה עם הרשת יהיה צורך לכתוב מחדש ביציאה לרשתות חדשות, יחד עם היסטוריה וכתובות |
| אגרגטור מולטי־צ׳יין | קהל מפוזר בין רשתות, נדרש ארנק ללא משמורת | מורכבות גבוהה יותר של ממשק ההעברות, כללי עמלות שונים, ביקורת יקרה יותר |
| היברידי עם אחסון מפתחות בשירות | אונבורדינג המוני, קהל בלי ניסיון, כניסה בתרחיש מוכר | חלק מהאמון ניתן לשירות, נדרשים מדיניות שחזור גישה וחתימת סף |
היכן הסכמה נשברת
רשת אחת נותנת את הדרך הקצרה ביותר לריליס ואת משטח השגיאות המינימלי, אבל ההפשטה שנבנתה בארכיטקטורת הארנק לרשת אחת כמעט לא ניתנת לשימוש חוזר. בדרך כלל כותבים מחדש לא רק את החתימה, אלא גם את ניתוח היסטוריית הפעולות ואת לוגיקת הכתובות.
סכמת אחסון מפתחות היברידית מעלה באופן ניכר את שיעור מי שמגיעים לעסקה הראשונה: החתימה נבנית לפי סף בין המכשיר לשירות, והמשתמש לא נתקל בצירוף seed ארוך. המחיר — אחריות מבוזרת לשחזור גישה והיקף בדיקות נוסף.
נדבר על הרשתות שלכם ותרחיש האונבורדינג — נחזור עם הערכה לפי הסכמה שנבחרה.
שלבי העבודה: מניתוח תרחישים ועד מסירת כללים
לפני שורת הממשק הראשונה אנחנו מנתחים איך אדם באמת מבצע פעולה: היכן הוא מאבד ביטחון, באיזה רגע סוגר את האפליקציה, מה הוא רואה כשהרשת נכשלת. לאחר מכן סדר העבודה זהה — עומק משתנה: ככל שהארנק תומך ביותר רשתות ונכסים, כך מפת המצבים צפופה יותר.
- ניתוח תרחישים קיימים. אוספים אנליטיקה והקלטות סשנים, מסמנים את המסלול מהכניסה ועד חתימת העסקה. בפלט — רשימת צווארי בקבוק עם שכיחות, ולא רשימת משאלות לגבי המראה.
- מפת מסכים ומצבים. מפרקים כל מסך: ריק, טעינה, שגיאת רשת, חוסר באמצעים, המתנה לאישור. בנפרד — סירוב וחזרה, כך שהסיבה תהיה מובנת בלי לפנות לתמיכה.
- אב־טיפוס של הארנק. אב־טיפוס קליקבילי על הסתעפויות אמיתיות: שחזור גישה ואישור חתימה נעשה ראשונים. שם גם בודקים כיצד נקראים כתובת הנמען וגובה העמלה.
- בדיקת תרחישים עם משתמשים. נותנים פעולות אמיתיות: התחברות, עסקה ראשונה, שגיאה, שחזור גישה. מתעדים זמן עד ליעד ומספר החזרות אחורה. השערות שלא אוששו יוצאות מהמקאפ.
- תיקונים והרצה חוזרת. מתקנים שינוי אחד בכל פעם, כדי לראות את התרומה של כל אחד, ומאמתים מחדש מקומות שנויים במחלוקת עם משתתפים חדשים. כך נסגר מקור ההפסדים העיקרי — סטטוס פעולה לא מובן.
- מסירת כללים וליווי. מוסרים מפת מצבים, מפרטי רכיבים וכללי התנהגות בעת כשלים: רשתות וטוקנים חדשים מתווספים בלי לצייר מחדש את הממשק. בהמשך עוקבים אחר היכן התרחיש שוב מתחיל להיקרע.
מה נשאר בפרויקט: מסכים, רכיבים, נהלים
הפרויקט נמסר לא בהצגת מקאפים, אלא בסט עבודה שלפיו המהנדס ממשיך בפיתוח בלי התכתבות עם המעצב על כל מסך. בהמשך — מה נשאר אצל המזמין אחרי המסירה.
- מערכת עיצוב לארנק — ספריית רכיבים עם מצבים: רשימה ריקה, טעינה, שגיאת רשת, חוסר באמצעים, עסקה תקועה. לכל רכיב יש וריאציות למצב בהיר וכהה וכללים לשימוש במסכים חדשים.
- מסכי יצירה ושחזור של הארנק — מהזנת הצירוף הסודי ועד אישור היתרה, עם בדיקת סכום בקרה, ולידציה של מילים ורמזים בכל שלב.
- נוהל שחזור גישה — מתואר איזה סט נתונים מספיק לכניסה, מה המשתמש רואה בעת אובדן חלק מהצירוף, כיצד האפליקציה מתנהגת בלי רשת ואילו פעולות מוצעות לו.
- מדיניות אבטחה של הממשק — היכן נדרשת ביומטריה, כמה זמן נשמרת כניסה ברקע, מה מוסתר ברשימת האפליקציות הפתוחות ובמעבר בין משימות.
- תיעוד הממשק — טקסטים של כפתורים, רמזים והודעות שגיאה עם הסבר של הטון הנבחר, כך שמסכים חדשים ייכתבו באותה לוגיקה.
- מפרטים למולטי־צ׳יין — כיצד הממשק מתנהג בעת החלפת רשת: אילו שדות מחושבים מחדש, היכן נדרשת הזנה חוזרת וכיצד מוצגת העמלה.
- כללי מסירת מקאפים לצוות — מבנה קבצים, שמות שכבות, משתני צבעים ומרווחים, גרסת הספרייה שאליה מתחברת הפיתוח.
סט כזה מסיר את התלות במבצע מסוים: מהנדס או מעצב חדש פותח את התיעוד וממשיך לעבוד באותם כללים.
ניתוח מקרה פרויקט: איך קיצרנו את הדרך לעסקה הראשונה
המשימה לא עסקה בוויזואל, אלא בהבאת אדם לעסקה הראשונה: הארנק פעל בסביבת מולטי־צ׳יין, אבל בהתחלה המשתמש עבר תשעה מסכי רישום. צירוף הקוד הוצג בשלב השני, לפני הסבר תפקידו, ואישור ההעברה הציג האש גולמי וכתובת חוזה. בשני המקומות האלה עבר עיקר הפניות לתמיכה.
אונבורדינג: מתשעה מסכים לארבעה
את התרחיש הרכיבו מחדש: בחירת הרשת הועברה לרגע שאחרי יצירת הארנק, במקום דף ארוך עם צירוף הקוד נעשה תצוגה שלב־אחר־שלב עם בדיקת מילות בקרה, ושחזור גישה הופרד למסלול נפרד עם אזהרה מפורשת. בכל שלב נשארה פעולה אחת ותוצאה צפויה אחת, וההתקדמות נראית. הדרך לעסקה הראשונה התקצרה מ־11 דקות ל־3.
מסכי אישור: השלכות במקום האש
באישור ההעברה אנחנו מציגים מה בדיוק מחויב, לאן זה הולך ומה תהיה היתרה אחרי הפעולה; חוזים לא מוכרים מסומנים באזהרה נפרדת, ומגבלת הסכום נקבעת מראש. החיבור לשירותים חיצוניים נעשה דרך WalletConnect — החתימה נוצרת במכשיר, המפתחות לא עוזבים אותו, ולכן מסך האישור הפך גם לנקודת אמון. התנהגות המסכים הושוותה ל־MetaMask, כדי שדפוסים שמוכרים למשתמש לא ידרשו לימוד מחדש.
מה הראו המדידות אחרי ההשקה מחדש: שיעור האונבורדינגים שהושלמו עלה מ־41% ל־68%, הפניות בנושא גישה ושחזור הצטמצמו בערך פי שלושה, ושיעור ההעברות שבוטלו במסך האישור ירד מ־18% ל־6%. לכל שלב הוטמעו אירועי אנליטיקה — התיקונים הבאים נעשים לפי המשפך, לא לפי ניחושים.
במה נבדלת סכמה שבה המפתחות אצל המשתמש מסכמה שירותית?
אחסון עצמאי של מפתחות: המפתח הפרטי נוצר במכשיר ולא עוזב אותו — חתימת העסקאות נעשית מקומית, והשירות לא רואה לא את המפתח ולא את הנגזרות שלו. הממשק נבנה סביב המגבלה הזאת: רישום חובה של הצירוף הסודי עם בדיקה במסך הבא, היעדר ״שחזור סיסמה״ ואזהרה שאובדן הצירוף שווה לאובדן גישה.
אחסון שירותי מעביר את המפתח למאגר מאובטח בצד המפעיל, והכניסה מצטמצמת לאימות רגיל. שחזור גישה נעשה דרך דואר, מספר או גורם שני, והתמיכה מקבלת תרחישים מנוהלים: הוצאת גישה מחדש, הקפאת פעולה חשודה, שלילת התקן. המחיר — אמון במפעיל ואישורים נוספים: כניסה חוזרת, מגבלות על פעולות.
בין הקצוות יש אפשרות ביניים: המפתח מתחלק לחלקים — אחד נשאר אצל המשתמש, השני אצל השירות, והחתימה נבנית בהשתתפות שניהם. הבעלות העצמאית נשמרת, אבל מופיע תרחיש שחזור עובד.
| מודל | גישת המשתמש | שחזור גישה | מה משתנה בממשק |
|---|---|---|---|
| מפתחות אצל המשתמש | צירוף סודי במכשיר, חתימה מקומית | רק באמצעות גיבוי הצירוף | רישום חובה של הצירוף ובדיקה |
| אחסון שירותי | כניסה, גורם שני, מפתח במאגר השירות | דרך דואר, מספר, תמיכה | כניסה רגילה, מגבלות, אישורים |
| פיצול מפתח | חלק אצל המשתמש, חלק אצל השירות | שחזור משותף של החלקים | כניסה ראשונה קצרה, חזרה ברורה |
מודל האחסון קובע לא רק את הקריפטוגרפיה, אלא גם את היקף התמיכה ואת מספר האישורים. לכן קובעים אותו ראשון — ממנו תלויים הניווט, הטקסטים ולוגיקת הסירובים.
ספקות טכניים לפני התחלה: בקצרה ולעניין
את ההתחלה רק לעיתים רחוקות חוסם החלק הוויזואלי — מה שמעכב הם צמתים הנדסיים: איך להוסיף רשת לארנק שכבר הושק, מה יקרה לתרחישי שחזור גישה אחרי שנה של שימוש ואיך הצוות עובד בסביבת פרודקשן בלי להתקרב למפתחות המשתמשים. ריכזנו ארבע שאלות שאנחנו סוגרים לפני שורת הקוד הראשונה.
האם אפשר להוסיף רשת חדשה לארנק שכבר הושק?
כן, אם תיאור הרשתות ופרמטרי ההתחברות נמצאים בשכבה נפרדת, ולא מוטבעים במסכים. הוספת רשת היא רשומה במרשם ובדיקת תאימות חתימה: מריצים את הקונפיגורציה בסביבת בדיקות, משווים פורמטים של כתובות והערכת עמלה, ואז מוסרים למשתמשים. אין צורך בהוצאת גרסה חדשה של האפליקציה לשם כך, המרשם מגיע יחד עם עדכון הנתונים.
האם עיבוד מחדש של הממשק ידרוש לכתוב מחדש את לוגיקת העבודה עם רשתות?
לא. את הרכבת העסקה, הערכת העמלה, האישור וטיפול בסירובים מוציאים למודול נפרד עם חוזה קבוע, והמסכים עובדים רק עם המצב שלו. לכן הרידיזיין לא נוגע בשכבת הרשת, והבדיקות האוטומטיות לחתימה ולשליחה נשארות תקפות — תיקוני ממשק לא הופכים לבדיקה חוזרת של כל הלוגיקה.
איך בודקים תרחישי שחזור גישה?
השחזור נעשה במסלול נפרד עם בדיקות אוטומטיות לכל רשת נתמכת: הזנת צירוף השחזור, הוצאת מפתחות חוזרת, גישה ליתרה, חתימת עסקה. בנפרד מריצים מסלולים שליליים — שגיאת הקלדה בצירוף, אובדן גישה להתקן, שלילת סשן פעיל. תרחישים עם כמה חתימות ואחסון חומרה של מפתחות נבדקים בעמדה נפרדת.
איך הצוות נכנס לסביבת העבודה ומה זה אומר לאבטחת הממשק?
גישה ניתנת לפי תפקידים, לכל מהנדס יש מפתח אישי, ופעולות בסביבת פרודקשן — רק דרך תהליך מאושר. לבדיקות יש סביבה מבודדת עם אמצעי בדיקה.
אבטחת הממשק נבנית על שלושה דברים: המפתח הפרטי לא עוזב את המאגר המאובטח של המכשיר, הכתובת והסכום מאושרים באופן מפורש, וכתובת שהודבקה מהלוח מושווית למקור.
נדבר על המשימה: מה נדרש מצדכם
הערכת פרויקט ארנק קריפטו מתחילה לא במקאפים, אלא בנתוני המקור. ככל שתתארו בצורה מדויקת יותר מה כבר קיים ואילו מגבלות חלות, כך יהיו פחות עבודות מחדש בשלב שבו הממשק כבר בנוי ונבדק.
דיון במשימה הוא שיחה אחת לעניין, שאחריה אנחנו מקבעים את ההיקף ולא חוזרים לשאלות בסיסיות. כדי לחזור עם הערכה ותוכנית עבודה, ולא עם הבהרות, נדרש קלט כזה:
- מסכים קיימים — צילומי מסך או קבצי מקור של מקאפים, אם הממשק כבר קיים;
- רשימת הרשתות והנכסים שהארנק צריך לתמוך בהם: ממנה תלויה לוגיקת הכתובות, העמלות ואישור הפעולות;
- תפקידי משתמשים — מחזיק קמעונאי, סוחר פעיל, חשבון ארגוני עם כמה חתימות;
- דרישות רגולטורים וקומפליינס פנימי: בדיקת כתובות, מגבלות, תיעוד פעולות ביומן, מצב קריאה בלבד;
- מגבלות של מועדי השקה ופלטפורמות — אפליקציות מובייל, הרחבת דפדפן, גרסת ווב;
- ממה המוצר כבר מורכב: ספריות, צמתים, ספק גישה לרשת, זמינות קוד המקור והזכויות עליו;
- מערכת עיצוב קיימת וגיידליינים — אם אין, נרכיב פלטה, טיפוגרפיה וספריית רכיבים מאפס.
היעדרות של חלק מהסעיפים לא חוסמת את ההתחלה: את החסר נשלים בעצמנו בשלב הניתוח ונאשר מולכם. בהמשך תקבלו הערכת פרויקט, תוכנית עבודה לפי שלבים עם נקודות קבלה והרכב צוות למשימה. תארו את המשימה בצורה נוחה — נחזור עם תוכנית ולוחות זמנים.