Тёмная тема: реальная необходимость или просто тренд?
Почему сейчас тёмную тему просят все клиенты
В какой-то момент за последние пять лет тёмная тема перестала быть прихотью разработчиков и превратилась в обязательный пункт почти в каждом брифе, который я получаю. Неважно, ведёт ли клиент сайт записи в стоматологическую клинику или B2B-платформу аналитики — где-то на вводном созвоне обязательно прозвучит: «Ах да, и нам ещё хотелось бы тёмную тему». Обычно это произносят мимоходом, как будто просят добавить фавиконку.
Я понимаю, откуда это берётся. Apple и Google примерно в 2019 году выпустили системные тёмные темы, Twitter и YouTube сделали переключатель видимым элементом интерфейса, и внезапно тёмная тема стала сигналом того, что продукт современный, технологичный и хорошо поддерживается. Это закрепилось как своего рода маркер дизайнерской грамотности — если в приложении нет тёмной темы, может, его давно не обновляли. Это восприятие сильное, и оно не совсем беспочвенно. Но это не повод её делать.
Вот неудобная правда, которую я говорю клиентам, иногда к их видимому разочарованию: тёмная тема — не универсальное улучшение. Это функция с реальными издержками — дизайнерскими, инженерными, издержками на QA и постоянную поддержку — и, как любая функция, она должна решать конкретную задачу. Иногда эта задача очевидна и ценна. Иногда она чисто декоративна. Вся остальная статья — о том, как отличить одно от другого, потому что я видел команды, которые тратили по три-четыре недели на тёмную тему, которую потом переключали менее 2% пользователей, пока реальные проблемы юзабилити в светлом интерфейсе так и оставались нетронутыми.
Это не статья против тёмной темы. Я реализовывал её десятки раз и считаю, что в правильном контексте она действительно хороша. Это статья за то, чтобы относиться к ней как к дизайнерскому решению с критериями, а не как к тренду, который перенимают просто потому, что так делают крупные игроки.
Случаи, когда тёмная тема — действительно правильное решение
Начнём с ситуаций, где я сразу говорю «да», без споров, потому что сценарий использования сам по себе оправдывает затраты.
Инструменты для работы при слабом освещении в течение долгого времени
Если людям приходится пользоваться продуктом в тёмных помещениях подолгу — редакторы кода, видеомонтажные студии, инструменты для работы с музыкой, дашборды систем видеонаблюдения, ПО для ночных смен — тёмная тема здесь не прихоть, а эргономическая необходимость. Рентгенолог, просматривающий снимки в два часа ночи, звукорежиссёр в тёмной студии, трейдер с шестью мониторами в слабо освещённом офисе — это люди, для которых яркий белый интерфейс по-настоящему неудобен и утомляет за целую смену. Я работал с логистической компанией, чьё диспетчерское ПО крутилось на настенных мониторах в тускло освещённой диспетчерской круглосуточно. Светлая тема там была не просто нелюбима — она была функциональной проблемой: блики на стекле, прищуренные глаза операторов. Это легитимный, измеримый сценарий.
Медиа и визуально насыщенные интерфейсы
Приложения, построенные вокруг фотографии, видео или любого визуально богатого контента, выигрывают от тёмного окружения, потому что тёмный нейтральный фон делает цвет и контраст контента более выразительным — по той же причине, по которой фотогалереи и кинотеатры тёмные. Lightroom, VSCO, большинство стриминговых платформ — их тёмный интерфейс не про экономию заряда или усталость глаз, а про то, чтобы не конкурировать с контентом за визуальное внимание. Если ключевая ценность вашего продукта — показ насыщенного визуального медиа, тёмная тема поддерживает реальную задачу интерфейса: не мешать.
Инструменты для разработчиков и технической аудитории
У этой аудитории сильное, устоявшееся предпочтение, близкое к ожиданию. Если вы делаете админ-панель, сайт с API-документацией или дашборд-компаньон для разработчиков, отсутствие тёмной темы реально будет восприниматься как пробел, потому что именно эта аудитория сделала её нормой во всей своей цепочке инструментов — терминал, IDE, devtools браузера. Здесь дело меньше в объективной эргономике и больше в соответствии ожидаемой среде пользователя. Контекст важнее универсальных правил.
Мобильное использование с OLED-экранами и долгими сессиями
Для мобильных приложений с действительно долгими сессиями — приложения для чтения, мессенджеры, которые люди держат открытыми часами, инструменты для заметок — тёмная тема на OLED-экранах даёт реальную, измеримую экономию заряда батареи, потому что чёрные пиксели в буквальном смысле выключены, а не просто затемнены. Это один из немногих случаев, где «модно» и «технически полезно» чисто совпадают. Если паттерн использования вашего приложения предполагает, что люди подолгу смотрят в него на телефоне, это законный аргумент эффективности, а не просто эстетика.
Доступность для людей с определёнными особенностями зрения
Некоторые пользователи с повышенной светочувствительностью (определённые формы мигрени, некоторые виды фотофобии, определённые стадии катаракты) действительно испытывают боль от ярких белых интерфейсов, а не просто предпочитают другое. Эта доля аудитории меньше, чем обычно подразумевают рекламные тексты про тёмную тему, но она реальна, и если ваш продукт обслуживает аудиторию, для которой это важно — медицинские платформы, вспомогательные инструменты — это стоит вложений уже только ради инклюзивности.
Обратите внимание на закономерность во всех пяти случаях: в каждом есть конкретная, называемая причина, связанная с тем, как и где люди реально пользуются продуктом. Ни одна из них не звучит как «потому что тёмная тема выглядит современно». Это различие — суть всей статьи.
Где тёмная тема — в основном тренд, а не необходимость
А теперь более сложные разговоры — те, что у меня случаются чаще всего, потому что большинство моих клиентов не управляют ночными диспетчерскими или видеомонтажными студиями. Они делают маркетинговые сайты, интернет-магазины, SaaS-дашборды для использования в рабочее время и внутренние инструменты.
Маркетинговые и имиджевые сайты
Задача маркетингового сайта — донести бренд, вызвать доверие и подтолкнуть человека к решению за короткую сессию. Тёмная тема здесь почти всегда эстетический выбор, замаскированный под функцию. Клиенты просили её у меня просто потому, что она есть у конкурента, а когда я спрашиваю «какую проблему посетителей она решает», честный ответ обычно звучит как «выглядит стильно». Это законный вкус, и если бренд действительно работает в тёмном исполнении (ночной клуб, игровая студия, премиальный аудио-бренд), стоит сделать тёмную тему основной и единственной — осознанную тёмную айдентику, а не переключатель. Я возражаю именно против переключателя — поддержки двух полноценных тем ради пятиминутной сессии посетителя, когда это инженерное время можно направить на работу, напрямую влияющую на конверсию: скорость загрузки или более понятные призывы к действию.
Интернет-магазины
Товарную фотографию снимают на контролируемом фоне, обычно белом или нейтральном, потому что так поддерживается цветовая точность и единообразие по всему каталогу. Переключи витрину в тёмную тему — и товарные фотографии, не рассчитанные на тёмное окружение, могут выглядеть мутными, со сдвинутым цветом или как будто парящими в пустоте с резкими белыми ореолами. Я видел магазины, которые запускали тёмную тему, а потом тихо отключали её на страницах товаров, потому что товарная фотография просто не выдерживала — и это кое-что говорит о реальном соотношении затрат и выгод. Если весь ваш каталог не снят и не отретуширован специально под тёмный контекст, это ловушка.
SaaS-дашборды для рабочего времени с короткими сессиями
Если ваш инструмент открывают по несколько раз в день на пару минут — биллинговый дашборд, CRM, в которую заглядывают между встречами, инструмент планирования — эргономический аргумент в пользу тёмной темы заметно слабеет. Сессии короткие, происходят в обычном офисном освещении, и преимущество тёмной темы (снижение нагрузки на глаза при длительном использовании в темноте) здесь попросту не применимо. Я не говорю «не делайте» — многие пользователи всё равно будут её просить и радоваться, что она есть. Я говорю: не относитесь к ней как к срочной или критичной для успеха продукта вещи и не позволяйте ей съедать бюджет роадмапа, предназначенный для реальных улучшений рабочего процесса.
Запросы в духе «у конкурента же есть»
Это, пожалуй, самая частая причина, которую я слышу, и самая слабая. Копирование фичи конкурента имеет смысл, когда фича решает реальную, общую проблему пользователей, которую конкурент выявил раньше вас. Смысла в этом гораздо меньше, когда фича — поверхностный тренд, который конкурент принял по тем же причинам, по которым его рассматриваете вы, — потому что все так делают. Я задаю клиентам один вопрос: если бы у конкурента не было тёмной темы, захотели бы вы её делать? Если честный ответ «нет» — это уже полезная информация.
Ничто из этого не значит, что тёмная тема плоха в таких контекстах. Это значит, что решение должно приниматься исходя из реальной пользы для конкретного продукта и аудитории, а не из общего давления индустрии. Слово «тренд» — не оскорбление: тренды появляются, потому что что-то откликнулось у людей, — но тренд не равен требованию, и путаница между этими понятиями — ровно то, из-за чего команды в итоге поддерживают функции, которые никому не нужны.
Сколько на самом деле стоит реализация тёмной темы
Клиенты часто недооценивают это, и я думаю, причина в том, что конечный результат — переключатель — выглядит так просто. Переключатель действительно прост. Всё, что за ним стоит, — нет. Вот что реально требуется для добавления тёмной темы, если делать это как следует, а не как быструю инверсию цветов через CSS.
- Полный второй набор цветовых токенов, а не инверсия. Простая замена чёрного на белый и наоборот даёт резкий, часто «сломанный» результат. Хорошие тёмные темы используют ненасыщенные, более тёплые тёмно-серые оттенки вместо чистого чёрного, и им нужны собственные тщательно подобранные акцентные цвета, потому что цвета, которые смотрятся ярко на белом, на тёмном фоне могут выглядеть неоновыми или неприятно «вибрировать». Это настоящее переосмысление цветовой системы, а не наложение фильтра.
- Перепроверенные коэффициенты контраста для каждой пары текст/фон. Сочетание цветов, которое проходит WCAG AA в светлой теме, может не пройти его в тёмной, и наоборот, потому что математика контраста не симметрична, как многие ошибочно считают. Каждое состояние кнопки, ошибка формы, отключённое состояние и бейдж требуют повторной проверки.
- Переработанные или адаптированные иллюстрации, иконки и графики. Плоские иллюстрации, созданные для белого фона, часто имеют тонкие обводки или цветовые решения, которые пропадают или конфликтуют с тёмной темой. Визуализациям данных нужна отдельная палитра, потому что категориальные цвета, различимые на белом, могут быть неразличимы на тёмно-сером, особенно для людей с нарушениями цветовосприятия.
- Пересобранная система теней и уровней. Тени, которые в светлом интерфейсе передают возвышение и иерархию, почти не читаются на тёмном фоне. Дизайн-системы для тёмной темы обычно заменяют тени на основе ступенчатых изменений светлоты фона или тонкие границы — это структурно иной подход, а не копипаст.
- Решения по обработке фотографий и медиа. Как уже упоминалось выше, реальным фотографиям часто нужны обрамление, отступы или деликатная фоновая обработка, чтобы хорошо смотреться в тёмном контексте.
- QA по всем состояниям экрана, а не только по основному сценарию. Пустые состояния, ошибки, скелетоны загрузки, модальные окна, подсказки, состояния при наведении — каждое из них нужно визуально проверить в обеих темах. Это примерно удваивает время визуального тестирования, и именно эту часть сроки проекта чаще всего тихо забывают заложить в бюджет.
- Постоянный налог на поддержку. Каждую новую функцию, выпускаемую впоследствии, нужно проектировать и тестировать в обеих темах — навсегда. Это та часть затрат, которая накапливается: не изначальная разработка, а постоянное удвоение площади дизайна и QA для каждого будущего изменения.
Я прошу клиентов представить этот список, особенно последний пункт, прежде чем одобрять переключатель тёмной темы. Изначальная разработка — это проект. Поддержка — это постоянный налог на каждый будущий проект. Если данные об использовании или сценарий не оправдывают разовую затрату, они почти наверняка не оправдывают и постоянную.
Как на самом деле принять решение — вопросы, которые я задаю клиентам
Вместо того чтобы начинать с «хотите ли вы тёмную тему», я давно понял, что гораздо продуктивнее начать с вопросов о продукте и его пользователях и дать ответу сложиться естественным образом. Вот примерно последовательность, которую я прохожу на ознакомительном созвоне.
- Где и когда обычно используется продукт? Если честный ответ включает фразы вроде «поздно вечером», «в тускло освещённом помещении» или «подолгу, часами», это аргумент в пользу реализации. Если ответ — «в течение рабочего дня, в офисе», это аргумент против срочности.
- Что реально говорят данные об использовании, если они есть? Если у вас уже есть работающий продукт, проверьте, сколько пользователей имеют тёмную тему в настройках ОС и заходят на сайт без отдельной темы — большинство систем аналитики и некоторые CMS могут показать это через медиа-функцию prefers-color-scheme. У некоторых клиентов выяснялось, что менее 8% трафика работает в системной тёмной теме, что сразу переворачивает предположение «всем это нужно». Бывало и обратное — инструмент для разработчиков, где больше 60% визитов приходило с систем с тёмной темой, что само по себе формировало бизнес-кейс.
- Является ли ключевая ценность продукта визуальной/медийной? Фотография, видео, портфолио — скорее в пользу тёмной темы, поддерживающей контент, а не конкурирующей с ним. Формы, текстовая информация, процессы оформления заказа — скорее против.
- Какова реальная длительность сессии? Пятиминутные заходы не накапливают усталость глаз. Полуторачасовые рабочие сессии — накапливают. Этот единственный фактор, вероятно, предсказывает пользу для пользователя лучше любого другого.
- Кто конкретно это просит? Иногда это один активный опытный пользователь или личное предпочтение одного заказчика, а не широкая закономерность. Мне доводилось выяснять, что фраза «наши пользователи постоянно просят тёмную тему» сводится к двум обращениям в поддержку и собственной привычке основателя просматривать всё в тёмной теме на телефоне. Это полезная информация, но это не то же самое, что спрос.
- Можете ли вы позволить себе постоянные затраты на поддержку, а не только разработку? Если команда небольшая, а роадмап и так плотный, обязательство навсегда поддерживать QA для двух тем — это реальный компромисс в ущерб другим приоритетам, и его нужно взвешивать именно так.
- Действительно ли ваша айдентика бренда работает в тёмном исполнении? Некоторые цветовые системы и стили фотографии были созданы для светлого фона и действительно не переносятся без разработки палитры с нуля. Если бренд не переносится, это дополнительная затрата сверх всего остального.
Проговаривание этих вопросов вслух с клиентом обычно разрешает решение быстрее, чем любое количество споров о том, «стоит ли того» тёмная тема в абстрактном смысле. У абстрактной версии этого вопроса нет ответа. У конкретной версии, применённой к реальному продукту и аудитории, он почти всегда есть.
Как сделать всё правильно, когда ответ — да
Когда сценарий использования действительно оправдывает тёмную тему, вот процесс, которому я следую, чтобы инвестиция окупилась, а не превратилась в наполовину готовую вторую тему, которая через полгода тихо конфузит бренд.
Сначала стройте систему токенов, а не экраны
Прежде чем трогать отдельные экраны, определите семантическую систему цветовых токенов — background-primary, background-elevated, text-primary, text-secondary, border-subtle, accent, destructive и так далее — со значениями, заданными отдельно для светлой и тёмной темы. Каждый компонент дизайн-системы должен ссылаться на эти токены, а не на жёстко заданные hex-значения. Это и есть разница между поддерживаемой тёмной темой и разовым хаком: если новый экран правильно построен на токенах, он автоматически получает поддержку тёмной темы без каких-либо дополнительных дизайнерских решений.
Проектируйте тёмную палитру отдельно, по её собственным правилам
Сопротивляйтесь инстинкту просто инвертировать светлую палитру. Начните с почти чёрной, но не абсолютно чёрной базы (что-то вроде очень тёмного угольного или глубокого тёмно-синего цвета выглядит более премиально и менее резко, чем настоящий чёрный, и снижает эффект «гало», когда яркий текст будто светится или размазывается на чистом чёрном фоне, — а это реальная проблема читаемости для некоторых пользователей). Снизьте насыщенность и немного осветлите акцентные цвета, чтобы они сохраняли визуальный вес и контраст, не превращаясь в неон. Отнеситесь к этому как к отдельному небольшому дизайн-проекту со своим ревью и утверждением, а не как к проходу с фильтром.
Пересоберите систему уровней без теней
Используйте постепенные ступени светлоты для поверхностей, расположенных «над» базовым фоном — карточки, модальные окна, выпадающие списки — вместо теней, которые почти теряют визуальный эффект на тёмном фоне. Чистый подход — определённая шкала (background, surface-1, surface-2, surface-3), где каждая ступень немного светлее предыдущей, передавая глубину через тон, а не через тень.
Проверяйте каждое состояние, а не только экраны по умолчанию
Пройдитесь по состояниям hover, focus, active, disabled, error, success и empty отдельно в обеих темах. Отключённые состояния особенно склонны становиться невидимыми в тёмной теме, потому что серый приглушённый текст уже имеет низкий контраст на белом, а в тёмной теме то же относительное снижение может опустить его ниже порога читаемости вовсе.
Относитесь к изображениям как к отдельному направлению работы
Явно решите, как фотографии и иллюстрации ведут себя в тёмной теме: деликатные скруглённые контейнеры с небольшими отступами, мягкая внутренняя рамка или лёгкое виньетирование помогут избежать того, чтобы изображения выглядели парящими прямоугольниками на фоне тёмной пустоты. Для наборов иконок проверьте толщину обводки и цвет в обеих темах — тонкие однопиксельные линии, чёткие на белом, могут пропадать или выглядеть размытыми на тёмно-сером, в зависимости от сглаживания.
Тестируйте на реальном контенте и с реальными пользователями, а не на lorem ipsum
Проблемы тёмной темы любят прятаться в граничных случаях — длинный текст, который переносится иначе, таблицы данных с чередующимися цветами строк, графики со множеством категорий. Тестируйте с контентом, максимально приближенным к реальному, и если возможно, дайте нескольким реальным пользователям, которые действительно будут пользоваться тёмной темой, провести в ней настоящее время перед релизом, а не полагайтесь на пятиминутный взгляд команды дизайнеров.
Разумно задавайте тему по умолчанию, но всегда давайте выбор
Уважать настройку операционной системы prefers-color-scheme в качестве значения по умолчанию — хорошая практика: это значит, что ваше приложение соответствует режиму, который пользователь уже выбрал как предпочтительный для всего устройства, и это ощущается уважительно, а не навязчиво. Но всегда предусматривайте явное переопределение внутри приложения, потому что немало людей хотят, чтобы система была тёмной, а конкретное приложение — светлым (или наоборот), именно по тем эргономическим причинам, что обсуждались ранее.
Ни один из этих шагов не экзотичен. Это просто то, что требуется, чтобы сделать «как следует» вместо «как побыстрее». Разрыв между этими двумя подходами обычно и есть то, что отличает тёмную тему, которая ощущается нативной и продуманной, от той, что выглядит как запоздалая мысль с инвертированными цветами, наброшенными поверх существующего макета, — и пользователи замечают эту разницу, даже если не могут точно сформулировать, что не так.
Как сказать «нет», не выглядя противником прогресса
Самая сложная часть во всём этом разговоре — не дизайнерская работа, а дипломатично сообщить клиенту, что функция, которой он воодушевлён, сейчас не является правильным приоритетом. Мне помогает несколько вещей.
Во-первых, я никогда не формулирую это как «тёмная тема — это плохо» или «она вам не нужна». Я формулирую это как последовательность приоритетов: это хорошая функция, вот свидетельства того, когда она окупает себя, и вот что я предложил бы приоритизировать вместо неё с учётом текущих данных и бюджета, с тёмной темой в качестве сильного кандидата на более поздний этап, когда появятся данные об использовании, подтверждающие спрос. Это сохраняет интуицию клиента нетронутой — он не ошибается, считая тёмную тему в целом ценной, — но при этом перенаправляет немедленное распределение ресурсов на то, что лучше подтверждено их конкретной ситуацией.
Во-вторых, где возможно, я показываю, а не просто рассказываю. Быстрый, грубый макет — их реальная товарная фотография или цвета бренда, наброшенные на тёмный фон, сделанный за двадцать минут, а не отполированный комп — часто демонстрирует проблему несоответствия быстрее, чем любой словесный аргумент. Увидев, как их собственное главное изображение выглядит выцветшим, а фирменный оранжевый становится неприятно резким на угольном фоне, люди обычно быстро и без трений корректируют ожидания, потому что аргумент приводит их собственный контент, а не моё мнение.
В-третьих, я особенно опираюсь на формулировку о поддержке, потому что именно её заказчики склонны недооценивать, и именно она на самом деле важна в долгосрочной перспективе. Основатели и руководители продукта мыслят в терминах следующего релиза; они часто интуитивно не закладывают в расчёт тот факт, что каждое UI-решение, принятое после этого момента, нужно будет проверять на соответствие обеим темам — всегда. Назвать это явно — «это удваивает площадь дизайна и QA для каждой будущей функции, бессрочно» — обычно срабатывает, потому что это конкретная, продолжающаяся операционная затрата, а не абстрактное мнение дизайнера.
Наконец, я оставляю дверь открытой, а не закрываю её навсегда. Проверка аналитики по prefers-color-scheme после запуска, возврат к решению через три или шесть месяцев с реальными данными об использовании и отношение к этому как к отложенному, а не отклонённому решению обычно сохраняют сотрудничество конструктивным. Несколько моих клиентов, изначально отложивших тёмную тему, вернулись к ней позже — уже с реальными данными на руках, — и в этот момент её реализация оказывалась гораздо более уверенным и хорошо спланированным проектом, чем была бы спонтанная добавка во время изначальной разработки.
Тёмная тема — хорошая функция. Просто она не функция по умолчанию, и отношение к ней как к обязательной — это способ, которым команды в итоге тратят реальный бюджет на то, что эффектно смотрится на скриншоте в портфолио, но ничего не даёт людям, реально пользующимся продуктом. Правильный вопрос никогда не звучал как «должны ли сайты иметь тёмную тему». Он звучит так: «нужна ли она конкретно этому продукту, для этой конкретной аудитории, в этом конкретном контексте использования» — и у этого вопроса каждый раз разный ответ, именно поэтому его стоит задавать по-настоящему, а не действовать по умолчанию так, как это делает остальная индустрия в этом году.
