moqap

Как подготовить хорошее тех.задание для UI/UX-дизайнера

  • Facebook
  • Twitter
  • VKontakte
  • LinkedIn
  • Email
  • RSS

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

К этому моменту я встречал множество различных примеров, как удачных, так и не очень. И для начала давайте проясним, что именно нужно UI/UX дизайнеру, чтобы начать работу по вашему ТЗ.

Минимальный набор требований для ТЗ по UI/UX

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

Карта экранов

Карту стоит показать дизайнеру, как минимум, чтобы он представлял что за чем следует, какие элементы общие, какие имеют единичный характер, а какие элементы вообще уникальны. Дизайнер с опытом сможет подсказать или внести корректировки, чтобы упростить и улучшить UX. Без карты экранов, работая только с элементами и окнами — риск получить неполноценный интерфейс значительно повышается. Кроме того, любому гейм дизайнеру будет полезно для понимая своих идей иметь эту карту не только по UI но и по механикам.

Пример плохой карты экранов:

badmapscreen

Пример хорошей карты экранов:

ScreenMap

В первом примере есть три основных минуса:

  • мелко и не понятно — дизайнеру крайне не комфортно разбираться в такой структуре, и уж точно прочувствовать все переходы и сделать хороший UI становится проблематичным
  • нет схематических обозначений, позволяющих отследить возможности возвратов между экранами
  • экраны уже изначально включают примеры UI, что при изменениях концепта, стиля или другой доработки придется редактировать всю карту — все ее элементы

Во втором примере отсутствуют эти недостатки, и присутствуют дополнительные преимущества:

  • есть возможность отследить все связи, понять насколько загружено каждое из окон
  • формат Иконка + Подпись — хороший способ для дизайнера понять на интуитивном уровне назначение окна.

Пример описание задания на UI

Для примера опишем задачу для UI/UX дизайнера из 2го примера карты экранов — «Гараж».

Описание:
Гараж выполнен в виде окна. Окно открывается при нажатии на «Гараж» в Лобби игры. Предполагается, что в этом окне пользователь будет проводить большую часть времени между заездами.

Мокап:

moqap

UI:

  • Заголовок
  • кнопка (х) — закрыть
  • Текст с призывом к действию — «Выбери машину»
  • Слайдер выбора
    • Изображение автомобиля
    • Логотип автомобиля
    • Диаграмма характеристик с иконками  и прогрессбарами
      • скорость
      • ускорение
      • управляемость
      • тормоза
    • Название автомобиля стилизированым шрифтом
    • Кнопка действия: «Купить за $$$» или «Выбрать» (если машина уже куплена) (сумма будет колебаться от 1000 до 999 999)
    • Кнопки Влево и Вправо
  • Блок улучшения разделён на 4 секции и вынесен отдельно.
    • иконка улучшения: двигатель, ходовая, трансмиссия, визуальные эффекты
    • кнопка действия «Улучшить»

Как работает слайдер:

Переключать автомобили можно как кнопками, так и свайпом.

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

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

Как работает апгрейд:

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

Внимание:
Поле денег остается общим, и его видно с экрана Лобби.
Если у пользователя не достаточно денег на покупку автомобиля, сумма денег в кнопке «купить» написана красным цветом.

Это простой вариант описания задачи для UI/UX-дизайнера. Он не является образцовым, как минимум потому, что он сделан как пример для статьи, и не имеет отношения к какому либо функционалу. Тем не менее вы можете сравнить его с вашими ТЗ и, возможно, взять что-то на вооружение. Тем, кто ни нашел ничего нового для себя в этом посте — мой поклон.

 Линки по теме: