Чеклист требований к UI-дизайну: 30 вопросов до старта

Хороший UI начинается до выбора цвета и компонентов. Перед макетом зафиксируйте, кто выполняет задачу, какие состояния нужно показать, какие ограничения есть у продукта и что должен получить разработчик. UI-дизайн-мейкер Pixso помогает собрать экран и прототип, но не заменяет этот список входных требований.

Как пользоваться чеклистом

Возьмите один реальный поток — например, вход, восстановление пароля или оформление заказа.

Для каждого вопроса запишите ответ, владельца и открытый риск.

Если ответа нет, отметьте допущение и согласуйте его до review.

1. Цель и пользователь

1. Какую задачу пользователь должен завершить?
2. Кто выполняет её и что он уже знает?
3. Какой продуктовый результат нужен?
4. Что считается успешным завершением?
5. Какие ограничения по роли, региону, устройству или доступу действуют?

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

2. Экраны и состояния

1. Какие экраны входят в поток?
2. Что увидит новый пользователь без данных?
3. Что происходит при ошибке, пустом результате и отсутствии прав?
4. Как выглядит загрузка и повтор после сбоя?
5. Что происходит после успешного действия?

Состояния должны быть частью требований, а не поздним дополнением.

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

3. Layout и responsive

1. Какая минимальная ширина поддерживается?
2. Что перестраивается на телефоне, а что остаётся доступным?
3. Как ведут себя длинные имена и переводы?
4. Какие элементы видимы при увеличении текста?
5. Где проходит клавиатурный и сенсорный порядок?

Сделайте desktop и мобильный вариант на одном содержимом. Проверяйте перенос текста, виртуальную клавиатуру, zoom и узкое окно.

4. Компоненты и дизайн-система

1. Какие компоненты уже утверждены?
2. Какие варианты и состояния нужно добавить?
3. Какие токены отвечают за цвет, размер, радиус и отступ?
4. Кто владеет библиотекой и изменениями?
5. Как проверить, что обновление не сломает другие экраны?

Не дублируйте компонент ради одного экрана.

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

5. Контент и accessibility

1. Кто предоставляет реальные тексты и локализации?
2. Какие заголовки, labels и ошибки должны быть понятны без цвета?
3. Как пользователь проходит поток с клавиатурой или screen reader?
4. Достаточен ли контраст и размер интерактивной цели?
5. Что происходит при увеличении текста и длинном слове?

Placeholder нельзя использовать вместо реального текста: длина строки влияет на layout, а сообщение «что-то пошло не так» не объясняет восстановление.

6. Handoff

1. Какие состояния и размеры увидит разработчик?
2. Какие ассеты и шрифты нужно передать?
3. Где лежит источник данных и какие значения динамические?
4. Какие аналитические события нужны?
5. Кто отвечает за открытые вопросы и дату content freeze?

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

7. Чеклист review

Заключение

Требования к UI — это договорённость о задаче, состояниях, ограничениях и результате handoff.

Зафиксируйте ответы до детальной отрисовки, а затем используйте Pixso для компонентов, prototype, review и передачи решения.