RUS
August 31, 2023

Когда UI собирают программисты:

Этот способ весьма распространен. Дизайнеры создают элементы, составляют макеты в Figma (кстати, уже не Photoshop), и передают их программистам. Затем программисты, опираясь на макеты, воплощают интерфейс внутри игры.

Что хорошего:

  • Интерфейс функционирует надежно, так как в нем используется "правильная" логика, гармонично сочетающаяся с игровым функционалом.
  • Количество программных багов остается на умеренном уровне, и QA-специалисты успешно их выявляют, отправляя на доработку без привлечения дополнительных экспертов.
  • Логика интерфейса находится под контролем, что облегчает манипулирование и внесение изменений. Однако остается вопрос, кто именно будет этим заниматься?

Что печального:

  • Присутствуют визуальные баги в большом количестве. Отслеживание и описание багов требуют от QA тщательного попиксельного сравнения с макетом. В нем могут упустить нюансы реального использования интерфейса. Но они редко могут предложить решения для их исправления, что вызывает длительные изменения. QA и программисты, не специалисты в дизайне, редко предлагают качественные решения. Это требует максимальной мобилизации UI/UX команды, даже для незначительных корректировок.
  • Долгая сборка интерфейса. Сборка интерфейса занимает много времени. Программистам требуется углубленно изучать ТЗ и описание реализации. Оперирование такими понятиями, как акценты, понятность, баланс, композиция и другие, представляет для них значительные трудности. Они усердно стараются следовать макету, но ошибки все равно возникают. Это происходит потому, что они фокусируются на логике, не всегда уделяя должное внимание цельной картине.
  • Огромное время на проработку подробного ТЗ. Умолчания типа "сделай красиво" недостаточно. Приходится детально описывать каждый аспект: цвета, шрифты, отступы и выравнивание. Намеренное упрощение визуальных требований необходимо, иначе сборка становится крайне сложной. Это отнимает много времени, даже для простых элементов интерфейса.
  • Упрощение важных для интерфейса аспектов. В первую очередь страдают удобство, понятность, отклик и акценты. Уникальные окна с индивидуальной реализацией вызывают множество споров и недопониманий, потому, что ребята стремятся минимизировать количество ошибок. Порой сложно объяснить, что многое важно для понимания, но, кажется, нелогично с их точки зрения. Иногда проще выбрать стандартное решение, чем придумывать новое. (Но бывают исключения).
  • Отсутствие интереса к этой работе. Об этом обычно умалчивают. Однако я не могу избавиться от ощущения, что немногие программисты получают удовольствие от такой работы. Им гораздо интереснее создавать алгоритмы или разрабатывать сложную логику, чем заниматься версткой. Из-за этого иногда возникают случайные ошибки и упрощения: неправильный шрифт, неверный цвет границы, неправильное выравнивание. И не только это, они также неохотно вникают в детали. Я думаю, это не их основная задача, скорее необходимость, с которой приходится смириться.
  • Усложнение процесса для поддержки приемлемого качества. Необходимо множество дополнительных процедур, чтобы скомпенсировать незнание программистами визуальных основ и критериев, умноженное на нежелание в это вникать. Что рождает баги и затягивание процесса, получается некая петля, которая усугубляет ситуацию.

Что делать?

  • Включать в работу с программистами UI спецов непосредственно во время сборки, перед тем как это будет закинуто в проект.
  • Описывать подробные ТЗ для программистов, с учетом их фокуса на логику, описывая алгоритм повторения визуального результата подробно. Разжевывая понятные любому дизайнеру аспекты.
  • Упрощать требования к интерфейсу. Ничего сложного и невероятного не придумывать.
  • Принять, что такой способ прокатывает только на этапе предпродакшена или прототипирования и не подходит для масштабирования в виду своей медлительности.
  • Освободить программистов для создания инструментов для сборки интерфейса.

@ArtsFactory

#solutions #cases

Ну или спроси у меня как.