כשהשדרוג סיבך פעולה פשוטה: כך החזרתי את שורת החיפוש לייעוד שלה

איך שינוי שנועד לעשות סדר הפך תהליך פשוט למסורבל במיוחד

במסגרת העבודה שלי ב-WeDev Technologies, ה-Partner Dashboard של Shopify הוא כלי עבודה יומיומי. הסוכנות מנהלת מאות חנויות, ועובדים בתפקידים שונים משתמשים בממשק לאורך היום כדי לעבור ביניהן לצורכי פיתוח, QA, תחזוקה, הגדרות וניהול שוטף.

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

לאחרונה, עם השקת ה-Dev Dashboard החדש, Shopify שינתה את מבנה הממשק וחילקה את החנויות לשלוש קטגוריות: Dev, Transfer ו-Collaborations. אלא שגם מנגנון החיפוש חולק בהתאם, כך שכל חיפוש מתבצע רק בתוך הלשונית הפעילה.

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

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

הסדר חשוב, אבל לא על חשבון פיצ'ר אחר

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

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

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

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

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

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

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

איך צריך להיראות תהליך החיפוש?

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

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

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

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

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

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

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

בתוצאות החיפוש בחרתי להשאיר את התגית שמציינת אם החנות היא Dev, Transfer או Collaboration. המידע עצמו עדיין יכול להיות שימושי, כל עוד המשתמש לא נדרש לדעת אותו מראש כדי לבצע חיפוש. מבחינתי, המטרה הייתה להסיר את ההחלטה המיותרת מה-flow, לא את המידע עצמו.

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

גמישות שהוסיפה מורכבות

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

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

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

מבחינה טכנית, כאמור, בניתי את הפתרון כתוסף Chrome שמזריק Content Script לתוך ה-Dashboard ומחליף את שכבת החיפוש הקיימת. בזמן שהמשתמש מקליד, התוסף שולח במקביל שלוש בקשות חיפוש - אחת לכל קטגוריית חנויות. לאחר מכן הוא מפרסר את תגובות ה-HTML, מאחד את התוצאות ומציג אותן ברשימה אחת בתוך הממשק.

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

לפתרון הזה יש גם trade-off ברור. לא מדובר באינטגרציה רשמית של Shopify, והפתרון הזה תלוי במבנה ה-DOM ובהתנהגות הנוכחית של הדשבורד. אם Shopify תשנה באופן משמעותי את הממשק או את הדרך שבה התוצאות נטענות, ייתכן שהתוסף ידרוש התאמות. אבל גם חשוב לציין שמבחינתי זו הייתה החלטה מודעת: לבחור בפתרון פרגמטי שמסיר חיכוך אמיתי כאן ועכשיו, גם במחיר של תלות מסוימת בממשק קיים.

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

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

גם מבחינת זמן, מדובר בפעולה שחוזרת בתדירות גבוהה מאוד. בהערכה של כ-15 כניסות לחנויות לעובד ביום אצל כ-30 משתמשים, מדובר בסדר גודל של כ-450 חיפושים ביום. במקרים שבהם נדרש לעבור בין כמה לשוניות, ה-flow המקורי יכול להתארך לכדקה, בעוד שהחיפוש המאוחד אורך בדרך כלל סביב 10 שניות.

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

חיכוך בודד יכול להצטבר לבעיה גדולה

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

תובנה נוספת הייתה שפתרון יכול להיות נכון מבחינת Information Architecture ועדיין ליצור friction בתוך flow מרכזי. החלוקה של Shopify מסדרת את המידע, אבל היא לא בהכרח צריכה להכתיב את הדרך שבה המשתמש מאתר חנות. החלטה מוצרית טובה צריכה לקחת בחשבון גם את מבנה המערכת וגם את הדרך שבה המשתמש מבצע את המשימה בפועל.

בסופו של דבר, הערך המרכזי בתהליך היה ביכולת לזהות חיכוך בתוך מוצר קיים, להבין מה בהחלטה המוצרית יצר אותו, לצמצם את הבעיה ל-user need ברור ולבחון פתרון אמיתי במהירות. הרקע הטכני שלי איפשר לי בתהליך הזה לחבר בין Product Thinking, UX ו-execution, ולעבור יחסית מהר מזיהוי הבעיה לפתרון שאפשר לבדוק, לשפר ולראות מאומץ בפועל.