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