Anna Lovsky UX UI

Anna Lovsky UX UI Bringing clarity to complex systems. From idea to production, through UX, product thinking, and AI.

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

אני אנה לובסקי, מומחית UX עם מעל 13 שנות ניסיון בעולמות התוכנה: SaaS, מערכות בריאות, מערכות עם AI, אוטומציה ו־Services. מתמקדת במוצרים דיגיטליים שמנהלים מידע מורכב או מייצרים תהליכים אוטומטיים – בין אם הצגת נתונים לרופאים תחת רגולציה ולחץ, או פלטפורמות למפתחים שמאפשרות בניית תהליכי

ם ללא קוד, עם AI או בלי ובחיבור וורקפלאוז אוטומטיים.

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

לפני שנה כתבתי לעצמי משפט מהפאנל של Design Systems Israel:“If you don’t build the components framework kit, your develop...
26/08/2026

לפני שנה כתבתי לעצמי משפט מהפאנל של Design Systems Israel:

“If you don’t build the components framework kit, your developers will.”

שנה אחרי, המשפט הזה כבר כמעט מרגיש מיושן.

כי היום לא רק המפתחים יבנו.

כולם יכולים לבנות.

PM יכול לפתוח Claude או Cursor, לתת לו Markdown וכמה כללים, ותוך זמן קצר יש לו פיצ’ר.

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

מעצב יכול לעבור מ-Figma לקוד ולבנות בעצמו.

ופתאום אפשר לייצר אזורים שלמים במוצר בקצב שפעם היה בלתי נתפס.

וזה מעולה.

אבל זה גם משנה את הבעיה.

כי כשהיכולת לבנות כבר לא מרוכזת אצל מעט אנשים, השאלה היא כבר לא:

מי רשאי לבנות קומפוננטה?

אלא:

איך שומרים על מוצר קוהרנטי כשכולם יכולים לבנות?

איך ה-Agent יודע שלא צריך להמציא Pattern חדש כי כבר יש אחד שמתאים?

איך הוא יודע איך הפיצ’ר החדש אמור להתנהג ביחס לשאר המוצר?

איך שומרים לא רק על אותם צבעים, Spacing ו-Buttons, אלא גם על אותם Patterns, התנהגויות וחוקים?

ואיך מונעים מצב שבו כל פיצ’ר בפני עצמו נראה מצוין, אבל המוצר כולו מתחיל לאט לאט להתפרק?

ופה בעיניי Design System נהיה אפילו יותר חשוב בעידן ה-AI.

רק שספריית Figma כבר לא מספיקה.

אנחנו צריכים מערכת שגם בני אדם וגם Agents יכולים לעבוד איתה.

וזה כבר הרבה יותר מ-Component Library.

נתקלתם באתגר הזה? דברו איתי אשמח לעזור

תחושת ביטחון ושליטה = חוויית משתמש טובה.מצחיק לכתוב את זה עכשיו.אחרי השביעי באוקטובר, המשפט הזה טעון מתמיד.אבל אל דאגה, ...
25/08/2026

תחושת ביטחון ושליטה = חוויית משתמש טובה.

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

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

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

אז אם אתם משחקים עם הבינה ובונים SaaS לבד

יוז יור פאוור וויזלי! 😉

Design System אף פעם לא באמת “גמור”.וטוב שכך.המוצר משתנה.הטכנולוגיה משתנה.הצוות משתנה.הלקוחות משתנים.Design System בוגר ...
24/08/2026

Design System אף פעם לא באמת “גמור”.

וטוב שכך.

המוצר משתנה.
הטכנולוגיה משתנה.
הצוות משתנה.
הלקוחות משתנים.

Design System בוגר צריך לדעת להשתנות יחד איתם, בלי שכל שינוי יהפוך לבלגן.

בפאנל של Design Systems Israel לפני כשנה דיברו על כמה פרקטיקות שעוזרות לזה לקרות:

לעשות Versioning לשינויים, אפילו בתוך Figma.

לתעד לא רק מה השתנה, אלא למה.

לאפשר וריאציות מקומיות כשיש ניסוי או צורך ספציפי לשוק מסוים.

לתכנן שינויי Layout גדולים יחד עם Releases של המוצר.

ולתעד גם את מה שכבר יצא מהמערכת.

שנה עברה, והעקרונות האלה עדיין נכונים.

רק שהיום הייתי מוסיפה להם עוד שכבה.

כי ה-Design System כבר לא חי רק ב-Figma ובקוד.

כשאנחנו בונים עם LLMs ו-Agents, חלק מהמערכת עובר גם לתיקיות, Markdown, Skills והוראות שה-AI יכול לעבוד איתן.

ופתאום Versioning ותיעוד של “למה החלטנו ככה” הופכים אפילו יותר חשובים.

כי Documentation טוב הוא לא רק קטלוג של “מה קיים עכשיו”.

הוא גם הזיכרון של המערכת.

מה היה כאן קודם?
למה שינינו?
מה Deprecated?
מה החליף אותו?

וזה נכון גם לבני אדם וגם ל-AI שעובד איתנו.

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

אז אם הייתי מעדכנת היום את הפרקטיקות מהפאנל:

כדי לתחזק Design System ב-2026, הייתי דואגת גם לגרסאות מסודרות של הקבצים וה-Markdown שה-LLM עובד איתם, ומתעדת לא רק מה השתנה, אלא למה.

Design System חי לא אומר שכל הזמן מוסיפים אליו דברים.

לפעמים בגרות היא דווקא לדעת מה לשנות, מה להשאיר ומה להוציא.

מעניין אותי איך זה עובד אצלכם היום.

ה-Design System עדיין חי בעיקר ב-Figma ובקוד, או שכבר בניתם לו גם שכבה שה-AI יכול לעבוד איתה?

לפעמים כל ההבדל בין “זה עובד” לבין “אפשר לסמוך על זה” הוא שתי מילים.לאחרונה עשיתי ל־Wizard שנבנה בעזרת AI.נעשתה עבודה ...
23/08/2026

לפעמים כל ההבדל בין “זה עובד” לבין “אפשר לסמוך על זה” הוא שתי מילים.

לאחרונה עשיתי ל־Wizard שנבנה בעזרת AI.

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

רק שזה לא היה Wizard סטנדרטי.

ב Wizard הזה לפני שנכנסים לשלבים עצמם, המשתמש בוחר איזה סוג Wizard הוא רוצה להפעיל.

במצב כזה, Back כבר לא בהכרח מרגיש חד־משמעי.

הוא עלול לגרום למשתמש לעצור רגע ולחשוב:

הBack הזה מחזיר אותי לשלב הקודם?
או לבחירת סוג ה־Wizard?

הפתרון היה פשוט.

שינוי קטן במיקרוקופי. שתי מילים שאומרות במפורש מה יקרה אחרי הלחיצה.

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

לא כאלה שישברו את המוצר.

כאלה שישחקו לאט את אמון המשתמשים
מסכימים? איך זה פוגש אתכם השבוע?

ועוד שאלה לאלו שעם שתי הידיים על זה
כש־AI מייצר לכם Flow שנראה טוב במבט ראשון, מה הדבר הראשון שאתם בודקים בעין אנושית?



הבעיה הכי גדולה במוצרים לפעמים היא לא ה־complexity,�אלא תחושת חוסר האונים שהם יוצרים אצל משתמשים.לא מזמן נתקלתי בשירות ש...
20/08/2026

הבעיה הכי גדולה במוצרים לפעמים היא לא ה־complexity,�אלא תחושת חוסר האונים שהם יוצרים אצל משתמשים.

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

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

גם בתמיכה אומרים שאין מה לעשות כרגע.

זהו השירות הזה איבד אותי לנצח. גם כשקניתי נייד חדש ויכלתי להשתמש שוב בשירות - לא חזרתי וגם לא אחזור לשם.

לא בגלל התקלה. בגלל התחושה.

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

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

לכן גם כשמביאים אותי ל־UX Review, Design Review או עבודה על Design System, אני תמיד מסתכלת גם על מסע המשתמש הרחב יותר.

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

“Design System חוסך לנו זמן ” לא משנה איפה היא נבנתה במארקדאון בתיקייה או בFigma.אם רוצים ש-Design System יקבל תמיכה מהנ...
19/08/2026

“Design System חוסך לנו זמן ”
לא משנה איפה היא נבנתה במארקדאון בתיקייה או בFigma.

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

צריך למדוד.

למשל:

Adoption Rate:
כמה מהפיצ’רים שעולים לפרודקשן משתמשים בקומפוננטות מהמערכת, וכמה עדיין בנויים Custom.

Time to Market:
כמה זמן לוקח לעבור מעיצוב לפרודקשן, לפני ואחרי אימוץ ה-Design System.

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

Tech Debt:
האם לאורך זמן באמת יורד מספר הקומפוננטות הכפולות וה-One-offs בקוד.

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

ואם עדיין אין מספיק Data?

אפשר להתחיל קטן.

לקחת פיצ’ר משמעותי אחד ולעשות עליו POC.

כמה זמן היה לוקח לבנות אותו בלי המערכת?
כמה לקח איתה?
איזו עבודת פיתוח נחסכה?
אילו בעיות נמנעו?

כי ברגע שאפשר להראות את הערך במספרים, השיחה על Design System מפסיקה להיות:
“אנחנו צריכים להשקיע יותר בעיצוב.”
והופכת לשיחה על איך החברה בונה מוצר.

אם אתם עמוק ב־vibe coding ומחפשיםOne MD to rule them allכי אתם כל הזמן:שולחים עוד contextמתקנים שובעושים compareמנסים re...
18/08/2026

אם אתם עמוק ב־vibe coding ומחפשים
One MD to rule them all

כי אתם כל הזמן:

שולחים עוד context
מתקנים שוב
עושים compare
מנסים reuse

והתוצאה עדיין… כמעט נכונה.

הקומפוננטות נראות טוב.

אבל יש שלושה אפורים שונים.
כפתור אחד בגובה קצת אחר.
אייקון X פעם קטן ופעם גדול.
שדה בלי hover כי פשוט שכחו.

שום דבר לא באמת “שבור”.

אבל הכל קצת off.

וזה מצטבר מהר.

⸻

וזה קורה גם אם יש Design System בפיגמה.

כי בפועל, ה־Design System בפיגמה הוא קצת כמו blueprint של אדריכל.

יפה. מדויק. חשוב.

אבל לא בהכרח מחובר למה שקורה בשטח.

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

אז במקום להאכיל אותו שוב ושוב בעוד context,
אפשר לבנות שכבת חוקים שהוא באמת יכול לעבוד איתה:

MD אחד חכם.

לא style.md עם צבעים, spacing ו־border radius.

יותר כמו MD על סטרואידים.

⸻

במובן מסוים, זה ה־Design System שעובד בשטח.

עם הרגליים בפרודקשן.

הוא לא מתאר רק איך דברים אמורים להיראות,
אלא גם:

👉 מה כן
👉 מה לא
👉 מה ה־canonical pattern
👉 ואיך לזהות ולתקן סטיות

למשל:

* יש 600 / 700 / 800 כמעט זהים? מאחדים ל־600.
* לא ממציאים עוד אפור כי “זה נראה קרוב”.
* לכפתור מאותו סוג יש אותו גובה.
* אייקון X לא משנה גודל בין מסכים.
* hover לשדה הוא לא אופציונלי.

⸻

והחלק החשוב הוא לא ה־MD עצמו.

העבודה האמיתית היא להבין מה החוקים שצריכים להיות בו.

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

כדי שלא רק תייצרו קומפוננטות מהר יותר.

אלא תייצרו אותן נכון מההתחלה.

רוצים לבנות שכבה כזאת אצלכם? דברו איתי.

כבר בניתם משהו דומה ועדיין ה־Agent מצליח להמציא לכם Design System חדש בכל feature?

עוד יותר מעניין. דברו איתי.

איך יודעים ש-Design System באמת בוגר? פוסט 2/5לא לפי מספר הקומפוננטות שיש בו.מהפאנל של Design Systems Israel יצאתי דווקא...
17/08/2026

איך יודעים ש-Design System באמת בוגר? פוסט 2/5
לא לפי מספר הקומפוננטות שיש בו.

מהפאנל של Design Systems Israel יצאתי דווקא עם כמה סימנים הרבה יותר מעניינים:

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

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

Legacy מנוהל ולא מוסתר.
יודעים אילו קומפוננטות קיימות רק מקומית, אילו נוצרו בשביל ניסוי, מה נשאר מקוד ישן ומה מתוכנן להיכנס ל-Core.

לקומפוננטות יש Lifecycle.
Active.
Deprecated.
Proposed.
Needs Refactor.

Design ו-Code מסונכרנים, או לפחות יודעים איפה הם לא.

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

בעיניי, המכנה המשותף לכל אלה הוא בכלל לא קומפוננטות.

הוא ניהול.

Design System בוגר לא רק מגדיר איך המוצר צריך להיראות.

הוא עוזר לארגון לקבל החלטות עקביות לאורך זמן.

אז אם אתם רוצים לבדוק את הבגרות של ה-Design System שלכם, אולי השאלה היא לא:

“כמה מה-UI כבר נמצא בספרייה?”

אלא:

“מה קורה כשצריך לשנות משהו?”

מה עדיף לתת למעצב/מאפיין: פרוטוטייפ חי או תיאור משימה מילולי כמו פעם? כמובן שאענה “תלוי” 🙂 !בפיצ’רים פשוטים, פרוטוטייפ ח...
16/08/2026

מה עדיף לתת למעצב/מאפיין: פרוטוטייפ חי או תיאור משימה מילולי כמו פעם? כמובן שאענה “תלוי” 🙂 !

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

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

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

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

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

כמו שטל פלורנטין אמר, נוצרים כאן Product Builders
שילוב של מאפיין, מעצב, מנהל מוצר ומפתח.





Anna Lovsky

מתי Design System באמת הופך לבוגר?לא כשיש לכם ספריית Figma או בימנו Markdown עם כפתורים יפים.לא כשהשקתם אתר Documentatio...
15/08/2026

מתי Design System באמת הופך לבוגר?

לא כשיש לכם ספריית Figma או בימנו Markdown עם כפתורים יפים.

לא כשהשקתם אתר Documentation מרשים.

ובטח לא כשמישהו בארגון הכריז:
“יש לנו Design System.”

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

וזה בדיוק מה שעלה בפאנל של Design Systems Israel בהובלת Erez Reznikov, עם Isaac Sheptovitsky, Saar Gil, Meirav Ron ו-Ido Zaifman.

אחד הדברים שהכי תפסו אותי היה איך ב-monday.com מתייחסים ל-Vibe, ה-Design System שלהם.

כאל מוצר.

יש לו תתי-מערכות, למשל Vibe for CRM ו-Vibe for AI.

יש לו Roadmap.

יש לו KPIs.

והכי מעניין בעיניי:
המטרה היא לא לגרום לצוותים “לציית” ל-Design System.

המטרה היא לבנות מערכת שאנשים ירצו להשתמש בה.

זה שינוי קטן לכאורה, אבל הוא משנה לגמרי את השאלה.

במקום:
איך גורמים לצוותים להשתמש ב-Design System?

לשאול:
מה צריך להיות במערכת כדי שהיא באמת תהיה הדרך הכי טובה עבורם לבנות מוצר?

וזה כבר Product Thinking, לא רק Design System.

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

Address

Jerusalem

Opening Hours

Monday 09:00 - 15:00
Tuesday 09:00 - 15:00
Wednesday 09:00 - 15:00
Thursday 09:00 - 15:00
Sunday 09:00 - 15:00

Website

Alerts

Be the first to know and let us send you an email when Anna Lovsky UX UI posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Shortcuts

Share

Category