Когда название функции приходится объяснять: как нейминг усложняет цифровой продукт
В цифровом продукте может быть несколько уровней сущностей: «Пространства», внутри них «Проекты», а в каждом проекте — «Потоки». Команда быстро привыкает к такой системе и свободно обсуждает права, настройки и участников. Но новый пользователь видит эти слова впервые. Ему нужно понять, что именно создать, чтобы поставить коллегам задачу, пригласить сотрудника или настроить рабочий процесс.
Название может хорошо звучать, соответствовать внутренней архитектуре и нравиться команде. Однако пользователь сталкивается не с архитектурой, а с задачей. Если перед действием ему приходится изучать специальный словарь, продукт получает дополнительный уровень сложности ещё до знакомства с основными возможностями.
Это не означает, что все термины нужно заменять на самые обычные слова. Собственное название бывает полезно: оно может обозначать новую сущность, объединять несколько функций или помогать различать близкие объекты. Важно другое — какую работу выполняет термин и сколько усилий требуется человеку, чтобы понять его смысл.
Команда знает функцию, пользователь сначала видит слово
Сотрудники начинают обсуждать название после того, как уже разобрались с функцией. Они знают её ограничения, связи с другими объектами и возможные сценарии использования. Поэтому новое слово быстро прикрепляется к знакомому понятию и через несколько недель начинает казаться очевидным.
У нового пользователя порядок обратный: сначала он видит термин, а затем пытается догадаться, что за ним стоит. «Поток» может быть лентой событий, этапом обработки заявки, набором задач или передачей данных. Каждая трактовка выглядит правдоподобно, пока человек не откроет нужный раздел. Поэтому обсуждать название только внутри команды недостаточно: сотрудники проверяют, насколько оно соответствует известной им функции, а пользователь пытается восстановить функцию по одному слову.
Сначала нужно договориться о самой сущности
Спор о нейминге иногда скрывает более серьёзную проблему — команда по-разному представляет устройство продукта. Для дизайнера «Проект» может быть набором задач, для разработчика — контейнером данных с отдельными правами, а для менеджера — рабочим пространством конкретного клиента. Различия проявляются, когда нужно объяснить, что произойдёт при переносе, архивировании или удалении объекта.
До выбора названия полезно описать сущность без её текущего имени:
- что в ней находится;
- зачем пользователь её создаёт;
- может ли она существовать отдельно;
- чем она отличается от соседних объектов;
- какие действия с ней доступны.
Отдельно стоит проверить пограничные случаи: можно ли включить один набор задач в несколько проектов, добавить участника в разные пространства или передать объект другому владельцу. Если ответы расходятся, красивое название не исправит модель продукта, а лишь замаскирует противоречие.
Не каждый элемент интерфейса должен быть частью бренда
У разных текстов в продукте разные задачи. Название сервиса помогает отличить его от конкурентов, заголовок раздела — найти нужное место, а текст кнопки — понять действие. Ошибка возникает, когда от каждого пункта меню требуют такой же оригинальности, как от имени самого продукта.
Например, раздел с инструкциями можно назвать «Академией решений». Но если внутри находятся справочные статьи о настройке уведомлений и ответы на частые вопросы, пользователь, скорее всего, будет искать «Помощь» или «Справку». Необычное имя создаёт дополнительное обещание, которое содержание раздела может не поддерживать.
Характер продукта можно передавать через тон объяснений, примеры, иллюстрации и названия самостоятельных сервисов. Но в местах выбора важнее обеспечить понимание. Особенно это касается действий с последствиями: выдачи доступа, подключения услуги, публикации материала или удаления данных.
Метафора полезна, пока её не приходится расшифровывать
Папки, корзины и рабочие столы работают как интерфейсные метафоры, потому что пользователь уже представляет связанные с ними действия. В папку можно положить объект, из корзины — восстановить его, если продукт поддерживает такую возможность. При этом метафора формирует ожидания, которые интерфейс должен оправдывать.
С новым словом такую опору ещё предстоит создать. «Капсула» может обозначать набор файлов с ограниченным сроком доступа. После объяснения название выглядит логичным, но само по себе не сообщает ни состав, ни срок хранения, ни правила доступа. Поэтому термин лучше проверять вместе с коротким пояснением: например, «Капсула — файлы по временной ссылке». Если описание появляется только после перехода, исходная проблема остаётся.
Похожие термины должны помогать различать объекты
Иногда каждое слово по отдельности кажется знакомым, но система в целом остаётся непонятной. «Группа», «Команда», «Организация» и «Рабочая область» могут обозначать разные уровни доступа и совместной работы. Пользователь примерно понимает смысл слов, но не знает, как именно они соотносятся в конкретном сервисе.
Проверять такие термины нужно не вопросом «Вам понятно слово?», а через реальные задачи. Где создать работу для нового клиента? Куда добавить подрядчика, чтобы он видел только часть данных? Что архивировать после завершения заказа? Значение названия раскрывается в момент, когда от него зависит решение.
Один объект не должен называться по-разному в разных каналах
Одна и та же функция может называться на лендинге «Автоматическими сценариями», в приложении — «Правилами», в справке — «Триггерами», а на демонстрации менеджер назовёт её конструктором автоматизации. Каждое слово может быть оправдано контекстом, но пользователю приходится самостоятельно устанавливать связь между ними.
Из-за этого он может не найти функцию в интерфейсе после чтения описания тарифа или решить, что нужная возможность ему недоступна. Дословное совпадение всех формулировок не обязательно, но связь должна быть явной: «Автоматизируйте обработку заявок с помощью правил». В таком случае «Правила» остаются устойчивым термином, а предложение объясняет пользу.
Подсказка не заменяет понятное название
Значок вопроса и всплывающая подсказка помогают уточнить детали, но не всегда решают проблему. Чтобы открыть подсказку, человек должен заметить непонимание и захотеть потратить время на изучение термина. Ещё сложнее ситуация, когда пользователь уверенно понимает слово неправильно.
Например, «Публикация» может ассоциироваться с сохранением материала внутри команды, хотя на самом деле действие открывает его по внешней ссылке. В подобных случаях основное назначение и важные последствия нужно показывать непосредственно перед действием. Короткое описание помогает выбрать функцию, а подробная справка может раскрывать ограничения, права и поведение объекта при изменениях.
Как проверять нейминг в продукте
Для проверки стоит выбрать несколько сценариев, где от термина зависит действие: пригласить внешнего специалиста, найти сохранённый набор настроек или подготовить документ для клиента. Затем нужно показать интерфейс представителям аудитории и попросить выполнить задачу.
Важно наблюдать не только за тем, куда человек нажал. Нужно выяснить, что он ожидал увидеть после действия и почему выбрал именно этот раздел. Случайный переход в правильное место не доказывает понятность, если пользователь рассчитывал на другой результат. Полезно также сравнивать людей с разным опытом: администратор и сотрудник, который заходит в систему раз в неделю, могут по-разному трактовать один термин.
Обращения в поддержку дают дополнительный материал для проверки словаря. Пользователь может называть уже существующую функцию иначе, путать два объекта или воспринимать изменение статуса как удаление. Однако одного обращения недостаточно, чтобы обвинить термин: проблема могла быть связана с правами, незаметной кнопкой или другой версией интерфейса. Надёжнее анализировать повторяющиеся неверные предположения и восстанавливать весь путь пользователя.
Хороший нейминг не обязан быть необычным. Его задача — помогать человеку ориентироваться, выбирать действие и понимать последствия. Если термин требует длинного объяснения в каждом месте интерфейса, стоит проверить не только формулировку, но и саму модель продукта. Иногда более понятное слово решает проблему, а иногда нужно сначала договориться о том, что именно продукт предлагает пользователю.
