עיצוב עמוד החיפוש: היכן התוצאות מאבדות את המשתמש
משתמש שלא מצא את מבוקשו דרך החיפוש חוזר לעיתים נדירות לקטלוג — הוא עובר לתוצאות חיפוש חיצוניות. עיצוב עמוד החיפוש אינו קובע את «יופי הטופס», אלא את מספר הצעדים מהשאילתה ועד לתוצאה: שדה הקלט, ההשלמות האוטומטיות, המסננים והמיון צריכים להתכנס לתוצאה אחת צפויה.
כשלים אופייניים חוזרים מפרויקט לפרויקט. חוסר רלוונטיות של התוצאות — כאשר החיפוש הפנימי באתר פועל לפי התאמת מחרוזת מדויקת ומתעלם משגיאות כתיב, ממילים נרדפות ומצורות נטייה: המשתמש מקבל עשרות כרטיסים, שאף אחד מהם אינו עונה על השאילתה. תוצאה ריקה ללא חלופות — מבוי סתום: אין פריטים דומים, אין מדורים פופולריים ואין איפוס תנאים.
צעדים מיותרים עד ליעד — עמוד תוצאות נפרד שאינו שומר את התנאים בכתובת: לא ניתן לשלוח את הקישור הלאה, וחזרה אחורה מאפסת את הבחירה. מסננים שאינם תואמים את התוצאות ומציעים ערכים שאינם קיימים במערך הנוכחי מאלצים את המשתמש לסנן מחדש — זהו סיבוב שני של תסכול במקום חידוד השאילתה.
המחיר לעסק — עזיבת המשתמש את עמוד התוצאות. הוא אינו מגיע לכרטיס, ולכן אינו משאיר פנייה. במדידות בקטלוגים ניכר: ככל שהתוצאות רחוקות יותר מהשאילתה, כך גבוה יותר שיעור החזרות לחיפוש החיצוני ונמוכים יותר המעברים לפעולה הרצויה.
אנו מפרטים כיצד סוגרים זאת: עיבוד שאילתות ומילים נרדפות, תוצאה ריקה בעלת משמעות, מסננים המסונכרנים עם מערך התוצאות, ומצב עמוד הניתן לכתובת.
האפקט של תוצאות מחודשות: מה משתנה עבור המשתמש
את העבודה מחדש על התוצאות מעריכים לא לפי המראה, אלא לפי ההתנהגות: עולה שיעור הפעלות החיפוש המוצלחות — אלו שבהן המשתמש הגיע לאובייקט הרצוי ולא חזר עם שאילתה חדשה.
את קו הבסיס אנו לוקחים מיומני ליבת החיפוש והממשק לפני השינויים: חידודים חוזרים לסשן, הזמן עד לתוצאה הרצויה, שיעור המעברים מתוך התוצאות, ושיעור התוצאות הריקות.
ההשלכה הראשונה — פחות חידודי שאילתה חוזרים. כאשר ליבת החיפוש מפרשת מילים נרדפות, צורות נטייה ושגיאות כתיב, והמסננים והמיון מתאפסים באופן צפוי, חלק מהחידודים עובר לממשק ומפסיק להיות שאילתה נפרדת. במדידות הדבר ניכר כירידה במספר השאילתות לסשן אחד.
השנייה — נתיב קצר יותר לאובייקט הרצוי. אם הכרטיס מציג מיד את המאפיינים המרכזיים ומוביל לעמוד הנכון, הסשן מתקצר ממספר איטרציות לאחת-שתיים: הפער בין השאילתה הראשונה למעבר האחרון מצטמצם. הוא בדיוק זה שקובע את הזמן עד לתוצאה הרצויה.
השלישית — שיעור מעברים גבוה יותר מתוך התוצאות. תקציר מובן ומיון הוגן מעלים את שיעור ההקלקות על המיקומים העליונים, ולכן יותר סשנים נסגרים בתוצאה, ולא בעזיבה לקטלוג באופן ידני או לחיפוש חיצוני.
הרביעית — שיעור נמוך יותר של תוצאות ריקות. עיבוד שגיאות כתיב, תעתיק והתאמות חלקיות, יחד עם חלופות בעלות משמעות במסך «לא נמצא דבר», מסירים את סוג הכשל העיקרי שממנו המשתמש כבר אינו חוזר. את כל ארבעת המדדים אנו לוקחים על אותו זרם שאילתות לפני ואחרי — אחרת ההשוואה אינה תקינה.
גישות לתכנון התוצאות: השוואת אפשרויות
את היקף העבודה קובע לא גודל הקטלוג, אלא הפער בין התוצאות הנוכחיות לשאילתות האמיתיות. שיעור הולך וגדל של סשנים ללא הקלקה על תוצאות, ושאילתות שנגמרות בתוצאה ריקה, מצביעים על תרחיש ולא על הפריסה; תלונות על שגיאות כתיב וניסוחים מעורפלים — על איכות ההשלמות והמילים הנרדפות.
| אפשרות | מתי מתאימה | מגבלות האפשרות |
|---|---|---|
| תיקון התוצאות הקיימות | ההיגיון של החיפוש מתאים, אך מפריעים ליקויים נקודתיים: איפוס מסננים, מיון, אובדן השאילתה בעת עימוד | התרחיש אינו משתנה: אם המשתמש מחפש אחרת, התיקון רק מסווה את הבעיה |
| תבנית תוצאות מוכנה | נדרשת השקה מהירה על קטלוג טיפוסי, והדרישות שלכם טרם התגבשו | התבנית קובעת סט קבוע של מסננים ומבנה כרטיס; התאמה לפי תאימות וחיפוש במסמכים אינם נכנסים בה |
| גרסת חיפוש לנייד | עיקר הסשנים מהסמארטפונים, והמסננים והמיון שם אינם עובדים | פותרת את הפריסה, אך לא את הדירוג; ללא מקור נתונים משותף התוצאות נבדלות מהדסקטופ |
| עבודה מחדש על תרחיש החיפוש | השאילתות אינן תואמות את מודל הנתונים: מחפשים לפי משימה, והמערכת — לפי שם | נדרשים בנייה מחדש של האינדקס, מילוני מילים נרדפות וניתוח שאילתות; לוחות הזמנים תלויים במוכנות הנתונים |
האפשרויות אינן סותרות זו את זו: את ענף הנייד ותיקון הליקויים מובילים במקביל, ואת העבודה מחדש על התרחיש — בשלב הבא, כאשר סטטיסטיקת השאילתות מאשרת את ההשערה. את ההסתעפות סוגרים לאחר ניתוח יומני החיפוש: מה מקלידים, היכן נוטשים, מה מוצאים.
סדר העבודה על תוצאות החיפוש: מהשאילתות ועד למוקאפים
חיפוש אינו שדה קלט עם כפתור, אלא סט ענפי התנהגות, וכמעט כל הכשלים במוקאפים קורים במקום שבו עיצבו לפי ניחושים: ההשלמות אינן תואמות את הניסוחים האמיתיים, ובתוצאה ריקה האדם נתקל במבוי סתום. לכן סדר העבודה בנוי כך שהמוקאפ נבדק מול נתונים עוד לפני הפריסה.
- איסוף שאילתות חיפוש. אנו מוציאים את הניסוחים האמיתיים: זנבות ארוכים, שגיאות כתיב, שפות מעורבות, תוצאות אפס. אנו מקבלים התפלגות תדירויות ומבינים אילו ענפים בכלל כדאי לתכנן.
- מפת תרחישי חיפוש. אנו מסמנים את הענפים: התאמה מדויקת, שאילתה מורחבת, חיפוש לפי מסננים, תוצאה ריקה, שגיאת קלט. עבור כל אחד אנו מתעדים מה רואה האדם ולאן מוביל הצעד הבא.
- תרשים התוצאות. אנו פורשים את התוצאה לשכבות: השלמות, מסננים, בלוק חידוד, כרטיסים, מעבר בין עמודים. בנפרד אנו מתארים את ההתנהגות בעת תוצאה ריקה ובעת נתונים חסרים בכרטיס.
- אב-טיפוס של התוצאות. אנו בונים מוקאפ לחיץ על נתונים שקרובים במבנהם לנתוני הייצור: שמות ארוכים, קטגוריות מקוננות, תמונות חסרות. אנו בודקים שהרשת אינה קורסת בערכים קיצוניים.
- בדיקה על נתונים אמיתיים. אנו מריצים מדגם של שאילתות ומחפשים היכן התרחישים נקרעים: ההשלמות אינן פועלות, החידודים אינם מצמצמים את התוצאות, הנתיב עד לתוצאה ארוך משלוש פעולות. את התיקונים אנו מבצעים לפני המסירה לפיתוח.
- מסירת המוקאפים. אנו מוסרים ספריית קומפוננטות עם מצבים, כללי אדפטיביות, טקסטי מציין מקום והתנהגות בעת טעינה. בהמשך אנו מלווים: מתקנים לפי ההתנהגות בפועל של אנשים, ולא לפי הערות טעם.
הרכב הפרויקט: מוקאפים, מצבים וכללי התוצאות
מוקאפי התוצאות אינם תמונה אחת של «איך נראית התוצאה», אלא סט מצבים שבהם עמוד החיפוש באמת נקלע. אנו מתעדים אותם לפני תחילת הפיתוח, כדי שהמהנדסים לא ימציאו התנהגות בעת תוצאה ריקה או תשובה קטועה של שירות החיפוש. הלקוח מקבל לידיו:
- מוקאפים של כל מצבי התוצאות: תוצאה מלאה, חלקית (חלק מהתנאים לא הניבו התאמות), ריקה, מצב טעינה, תקלה בשירות החיפוש ותוצאות ללא גישה לחלק מהקטלוג.
- כללי מיון: מה מוצג ראשון כאשר הרלוונטיות שווה, האם הסדר הנבחר משפיע על סדר הבלוקים והאם המיון נשמר בקישור בעת רענון העמוד.
- כללי מסננים: אילו תנאים משתלבים, מה קורה כאשר החיתוך ריק, כיצד פועל האיפוס ומוצג מונה התוצאות שנמצאו עבור כל תנאי.
- התנהגות בעת תוצאה חלקית: הצעה להסיר תנאי מיותר, בלוק פריטים דומים וניסוחים — מה שמחזיק את המבקר במקום עזיבה של עמוד ריק.
- מבנה הכרטיס בתוצאות: שדות חובה, התנהגות של כותרת ארוכה, תמונה חסרה ומאפיינים לא מלאים.
- תיעוד התוצאות: טבלת פרמטרים של שורת הכתובת, כך שכל מצב משוחזר באמצעות קישור, ותיאור שדות התשובה של שירות החיפוש לפיתוח.
- כללים לתמיכה: אילו תיקונים במסננים ובמיון בטוחים, מה מחייב בנייה מחדש של אינדקס החיפוש, ורשימת בדיקה לתוצאות לפני שחרור.
מקרה בוחן: כיצד תוצאות של חנות מקוונת חדלו לאבד שאילתות
הלקוח — חנות מקוונת עם קטלוג של עשרות אלפי פריטים. החיפוש החזיר תוצאות «כמו שהן»: מצא התאמות לפי שם מדויק, אך לא הבין שגיאות כתיב, מילים נרדפות או פריסת מקלדת אחרת. הפניות לתמיכה גדלו מהר יותר מההזמנות, והבעלים תלה זאת בתנועה חלשה.
מה הראתה המדידה לפני
התחלנו לא מהמוקאפ, אלא מהמדדים. שיעור התוצאות הריקות — 23% מהשאילתות: אדם הקליד «אוזניות אלחוטיות» וקיבל מסך ריק ללא אף השלמה. מהמסך הראשון עזבו 41% מהמבקרים, עומק הצפייה הממוצע בתוצאות — 1.4 כרטיסים, כלומר רובם אפילו לא גללו את הרשימה.
מה שינינו
את לוגיקת התוצאות כתבנו מחדש על Elasticsearch: פירוש שגיאות כתיב, מילון מילים נרדפות, קישור בין קבוצות מוצרים ומשקל מאפיינים במקום התאמה נקייה לפי מחרוזת.
את עיצוב עמוד החיפוש בנינו סביב התוצאה — מסננים רק לפי מאפיינים רלוונטיים לקטגוריה, תוצאות חיות מתחת לשורה, ובלוק חידוד נפרד במקום מסך ריק.
מה קרה לאחר ההשקה
שיעור התוצאות הריקות — 6%, ובמקביל המסך הריק מציע כעת תמיד חידוד או קבוצת מוצרים דומה. העזיבות מהמסך הראשון — 22%, עומק הצפייה בתוצאות — 3.1 כרטיסים, ומספר שאילתות החידוד הוכפל.
המעברים מהחיפוש לכרטיס המוצר גדלו פי 1.8 באותה תנועה — מקרה הבוחן של החיפוש נסגר לא בעיצוב מחדש, אלא בניתוח היכן בדיוק התוצאות איבדו את השאילתה.
מה לעשות אם התוצאות כבר עובדות, אך אין בהן שימוש
האות הראשון — פער בין הביקוש לבין השימוש בפועל. אנו בוחנים את שיעור הסשנים שבהם בכלל פתחו את החיפוש, את שיעור השאילתות עם תוצאה אפס ואת שיעור הניסוחים מחדש בתוך סשן אחד.
אם אנשים נכנסים לחיפוש ועוזבים לתפריט או גוללים את הקטלוג ידנית — הבעיה אינה בתנועה, אלא בכך שהתוצאות אינן מאשרות את הכוונה.
הביקורת מתחילה ביומני השאילתות, ולא במוקאפ. אנו מוציאים את הניסוחים המובילים, ביטויים ארוכים, שגיאות כתיב ושאילתות שבהן אפס תוצאות או אחת. אנו משווים מה האדם כתב למה שקיבל ולאן המשיך: הקלקה על המיקום הראשון, נטישה, הקלדה חוזרת במילים אחרות. הקלדה חוזרת — האינדיקטור הכנה ביותר: המשתמש סבור שהמערכת לא הבינה אותו.
שיפורים מהירים סוגרים את רוב האבדות. אנו מוסיפים מילים נרדפות ותיקון שגיאות כתיב, מעלים את משקל השדות שלפיהם באמת מחפשים — מק"ט, שם, מאפיין — ומכווננים את ההתנהגות של שאילתה ריקה ואת ההשלמות לפי התווים הראשונים.
בנפרד אנו מתקנים את המצב הריק: במקום «לא נמצא דבר» אנו מציגים קטגוריות קרובות והסרה של תנאים מיותרים.
בנייה מחדש של התרחיש נדרשת במקום שבו השאילתה אינה תואמת את המשימה. האדם מחפש לפי מאפיין שאינו קיים בשדות המאונדקסים, או שהוא זקוק להתאמה לפי פרמטרים ולא להקלדת מחרוזת.
אז משתנים מודל הנתונים ולוגיקת התוצאות: החיפוש מפסיק להיות שדה נפרד והופך לחלק מהסינון, והתוצאה נאספת ממספר מקורות.
סדר העבודה הוא אפוא כזה: תחילה ביקורת של התוצאות הקיימות והתנהגות המשתמשים בחיפוש, אחר כך שיפורים מהירים, ורק לאחר מכן בנייה מחדש של התרחיש עבור אותם ענפים שבהם התיקונים אינם מספיקים. תארו את המשימה — נחזור עם הערכה ותוכנית לחיפוש שלכם.
הבהרות בנוגע להיקף, ללוחות זמנים ולתיקוני התוצאות
חמש שאלות שלקוחות שואלים כמעט תמיד: היקף תיקוני המוקאפים, לוחות הזמנים של התכנון, הגרסה לנייד, בדיקת התוצאה והמסירה. להלן תשובות קצרות, כדי להסיר אי-ודאות לפני הערכת העבודה.
כמה תיקוני מוקאפים נכללים בעבודה?
שני סבבי תיקונים בשלב התכנון נכללים מיד — הם נוגעים למבנה התוצאות, למסננים ולכרטיסים. בהמשך השינויים מתנהלים לפי יומן: רואים מה השתנה ולשם מה, ולכן ההיקף אינו מתנפח באופן בלתי מורגש.
כיצד נראים לוחות הזמנים של תכנון עמוד החיפוש?
לוחות הזמנים מחולקים לפי שלבים: תרשים התוצאות, מצבי הכרטיסים, רשתות אדפטיביות, מסירה לפריסה. כל שלב נסגר באישור, ולכן עיכוב נראה מראש ולא בסוף.
מה משתנה בגרסה לנייד?
המסננים עוברים לפאנל נפרד, והתוצאות — לכרטיסים קומפקטיים עם שדות מרכזיים. בנפרד אנו מעבדים את המצבים: תוצאה ריקה, טעינה, שגיאת שאילתה — בטלפון הם מתרחשים בתדירות גבוהה יותר.
כיצד ניתן לוודא שהממשק עובד לפני ההשקה?
אנו עורכים בדיקות עם משתמשים: 5–8 אנשים עוברים את התרחיש «מצאתי ופתחתי את המבוקש». אנו בוחנים את הזמן עד לתוצאה הראשונה ואת שיעור התרחישים שהושלמו, ומתקנים מקומות שנויים במחלוקת לפני הפריסה.
האם ניתן להחליף מאוחר יותר את מנגנון החיפוש?
כן. שכבת התצוגה מופרדת ממקור הנתונים: המבנה והסגנונות אינם תלויים במנגנון שמחזיר את התוצאות. ההחלפה אינה מחייבת ציור מחדש של התוצאות.
מה מקבלים במסירה ומה עם הליווי?
נגישות הממשק הוצאה לרשימת בדיקה נפרדת לפי WCAG, ולצידה תיעוד הקומפוננטות וכללי התיקונים. בהמשך — ליווי: עדכון מצבי התוצאות וניתוח פניות ככל שהקטלוג גדל.
נדון במשימה: נחזור עם הערכה ותוכנית
הערכה מדויקת של היקף העבודה בעיצוב עמוד החיפוש מתקבלת לא «בעין», אלא מנתוני הקלט: ככל שהדוגמאות קונקרטיות יותר, כך פחות הנחות בתוכנית הפרויקט ולוחות הזמנים צפויים יותר. להלן מה שמספיק לשלוח כדי שנחזור עם הרכב הצוות והשלבים, ולא עם ניסוחים כלליים.
- התוצאות הנוכחיות: כיצד עמוד החיפוש נראה כעת — עם מסננים, מיון, השלמות, מצבי טעינה ותוצאה ריקה. צילומי מסך או קישור לסביבת העבודה.
- דוגמאות לשאילתות: 20-30 ניסוחים אמיתיים, כולל ארוכים, עם שגיאות כתיב ובאותיות לטיניות — הם קובעים את לוגיקת ההשלמות ואת מבנה בלוקי התוצאה.
- אנליטיקה או ייצוא נתונים: שיעור השאילתות ללא תוצאות, שיעור החידודים לאחר התוצאות הראשונות, התפלגות לפי מסננים. זה יראה אילו תרחישים לתקן ראשונים.
- מגבלות של לוחות זמנים ותאימות: תאריכים קשיחים, דפדפנים ומכשירים נתמכים, דרישות נגישות, ומה אסור לשנות בעיצוב הנוכחי ובמבנה הכתובות.
- חומרים קיימים: לוגו, פלטה, גופנים, ספריית קומפוננטות, אם קיימת. אחרת נקצה בתוכנית הפרויקט שלב נפרד לתיאורה.
- הרכב מקבלי ההחלטות: מי מאשר את המוקאפים ומי אחראי על הקבלה. הדבר משפיע לא על העלות, אלא על מספר האיטרציות ועל המהירות שבה השלבים נסגרים.
בתגובה אנו שולחים תוכנית פרויקט לפי שלבים עם נקודות קבלה, הרכב צוות להיקף העבודה המסוים, ורשימת התרחישים שייכנסו למחזור הראשון. תארו את המשימה — נחזור עם הערכה ותוכנית.
