У матеріалі розбирається підбір послідовних і зрозумілих назв за підходом Віталія Фрідмана (Smashing Magazine) і авторів, яких він цитує. Фокус — на практичних інструментах і принципах для дизайнерів, розробників та продуктових команд.
Чому називання так «болить» саме в цифрових продуктах
Мова, якою називаються сутності в команді та інтерфейсі, визначає, як про них думають, як про них сперечаються й як їх розвивають. Коли назви:
- надто загальні («box», «item», «thing»), — незрозуміло, що саме мається на увазі;
- надто конкретні («green-small-rounded-button-on-homepage»), — неможливо повторно використати й масштабувати;
— команда швидко потрапляє у хаос: одна й та сама річ має різні назви в дизайні, в коді, у продуктових документах та у користувачів.
Підбір адекватних імен — окрема робота. Далі — практичні інструменти та кроки, які різні автори використовують для роботи з назвами у конкретних зонах: класи, кольори, шари, токени, фічі, компоненти, продукти.
1. Імена для класів, станів і патернів UI
Проблема
HTML-класи, назви функцій і компонентів часто виростають «як попало»: щось від дизайнера, щось від бекенду, щось «тимчасово». У підсумку:
- важко зрозуміти, що робить елемент за його назвою;
- важко знайти та перевикористати готове рішення;
- з часом проект обростає дублями («card», «tile», «teaser» для одного й того ж).
Рішення: тематичні словники та «дивитися вбік»
Віталій Фрідман радить не винаходити все з нуля, а підключати тематичні словники і «бічне» мислення. Сервіс classnames.paulrobertlloyd.com дає списки слів, згрупованих за темами: поведінка, схожість, порядок, групування, асоціації, а також колекції з доменів мистецтва, архітектури, моди, видань тощо.
Практичний прийом:
- коли потрібно назвати щось абстрактне (стан, шаблон, тип блоку), скористатися такою підбіркою як джерелом варіантів;
- перевірити, чи є слово однозначним у контексті продукту — без зайвих асоціацій;
- за можливості уникати в назвах суто візуальних деталей (про це далі).
2. Як називати кольори: від «#0F62FE» до зрозумілих імен
Проблема
У дизайні й коді кольори часто фігурують як «primary», «secondary», «blue-1» чи просто хеш-значення. З часом:
- важко згадати, що це за відтінок;
- немає зв’язку з реальними асоціаціями (теплий, холодний, попереджувальний тощо);
- зміна бренду або теми перетворюється на суцільний пошук і заміну.
Рішення: словник кольорів та пошук імен по зразку
Девід Ерне підтримує репозиторій color-names з десятками тисяч (на момент опису — близько 30 000) унікальних назв, зібраних з різних джерел та внесків користувачів. На базі цього словника працюють інструменти:
- parrot.color.pizza — сервіс, що підбирає назву для конкретного кольору;
- color picker і пошук по назвах на CodePen.
Практичний сценарій використання:
- Взяти бренд-колір (hex або RGBA) з вашої системи.
- Прогнати через Color Parrot або color picker із репозиторію.
- Подивитися, які імена пропонуються — і взяти як основу для внутрішньої номенклатури або натхнення.
Ці назви не обов’язково переносити один в один у продукт, але вони дають послідовну систему позначень, з якою легше працювати в команді.
3. Шари, групи, компоненти: структура і логіка замість «final_v3»
Проблема
У Figma, Sketch чи іншому редакторі структуру файлу часто руйнують назви типу «frame 1», «new group», «button copy 3» тощо. Для великих систем це боляче:
- складно шукати потрібний компонент;
- новим членам команди важко розібратися в системі;
- передача у розробку сповільнюється.
Рішення: правила ієрархії і заборона на «візуальні» назви
Хав’єр Куельйо сформулював набір рекомендацій з найменування шарів, груп та компонентів. Ключові принципи, які передає Віталій Фрідман:
- Логічна структура — ім’я відображає місце в ієрархії та роль (наприклад, «Form / Field / Input / Email»).
- Стислість — чим коротше й ясніше, тим краще, без зайвих слів.
- Зрозумілість усім — не локальний жаргон окремого дизайнера, а терміни, які поділяє команда.
- Без прив’язки до зовнішнього вигляду — замість «Green button» краще «Button / Primary / Success», щоб назва жила довше за конкретний колір.
У своїх гайдах Куельйо наводить «do’s and don’ts» для назв розмірів, кольорів, груп, шарів і компонентів. Ідея — щоб, читаючи ім’я, будь-хто з команди розумів функцію та місце в системі, а не лише зовнішню форму.
4. Дизайн-токени та змінні: кейси Intuit і Vodafone
Проблема
У великих організаціях із кількома продуктами й брендами звичайна схема «primary / secondary / danger» швидко ламається. Токени дублюються, важко зрозуміти, де вони використовуються, локальні команди вигадують свої правила.
Кейс Intuit: гнучка таксономія токенів
Для продуктів на кшталт Mailchimp, QuickBooks, TurboTax та Mint команда Intuit зіткнулася з тим, що проста схема токенів не витримує складність. Нейт Болдуін описує у кейсі, як будувалася більш гнучка таксономія.
Ключові ідеї з опису:
- Перед розробкою нової системи команда чітко зафіксувала больові точки старої: де і чому назви не працюють.
- Були визначені критерії до нового підходу: масштабованість між продуктами й брендами, читабельність, можливість зрозуміти призначення токена з назви.
- Токени поділялися на логічні рівні (брендові, базові, семантичні тощо), щоб не змішувати в одному шарі колір бренду й конкретну роль у UI.
На базі цього Intuit створив систему, яка виходить за межі однієї теми і слугує фундаментом для різних продуктів компанії.
Кейс Vodafone: «карта таксономії змінних»
Команда Vodafone UK Design System опублікувала у Figma Variables Taxonomy Map. Це спроба явно показати «анатомію» токена в складній системі з кількома брендами й темами.
На карті видно:
- чотири колекції, потрібні для роботи системи;
- зв’язки між токенами — від брендових і примітивів до семантичних і сторінкових рівнів;
- як ім’я токена дозволяє зрозуміти, де він використовується і що означає.
Цей підхід спирається на роботу Нейтона Кертіса про найменування дизайн-токенів і демонструє, як теоретичні принципи перетворюються на практичну карту для всієї організації.
Інструмент від Роміни Кавчич: гід + конструктор назв
Роміна Кавчич створила онлайн-інструмент Name Design Tokens Guide + Builder, який поєднує:
- коротке навчання — як працюють токени й на що звертати увагу при найменуванні;
- конфігуратор власної структури назв: компоненти, категорії, стани, ролі.
Додатково авторка ділиться Design Token Names Inventory — таблицею з чотирирівневою структурою для огляду всіх токенів, де можна додавати рядки, теми та режими й фільтрувати сутності.
5. Назви UI-компонентів і поведінок
Проблема
Один і той самий компонент у різних системах може називатися по-різному: «Accordion», «Disclosure», «Expander». Те саме — з банерами, toast-повідомленнями, тегами тощо. Це ускладнює:
- орієнтацію в чужих дизайн-системах;
- узгодження термінів між командами;
- перенос знань з одного продукту в інший.
Рішення: дивитись на реальні системи
Іейн Бін зібрав Component Gallery — колекцію UI-компонентів із реальних дизайн-систем. Для кожного типу елементу там є:
- приклади реалізацій в різних системах;
- список альтернативних назв, якими цей компонент називають інші команди.
Це корисно, коли:
- ви запускаєте власну систему й не хочете вигадувати терміни з нуля;
- потрібно обрати найчастіше вживану або найменш неоднозначну назву;
- ви пояснюєте новим членам команди, як різні компанії називають подібні патерни.
Додатково згадується Name That UI — візуальний словник поширених UI-компонентів, де можна зіставити «як це виглядає» і «як це зазвичай називають».
6. Назви функцій і фіч: мова користувача проти мови команди
Проблема
Навіть корисні фічі можуть мати низьке використання не через UX, а через те, що:
- їх важко знайти (назва не привертає увагу, виглядає «службовою»);
- зі самої назви незрозуміло, навіщо це й що відбудеться;
- назва відображає внутрішню термінологію, а не слова користувача.
Підхід Ерін Геннон: назва як відповідь на потребу
Ерін Геннон у практичному гіді описує, як підібрати назву, яку люди зможуть помітити, зрозуміти й вплести у свій робочий процес. Кілька опорних тез, на які посилається Віталій Фрідман:
- Від потреб, а не від рішення. Назва повинна підкреслювати результат або job-to-be-done («Schedule send», «Smart fill»), а не технічний механізм.
- Мова користувача. Краще попросити людей описати функцію своїми словами — і опертися на їхні формулювання.
- Ланцюжок прийняття. Фіча спочатку має бути знайдена, потім зрозуміла, потім спробувана, вивчена й вбудована у звичний сценарій. Назва — лише перший, але критичний крок.
Тобто «що ми напишемо на кнопці або в меню» безпосередньо впливає на adoption, а не є вторинною деталлю.
7. Назви продуктів і сервісів: коли ставки особливо високі
Проблема
Назва продукту чи сервісу повинна одночасно:
- бути юридично безпечною й доступною з точки зору доменів/торгових марок;
- не мати небажаних конотацій на ключових ринках;
- узгоджуватися зі стратегією бренду й продуктового портфеля;
- бути хоча б частково промовистою або запам’ятовуваною.
Це вже виходить за рамки суто UX чи розробки й зачіпає бренд та маркетинг.
Рішення: структурований репозиторій інструментів
Проєкт Onym — це відкритий репозиторій інструментів і ресурсів для неймінгу продуктів і сервісів. Там зібрані:
- методики брейнштормів і неймінг-спринтів;
- чек-листи для валідації назв;
- етімологічні довідки, приклади, обережні історії («як не треба»);
- посилання на агенції, що спеціалізуються на неймінгу, та книги.
Ідея — замість хаотичного пошуку в інтернеті мати одну стартову точку, яка систематизує підходи до називання.
8. Швидкі закладки: де шукати приклади й методики
Віталій Фрідман підсумовує добіркою корисних посилань для різних типів назв (усі URL — з оригіналу):
| Що називаємо | Ресурс |
|---|---|
| Текст на кнопках і UI-копі | NN/g on UI copy |
| CSS/HTML-класи | classnames.paulrobertlloyd.com |
| Кольори | parrot.color.pizza і color-names |
| Дизайн-токени | кейс Intuit, namedesigntokens.guide |
| Фічі продукту | Shopify Polaris naming guide, стаття Ерін Геннон |
| Іконки | Iconography guide |
| Шари, групи | goodpractices.design |
| Назви продуктів | guide.onym.co (Onym) |
| UI-компоненти | component.gallery |
| UI-поведінки | namethatui.com |
| Змінні, токени | Vodafone UK Variables Taxonomy Map, naming-cheatsheet на GitHub |
| Загальна термінологія UI | Moccu’s naming convention framework |
9. Підсумок: узгоджена мова як «невидимий» елемент системи
Ключовий висновок, який робить Віталій Фрідман разом із авторами, на яких він посилається: «правильне» ім’я — це те, яке однаково розуміють команда і користувачі. Часто низька adopion нового елементу або фічі пов’язана не з UX чи технічною якістю, а з тим, що:
- дизайнери, девелопери, продакт-менеджери та користувачі говорять різними «діалектами» про одну й ту ж річ;
- у системі залишені нерозв’язані конфлікти назв, які плутають і новачків, і ветеранів.
Рекомендація авторів — відстежувати такі конфлікти, складати з них беклог і планомірно розгрібати: найчастіше зміна назви обходиться дешевше, ніж переробка інтерфейсу, але здатна суттєво знизити фрустрацію та покращити роботу команди.
Джерело: Vitaly Friedman — Smashing Magazine