UX/UI Designer
Назад

Пример регламента · UX/UI Designer

Регламент работы UX/UI Designer

Стандарт организации по исследованию пользователей, проектированию сценариев, дизайн-системе, доступности, handoff и design QA.

Паспорт регламента

Код
EXAMPLE-REG-UX-UI-DESIGNER
Версия
2.0
Статус
Пример регламента для адаптации
Владелец
Design Lead
Утверждает
Уполномоченное лицо организации после внутреннего согласования
Юрисдикция
Республика Беларусь
Пересмотр
Не реже одного раза в год, а также после существенного изменения законодательства, процессов или технологий
Актуализирован
5 августа 2026 года

Цель регламента

Создавать понятный, доступный и последовательный пользовательский опыт, проверенный данными и корректно реализованный в продукте.

Применение в Республике Беларусь

  • Работа выполняется в пределах трудовой функции, полномочий, локальных правовых актов и договоренностей конкретной организации. Обязательства перед клиентом принимает только уполномоченное лицо.
  • При обработке персональных данных применяются принципы Закона Республики Беларусь от 7 мая 2021 г. № 99-З: законная цель и основание, соразмерность состава данных, ограничение срока хранения, прозрачность и защита прав субъекта.
  • До привлечения внешнего сервиса или подрядчика определяется роль организации и контрагента как оператора либо уполномоченного лица, перечень данных, операции, меры защиты, возврат и удаление данных.
  • Трансграничная передача персональных данных и использование зарубежных SaaS согласуются с ответственным за внутренний контроль обработки персональных данных до загрузки реальных данных.
  • Юридически значимые решения, согласования и документы оформляются в форме, предусмотренной договором и законодательством. Сообщение в чате или отметка в трекере не приравниваются автоматически к электронному документу с ЭЦП.
  • Коммерческая тайна, сведения клиента, исходный код, учетные данные и внутренние документы передаются только лицам с рабочей необходимостью через одобренные компанией системы.
  • При дистанционной или комбинированной работе соблюдаются условия трудового договора, локальный порядок взаимодействия, режим рабочего времени и требования по безопасному использованию предоставленного оборудования.
  • Исследования с записью голоса, видео, экрана или поведения участников проводятся по заранее согласованному сценарию информирования и обработки персональных данных.
  • Проектирование согласий, уведомлений, тарифов, акций и пользовательских условий выполняется вместе с владельцем процесса и ответственным за правовую корректность текста.

Что проверить до начала работы

  • Названы заказчик результата, владелец решения, исполнители, согласующие лица и канал эскалации.
  • Зафиксированы цель, ожидаемый результат, границы задачи, срок, приоритет, зависимости и критерии приемки.
  • Определена классификация информации: публичная, внутренняя, конфиденциальная, коммерческая тайна или персональные данные.
  • Подтверждено, что специалист имеет необходимые доступы и полномочия, а лишние права не выдаются.
  • Понятно, где хранится актуальная версия результата и какие записи подтверждают выполненную работу.
  • Определены исследовательский вопрос, критерии участников, способ рекрутинга, компенсация, формат записи, доступ к материалам и срок удаления.
  • Получены утвержденные product/legal тексты; дизайнер не заменяет юридическую формулировку декоративным или сокращенным вариантом без согласования.

Зона ответственности

  • UX-исследования, информационная архитектура, пользовательские потоки, прототипы, UI, дизайн-система, accessibility и контроль реализации.
  • Дизайнер отвечает за сценарий и качество опыта целиком, включая ошибки, пустые состояния и реальные ограничения.

Обязанности специалиста

  • Основывать значимые решения на пользовательских данных или явно отмеченных гипотезах.
  • Прорабатывать real content, состояния, адаптивность и доступность до handoff.
  • Использовать и развивать дизайн-систему вместе с frontend.
  • Проверять реализацию в работающей сборке и измерять outcome после релиза.

Рабочий порядок

  1. Сформулировать исследовательский вопрос и изучить пользовательский контекст.
  2. Построить IA, user flow и варианты решения.
  3. Проверить прототип на реалистичных задачах.
  4. Описать компоненты, состояния, responsive и accessibility.
  5. Провести handoff, design QA и review продуктового эффекта.

Контрольные вопросы специалиста

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

  1. Какие данные участника действительно нужны для ответа на исследовательский вопрос?
  2. Понимает ли участник, что записывается, кто увидит материал и когда он будет удален?
  3. Можно ли провести исследование без имени, контакта или записи лица?
  4. Не раскрывает ли прототип реальные данные другого человека или клиента?
  5. Дает ли интерфейс свободный и понятный выбор без dark patterns?
  6. Видны ли цель сбора данных, обязательность поля и последствия отказа?
  7. Проработаны ли доступность, ошибки, удаление, отзыв согласия и ограничение прав?
  8. Достоверны ли цена, акция, сравнение и существенные условия?
  9. Какие исследовательские файлы должны быть удалены после синтеза?

Персональные данные и безопасность

  • Использовать корпоративные учетные записи, MFA, менеджер секретов и принцип минимально необходимых прав; не передавать пароли в чатах, документах и задачах.
  • Не копировать рабочие материалы в личную почту, личные облака, публичные AI-сервисы или неутвержденные инструменты без письменного разрешения владельца информации.
  • Не использовать реальные персональные данные в разработке, тестировании, демонстрациях и обучении, если цель может быть достигнута синтетическими или обезличенными данными.
  • В логах, снимках экрана, отчетах и bug report скрывать токены, пароли, номера документов, платежные данные и иные избыточные идентификаторы.
  • При ошибочной отправке, утрате доступа, подозрении на утечку или несанкционированную обработку немедленно прекратить распространение и уведомить руководителя и ответственного за персональные данные; внешние уведомления выполняют уполномоченные лица в установленные сроки.
  • Доступы пересматриваются при смене роли, завершении проекта и увольнении; данные и носители возвращаются или удаляются по подтвержденной процедуре.
  • Использовать обезличенные цитаты и participant ID; контакты рекрутинга хранить отдельно от research notes.
  • Не размещать записи интервью и макеты с реальными данными в публичных Figma-проектах, Miro-досках и портфолио.

Обязательные артефакты

  • Research Summary
  • Information Architecture и User Flow
  • Prototype и Usability Report
  • UI Specification и Component Library
  • Handoff и Design QA Report

Критерии качества

  • Ключевой сценарий проверен пользователями.
  • Все интерактивные состояния и размеры экрана описаны.
  • Критерии WCAG AA выполнены для критичных маршрутов.

Контрольные точки

  • До UI согласованы problem, flow и content.
  • Перед handoff проверены states, real data, responsive и a11y.
  • Перед релизом расхождения design QA устранены или приняты.

Антипаттерны

  • Полировать первую идею без альтернатив.
  • Использовать lorem ipsum вместо реального контента.
  • Рисовать только happy path desktop.
  • Считать ссылку на Figma достаточным handoff.

Рабочий ритм и периодический контроль

  • По рабочим дням: обновить статус задач, зафиксировать блокеры и решения, требующие участия других ролей.
  • Еженедельно: сверить приоритеты, риски, качество артефактов, просрочки и необходимость эскалации.
  • Перед релизом или передачей результата: провести проверку по критериям приемки, безопасности, персональным данным и эксплуатационным рискам.
  • После релиза: проверить фактический результат и зарегистрировать дефекты, отклонения, уроки и последующие действия.
  • Ежеквартально: пересмотреть доступы, устаревшие документы, ручные операции, технический долг и соответствие регламенту.
  • Перед каждым usability test проводить privacy/safety review сценария, а после синтеза — проверку удаления временных записей и экспорта.

Метрики контроля

Task successTime on taskКритичные usability issuesAccessibility defectsAdoption дизайн-системы

Коммуникации и эскалация

  • Неясности поведения обсуждаются с продуктом и разработкой до детализации.
  • Изменения компонентов проходят совместный design/code review.
  • UX-риски эскалируются с наблюдением, влиянием и вариантом решения.

Матрица обязательной эскалации

  • Немедленно: утечка или подозрение на утечку данных, компрометация учетной записи, критическая уязвимость, недоступность ключевого сервиса или риск необратимой потери данных.
  • В течение рабочего дня: нарушение договорного срока, блокирующее противоречие требований, несанкционированное изменение production, юридический или репутационный риск.
  • До продолжения работы: отсутствует владелец решения, правовое основание обработки данных, согласованный критерий приемки либо полномочие на действие.
  • Эскалация содержит факты, влияние, затронутые системы и данные, уже выполненные безопасные действия, варианты решения и время следующего обновления.
  • Остановить исследование или handoff при отсутствии согласованного информирования, использовании данных не по заявленной цели, манипулятивном UX или риске раскрытия личности.

Когда работа считается завершенной

  • Результат проверен по всем критериям приемки, а непроверенные области и остаточные риски перечислены явно.
  • Артефакты, решения, версии, ссылки и доказательства проверки сохранены в согласованном корпоративном источнике.
  • Заинтересованные роли уведомлены об изменении, ограничениях, действиях после релиза и владельце дальнейшего сопровождения.
  • Временные доступы, файлы, тестовые данные, feature flags и обходные решения удалены либо имеют владельца и срок закрытия.
  • Результат принят владельцем решения или имеется письменное решение о принятии остаточного риска уполномоченным лицом.
  • Дизайн готов после проверки real content, всех состояний, responsive, accessibility, privacy patterns, handoff и design QA в работающей сборке.

Документирование и хранение записей

  • Рабочие решения и согласования фиксируются в трекере, базе знаний, репозитории или системе электронного документооборота, принятой в компании.
  • Срок хранения определяется номенклатурой дел, договором, целью обработки и требованиями законодательства; персональные данные не хранятся “на всякий случай”.
  • Удаление или архивирование должно быть контролируемым: сохраняются необходимые версии, авторство, дата решения и связь с проектом или релизом.
  • Экспорт данных и локальные копии допускаются только на срок рабочей необходимости и удаляются после подтвержденной загрузки результата в корпоративную систему.
  • Хранить research plan, форму информирования, обезличенные notes, synthesis, decision log, UI specification и Design QA; сырые записи удалять по утвержденному сроку.

Нормативная основа и официальные материалы

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