27 KiB

Raw Blame History

Словарь терминов проектирования

UX · UI · IA и смежные понятия

Контекст: HR system / Платформа Цифровых Сервисов клиники им. Е. Н. Оленевой

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

Файл живой: добавляйте сюда термины, которые регулярно всплывают в обсуждениях.

1. Три основных слоя проектирования

Три понятия, которые часто путают друг с другом. Это не синонимы и не одно и то же — это три разных профессиональных взгляда на один и тот же продукт.

UX (User Experience) — опыт взаимодействия / пользовательский опыт

Совокупность ощущений пользователя от взаимодействия с продуктом: насколько просто понять, как достичь цели, насколько быстро это получается, насколько мало раздражения по дороге. UX — это про задачу пользователя, а не про конкретный экран.

Пример из HR system: HR-менеджер хочет назначить тест 50 сотрудникам отделения. Хороший UX — он делает это в три клика через фильтр по отделу. Плохой UX — он скроллит список из 147 человек и отмечает чекбоксами вручную.

UI (User Interface) — пользовательский интерфейс

Видимая и кликабельная часть продукта: кнопки, поля, цвета, иконки, типографика, состояния (наведение, фокус, ошибка). UI — это про то, как продукт выглядит и как откликается на действия.

Пример из HR system: Кнопка «Сохранить черновик» на странице теста — её цвет, размер, скруглённые углы, текст внутри, реакция на наведение курсора — это всё UI.

IA (Information Architecture) — информационная архитектура

Структура продукта на уровне «что где лежит и как связано»: какие есть разделы, какие сущности живут внутри, по какой логике пользователь переходит с одной страницы на другую. IA — это скелет, на который потом натягиваются UX и UI.

Пример из HR system: Решение «авторская работа над тестом, назначение и отчётность — это три разных раздела меню, а не один длинный аккордеон» — это IA-решение.

2. Исследования и работа с пользователем

Целевая аудитория — target audience

Группы людей, для которых проектируется продукт. У каждой группы своя задача и контекст использования.

Пример из HR system: В вашей системе четыре аудитории: сотрудник, руководитель подразделения, HR-менеджер, директор. У них разные потребности и разные роли в системе.

Персона — persona

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

Пример из HR system: «Ольга, HR-менеджер, 35 лет. Раз в квартал назначает массовое обучение 200 сотрудникам. Не любит интерфейсы, где надо кликать каждого по отдельности. Открывает систему с рабочего ноутбука и иногда с телефона на ходу.»

Сценарий использования — user scenario / use case

История: пользователь приходит с какой-то задачей и проходит шаги, чтобы её решить. Сценарий описывает, что он делает и какие ожидания у него есть.

Пример из HR system: «Руководитель отделения хочет, чтобы все его подчинённые прошли тест по пожарной безопасности до конца квартала. Он входит в систему, выбирает свой отдел, выбирает тест, ставит дедлайн, отправляет.»

Пользовательский путь / CJM — Customer Journey Map

Развёрнутая визуализация пути пользователя: шаги, точки контакта, эмоции на каждом этапе, где возникают проблемы (pain points) и где можно улучшить.

Пример из HR system: CJM сотрудника: получил уведомление → открыл письмо → перешёл по ссылке → ввёл логин → увидел список назначенных тестов → выбрал → прошёл → получил результат. На каждом шаге — что ему легко, а что мешает.

JTBD (Jobs To Be Done) — работы, которые нужно выполнить

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

Пример из HR system: HR не «нанимает» вашу систему, чтобы кликать по чекбоксам. Он нанимает её, чтобы доказать аудиту, что 100% персонала прошли инструктаж в срок.

Pain point — болевая точка

Конкретное место, где пользователю плохо: непонятно, медленно, страшно, обидно. Pain points — главные кандидаты на улучшение.

Пример из HR system: На странице теста пользователь не понимает, где кнопка «Сохранить», и боится потерять изменения — это pain point.

3. Информационная архитектура и навигация

Карта сайта / структура продукта — sitemap

Иерархическое описание всех экранов и разделов продукта. Показывает, что есть в продукте и в каких отношениях разделы стоят друг к другу.

Пример из HR system: Главная → Тесты → [страница теста] → Назначения → Отчёты → Сотрудники → Настройки.

Способ перемещаться по продукту: главное меню, хлебные крошки, ссылки, табы, кнопки «назад». Навигация бывает первичной (основной), вторичной и контекстной.

Пример из HR system: Шапка с логотипом «Тестирование», меню справа («Тесты», «Назначения», «Отчёты»), ссылка «← к списку» наверху страницы — всё это элементы навигации.

Хлебные крошки — breadcrumbs

Цепочка ссылок, показывающая, где пользователь находится в иерархии и куда можно вернуться: «Тесты / Введение про LLM / Редактирование».

Пример из HR system: Сейчас на странице теста есть только «← к списку». Полные крошки помогли бы быстрее ориентироваться.

Таксономия — taxonomy

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

Пример из HR system: Тест может иметь категории: «обязательные», «рекомендованные», «по специальности», «обучающие». Это таксономия.

Сущность / объект предметной области — entity / domain object

Главные «существительные» вашей системы: Тест, Версия теста, Вопрос, Вариант, Сотрудник, Назначение, Прохождение, Отчёт. Дизайн начинается с понимания, какие сущности есть и как они связаны.

Пример из HR system: Связь «Тест → Версия → Прохождение» позволяет фиксировать результаты конкретной версии, даже если автор потом изменил вопросы.

4. Проектирование интерфейса

Вайрфрейм — wireframe

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

Пример из HR system: Перед прорисовкой страницы создания теста — простой набросок: «слева 70% — форма, справа 30% — превью теста».

Макет — mockup

Визуально проработанный вариант экрана: с реальными цветами, шрифтами, иконками, но обычно статичный (не кликается).

Пример из HR system: Готовый Figma-макет страницы теста, согласованный с вашим зелёным брендом и шрифтом.

Прототип — prototype

Кликабельная модель продукта: можно жать на кнопки, переходить между экранами, увидеть переходы. Прототип бывает разной степени проработанности — от карандашных набросков до почти-настоящего продукта.

Пример из HR system: Кликабельный прототип в Figma, на котором можно «пройти» сценарий «создал тест → назначил отделению → получил уведомление о результате».

Состояния интерфейса — states

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

Пример из HR system: Кнопка «Назначить выбранных» имеет состояния: disabled (никто не выбран), normal, hover, loading (отправка идёт), success (готово).

Empty state — пустое состояние

Что пользователь видит, когда данных нет: список пуст, поиск ничего не нашёл, ещё ничего не назначено. Хороший empty state объясняет, почему пусто, и предлагает следующий шаг.

Пример из HR system: Сотрудник заходит и видит пустой список «Мои тесты». Empty state: «Сейчас вам ничего не назначено. Когда руководитель добавит тест — он появится здесь.»

Edge case — крайний случай

Редкая, но возможная ситуация: ноль элементов, тысяча элементов, очень длинный текст, обрыв сети. Игнорирование edge cases ломает интерфейс именно тогда, когда пользователь меньше всего этого ожидает.

Пример из HR system: Что если в клинике 5000 сотрудников, а не 147? Список «Кому выдать» сегодня этого не выдержит — это edge case, который нужно учесть.

Happy path — счастливый сценарий

Идеальное прохождение сценария без ошибок и непредвиденных ситуаций. Полезно как стартовая точка, но проектирование только под happy path — частая ошибка.

Пример из HR system: «Автор создаёт тест, заполняет 7 вопросов, сохраняет, назначает отделу, все проходят» — это happy path. А что если у автора оборвался интернет на полпути?

5. Дизайн-система и компоненты

Дизайн-система — design system

Набор готовых правил, компонентов и токенов (цветов, отступов, шрифтов), которыми пользуется вся команда. Цель — единообразие и скорость: не изобретать каждый раз кнопку с нуля.

Пример из HR system: Внутри Платформы Цифровых Сервисов клиники должна быть единая дизайн-система: HR system, регистратура, эндовидеоплатформа выглядят как продукты одной семьи.

UI-кит — UI kit

Библиотека готовых интерфейсных элементов (кнопки, поля, модалки, таблицы) в Figma или коде, которой пользуются дизайнеры и разработчики.

Пример из HR system: Если у вас есть UI-кит, новая страница «Назначения» собирается из готовых компонентов за день, а не за неделю.

Компонент — component

Самостоятельный кусочек интерфейса с понятным API: входные параметры, состояния, поведение. Кнопка, поле ввода, аккордеон, модалка — всё это компоненты.

Пример из HR system: Аккордеон «О тесте» / «Вопросы» / «История» / «Показ в каталоге» — четыре экземпляра одного и того же компонента «аккордеон».

Токен дизайна — design token

Атомарная переменная стиля: цвет, отступ, размер шрифта, радиус скругления. Токены позволяют менять оформление всего продукта централизованно.

Пример из HR system: Цвет primary-green = #2E7D5B — токен. Если решите перейти на другой оттенок зелёного, меняете в одном месте, и все кнопки обновляются.

Паттерн — pattern

Типовое решение типовой задачи: «как реализовать поиск с фильтрами», «как показать длинный список». Паттерны — это коллективная мудрость комьюнити.

Пример из HR system: Паттерн «master-detail»: слева список тестов, справа детали выбранного. Хорошо ложится на ваш будущий раздел «Назначения».

6. Качество и проверка дизайна

Юзабилити — usability

Свойство интерфейса быть простым и эффективным в использовании. Измеряется через эффективность (получилось ли), скорость и количество ошибок.

Пример из HR system: Если сотрудник не может с первого раза найти, как пройти тест — у интерфейса проблема с юзабилити.

Возможность использовать продукт людям с особенностями: слабовидящим, незрячим (через скринридеры), людям с моторными ограничениями (только клавиатура), дальтоникам. Стандарт — WCAG.

Пример из HR system: Радиокнопки выбора правильного варианта должны быть доступны с клавиатуры (Tab + Space) и понятны скринридеру («Вариант 1 из 3, выбран»).

Юзабилити-тестирование — usability testing

Метод исследования: реальный пользователь выполняет задание, исследователь наблюдает, где он спотыкается. Дешёвый способ найти большую часть проблем.

Пример из HR system: Дать HR-менеджеру задание «назначь этот тест всему отделению хирургии до 1 мая» и записать, где он зависнет.

Эвристическая оценка — heuristic evaluation

Эксперт сверяет интерфейс с набором эвристик (правил хорошего дизайна, например, эвристиками Нильсена) и фиксирует нарушения. Быстрее теста с пользователями, но менее точно.

Пример из HR system: Анализ страницы теста, который мы делаем сейчас — это, по сути, эвристическая оценка.

A/B-тест — A/B testing

Сравнение двух вариантов интерфейса на реальной аудитории: половина видит вариант A, половина — B; измеряем, какой работает лучше.

Пример из HR system: Сравнить две формулировки кнопки: «Сохранить черновик» vs «Сохранить и назначить» — что чаще ведёт к завершению задачи.

Аналитика продукта — product analytics

Сбор и анализ данных о том, как пользователи реально пользуются продуктом: где кликают, где бросают, сколько времени проводят. Подсказывает, где искать проблемы.

Пример из HR system: Если в аналитике видно, что 40% авторов не доходят до раздела «Показ в каталоге» — это сигнал, что его упускают.

7. Технические понятия, нужные дизайнеру

Респонсив / адаптивность — responsive design

Способность интерфейса корректно работать на разных размерах экрана: от телефона до большого монитора. Не путать с «мобильной версией».

Пример из HR system: Список «Кому выдать» должен оставаться удобным на 13-дюймовом ноутбуке руководителя и на телефоне HR-менеджера в дороге.

Брейкпойнт — breakpoint

Ширина экрана, на которой меняется раскладка интерфейса. Типовые: 360, 768, 1024, 1440 px.

Пример из HR system: На брейкпойнте 768 px (планшет) две колонки на странице теста схлопываются в одну.

RBAC — Role-Based Access Control / ролевая модель доступа

Правила, что какая роль видит и может делать в системе. Дизайн интерфейса должен учитывать роль: один и тот же экран показывается по-разному сотруднику, руководителю, HR и директору.

Пример из HR system: Сотрудник видит только «Мои тесты». Руководитель — ещё «Мой отдел». HR — все назначения. Директор — сводный отчёт.

Версионирование — versioning

Подход, при котором у объекта (теста, документа) есть несколько версий, и история фиксируется. Полезно для аудита и неизменности результатов.

Пример из HR system: В вашей системе тест имеет версии v1, v2 и т.д. Прохождение всегда привязано к конкретной версии — изменения автора не «переписывают» прошлые результаты.

Состояние черновика — draft state

Промежуточное состояние объекта: ещё не опубликован/не активирован, можно безопасно править.

Пример из HR system: Кнопка «Сохранить черновик» означает: тест сохранён, но пока не выдан сотрудникам. Можно ещё дорабатывать.

Уведомление — notification

Сообщение системы пользователю: всплывающее (toast), баннер на странице, push, e-mail. Каждый канал имеет свои правила использования.

Пример из HR system: Тост «Тест сохранён» после нажатия кнопки. E-mail сотруднику с дедлайном по назначенному тесту.

8. Терминология этого проекта

Чтобы команда не путалась, фиксируем основные сущности HR system явно.

Тест — учебный материал, состоящий из вопросов с вариантами ответов. Один тест может иметь несколько версий.
Версия теста — снимок содержимого теста на момент сохранения. Прохождение всегда привязано к конкретной версии.
Вопрос — отдельный пункт теста с формулировкой и набором вариантов. Может допускать один или несколько верных ответов.
Вариант ответа — один из предложенных ответов на вопрос. Помечается как верный или нет.
Назначение — связь «тест × сотрудник × срок». Формирует у сотрудника обязательство пройти этот тест.
Прохождение — попытка сотрудника пройти конкретную версию теста. Имеет статус (в процессе, пройдено, не пройдено) и результат (X из Y).
Порог зачёта — процент правильных ответов, начиная с которого прохождение засчитывается.
Каталог — общий список тестов, видимый сотрудникам с правами.
Роль — профиль доступа: сотрудник, руководитель подразделения, HR-менеджер, директор.

Полезные ссылки и стандарты

Эвристики Якоба Нильсена — 10 базовых правил юзабилити: nngroup.com
WCAG 2.2 — стандарт доступности: w3.org/TR/WCAG22
Material Design — m3.material.io и Apple HIG — developer.apple.com/design — два больших источника готовых паттернов и принципов.
Refactoring UI (Adam Wathan, Steve Schoger) — настольная книга по практическому UI-дизайну.

— Справочник можно дополнять по мере появления новых терминов —

27 KiB Raw Blame History