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