Десь у паралельному всесвіті в Airbnb існує публічний портал дизайн-системи — такий же красивий, як маркетинговий лендинг, і такий же корисний, як документація API. У нашому всесвіті ні.
З усього, що публічно з’являлося в останні роки, найофіційніше й найпомітніше — Summer Release 2025 (Summer Release): новий застосунок Airbnb, нові напрями (Services / Experiences), нова візуальна мова і пряме твердження, що вони створили нову дизайн-систему з dimensional (об’ємним) та анімованим інтерфейсом.
Паралельно в публічному просторі з’являлися відео й пости людей, які працювали над оновленням системи. Але саму систему у вигляді відкритої бібліотеки або док-порталу Airbnb так і не виклали. LinkedIn
Тож я зробив те, що робить будь-який допитливий дизайнер у 2026 році, коли не знаходить «Airbnb DLS download»:
витратив вихідні на дослідження матеріалів і зібрав усе по крупинках: статті, доповіді, офіційні релізи, інтерв’ю, open-source сліди і розклав, як у них це влаштовано на рівні підходів. Щоб було зрозуміло навіть тим, хто слово governance вимовляє як «гавернанс» і робить вигляд, що так і треба.
Сьогодні проливаємо цифровий чай на тему внутрішньої кухні Airbnb. Заварюйте чай-каву, поїхали по 10 ключових пунктах.
1. Що саме “оновилося” у Airbnb і чому всі знову заговорили про їхню систему
У Summer Release 2025 Airbnb не просто «перефарбували кнопки». Вони заявили:
- застосунок тепер покриває більше сценаріїв (житло + сервіси + враження);
- під це вони створили новий технологічний стек;
- і нову дизайн-систему з більш об’ємним і анімованим інтерфейсом, щоб планування подорожі відчувалося «живішим».
Важливо: це не чийсь блог «мені здається, вони оновилися», а пряме твердження в офіційному Airbnb Newsroom.
Плюс є публічні інтерв’ю та матеріали, де люди з Airbnb говорять, що для нового застосунку знадобилася цілком нова дизайн-система. Це фактично підтверджує масштаб роботи. Design Week
Чому це важливо для нас: оновлення такого рівня майже завжди означають, що система — це не «UI-Kit у Figma», а реальна інфраструктура, яка витримує зміну продуктової стратегії.
2. Чому їхню дизайн-систему досі не віддають назовні (і це логічно)
Коротко: тому що Airbnb DLS — це конкурентна перевага, а не «плюшки для спільноти».
Для великої продуктової компанії дизайн-система — це:
- прискорювач розробки,
- контроль консистентності,
- спосіб масштабувати сотні дизайнерів і інженерів,
- частина внутрішнього «виробничого конвеєра».
Публічний реліз означає:
- величезні витрати на підтримку зовнішніх користувачів,
- необхідність документувати все так, щоб зрозумів будь-хто з вулиці,
- юридичні й брендові обмеження,
- і найсмішніше — ризик, що за рік усе застаріє, і тебе тикатимуть носом: «а ось тут у вас у доках не так».
Те, що Airbnb замість «публічного порталу» залишили публічні шматки інфраструктури та доповіді, підтверджується їхніми open-source проєктами та виступами:
вони діляться принципами й інженерними ідеями, але не «повним пакетом продукту».. GitHub
3. “Одна система для Web і Mobile”. Як це можливо, якщо патерни різні
Головна думка:
одна система ≠ однакові екрани
одна система = єдина мова + єдиний контракт.
3.1. Що в них спільне (контракт)
Зазвичай спільними є:
- сенс дій (primary / secondary / destructive),
- ієрархія,
- стани (disabled / loading / pressed / focus),
- правила візуальної виразності,
- базові токени (колір, типографіка, відступи, радіуси, тіні),
- accessibility як принцип.
У їхніх офіційних матеріалах Summer Release овони прямо підкреслюють: система стала більш dimensional і анімованою — це рівень мови й поведінки, а не список компонентів.
3.2. Що різне між платформами
Різне те, що диктує платформа:
- навігаційні патерни (iOS vs Android vs Web),
- жести й touch vs mouse/keyboard,
- системні компоненти,
- нюанси accessibility API.
Принцип:
система відповідає за “що і чому”, платформа — за “як саме”.
3.3 Органічна еволюція
Раніше:
єдина система → різні реалізації → суворе дотримання платформ
Тепер:
одна мова → одна естетика → платформи адаптуються під систему
Сьогодні інтерфейси Airbnb відчутно ближчі один до одного.
Платформа більше не формує обличчя продукту — його формує дизайн-система.
4. Чому всі вважають їх еталоном, навіть не бачачи “під капотом”
Тому що індустрія бачить результат:
- єдину «інтонацію» продукту,
- передбачуваність інтерфейсу,
- швидкість еволюції без розпаду на «зоопарк» рішень.
І Airbnb першими дуже гучно показали: дизайн-система — це не набір кнопок, а Design Language: узгоджена візуальна та поведінкова мова. Це прямо лежить у тому, як вони публічно описують свої великі зміни:
“new design system”, “new interface”, “dimensional and animated”. Airbnb Newsroom
А ще є фактор «міфу»: чим менше доступно деталей, тим простіше людям домалювати в голові «там ідеальна магія».
(Не засуджуємо. Ми всі так робили.)
5. Головний публічний розбір “під капотом”: чому вони перебудовували систему, а не просто “підтримували”
Найсмачніше з точки зору інженерної логіки — доповідь “Building (And Re-Building) the Airbnb Design System” (React Conf). YouTube
Цінність доповіді не в «які у них кнопки», а в тому, які проблеми неминуче виникають у великій компанії і що вони з цим робили.
5.1. Які проблеми в них виникали (типові для будь-якого ентерпрайзу)
За переказами та матеріалами навколо доповіді (і слайдами) картина така:
- фрагментація: команди починають робити «свої варіанти» компонентів,
- forked code: один і той самий компонент існує у кількох несумісних версіях,
- ускладнення продукту: з’являються нові сценарії та сутності (житло, враження тощо), стара структура компонентів «не тягне»,
- система стає або занадто жорсткою (заважає), або занадто пухкою (не утримує консистентність).
Ця логіка прямо відображена в описах матеріалів доповіді та розборах. Slideshare
5.2. Головний висновок Airbnb (корисніший за будь-які токени)
Дизайн-система — це архітектура, яка має переживати зростання і зміни продукту.
Якщо система не вміє еволюціонувати — вона ламається. Не «може зламатися», а обов’язково зламається, бо продукт живий.
І тут Airbnb зробили важливу річ: вони публічно нормалізували ідею, що систему іноді потрібно перепроєктовувати, а не «підпилювати нескінченно».
6. Що можна зрозуміти з їхнього open-source: Lona як спроба зробити “Design System as Code”
Найпоказовіший відкритий артефакт епохи Airbnb — Lona.
Офіційно Lona описується як набір інструментів для:
- визначення дизайн-системи,
- генерації кросплатформних артефактів: UI-коду, Sketch-файлів тощо. GitHub
6.1. Чому це важливо
Це показує їхнє мислення:
система — це не «вручну синхронізований Figma/Sketch + React».
Система — це дані й правила, з яких можна отримувати різні представлення:
- «джерело істини» (структурований опис),
- UI-код під платформу,
- дизайн-артефакти,
- документаційні матеріали.
Тобто вони намагалися піти від вічного болю:
«Дизайнер оновив компонент, у коді він інший, а в застосунку взагалі третій».
Lona як концепт — це спроба зробити так, щоб дизайн і код були похідними від одного опису, а не двома паралельними всесвітами.
6.2. Як це влаштовано по шарах (з того, що можна стверджувати)
У публічному описі Lona прямо сказано про три ключові частини:
- формат компонентів .component,
- візуальний редактор (Studio),
- компілятор (Compiler), який генерує артефакти.
Тобто «під капотом» проглядається стандартна система зрілого рівня:
- model (дані / опис),
- tooling (редактор / валідатор),
- compiler / generator (виводи під платформи).
7. Що нам говорить Summer Release 2025 про “нову систему”: не тільки UI, а й досвід
Офіційний реліз підкреслює:
- “dimensional” інтерфейс,
- “beautifully animated”,
- “brings the world of Airbnb to life”.
Перекладаючи з маркетингової на людську:
- вони закладають у систему правила глибини / шарів (як картки нашаровуються, як контент «дихає»),
- вони закладають motion-поведінку як частину мови (не «анімації за смаком команди», а спільний стиль),
- вони роблять це системно, бо інакше на масштабі все перетворюється на цирк.
Сторонні медіа (Itsnicethat), описуючи редизайн, повторюють ту саму ідею: інтерфейс має залишатися “distinctly Airbnb” — живим, простим, впізнаваним. Це рівно те, чого досягає дизайн-система як «мова».
8. “Система на 200 дизайнерів”: що можна винести з публічних інтерв’ю та матеріалів
Коли в інтерв’ю фігурують масштаби типу «команда дизайнерів — сотні людей», головний сенс завжди один:
- без системи у тебе не продукт, а колективна художня творчість,
- із системою у тебе фабрика, що виробляє єдиний досвід.
В інтерв’ю та матеріалах про редизайн прямо згадується, що під новий застосунок знадобилася “whole new design system”, і що це робота великої команди.
Це підтверджує простий факт: “Airbnb — еталон” не тому, що в них красивий UI, а тому, що вони вміють організувати виробництво інтерфейсу.
9. Почему “доказательства есть”, а “публичной библиотеки нет”: разделяем, что мы знаем точно, а что — домысливаем
Щоб не перетворитися на тих самих людей, які «всі говорять, але ніхто не бачив», ось чесний поділ.
9.1. Що можна стверджувати як факт (є підтвердження)
Airbnb у 2025 заявляли про нову дизайн-систему і нову візуальну мову / інтерфейс у межах Summer Release.
У Airbnb був (і публічно обговорювався) серйозний процес побудови та перебудови дизайн-системи на масштабі компанії (доповідь React Conf).
Вони ділилися інструментами та ідеями, пов’язаними з описом системи та генерацією кросплатформних артефактів (Lona).
9.2. Чого не можна чесно стверджувати (якщо не фантазувати)
Не можна стверджувати, що в них «ось такий список токенів», «ось такі компоненти» і «ось такі правила», якщо цього немає у відкритій документації. Ми можемо говорити про підходи, але не про конкретну внутрішню специфікацію.
10. Практичний підсумок: як застосувати “Airbnb-підхід” у себе (без спроб украсти їхні кнопки)
Якщо винести суть із усіх джерел і зробити прикладний висновок, виходить дуже прагматична схема.
10.1. Будуй систему як мову + контракт
Не «UI-Kit», а:
- семантика компонентів (що таке primary / secondary),
- стани як стандарт (loading / disabled / focus),
- ієрархія та композиція,
- motion як частина мови (якщо ви доросли до цього),
- accessibility як правило за замовчуванням.
(І так — у 2025 вони фактично це підтверджують через “dimensional + animated design system”: мова включає поведінку.)
10.2. Зроби платформи “діалектами”
Одна система — різні реалізації:
- Web: mouse / keyboard / focus / ARIA
- iOS / Android: touch / gestures / native navigation / a11y API
Система відповідає за «що і чому», платформа — за «як».
10.3. Прийми, що система буде ламатися — і заклади можливість “rebuild”
Найцінніша спадщина Airbnb — нормалізація ідеї, що:
- система не вічна,
- продукт змінюється,
- отже архітектура системи теж має змінюватися.
Це не «провал». Це зрілість.
10.4. Інструменти: думай у бік “single source of truth”
Lona показує напрям мислення:
- описуємо систему структурно,
- генеруємо артефакти,
- зменшуємо ручну синхронізацію «дизайн ↔ код».
Навіть якщо Lona тобі не потрібна — сама ідея «не два світи, а один» надзвичайно практична.
Замість висновку: чому тобі не потрібна “дизайн-система як у Airbnb”
Найнебезпечніша думка після всіх цих розмов: «Нам потрібна така ж дизайн-система, як у Airbnb».
Ні. Тобі не потрібна їхня система. Тобі потрібен їхній рівень мислення.
Airbnb стали еталоном не тому, що в них «ідеальні кнопки».
Вони стали еталоном, бо перестали мислити екранами і почали мислити мовою продукту. Вони зрозуміли просту, але болісну істину:
інтерфейс — це не набір компонентів, це спосіб, яким продукт розмовляє з людиною. А дизайн-система — це граматика цієї розмови.
І поки більшість компаній усе ще сперечаються, як назвати компонент і де зберігати токени, Airbnb вже багато років будують виробничу інфраструктуру UX — ту саму, що дозволяє спокійно переживати зростання, зміну стратегії, нові ринки та нові продукти, не перетворюючи інтерфейс на музей випадкових рішень.
Тож якщо після цієї статті в тебе не з’явилося бажання
«скопіювати Airbnb», а з’явилося бажання нарешті перестати ліпити інтерфейс і почати будувати систему — значить, усе було не дарма, і мій аналіз підштовхнув тебе до корисних думок і покращень у твоєму продукті.
І так. Їхню дизайн-систему ти, можливо, ніколи не побачиш.
Але тепер ти точно розумієш, чому вона працює.
Якщо вам близький мій підхід до роботи з дизайном і процесами, я зібрав його в книзі «Design Systems. Step by Step» — практичному посібнику про те, як вибудовувати дизайн-системи в реальних командах: від структури й логіки рішень до взаємодії дизайну, розробки та продукту. Без теорії заради теорії. Лише досвід, помилки й практики, що справді працюють.
👉 Print & Kindle Amazon →
👉 PDF (Digital Edition) Gumroad →
Добра 🦫
Топ коментарі (0)