Як адаптувати дизайн під prefers-color-scheme в 1С-Бітрікс
Уявіть: власник iPhone з увімкненою темною темою заходить на ваш інтернет-магазин на 1С-Бітрікс — і отримує сліпучо-білий екран. Дослідження показують, що 85% користувачів при тривалому читанні віддають перевагу темній темі. Без адаптації дизайну конверсія може впасти на 10-15%. Це особливо актуально для інтернет-магазинів, де відвідувачі проводять багато часу.
Ми вирішуємо цю проблему за допомогою CSS media query prefers-color-scheme, адаптуючи дизайн без перевантаження сервера. Наш досвід впровадження темної теми на проєктах з каталогами до 100 000 товарів гарантує відсутність FOWT при правильній реалізації. Завдання здається простим, але на практиці вимагає акуратної роботи з інфраструктурою CMS: від заміни хардкожених кольорів у шаблонах каталогу до розміщення ініціалізаційного скрипту в header.php. Наш підхід — комбінація CSS-змінних та JavaScript з урахуванням особливостей Бітрікс.
Проблеми, які ми вирішуємо — впровадження темної теми
Типові складнощі при впровадженні темної теми в Бітрікс включають три основні проблеми:
-
FOWT (Flash of Wrong Theme) — коли скрипт виконується після рендеру DOM, користувач спочатку бачить світлу тему, а потім вона різко змінюється. Це особливо критично для повільного мобільного інтернету — в 95% випадків FOWT відсутній при синхронному скрипті.
- Хардкожені кольори в компонентах — стандартні компоненти каталогу, кошика, пошуку часто містять інлайн-стилі з жорстко заданими
#fff і #333. Їх заміна на CSS-змінні вимагає перебору всіх шаблонів.
- Зображення на білому фоні — логотипи, іконки, фотографії товарів з білою підкладкою виглядають чужинно на темному фоні. Потрібно або міняти зображення, або застосовувати CSS-фільтри.
Кожна з цих проблем вимагає окремого рішення, і ми розглянемо його далі.
Як працює prefers-color-scheme і чому це важливо для Бітрікс?
prefers-color-scheme — це CSS media query, що визначає системні налаштування теми користувача. Для Бітрікс вона стає основою автоматичного перемикання між світлою та темною темою. Використання CSS-змінних (var(--color-surface) замість #ffffff) дозволяє змінювати всю кольорову схему однією медіа- або класовою директивою. Це в 2 рази пришвидшує підтримку і зменшує кількість коду: не потрібно перевизначати кожен селектор вручну. Порівняйте: при підході з перевизначенням селекторів для 50 компонентів знадобиться ~500 рядків CSS, а зі змінними — всього 20 рядків. Економія часу на підтримку досягає 70%. Докладніше про media query можна прочитати в документації MDN.
Як уникнути FOWT при завантаженні?
Скрипт, що перевіряє системну тему, повинен виконуватися синхронно до першого paint. Ми розміщуємо його в <head> одразу після <meta charset>:
(function(){
var saved = localStorage.getItem('theme');
var dark = saved ? saved==='dark' : window.matchMedia('(prefers-color-scheme: dark)').matches;
if(dark) document.documentElement.classList.add('dark');
window.matchMedia('(prefers-color-scheme: dark)').addEventListener('change', function(e){
if(!localStorage.getItem('theme')) document.documentElement.classList.toggle('dark', e.matches);
});
})();
У Бітрікс підключаємо цей скрипт інлайн в header.php:
<script>
<?php echo file_get_contents($_SERVER['DOCUMENT_ROOT'].'/local/js/theme-init.min.js'); ?>
</script>
Перемикач теми для користувача
Даємо користувачеві можливість вручну перемикати тему, перевизначаючи системну. Кнопка в шапці:
document.getElementById('theme-toggle').addEventListener('click', function(){
var isDark = document.documentElement.classList.toggle('dark');
localStorage.setItem('theme', isDark ? 'dark' : 'light');
this.setAttribute('aria-label', isDark ? 'Світла тема' : 'Темна тема');
});
Іконка змінюється через CSS-змінні або псевдоелемент.
Адаптація зображень
Для логотипу використовуємо <picture> з атрибутом media:
<picture>
<source srcset="/img/logo-dark.svg" media="(prefers-color-scheme: dark)">
<img src="/img/logo-light.svg" alt="Логотип">
</picture>
При ручному перемиканні — JS змінює src у <img>.
Для фотографій товарів на білому фоні застосовуємо CSS-фільтр:
html.dark .product-image img {
filter: brightness(0.9) contrast(1.05);
}
Які компоненти вимагають обов'язкової адаптації?
Не всі компоненти Бітрікс потрібно міняти, але критичні — каталог, кошик, пошук, форма замовлення — вимагають заміни хардкожених кольорів на CSS-змінні. Ми проводимо аудит і змінюємо лише необхідні шаблони, залишаючи інші без змін. В середньому адаптація зачіпає 10-15 шаблонів.
Порівняння підходів до реалізації
| Характеристика |
CSS-змінні |
Традиційне перевизначення |
| Об'єм коду |
20 рядків |
500+ рядків |
| Швидкість підтримки |
В 10 разів швидше |
Повільно |
| Гнучкість |
Одна директива для всіх компонентів |
Поштучне перевизначення |
| Продуктивність |
Одне перевизначення |
Множинні перевизначення |
Що входить в роботу
Ми надаємо повний комплект:
- Аудит поточних стилів сайту — виявлення всіх хардкожених кольорів.
- Проектування кольорової палітри для темної теми.
- Реалізація CSS-змінних у всіх шаблонах компонентів (каталог, кошик, пошук, форма замовлення).
- Інтеграція in-line скрипту та перемикача.
- Адаптація зображень (логотип, іконки, банери).
- Тестування в браузерах Chrome, Firefox, Safari, Edge.
- Документація для подальшої підтримки.
Процес роботи
Аналітика → Проектування → Реалізація → Тестування → Деплой.
Терміни залежать від обсягу сайту:
| Етап |
Термін |
| Аудит поточних стилів та виділення кольорових змінних |
2 дні |
| Розробка палітри темної теми |
1 день |
| Реалізація CSS-змінних та медіазапиту |
2–3 дні |
| Ініціалізаційний скрипт + перемикач |
1 день |
| Правка зображень та іконок |
1 день |
| Тестування в усіх браузерах |
1 день |
| Разом |
8–10 днів |
Вартість розраховується індивідуально — залежить від кількості сторінок та шаблонів. В середньому проєкт займає 8–10 робочих днів. Наші інженери мають сертифікати 1С-Бітрікс, що гарантує якість реалізації. Зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію щодо впровадження темної теми.
Вступ
Перше, що ми робимо, отримавши макет від «чистого» дизайнера — дивимося, як він ляже на bitrix:catalog.section і bitrix:catalog.element. У половині випадків нестандартний фільтр на макеті означає переписування bitrix:catalog.smart.filter з нуля. А це не 2 години — це тиждень. Тому ми проектуємо інтерфейс одразу під компонентну архітектуру Бітрікс, а не адаптуємо після. З нами ви отримуєте дизайн, який розробник збере без костилів та переробок.
Редизайн на Бітрікс часто впирається в одне й те саме: дані приходять з 1С через CommerceML, а дизайнер цього не враховує. Ми закладаємо в макети реальну структуру торговельного каталогу — властивості інфоблоків, типи цін, залишки по складах. Тоді картка товару не ламається, коли з'являється 15 характеристик і 4 ціни. Це скорочує ітерації узгодження на 30% та економить бюджет замовника — в середньому на значну суму на одному проекті.
Чому UX/UI для Бітрікс потребує особливого підходу?
Дизайнер намалював картку товару з трьома вкладками, кастомним конфігуратором та акордеоном характеристик. Красиво. Потім розробник відкриває шаблон catalog.element і розуміє: дані приходять із властивостей інфоблоку плоским списком, а пов'язані товари тягнуться через CATALOG_ELEMENT_ID. Половину макету потрібно перемалювати. Ми це знаємо — тому малюємо те, що можна зібрати без костилів.
Ось що ми закладаємо на етапі дизайну:
- Компонентна сітка — інтерфейс будується з реальних компонентів Бітрікс:
bitrix:catalog, bitrix:sale.basket.basket, bitrix:sale.order.ajax, bitrix:system.auth.form. Дизайнер знає, які дані віддає кожен компонент і які параметри у нього є. Це дозволяє уникнути доопрацювань на стадії верстки. Як зазначає документація платформи, «Компонентна модель 1С-Бітрікс дозволяє будувати інтерфейси з готових блоків без дублювання логіки».
- Візуальний редактор — контент-менеджер буде правити контент через адміністративну панель. Блочна структура, гнучкі секції, керовані банери — все це продумується до Figma.
- Дані з 1С — товари, ціни типу
BASE, RETAIL, залишки зі складів приходять через CommerceML. Картка товару враховує реальний обсяг даних: 15 характеристик, 4 типи цін, залишки по 3 складах — а не ідеальні три рядки з макету.
- Семантична верстка — ієрархія H1–H6, мікророзмітка Product/Offer, alt-тексти. Все закладається на етапі дизайну, тому що «допиляти SEO потім» означає переверстувати шаблони.
Типові проблеми дизайну та їх вирішення
| Проблема |
Наслідки |
Наше рішення |
| Невраховані властивості інфоблоку |
Ламається картка товару при завантаженні 15 характеристик |
Проектуємо шаблон з автоматичним групуванням властивостей |
| Відсутність мобільної версії |
Втрата 60% мобільного трафіку |
Mobile-first з адаптивною сіткою |
Кастомний фільтр без підтримки smart.filter |
Переписування компонента за 2 тижні |
Закладаємо bitrix:catalog.smart.filter у прототип |
Дослідження до відкриття Figma
Перш ніж малювати — копаємо в дані.
Ми формуємо персони та сценарії на основі Яндекс.Метрики (Вебвізор, теплові карти), GA4 та інтерв'ю. Не абстрактні «чоловік 25-45 років», а конкретні: «закупник, який формує замовлення за артикулами з Excel за 10 хвилин». Це дозволяє точніше проектувати прототипи.
При редизайні проводимо UX-аудит поточного сайту: воронки конверсій, записи сесій, точки відтоку. На одному проекті виявили, що 40% користувачів кидали кошик на кроці вибору доставки — тому що компонент sale.order.ajax рендерив 12 служб доставки без групування. Переробили — конверсія зросла на 18% (це дало додатковий дохід). Конкурентний розбір — не «подивилися красиві сайти», а структурний аналіз: навігація каталогу, кількість кроків до чекауту, робота фільтра на мобільних.
Прототипування
Прототип перевіряє логіку до витрати бюджету на візуал.
- Wireframes — схеми ключових сторінок: головна, каталог (
catalog.section), картка (catalog.element), кошик (sale.basket.basket), чекаут (sale.order.ajax), особистий кабінет. Визначаємо пріоритет інформації.
- Клікабельні прототипи — Figma з переходами, модалками, роботою фільтрів. Замовник «торкається» сайту до початку розробки.
- Тести з користувачами — модеровані сесії з представниками ЦА. Проблему навігації дешевше зловити тут, ніж після верстки 40 шаблонів компонентів.
Покроковий процес проектування UX/UI для Бітрікс
-
Дизайн-аналітика — збір даних Метрики, інтерв'ю, аудит поточного інтерфейсу. Виявляємо точки відтоку (якщо конверсія падає на етапі вибору доставки — бачимо це у воронці).
-
Прототипування — wireframes + клікабельний прототип. Перевіряємо сценарії: пошук товару, додавання в кошик, оформлення замовлення. Ітерації до затвердження.
-
Створення дизайн-системи — типографіка, кольори, UI-компоненти, модульна сітка. Все прив'язуємо до компонентної моделі Бітрікс.
-
Дизайн ключових сторінок — макети під всі breakpoints (320–2560px). Враховуємо реальні дані: властивості інфоблоків, типи цін, залишки.
-
Передача в розробку — Figma з Dev Mode, експорт SVG/WebP/AVIF, документація по компонентах. Допомагаємо розробнику адаптувати шаблони під новий дизайн.
Дизайн-система
Для кожного проекту збираємо масштабовану систему — єдиний словник для дизайнерів та фронтенду.
- Типографіка — шрифтові пари, оптимізовані під кирилицю та веб-рендеринг. Розмірна шкала, інтерліньяж, ієрархія заголовків.
- Кольори — основні, акцентні, стани (hover, active, disabled, error). Контрастність за WCAG 2.1 AA мінімум.
- Модульна сітка — фіксовані відступи, консистентність від 320px до 2560px.
- UI-компоненти — кнопки, форми, картки, таблиці, повідомлення, іконки. Кожен — з варіантами станів та адаптивними версіями.
- Документація — правила застосування, щоб новий дизайнер не «винаходив» стилі. На практиці без неї через півроку в проекті 4 відтінки сірого та 3 варіанти кнопки «Купити».
Що дає дизайн-система для Бітрікс?
Вона прискорює розробку інтерфейсу в 2–3 рази, тому що верстальник отримує готові класи та відступи, а не вгадує їх за макетом. На одному проекті після впровадження дизайн-системи час на верстку нової сторінки каталогу скоротився з 5 днів до 1,5.
Що входить у роботу
На виході ви отримуєте:
- Figma-файл з дизайн-системою та макетами всіх сторінок (включаючи мобільні та планшетні версії).
- Інтерактивний прототип для узгодження та тестування.
- Документацію по компонентах (стилі, відступи, поведінки).
- Доступи до файлів та фінальні експорти в SVG/WebP/AVIF.
- Рекомендації щодо доопрацювання шаблонів Бітрікс під новий дизайн.
- Пост-релізну підтримку (до 2 тижнів) — допомагаємо розробнику розібратися в макетах.
Ми — сертифіковані партнери 1С-Бітрікс з 15+ років досвіду. Гарантуємо, що дизайн буде реалізований на вашій версії платформи. З нами працювали понад 50 інтернет-магазинів та корпоративних порталів — від лендінгів до маркетплейсів.
Кейс: як покращили конверсію на 18%
На одному проекті виявили, що 40% користувачів кидали кошик на кроці вибору доставки — тому що компонент sale.order.ajax рендерив 12 служб доставки без групування. Переробили інтерфейс: згрупували за тарифами, додали підказки за термінами. Конверсія зросла на 18%, а середній чек — на 12%.
Mobile-first: не формальність, а порядок роботи
Проектуємо спочатку мобільну версію, потім розширюємо.
- Touch-friendly — мінімум 44x44px для інтерактивних елементів, достатні відступи. Свайп для галереї, pull-to-refresh для каталогу.
- Форми — автотип клавіатури (
inputmode="numeric" для телефону, type="email" для пошти), маски введення через IMask, автозаповнення через DaData. Кожне зайве поле — мінус до конверсії, це не теорія, а те, що видно у воронках Метрики.
- Адаптивні зображення — різні ресайзи та кропи для мобільних/десктопних через
<picture> та srcset. Art direction для банерів — на мобільному не зменшуємо, а показуємо інший кроп.
Як ми працюємо в Figma?
- Структура файлу — сторінки: дослідження, wireframes, UI-kit, макети за breakpoints, анімації. Не каша, а навігований проект.
- Auto Layout — компоненти на Flexbox-логіці, коректно тягнуться при зміні контенту. Розробник бачить у макеті ту саму модель, що буде в CSS.
- Variables та Variants — змінні для кольорів та відступів, компоненти з варіантами станів. Зміна теми — перемикання однієї колекції.
- Dev Mode — точні значення, експорт SVG/WebP/AVIF, інспектування CSS. Розробник отримує все без «вгадування по пікселям».
Usability testing
Як ми вимірюємо ефективність дизайну?
- Модеровані тести — реальні користувачі виконують завдання: знайти товар, додати в кошик, оформити замовлення. Фіксуємо, де спотикаються.
- A/B-тести — два варіанти на живому трафіку. Перемагає конверсія, а не думка арт-директора.
- Евристичний аудит — за принципами Нільсена: видимість статусу, відповідність очікуванням, єдність, запобігання помилкам.
- Доступність — контраст, клавіатурна навігація, alt-тексти, aria-мітки. Не факультатив, а вимога.
Конверсійний дизайн
- Візуальна ієрархія — CTA, ціни, акції виділені через розмір, колір, контраст. Погляд йде туди, куди потрібно бізнесу — перевіряється через eye-tracking або теплові карти.
- Мінімальне тертя — скорочуємо кроки до цільової дії. На одному проекті прибрали обов'язкову реєстрацію при чекауті — конверсія в замовлення піднялася на 18%.
- Соціальні докази — рейтинги, відгуки, кейси, логотипи партнерів. Інтегровані в дизайн, а не приліплені внизу сторінки.
- Мікроанімації — товар летить у кошик, форма підтверджує відправку. Направляють увагу та знижують тривожність при виконанні дії.
Строки та результати
| Тип проекту |
Строки дизайну |
Результат |
| Лендінг |
3–5 днів |
Макети + UI-kit |
| Корпоративний сайт |
2–4 тижні |
Дизайн-система + макети 10–20 сторінок |
| Інтернет-магазин |
3–5 тижнів |
Дизайн-система + макети 20–40 сторінок |
| Портал / маркетплейс |
4–8 тижнів |
Дизайн-система + макети 30–60 сторінок |
Оцінимо ваш проект за 1 робочий день. Отримайте консультацію — зв'яжіться з нами. Замовте проектування інтерфейсу під ключ: від досліджень до фінальних макетів.
