Mobile First או Desktop First? מתחילים ממשימת המשתמש
מדריך החלטה · ברנדיני
תכנון למובייל אינו רק הקטנת עמוד מחשב. הוא מחייב סדר עדיפויות, אזורי לחיצה נוחים ותוכן שאפשר להבין במסך צר. גם מחשב חשוב, במיוחד במשימות מורכבות. המטרה היא אותה פעולה ברורה בכל מכשיר, עם פריסה שמותאמת אליו.
תכנון מהמובייל
עוזר לחדד מה חשוב כאשר המקום מוגבל. מתחילים במסר, בפעולה ובניווט, ואז מרחיבים את הפריסה למסכים גדולים.
תכנון מהמחשב
יכול לסייע במערכות עם מידע צפוף או עבודה מורכבת. צריך לתכנן במקביל כיצד המשימות והתוכן נשארים זמינים במסך קטן.
ההבדלים שכדאי לבדוק
| מה בודקים | תכנון מהמובייל | תכנון מהמחשב |
|---|---|---|
| סדר תוכן | המידע החיוני מופיע לפני פירוט | אפשר להציג מידע מקביל בלי לאבד היררכיה |
| ניווט | תפריט נגיש ודרך ברורה לחזור | ניווט רחב יותר עם סדר עקבי |
| טפסים | מקלדת מתאימה ושגיאות מובנות | קיבוץ שדות וסדר מעבר במקלדת |
| תוכן | אותו מידע מהותי בפריסה מותאמת | אותו מסר עם ניצול שטח נוסף |
מהשוואה לתוכנית
איך זה נראה בהחלטה אמיתית?
דוגמה לבדיקה: משתמש בוחר שירות, קורא מה כלול ומנסה ליצור קשר. בודקים את הדרך במסך צר ובמסך רחב, כולל פתיחת תפריט, טבלה ופופאפ. אם כפתור צף מסתיר שדה או שכותרת נעלמת מתחת להדר, זו בעיית שימוש שצריך לתקן. Google מציינת שהיא משתמשת בגרסת המובייל של התוכן לאינדוקס ולדירוג.
לפני שמתקדמים
- הגדירו שלוש פעולות מרכזיות באתר.
- בצעו אותן במגע ובמקלדת.
- בדקו תוכן, תמונות וטפסים בכמה רוחבים.
- ודאו שתוכן חיוני אינו נעלם במובייל.
שאלות שעוזרות לבחור
צריך אתר נפרד למובייל?
במקרים רבים אפשר להשתמש באתר רספונסיבי אחד. בוחנים את הצורך ולא יוצרים תחזוקה כפולה ללא סיבה.
מותר לקצר תוכן במובייל?
אפשר לשנות פריסה ולרכז מידע ברכיבים נפתחים. חשוב שהתוכן המהותי יישאר זמין ולא יוסר רק בגלל רוחב המסך.
מקורות רשמיים להמשך בדיקה
החלטה לפי המשימה
התחלת עיצוב במסך צר מכריחה לבחור סדר מידע ופעולה; התחלה במסך רחב יכולה להקל בתכנון מערכת צפופה. שתיהן צריכות להסתיים בחוויה שימושית בכל רוחב שבו הקהל פועל. מתחילים מרשימת הפעולות שהמשתמש צריך להשלים: למצוא שירות, להשוות תנאים ולשלוח בקשה. במסך צר סדר התוכן מוכרח להיות חד; במסך רחב אפשר לראות רכיבים יחד. הבחירה במתודת התחלה היא כלי תכנון בלבד, והמסירה נבחנת בכל רוחב שבו הקהל משתמש, כולל מצב שגיאה ותפריט פתוח.
מה לבדוק בחלופה הראשונה
ב־Mobile First בודקים מה רואים לפני גלילה, האם אפשר להגיע לטופס באצבע והאם תוכן חיוני אינו מוסתר. צמצום מקום אינו היתר להסיר מחיר, תנאים או הסבר חשוב. ב־Mobile First מתכננים מה מוצג לפני גלילה, איפה נמצאת פעולה מרכזית והאם טקסט חיוני נשאר קריא. בודקים הקלדה במקלדת נייד, הודעת שגיאה וכפתור שיכול להסתיר שדה. אם מחיר או תנאי שירות הוסרו כדי לחסוך מקום, התכנון פגע בהחלטת המשתמש במקום לשפר אותה.
מה לבדוק בחלופה השנייה
ב־Desktop First בונים לעיתים סביב טבלה, לוח בקרה או עריכה ממושכת. לפני אישור מתכננים כיצד אותן משימות מתפרקות למסך צר ומה קורה לניווט ולמקלדת. ב־Desktop First אפשר לסדר לוח צפוף או טבלה רחבה לפני פירוקם למסך צר. כבר בשלב הזה מסמנים מה יתקפל, מה יישאר גלוי ואיך עוברים עם מקלדת. אם רכיב גדול דורש גלילה אופקית, מגדירים אותה בתוך הרכיב עם כותרת מובנת, ולא משאירים את כל המסמך רחב מן המסך.
תרחיש להמחשה
לקוח בוחר שירות, משווה תנאים ושולח בקשה. בודקים את המסלול ב־320, 390 ו־1440 פיקסלים, כולל הודעת שגיאה, תפריט פתוח וכפתור צף שעלול להסתיר שדה. בתרחיש בחירת שירות, אדם קורא תנאים, בוחר אפשרות וממלא טופס. בודקים ב־320, 390 ו־1440 פיקסלים עם שגיאה בטופס ותפריט פתוח. מי שבודק מנסה להגיע לאותו מידע בכל רוחב, כדי לזהות רכיב שנעלם או שינוי בסדר הקריאה ולא להסתפק בצילום מסך נקי.
מחיר ופשרות
עיצוב נייד עשוי לדרוש החלטות על קיצור טקסט; עיצוב מחשב עשוי להסתיר בעיית סדר קריאה. בכל מסלול תמונות כבדות ורכיבים חיצוניים יכולים לפגוע בביצועים. עלות עיצוב אינה רק שעות סקיצה. צריך לכלול בניית רכיבים רספונסיביים, תמונות בגדלים מתאימים, בדיקות מקלדת ומגע ותיקון רכיבי צד שלישי. מתודת התחלה שמקצרת ציור אך דורשת טיפול מאוחר במידע שנחתך בנייד אינה חיסכון. קובעים תוצרי קבלה ולא מנחשים עלות לפי רוחב המסך הראשון.
ניסוי לפני בחירה
מגדירים שלוש פעולות מרכזיות ומשרטטים להן רצף תוכן. בונים רכיב מייצג, בודקים מקלדת ומגע ואז מרחיבים למסכים נוספים במקום לאשר צילום סטטי אחד. בוחרים שלוש משימות אמיתיות ומשרטטים רצף תוכן לכל אחת. בונים רכיב מייצג עם כותרת, טבלה או טופס, ומבקשים מאדם שלא עיצב אותו לבצע פעולה במגע ובמקלדת. מתקנים לפני הרחבה לתבניות נוספות. כך ההחלטה מבוססת על שימוש, לא על ויכוח עקרוני איזה מסך ראוי לקבל קובץ עיצוב ראשון.
מדידה לאחר החלטה
מודדים השלמת משימה, שגיאות ושאלות שירות לפי מכשיר. מהירות טעינה ומרחק גלילה מסייעים לאבחון, אך אינם מחליפים מבחן שבו אדם מנסה לבצע פעולה אמיתית. מודד שימושי הוא השלמת משימה, מספר טעויות וזמן למצוא מידע לפי מכשיר. מוסיפים בדיקת רוחב מסמך, משקל תמונות וקריאות הודעות שגיאה כדי לאבחן מקור קושי. מרחק גלילה לבדו אינו כישלון אם אדם מבין את המסלול, ואילו כפתור גלוי שלא עובד הוא כישלון גם כשהעמוד קצר.
שאלה שעוזרת להכריע
האם צריך שני אתרים נפרדים? בדרך כלל מתחילים מפריסה רספונסיבית אחת ובודקים את הצורך. תחזוקה כפולה עלולה להשאיר תוכן שונה או מידע ישן באחד המכשירים. בדרך כלל אין צורך בשני אתרים נפרדים כדי להתחיל ב־Mobile First או ב־Desktop First. פריסה רספונסיבית אחת יכולה לשמור תוכן זהה עם סדר מותאם. אם בכל זאת נדרשות חוויות שונות, מגדירים מי יעדכן מידע בשתיהן ומוודאים שלא יישאר מחיר, תנאי או טופס ישן באחת מהן. מומלץ לשמור גם סדר קריאה עקבי לקורא מסך כאשר רכיבים עוברים ממבנה עמודות למבנה אנכי. בודקים שכותרת, הסבר ושדה טופס נשארים סמוכים במבנה הדף, ולא רק מבחינה חזותית. כך התאמת רוחב אינה משנה בטעות את משמעות התוכן.
בדיקת מסירה לצוות
מבחן שימוש מתחיל בתוכן מלא ולא בשלד. בחרו שירות עם תנאים, תמונה, טופס וטבלה קצרה, ונסו למצוא אותו במסך צר ובמסך רחב. בדקו מה קורה כשהתפריט פתוח, הודעת שגיאה מופיעה או הטקסט מוגדל. אם המידע החיוני נעלם במובייל כדי לשמור על עיצוב נקי, זו אינה התאמה מוצלחת. אם שולחן העבודה עמוס בכרטיסים שאין בהם סדר קריאה, גם פריסה גדולה אינה מסייעת. תעדו את נקודות העצירה במקום להכריע על בסיס צילום מסך.
איך מחליטים מה לעשות עכשיו
תהליך טוב נותן לצוות רשימת בדיקות לכל שינוי תוכן: רוחב 320, רוחב 390 ורוחב גדול; שימוש במקלדת; טעינה של תמונות והשלמת טופס. אין צורך לתחזק שני אתרים כדי להתאים מבנה למכשיר, אך יש לוודא שהשינוי שפורסם נראה בשניהם. מדדו השלמת פעולה ולא רק זמן גלילה. שאלה שונה עשויה לדרוש פריסה שונה, ולכן ההחלטה היא על סדר העבודה של העיצוב ועל בדיקת קבלה, לא על זהות נצחית של אתר כאתר מובייל או מחשב.
בדיקת קבלה נוספת
בעת מסירת עיצוב בקשו גם מצב שגיאה לכל רכיב חיוני: שדה חסר, תפריט פתוח, תמונה שטרם נטענה וטקסט מוגדל. בדקו כל מצב במקלדת ובמגע. אם כרטיסים הופכים לטור ארוך בנייד, שמרו סדר קריאה הגיוני והראו היכן נמצאת הפעולה הראשית. אם טבלה נגללת אופקית, ודאו שרק הטבלה גוללת ולא כל הדף. כך הבחירה בסדר העיצוב נבחנת לפי שימוש בפועל.
| בדיקה | תכנון מהמובייל | תכנון מהמחשב |
|---|---|---|
| יכולת | ב־Mobile First בודקים מה רואים לפני גלילה, האם אפשר להגיע לטופס באצבע והאם תוכן חיוני אינו מוסתר. צמצום מקום אינו היתר להסיר מחיר, תנאים או הסבר חשוב. | ב־Desktop First בונים לעיתים סביב טבלה, לוח בקרה או עריכה ממושכת. לפני אישור מתכננים כיצד אותן משימות מתפרקות למסך צר ומה קורה לניווט ולמקלדת. |
| מבחן מעשי | מגדירים שלוש פעולות מרכזיות ומשרטטים להן רצף תוכן. בונים רכיב מייצג, בודקים מקלדת ומגע ואז מרחיבים למסכים נוספים במקום לאשר צילום סטטי אחד. | |
לבדיקת מידע משתנה: תיעוד רשמי. להעמקה בעבודה עצמה: מדריך קשור באתר.
