Проблема страницы настроек

Страница настроек — самый честный экран вашего продукта. За один скролл она показывает, какие именно решения команда отказалась принимать. Каждый переключатель — окаменевший спор. Каждая вложенная вкладка — «разберёмся позже», в которое так никто и не разобрался.

Большинство страниц настроек — свалки. Три года переключателей, набросанных инженерами, не умевшими сказать «нет», маркетологами, которым нужен был opt-out, и продакт-менеджерами, которые принимали «сделаем настраиваемым» за «решим». В итоге получается экран, который команде стыдно показывать на демо, а пользователю страшно трогать.

Это аргумент за то, чтобы считать настройки полноценной продуктовой поверхностью. Пять архетипов, шесть правил, реальные примеры из продуктов, которыми вы уже пользуетесь, и аудит, который стоит провести перед релизом.

Настройки — экран, который выдаёт команду

Разрастание настроек — опережающий индикатор организационной дисфункции. Когда команда не может договориться о значении по умолчанию, переключатель уходит в релиз. Когда клиент жалуется и никто не хочет возражать, переключатель уходит в релиз. Когда PM не может выбрать между двумя сценариями, оба выходят за настройкой.

Через полгода никто не помнит, зачем нужна половина переключателей. Чтобы убрать настройку, нужно принять то самое решение, которого команда избежала в первый раз, поэтому настройки только накапливаются. Посмотрите на любой продукт старше трёх лет, и вы сможете пересчитать непринятые решения прямо в дереве настроек.

Пять архетипов плохих страниц настроек

Плохие страницы настроек не случайны. Они укладываются в пять паттернов, и каждый из них — конечная точка определённого вида организационной лени.

1. Свалка

Хронологическое накопление. Настройки появляются в порядке добавления и никогда не группируются. Новейший feature flag соседствует с настройкой уведомлений 2019 года и бета-переключателем, который должен был стать стабильным два года назад. Cursor сползает в это состояние. Каждый релиз добавляет по три переключателя во вкладку General, и теперь General — это скролл на 40 строк несвязанных решений. Свалка — состояние по умолчанию любой страницы настроек, которой никто активно не занимается.

2. Таблица

Настройки по алфавиту. Команда сдалась в вопросе иерархии и доверила сортировку системе. Все переключатели одного веса, все строки одинаковые. Настройки уведомлений Slack живут именно здесь. Звук, бейдж, мобильные, канал, ключевое слово, «не беспокоить», расписание, кастомные: всё сплющено в стену без истории о том, какие из них важны.

3. Тупик

Настройки, которые ничего видимого не меняют. Пользователь включает «Компактный режим», а экран выглядит так же. Включает «Расширенные функции», и ничего не появляется. Редизайн «Системных настроек» Apple в macOS выпустил целое поколение таких: настройки, молча переопределённые другими настройками, настройки, требующие перезапуска, о котором экран не упоминает. Тупик учит пользователей, что настройки не работают, и они перестают доверять остальному продукту.

4. Лабиринт

Десять уровней вложенных вкладок. Настройки зарыты под категорией, подкатегорией, раскрывающимся блоком «Расширенные», модальным окном. Пользователь знает, что переключатель существует, уже включал его раньше и всё равно не может найти. Старая Jira построила на этом карьеру: проект, доска, воркфлоу, схема, схема прав, схема уведомлений, и всё это отдельные деревья.

5. Музей

Настройки, которых три года никто не касался. Они существуют, потому что удалять их страшно. Они ссылаются на функции, закрытые в 2023 году. В каждом устаревшем SaaS-продукте есть крыло музея, а цена — обещание команды поддерживать код, который должен был умереть два рефакторинга назад.

Настройки — продуктовая поверхность, а не кладовка

Большинство команд считают настройки местом, где подчищается всё остальное в продукте. Эта рамка и есть баг. Настройки — одна из самых рычажных поверхностей продукта, и сильнейшие команды проектируют их именно так.

Настройки выражают взгляд продукта на пользователя. Они сообщают сразу четыре вещи. Насколько команда доверяет пользователю. Каким контролем команда готова поделиться. Какими команда считает правильные значения по умолчанию. Уважает ли команда время пользователя настолько, чтобы проектировать для 5%, меняющих дефолты, не наказывая 95%, которые этого не делают.

Linear спроектировал настройки как единую поверхность поиска, на command-K, почти без вложенных вкладок. Скрытое послание: пользователь компетентен, поиск быстр, команда проделала работу по иерархии, чтобы пользователю не пришлось. Notion пошёл в противоположную сторону и выиграл так же. Настройки живут рядом с тем, на что влияют. Настройки страницы на странице. Настройки базы данных на базе данных. Контекстные настройки растворяются в работе.

Vercel использует иерархию по областям: проект, команда и аккаунт, каждая чётко подписана и привязана к ресурсу, которым управляет. Stripe Dashboard выбирает ориентацию на действие: каждый экран — «сделай это», а не «настрой это предпочтение». Настройки репозитория на GitHub идеально задают области видимости с чётким разделением между владением репозитория, организации и аккаунта.

Шесть правил, которые решают судьбу любой страницы настроек

Эти правила накапливаются. Выполните пять из шести, и страница читается как продуктовая поверхность. Выполните три, и за год она сползёт в один из архетипов.

Правило 1: сначала поиск

Иерархия — запасной вариант, а не основной. Пользователь знает название настройки раньше, чем знает, под какой вкладкой она лежит. Command-K в Linear выдаёт настройки как полноценный тип результата. Figma добавила поиск по настройкам, и время до нужного переключателя сразу сократилось. Если на вашей странице настроек нет строки поиска, вы ставите на то, что пользователи запомнят вашу информационную архитектуру. Не запомнят.

Правило 2: контекстное размещение вместо центрального реестра

Настройки живут рядом с тем, на что влияют. Настройки уведомлений в панели уведомлений. Настройки страницы на странице. Центральная страница настроек подходит для вопросов уровня аккаунта вроде профиля, оплаты и сессий и почти ни для чего больше. Notion — золотой стандарт. Правая панель Figma выполняет ту же работу для свойств слоёв, фреймов и компонентов.

Правило 3: разумные значения по умолчанию, которые заслуживают доверия

Каждый дефолт — продуктовое решение. Он выражает, что команда считает правильным ответом для 80% пользователей. Если дефолт неверен, переключатель — это пластырь. Дефолты уведомлений Slack исходят из того, что вы хотите быть на связи, а не в тишине. Для медианного пользователя ставка верна. Большинство команд сначала проектируют переключатель, а дефолт выходит сам собой. Порядок неверный.

Правило 4: прогрессивное раскрытие вместо плоского разрастания

Пользователь должен видеть пять настроек, важных для 90% людей. Остальные 50 лежат на клик глубже, за понятным элементом «Расширенные». Настройки проектов Vercel делают это отлично. Первый экран показывает домен, переменные окружения и защиту деплоя. Переопределения сборки, конфиги функций и rewrites живут в разделе «Расширенные».

Правило 5: никаких сирот

Каждая настройка принадлежит группе. У каждой группы есть название. Тест на сирот: прочитайте любую подпись вслух без другого контекста. Если дизайнер вашей команды не может сказать, что делает переключатель, это сирота. Сироты — рассада Музея.

Правило 6: каждая настройка отрабатывает своё место

Настройка — это контракт. Команда обязуется поддерживать её, документировать, тестировать и рассуждать о её взаимодействии со всеми остальными настройками навсегда. Большинство настроек не могут платить эту аренду. Отношение по умолчанию к любой новой настройке должно быть «нет». Хорошие команды убирают больше настроек, чем выпускают.

Антипаттерны, сигналящие о более глубокой проблеме

Три паттерна убивают больше страниц настроек, чем все остальные вместе взятые. Каждый — симптом того, что проблема не в экране, а в команде за ним.

Настройки как замена продуктовым решениям. Команда не смогла договориться между opt-in и opt-out, поэтому выпустила переключатель. Пользователь наследует неразрешённый спор. Если на стендапе вы слышите «давайте сделаем настраиваемым», вы наблюдаете формирование этого антипаттерна. Подробнее об этом в материале о намеренном проектировании трения.

Настройки, компенсирующие плохой дизайн. Переключатель «компактный режим», потому что плотность по умолчанию слишком рыхлая. Переключатель «высокая контрастность», потому что фирменные цвета не проходят проверку доступности. Переключатель «классический вид», потому что редизайн не приняли. Каждый из них — настоящее исправление, наряженное в опцию. Правильный путь: с первого раза корректно спроектировать плотность, контраст и виды.

Настройки, которые никто не может объяснить одним предложением. Если дизайнер не может описать, что делает настройка, что меняется при переключении и для кого она, настройка не должна выходить. Проведите этот тест до того, как новый переключатель попадёт в кодовую базу.

Аудит страницы настроек

Пропустите каждую страницу настроек через эти семь вопросов. Если уверенное «да» меньше чем на шесть, страница не готова.

1. Может ли пользователь найти любую настройку меньше чем за пять секунд? Если нет, на странице нет поиска или сломана иерархия.
2. Есть ли у каждой настройки описание в одно предложение, понятное не инженеру? Если подпись требует объяснения инженера, ей не место на продуктовой поверхности.
3. Даёт ли переключение видимый и мгновенный эффект? Скрытые изменения состояния убивают доверие.
4. Сгруппированы ли настройки по задачам пользователя, а не по командам-разработчикам? Страница, организованная по тому, какая команда владеет функцией, — это внутренний артефакт, протекший в продукт. Группируйте по цели пользователя.
5. Обоснованы ли дефолты письменно где-нибудь? Команда должна уметь указать на документ, решение по визуальной иерархии или принцип бренда. Если дефолт — «что инженер выставил во время спринта», страница не готова.
6. Можно ли убрать половину настроек так, чтобы пользователь не заметил? Если да, сделайте это. Музей тяжелее, чем думает команда.
7. Выглядит ли страница и ощущается ли как остальной продукт? Прочитайте её рядом с вашими принципами дизайна лендингов. Если бренд разваливается, страница настроек не соответствует бренду.

Команда, проводящая этот аудит дважды в год, выпускает поверхность настроек, от которой пользователи не вздрагивают. Команда, которая не проводит его никогда, рано или поздно выпускает такую страницу настроек, что она становится рекрутинговым инструментом для конкурентов.

Выберите принцип, затем прорежьте страницу

Настройки — это мировоззрение команды, застывшее в переключателях. Хорошие команды относятся к странице как к полноценному флоу, с тем же мастерством, которое вкладывают в онбординг, дашборд и маркетинговый сайт.

Самый быстрый способ починить страницу настроек — не редизайн. Это удалить половину. Уберите каждую настройку, не прошедшую тест на сирот, тест одного предложения и тест «заслуживает ли место». То, что останется, и есть хребет настоящей поверхности настроек.

Связь с пустыми состояниями не случайна. Оба экрана показывают, во что верит команда, когда на экране нет ничего, что отвлекало бы от этого. Та же дисциплина проявляется в принципах веб-дизайна.

Частые вопросы

Сколько настроек должно быть в продукте?

Как можно меньше. Каждая настройка — контракт, который команда поддерживает вечно. Отношение по умолчанию к любой новой настройке должно быть «нет». Если команда не может обосновать настройку одним предложением, назвать пользователя, которому она служит, и описать, что видимо меняется при переключении, настройка не должна выходить.

Где в продукте должны жить настройки?

Рядом с тем, на что они влияют, а не в центральном крыле настроек. Настройки страницы на странице. Настройки рабочего пространства в рабочем пространстве. Настройки уведомлений в панели уведомлений. Центральная страница настроек подходит для вопросов уровня аккаунта вроде оплаты, профиля и сессий и почти ни для чего больше.

Как почистить страницу настроек с годами накопленных переключателей?

Проведите аудит, затем удаляйте. Сгруппируйте каждую настройку по задаче пользователя. Определите сирот, тупики и музейные экспонаты. Уберите нижние 30% за первый проход и следите за обращениями в поддержку. Если никто не жалуется, уберите ещё 20%.

Проектируйте страницу настроек как главную

Страница настроек — не подвал. Это комната, в которой живут ваши продвинутые пользователи и по которой вас оценивают новые. Относитесь к ней как к главной странице, онбордингу, дашборду. Применяйте то же мастерство. Выпускайте с той же убеждённостью.

Если вам нужна команда, которая проектирует страницу настроек как остальной продукт, а не наследует её из бэклога, наймите Brainy. Мы проектируем настройки как полноценный флоу, с дисциплиной, которая держит страницу компактной, а переключатели заставляет отрабатывать своё место.