עיצוב אתרים בעידן ה-AI
שלום לכולם. אני שיר, [תפקיד], ואיתי מיכאל, [תפקיד]. אנחנו חלק מצוות [שם הצוות], שאחראי על [עיצוב ובניית אתרים ודפי נחיתה]. בצוות [X] אנשים: [חלוקת תפקידים במשפט אחד].
בשנה האחרונה AI נכנס כמעט לכל שלב בעבודה שלנו, והיום נספר לכם איך זה נראה בפועל. ההרצאה מחולקת לשניים: בחלק הראשון אני אספר מה השתנה בתהליך, איפה AI עוזר ואיפה לא. בחלק השני מיכאל יראה פרויקטים אמיתיים — כולל הרגעים שבהם זה לא עבד. בסוף נשאיר כמה דקות לשאלות.
מבריף לפרוטוטייפ
בואו נתחיל מהשורה התחתונה. עד לפני [שנה], הדרך מבריף של לקוח עד פרוטוטייפ שאפשר להראות לו נמשכה בממוצע [X שבועות]. קודם אפיון, אחר כך wireframes, אחר כך עיצוב עמוד עמוד בפיגמה, ורק בסוף פרוטוטייפ. כל שלב חיכה לקודם.
היום אותו מסלול לוקח [Y ימים]. שימו לב שהשלבים לא נעלמו — עדיין יש בריף, עדיין מגדירים מה בונים, ועדיין בודקים את התוצאה. מה שהתכווץ הוא האמצע: הייצור עצמו. במקום לצייר כל מסך בנפרד, אנחנו מגדירים הנחיות ו-AI מייצר גרסה ראשונה תוך שעות.
וחשוב להבין: מה שמתקבל בסוף הוא לא תמונה של אתר, אלא אתר עובד ב-HTML. הלקוח לוחץ, גולל, פותח בנייד. זה משנה את שיחת המשוב לגמרי.
אבל המספר הזה לא מספר את כל הסיפור. הזמן לא נעלם — הוא עבר למקום אחר. וזה השקף הבא.
פחות לבנות, יותר להגדיר ולבדוק
ככה נראה היום עבודה של מעצב אצלנו. פעם רוב הזמן הלך על ייצור — לצייר מסכים, לשכפל קומפוננטות, להכין גרסאות למובייל. היום את רוב הייצור עושה AI.
הזמן שהתפנה עבר לשני מקומות. הראשון — הגדרה: מה בדיוק אנחנו רוצים, מה המבנה, איך מסבירים את זה ל-AI כך שיבין. השני — ביקורת ובקרת איכות: לעבור על מה שיצא, לתפוס טעויות, לבדוק נגישות וחוויית משתמש.
במילים אחרות: המעצב עבר מתפקיד של מבצע לתפקיד של מנהל קריאייטיב ועורך. זה דורש שיקול דעת יותר טוב, לא פחות.
איפה AI נכנס — ואיפה לא
חשוב לי להבהיר מה AI לא עושה אצלנו. ברוב המקרים ה-UX נשאר בידי המעצב: מבנה האתר, הזרימה של המשתמש, מה חשוב ומה משני. אלה החלטות שדורשות הבנה של הלקוח ושל הקהל שלו.
איפה AI כן נכנס? בשלב ה-UI ובמה שאנחנו קוראים לו «עבודה שחורה»: לבנות עוד עשרה דפים פנימיים באותו סגנון, להתאים למובייל, להכין כמה וריאציות של באנר. זו עבודה שלוקחת הרבה זמן ומעט מחשבה — בדיוק מה ש-AI עושה טוב.
כלל אצבע: מה שדורש שיקול דעת — אצלנו. מה שדורש סבלנות — אצל ה-AI.
אתר פשוט מול אתר מורכב
בפועל אין לנו תהליך אחד. יש שניים, והבחירה ביניהם תלויה במורכבות של הפרויקט.
באתר פשוט — דף נחיתה, אתר תדמית קטן, אירוע — AI נכנס מהרגע הראשון. אנחנו כותבים הנחיות מסודרות על בסיס הבריף, והוא בונה גם את המבנה וגם את העיצוב ישירות. התפקיד שלנו כאן הוא להגדיר טוב בהתחלה ולבדוק טוב בסוף.
באתר מורכב זה שונה. קודם המעצב בונה wireframes בפיגמה — זה השלב שבו נקבעים ה-UX, המבנה וההיררכיה. רק אחרי שהעמודים המרכזיים מוכנים, הם עוברים ל-AI. הוא ממשיך את הדפים הפנימיים ומתאים אותם לשפה העיצובית הקיימת של המותג. כלומר, במקרה הזה AI לא ממציא — הוא משכפל ומרחיב משהו שאנחנו כבר החלטנו עליו.
בשני המקרים הסוף זהה: בקרה של מעצב, ו-HTML שעובר לפיתוח.
מיכאל יראה בהמשך דוגמה לכל אחד מהתהליכים: פרויקט נסיעה לפולין הוא המסלול הפשוט, ומרכז נופש הוא המסלול המורכב.
משימה אחת בכל פעם
כמה דברים שלמדנו בדרך הקשה. הראשון: לא מבקשים מ-AI הכול בבת אחת. אם מבקשים ממנו לבנות מבנה וגם לעצב באותה משימה, הוא מתעייף והתוצאה יוצאת בינונית בשניהם. לכן קודם wireframe, מאשרים, ורק אז עיצוב. זה חוסך טוקנים ומשפר את האיכות.
השני: תוכן. AI שבונה את האתר לא ימציא לבד תמונות, וידאו או אייקונים שמתאימים למותג. את זה אנחנו עדיין מביאים ממאגרים, מהלקוח, או מייצרים בכלים נפרדים — ותמיד מעצב בוחר מה נכנס. מיכאל יראה בהמשך איך זה נראה עם וידאו.
מה באמת מרוויחים
מה באמת מרוויחים? קודם כל, דברים שפעם היו שלב נפרד נכנסים עכשיו מההתחלה: מיקרו-אנימציות, נגישות, SEO, התאמה למובייל. גם אופטימיזציה של תמונות ווידאו קורית אוטומטית, בלי שמישהו יזכור לבקש.
שנית, לפיתוח עובר HTML אמיתי, לא קובץ פיגמה עם מסמך אפיון של עשרים עמודים. המפתח רואה בדיוק איך זה צריך לעבוד, ופחות דברים הולכים לאיבוד בדרך.
ושלישית, העבודה עם הלקוח: תיקון שפעם לקח יום לוקח היום שעה. כל התהליך מתקצר.
מה צריך לזכור
ועכשיו הצד השני. AI מייצר פתרונות סטנדרטיים. הם נראים טוב במבט ראשון, וזה בדיוק המלכודת: מתחת לעיצוב נקי יכולות להסתתר טעויות UX ובעיות נגישות. מי שלא בודק, מעביר אותן ללקוח.
דבר שני — כל היתרון בזמן תלוי בלקוח. אנחנו יכולים להוציא גרסה ביום, אבל אם הלקוח מגיב אחרי שבוע, הפרויקט לא מתקצר.
והדבר הכי חשוב: AI לא מחליף שיקול דעת עיצובי וויז׳ן. הוא כלי חזק, אבל מישהו צריך להחליט לאן הולכים.
וכדי לראות איך כל זה נראה בפרויקטים אמיתיים — מיכאל.
שני פרויקטים, שני תרחישים
תודה, שיר. אני אראה שני פרויקטים אמיתיים, אחד לכל תהליך ששיר הציגה. הראשון — אתר קטן שהיה צריך לצאת בדחיפות. השני — אתר מורכב, שבו עברנו את כל השלבים.
נסיעה לפולין
פרויקט ראשון: נסיעה לפולין. המשימה הייתה [מה האתר עושה]. פרויקט קטן, בלי שום דבר מסובך במבנה — אבל עם בעיה אחת גדולה: זמן.
הבריף הגיע ב-[תאריך], והאתר היה צריך להיות באוויר תוך [X ימים]. בתהליך הרגיל שלנו, בלי AI, זה פשוט לא היה קורה — רק האפיון והעיצוב היו לוקחים יותר מזה. אז הלכנו על המסלול הפשוט ששיר תיארה: AI נכנס מהיום הראשון.
גרסה ראשונה תוך זמן קצר
לא פתחנו פיגמה בכלל. כתבנו הנחיות מסודרות על בסיס הבריף: מי הקהל, אילו סקשנים צריך, מה הטון, אילו צבעים. ו-AI בנה מזה גם את המבנה וגם את העיצוב.
תוך [X שעות] היה לנו אתר עובד — לא תמונה, אתר. עם אנימציות, מותאם למובייל, עם תמונות מוקטנות. שלחנו ללקוח קישור, והוא פתח אותו בנייד.
מה שאני רוצה שתשימו לב אליו: הגרסה הראשונה הייתה טובה, אבל סטנדרטית — בדיוק מה ששיר דיברה עליו. שם נכנסנו אנחנו.
סבבי תיקונים: טקסטים וסקשנים
ואז התחילו התיקונים. הרבה תיקונים. רובם היו טקסטואליים: נוסח אחר, פרטים שהשתנו, משפט שצריך להוסיף. חלק נגעו במבנה — [דוגמה: סקשן שעבר מקום, סקשן שנוסף].
פעם, כל סבב כזה היה עובר מעצב, ואחר כך מפתח, ולוקח יום עד שהלקוח רואה את השינוי. כאן עברנו [X] סבבים ב-[Y] ימים, ותיקון טיפוסי לקח [X דקות]. הלקוח שלח הערות — וקיבל אתר מעודכן כמעט מיד.
זה בדיוק היתרון ששיר דיברה עליו. וגם החיסרון: הקצב של הפרויקט נקבע בעיקר לפי כמה מהר הלקוח ענה.
הבאנר המקורי
והשינוי המעניין ביותר — הבאנר. מה ש-AI הציע היה תקין, אבל גנרי. אז הוספנו באנר מקורי — [מה הוא מראה, מאיפה הגיע].
זה הרגע שבו האתר הפסיק להיראות «עוד אתר של AI» והתחיל להיראות כמו הפרויקט של הלקוח. המהירות הגיעה מ-AI. האופי — מהמעצב.
מרכז נופש
פרויקט שני: מרכז נופש. כאן התמונה הפוכה מפולין. אתר גדול — [X] עמודים, [מאפיינים עיקריים]. קהל מגוון, הרבה תוכן, ודרישה לשפה עיצובית מדויקת. בפרויקט כזה אי אפשר לתת ל-AI להתחיל מאפס — אז הלכנו על המסלול המורכב, שלב אחרי שלב.
Wireframes
התחלנו כמו פעם: wireframes בפיגמה. כאן נקבע מה המשתמש רואה ראשון, איך הוא מגיע להזמנה, איך העמודים מתחברים.
זה השלב שבו שיקול הדעת של המעצב הכי קריטי, ולכן הוא נשאר אצלנו. וזה גם הכלל ששיר הזכירה: קודם מבנה, רק אחר כך עיצוב.
עיצוב בפיגמה
על בסיס ה-wireframes עיצבנו בפיגמה רק את העמודים המרכזיים — [X] עמודים. לא את כל האתר.
המטרה כאן היא לקבוע את השפה העיצובית: צבעים, טיפוגרפיה, איך נראים כרטיסים וכפתורים. ברגע שהשפה הזו קיימת, AI יכול להמשיך ממנה. בלעדיה — הוא ימציא משהו סטנדרטי משלו.
מפיגמה ל-HTML עם AI
וכאן AI נכנס. העברנו לו את העיצוב מפיגמה, והוא הפך אותו ל-HTML עובד. אבל החלק החשוב באמת הוא מה שקרה אחר כך: הוא בנה עוד [Y] עמודים פנימיים שלא עיצבנו בכלל — באותה שפה עיצובית.
זו בדיוק העבודה השחורה ששיר דיברה עליה. בתהליך הישן מעצב היה משכפל כל עמוד בפיגמה, ומפתח היה בונה כל אחד מחדש. כאן זה לקח [X ימים], ויצא ישר כקוד עם רספונסיביות ואנימציות.
נשמע מושלם? לא בדיוק.
איפה AI נכשל
הנה הנקודה שבה AI נכשל. [תיאור הבעיה: מה בדיוק יצא לא טוב ובאיזה עמוד]. במבט ראשון הכול נראה תקין. רק כשעברנו עמוד עמוד ראינו את זה.
זה בדיוק מה ששיר אמרה: פתרון סטנדרטי שנראה טוב, אבל מסתיר טעות. תיקנו את זה [איך: ידנית / בהנחיה מדויקת יותר ל-AI].
המסקנה שלנו: שלב הבקרה הוא לא תוספת. הוא חלק מהעבודה, וצריך לתכנן לו זמן מראש.
ייצור וידאו עם AI
[להריץ את הווידאו קודם, בלי לדבר.]
הווידאו הזה לא צולם. הוא נוצר ב-AI.
שיר אמרה קודם שתוכן לא נוצר לבד — וזה נכון. ה-AI שבנה את האתר לא ייצר את הווידאו. אבל בכלי ייעודי לייצור וידאו, עם מעצב שמכוון אותו, אפשר להגיע לתוצאה כזו.
התהליך נראה ככה: כתבנו פרומפט שמתאר את הסצנה, האור והתנועה. יצרנו [X] גרסאות. רובן לא היו טובות — [דוגמה לבעיה טיפוסית]. בחרנו את הקטעים הטובים, ערכנו, והכנסנו לאתר בגודל שלא מאט את הטעינה.
למה זה חשוב? עד עכשיו, וידאו כזה דרש צילום או סטוק יקר, ולקוח קטן פשוט ויתר עליו. כאן זה לקח [זמן] ועלה [עלות]. זה משנה את מה שאפשר להציע ללקוח.
ושוב, המשפט שחוזר כל ההרצאה: הכלי מייצר, המעצב בוחר.
מה למדנו
אם צריך לסכם את שני הפרויקטים בארבעה משפטים — זה מה שלמדנו.
אחד: AI עושה את הייצור מהר יותר מכל מה שהכרנו. אבל ההחלטות — מבנה, אופי, מה נכנס ומה לא — נשארות אצלנו. ראיתם את זה בבאנר של פולין ובווידאו של מרכז נופש.
שתיים: מבנה קודם, עיצוב אחר כך. משימות קטנות נותנות תוצאות טובות יותר.
שלוש: הבקרה היא לא בונוס. מתכננים לה זמן מראש, כי שם נתפסות הטעויות שנראות טוב.
וארבע: אנחנו יכולים לעבוד מהר ככל שנרצה — הפרויקט יזוז בקצב של הלקוח. אז כדאי לסכם איתו לוח זמנים לתשובות כבר בהתחלה.
שאלות?
תודה רבה. נשמח לענות על שאלות.
תשובות מוכנות לשאלות צפויות
- «באילו כלים אתם משתמשים?»
- [רשימת הכלים: בניית אתר, עיצוב, וידאו].
- «מה עם אבטחת מידע?»
- חומרי לקוח רגישים לא עולים לכלים; [מדיניות הצוות].
- «AI יחליף מעצבים?»
- הוא מחליף חלק מהעבודה, לא את המעצב. כל הפרויקטים שראיתם היו נכשלים בלי שלב ההגדרה והבקרה.