עיצוב NFT מרקטפלייס: היכן הממשק מאבד קונים
בעיות בתרחיש הרכישה ב-NFT מרקטפלייס כמעט אף פעם לא קשורות לבלוקצ'יין. מה שנשבר הוא החיבור בין השלבים: הקונה מצא לוט, אך לא הבין במסך אחד כמה ישלם בסופו של דבר.
המחיר מוצג בטוקן התשלום, ואילו עמלת הפלטפורמה ותמלוגי היוצר צפים רק בשלב האישור האחרון — וחלק מהאנשים חוזרים לגלריה במקום להשלמת הרכישה.
צוואר הבקבוק השני הוא היסטוריית העסקה. בממשק של פלטפורמת NFT הבעלים, מכירות קודמות ותנאי התמלוגים מפוזרים לעיתים בין לשוניות או מקופלים בבלוק שאיש לא פותח. הקונה לא מבחין בין הנפקה ראשונית למכירה חוזרת ולא מבין מה בדיוק הוא חותם עליו.
שמישות המרקטפלייס נפתרת כאן באמצעות סדר הנתונים: הסכום הסופי עם מבנה תשלום מפורק, מקור הלוט וסטטוס ההנפקה — במסך אחד ובפורמט אחד, בלי החלפת הקשר.
התרחיש השלישי הוא היקר מכולם באפליקציה הניידת: הפילטרים שהוחלו אינם נשמרים. הקונה עובר לכרטיס הלוט, חוזר — והאוסף שוב אבד, יש להרכיב את המבחר מחדש מאפס. תכנון המקטעים במרקטפלייס חייב לשמור על מצב: פרמטרי הפילטר נשארים בקישור, המיקום בפיד והאוסף האחרון שנצפה משוחזרים בחזרה.
עיצוב NFT מרקטפלייס — זהו מפת מצבים ומעברים ביניהם, ולא אוסף של מסכים יפים. להלן נבחן כיצד נסגר כל אחד מהפערים הללו.
מה נותן ממשק מעובד היטב: מהירות, אמון, מכירות
נוחות רכישת NFT תלויה במספר הצעדים בין "אני רוצה" ל"חתמתי". חיבור ארנק, בחירת רשת, הזנה חוזרת של נתונים, המתנה לאישור — כל מסך מיותר מאבד חלק מהמשתמשים.
כאשר המסלול מתכווץ ל"כרטיס → מחיר ועמלה → חתימה בארנק", ההמרה של המרקטפלייס נמדדת כבר לא לפי קליקים, אלא לפי שיעור העסקאות שהושלמו.
שמישות המרקטפלייס נשענת על מצבי ממשק כנים. שלד עמוד בזמן טעינה, התקדמות הנפקת הטוקן, סטטוס מפורש "ברשת / אושר / נדחה" עם סיבה וכפתור ניסיון חוזר — מסירים את המקור המרכזי לנטישות: האדם לא מבין מה קורה וכמה זמן לחכות. את הרשת והעמלה מציגים לפני החתימה, כפי שזה בנוי ב-MetaMask ובארנקים חיצוניים אחרים.
הפחתת הנטישות בפלטפורמה מגיעה גם מהצד השני — האזור האישי של היוצר. התקדמות הנפקת האוסף, טיוטות, היסטוריית מכירות והצגה חוזרת בקליק אחד מחזירים יוצרים למרקטפלייס, ולא להתכתבות עם התמיכה. מכירות חוזרות גדלות במקום שבו היוצר רואה את תוצאת עבודתו.
את אפקט העיבוד בודקים במספרים: שיעור העגלות הנטושות, מספר הצעדים הממוצע עד לרכישה, חזרת יוצרים בתקופה, שיעור העסקאות החוזרות. אם המדדים לא זזו, הממשק נשאר החלטה של טעם אישי.
דרכי מימוש: ויטרינה, אפליקציה, בלוק מוטמע
אופן הצגת הקטלוג קובע כיצד המשתמש עובר את הדרך מצפייה בלוט ועד לחתימה על העסקה, וכאן יש שלוש קונפיגורציות עובדות. ויטרינת הווב של NFT נבנית מהר יותר מאחרות וסוגרת מיד תנועה מחיפוש ומרשתות חברתיות, אך חתימת העסקה דרך ארנק בטלפון נשארת נקודת הניתוק השכיחה ביותר.
אפליקציית המובייל של המרקטפלייס מסירה זאת — סשן נייטיבי והתראות על הצעות מחזירים את המשתמש — אך דורשת בנייה נפרדת וסנכרון מתמשך עם הוויטרינה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| ויטרינת ווב עם ממשק אדפטיבי | השקה ובדיקת ביקוש, תנועה מחיפוש ומרשתות חברתיות, רכישות נדירות | פילטרים ועומק הגלילה נתקלים ביכולות הדפדפן, החזרה נשענת רק על סשן שמור |
| אפליקציית מובייל של המרקטפלייס | ליבת הקהל נכנסת מדי יום, דרושות התראות על הצעות והצעות מחיר | בנייה נפרדת לשתי פלטפורמות, ביקורת בחנויות, שתי גרסאות קטלוג בתמיכה |
| בלוק קטלוג מוטמע | אתר שותף, עמוד אוסף, גלריית יוצר | שליטה מוגבלת על סגנונות ומרקאפ, חלק מעיצוב העסקה עובר לצד השותף |
לא משנה איזו אפשרות נבחר, מתחתיהן מונחת שכבה משותפת: סכמת מטא-נתונים אחידה ללוט, קטלוג עם הגשה מהשרת ותרחיש חתימה אחד. אז המעבר מוויטרינה לאפליקציה לא שובר לא את סטטוסי הלוטים ולא את טיוטות העסקאות.
ממשק אדפטיבי של המרקטפלייס אינו אפשרות נפרדת, אלא דרישת בסיס — מרקאפ אחד נבנה באופן זהה ממסך צר ועד רחב.
כיצד בנויה העבודה על הממשק: שלבים ובדיקות
סדר השלבים כאן אינו מקרי: כל צעד הבא יקר יותר מהקודם, ולכן החלטות בלתי הפיכות — מבנה המקטעים, מודל המצבים, הרכב הרכיבים — מתקבלות לפני שמופיע הפיקסל הראשון של השכבה הוויזואלית. להלן הרצף שבו עוברת העבודה על ממשק המרקטפלייס.
- ניתוח תרחישים ותפקידים — קונה, יוצר נכס, מודרטור. עבור כל אחד קובעים מטרות, פעולות מפתח ונקודות שבהן התרחיש נשבר.
- סכמת מקטעים של הפלטפורמה — מפת מסכים ומעברים: גלריה, כרטיס נכס, פרופיל, ארנק, היסטוריית פעולות. בנפרד מתארים מצבים: רשימה ריקה, טעינה, שגיאת רשת, עסקה שנדחתה.
- אב-טיפוס של המרקטפלייס בווירפריימים — שלד קליקבילי ללא שכבה ויזואלית, כדי לבדוק לוגיקה ולא עיצוב. תיקונים בשלב זה עולים דקות במקום ימים.
- דיזיין-סיסטם ושכבה ויזואלית — טוקנים, גרידים, מצבי כפתורים, אישור פעולות עם ארנק; רכיבים נבנים מיד גם לערכה כהה וגם לערכה בהירה.
- בדיקות שמישות עם משתמשים אמיתיים — 5–8 אנשים פותרים משימות של רכישה והצגת לוט, סופרים שיעור השלמות מוצלחות וזמן עד לפעולה הראשונה.
- מסירה לפיתוח — מקאטים ב-Figma עם תיאור התנהגות רכיבים, מצבים אדפטיביים ואנימציות: המהנדס מקבל רכיב, לא תמונה.
- ליווי הבנייה — משווים את הממשק המיושם למקאט ומבררים פערים לפני הריליז, לא אחריו.
מה מוסרים לאחר העבודה: מקאטים, מערכת רכיבים, נהלים
אנחנו מוסרים לא אוסף תמונות, אלא מערכת עובדת שלפיה הפיתוח בונה את הממשק בלי ניחושים. כל אלמנט מקושר למשתנה של ערכה, עבור כל מסך מתוארת התנהגות במצב חריג, ונקודות מחלוקת נסגרות בכללים, לא בהסכמות בעל פה.
- מקאטים של עמודי המרקטפלייס לפי התרחישים העיקריים: קטלוג עם פילטרים, כרטיס טוקן והיסטוריית בעלות, הצגה למכירה, רכישה, פרופיל יוצר — לדסקטופ ולאפליקציית מובייל.
- מערכת רכיבים של המרקטפלייס: כרטיסים, תגיות מחיר וסטטוס, פאנלים של פילטרים, חלונות אישור — עם וריאנטים וכללי קינון.
- כללי מצבי ממשק: טעינה, תוצאה ריקה של פילטר, ניתוק קשר, עסקה בעיבוד, חתימה שנדחתה, פעולה שבוטלה.
- טוקני עיצוב: צבע, טיפוגרפיה, גרידים, ריווחים, צללים — כמשתנים שמועברים לערכת הפרויקט בשלמותם.
- אב-טיפוס של מעברים עם לוגיקת חזרה: לאן מובילה הפעולה ומה רואה המשתמש אם ויתר עליה.
- תיעוד הממשק: שמות שכבות, מפרטי ריווח, צ'ק-ליסט לקבלת המרקאפ, מילון מונחים בשפת המשתמש.
- טקסטים של תוויות, רמזים והודעות שגיאה — כדי שהמפתח לא ייאלץ להמציא אותם תוך כדי.
- צ'ק-ליסט נגישות: ניגודיות, פוקוס מהמקלדת, תוויות לתוכנות קריאת מסך.
המסירה לא מסתיימת בקישור לקובץ: אנחנו עורכים סשן הבהרה עם צוות הפיתוח, עונים על שאלות בנוגע למצבים ומלווים את המרקאפ עד לקבלה.
מקרה בוחן: כיצד השתנו המדדים לאחר עיבוד הממשק
המרקטפלייס עלה לפרודקשן עם בק-אנד עובד, אך תרחיש הרכישה התפרק בממשק: אחד עשר מסכים, ארבעה מהם אישורי חתימה ב-MetaMask, וסטטוס העסקה חי בלשונית נפרדת "הפעולות שלי". המשתמש לא ראה אם העמלה חויבה ובאיזה שלב התהליך נתקע, ולכן סגר את החלון באמצע והתחיל את הרכישה מחדש.
מה הראו המדידות לפני העיבוד
המסלול הממוצע עד לעסקה מאושרת — 9 דקות ו-11 צעדים, שיעור הפעולות שבוטלו בשלב החתימה — 38%. פניות לתמיכה בנוגע לממשק היוו יותר ממחצית מהטיקטים, ומתוכן שני שלישים — "הכסף חויב, הטוקן לא הגיע" ו"אני לא מבין מה לעשות הלאה". במובייל הביטולים היו גבוהים עוד יותר: טופס ההצגה איבד את המטא-נתונים שהוזנו בעת מזעור האפליקציה.
מה שינו ומה יצא
הרכבנו תרחיש השלמה אחיד של ארבעה צעדים, את העמלה והסכום הסופי הצגנו לפני החתימה, ואת מצב העסקה הוצאנו ישירות לכרטיס — עם שלבים מפורשים: חתימה, המתנה לאישור הרשת, מוכן. טיוטת ההצגה נשמרת במכשיר, ואפליקציית המובייל עושה שימוש חוזר באותם מצבים כמו הווב.
חודשיים לאחר הריליז המסלול עד לרכישה התקצר מ-11 צעדים ל-4, הזמן עד לעסקה מאושרת — מ-9 ל-3 דקות, הביטולים בשלב החתימה ירדו מ-38% ל-12%, והפניות לתמיכה בנוגע לממשק — ב-61%.
רכישות חוזרות בתוך שבוע עלו כמעט פי שניים — מדדי השמישות לפני ואחרי נמדדו על אותו משפך, בלי שינוי בלוגיקת החוזים.
במה שונה הוויטרינה מהאזור האישי של היוצר?
הוויטרינה והאזור האישי של היוצר הם שני מוצרים שונים בתוך פלטפורמה אחת, עם תפקידי משתמשים שונים ותרחישים שאינם חופפים. הקונה מגיע כדי למצוא נכס ולקבל החלטה על עסקה; היוצר — כדי להנפיק אוסף ולנהל את מחזור החיים שלו.
אסור לתכנן את שני המעגלים באוסף מסכים אחד: החפיפה כאן היא רק ברמת השפה הוויזואלית והרכיבים המשותפים.
בוויטרינה תרחיש הקונה הוא לינארי — למצוא דרך חיפוש או אוסף, להשוות לוטים, לבדוק את היוצר ואת היסטוריית הבעלות, לאשר רכישה. לכן כרטיס הטוקן חייב להציג מיד נדירות, בעלים נוכחי, נתח תמלוגים וסטטוס מכירה, כדי שההחלטה תתקבל בלי מעבר למקטעים נוספים. צומת נפרד הוא הערכת עמלת הרשת לפני החתימה: אם מסתירים אותה עד הסוף, חלק ניכר מהעסקאות נשבר באישור.
באזור האישי של היוצר הפוקוס מוסט להנפקה ולניהול הנכס: ליצור אוסף, להגדיר מהדורה ותמלוגים, להעלות מדיה לאחסון מבוזר, להנפיק טוקן, להציג למכירה או להסיר ממנה.
שם גם נמצאים טיוטות, הנפקה מושהית, יומן עסקאות וניתוח שגיאות — ההנפקה ברשת עלולה להיכשל, והיוצר זקוק לדרך לחזור על הפעולה בלי ליצור כפילות.
לערבב את המעגלים מסוכן גם מבחינת מצבי הנתונים. הוויטרינה עובדת עם מטמון מטא-נתונים וצריכה להגיש את הקטלוג באופן מיידי, האזור האישי — עם תור עסקאות שבו קריטיים סטטוס מדויק ואידמפוטנטיות.
לכן מפת המקטעים של המרקטפלייס נבנית מתפקידי המשתמשים בפלטפורמה: דיזיין-סיסטם משותף, אך ניווט שונה, צפיפות ממשק שונה וספי אישור פעולות שונים.
שאלות נפוצות על ממשק המרקטפלייס
שאלות על ממשק המרקטפלייס צפות בדרך כלל לפני תחילת העבודה, ולא אחריה: המזמין רוצה להבין אם יהיה צורך לצייר הכול מחדש מאפס, מי אחראי לפערים בין המקאט למרקאפ, ומה יקרה לעיצוב כשהפלטפורמה כבר פעילה. להלן מה שאנחנו בדרך כלל דנים בו בהתחלה ומקבעים בהסכמות.
בקצרה: העברת סגנון קיים היא אפשרית, אך דורשת סקר — חלק מההחלטות יהיה צורך להרכיב מחדש על טוקנים ורכיבים, אחרת המסכים החדשים לא יהיו ברי-סקייל. לוחות הזמנים של תכנון הממשק תלויים במספר התרחישים, לא במספר המסכים.
האם אפשר לשמור על הסגנון הוויזואלי הקיים ולא לעשות רידיזיין מאפס?
כן. אנחנו מנתחים את הצבעים, הטיפוגרפיה, הגרידים ומצבי האלמנטים הקיימים, מוציאים מהם כללים חוזרים ומרכיבים דיזיין-סיסטם: טוקנים, רכיבי גלריה, כרטיס לוט, פילטרים, היסטוריית עסקאות.
הוויטרינה נשארת מזוהה, אך תרחישים חדשים — הצגת לוט, אישור בארנק, מצב המתנה ושגיאה — נבנים כבר מבלוקים מוכנים ולא מצוירים מחדש. כפילויות סגנון במקאטים נעלמות, והיקף התיקונים באיטרציה הבאה יורד.
כמה זמן תופס תכנון הממשק ובאיזה شکل עוברים המקאטים לעבודה?
תחילה מתארים תרחישי משתמש ומצבים, אחר כך מרכיבים את המסכים, ואז — את המפרט. מסירת המקאטים למפתחים אינה נעשית בתמונות: מוסרים שכבות מסומנות עם ריווחים מפורשים, וריאנטיות של רכיבים, רשימת מצבים (טעינה, רשימה ריקה, שגיאת רשת, חתימה שנדחתה) ותיאור נקודות אדפטיביות. בנפרד מפרטים את הערכה הכהה ואת התנהגות הרשימות הארוכות — זה מה שבדרך כלל שובר את המרקאפ.
מי אחראי לפערים בין המקאט למרקאפ?
אנחנו. המפרט והמרקאפ הם חלק מהתוצאה, ולא נספח לתמונה. בקבלה אנחנו משווים התנהגות ולא פיקסלים: מצבי רכיבים, מעברים, הודעות שגיאה, עבודת טפסים וטבלאות. אם הפער נגרם מתיאור חסר מצדנו — מתקנים בלי אישור נפרד, ואם הוא נובע ממגבלה פלטפורמית — מציעים חלופה ששומרת על הלוגיקה.
מה קורה לממשק לאחר ההשקה?
תמיכה בממשק לאחר ההשקה היא ניהול ספריית הרכיבים, ולא תיקון חד-פעמי. תרחישים חדשים מוסיפים לאותם כללים, וישנים — מעדכנים כשהלוגיקה של הפלטפורמה משתנה. כך המרקטפלייס לא מתפזר לסגנונות שונים לאורך כמה ריליזים.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי לחזור עם הערכת עבודה על הממשק, ולא עם נוסחים כלליים, יש צורך בסט נתוני פתיחה מכם. בדרך כלל די בשיחה אחת: אתם מתארים את המוצר, מציגים את המסכים הנוכחיים ומציינים את תרחישי היעד — אנחנו מחשבים היקף ומרכיבים תוכנית עבודה על המרקטפלייס.
- תיאור המוצר: מודל הפלטפורמה, מי המוכר ומי הקונה, מה נמכר — לוטים בודדים או אוספים.
- מסכים נוכחיים: מקאטים, צילומי מסך, אב-טיפוס או ממשק חי — אפילו טיוטות, אם המוצר כבר קיים.
- תרחישי יעד: כיצד המשתמש נכנס, מחבר ארנק, מציג לוט, קונה — ומה נחשב להצלחה בכל שלב.
- מגבלות: לוחות זמנים, תפקידים בצוות, מוכנות הצד השרתי, אילו נתונים מגיעים מהלוגיקה של הבלוקצ'יין.
- נקודות התייחסות: שניים-שלושה אתרים שמוצאים חן בעיניכם או מעצבנים אתכם, עם הסבר מה בדיוק ולמה.
- נתונים על התנהגות: אנליטיקה, הקלטות סשנים, פניות לתמיכה — אם הממשק כבר פעיל.
בתגובה אנחנו שולחים לא מילים כלליות, אלא תוכנית עבודה: מפת מסכים ומצבים, רשימת נקודות מחלוקת, סדר השלבים והערכת עבודה על הממשק עם הנחות מפורשות. אם חלק מהנתונים חסר, זה לא חוסם את ההתחלה — ההנחות מקבעות בתוכנית כדי שלא יהיה צורך להרכיב את המקאטים מחדש אחר כך.
כדי להזמין תכנון ממשק, די לתאר את המשימה בצורה חופשית. לאחר מכן מבררים נקודות מחלוקת וחוזרים עם תוכנית: מה עושים, באיזה סדר וממה תלוי התוצאה.