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