Time to market — это время от начала работы до конечной реализации продукта или фичи, буквально «время до выхода на рынок». Чем меньше TTM — тем лучше. Никто не хочет затягивать выпуск новой функциональности и отставать от конкурентов.
Один из факторов, влияющих на TTM — это скорость разработки. А одним из факторов, в свою очередь влияющих на скорость разработки, является, как вы уже догадались, дизайн-процесс.
Меня зовут Андрей Богданов, и я работаю дизайн-лидом в ВТБ.
Сегодня я расскажу, как дизайнер может ускорить (или, как минимум, не замедлять) работу frontend-разработчиков. А другие мои посты вы можете найти в телеграм-канале: https://t.me/na_produkte
Хорошее начало
В идеальной картине мира разработчики приступают к работе, когда дизайн готов, согласован и пригоден к реализации. В таком случае дизайнеру важно не факапить и укладываться в обозначенные дедлайны — будет довольно неприятно, если из-за вас коллеги не смогут вовремя приступить к работе.
Бывает и по-другому (хоть это и не очень здорово): дизайнеры и разработчики приступают к проекту одновременно или с минимальной разницей во времени. Но и в такой ситуации можно оптимизировать процесс, договорившись о последовательности реализации экранов или сценариев и подсвечивая актуальные статусы по ним («в работе», «согласовано», «есть проблемы» и т.д.).
На связи
Доступность дизайнера для разработчиков — это очень важно.
Даже если ваши макеты сконструированы идеально, а юзерфлоу досконально прорисован, у разрабов все равно могут возникнуть вопросы по ходу дела. Не найдя ответы на них у дизайнера, разработчики могут реализовать спорный момент по своему усмотрению, и не всегда их решение окажется верным.
Как следствие — необходимость переделки. Или спорное решение в продакшене, что еще хуже. Поэтому лучше подружиться с фронтами, помогать им и вместе оперативно выдавать качественный результат.
Простые решения
Хороший UI kit уже содержит в себе решения, позволяющие покрыть большинство кейсов. Используйте его по максимуму и не плодите кастомные компоненты там, где в этом нет необходимости.
Это позволит ускорить и разработку. Взять готовый кусок кода проще, чем программировать какие-либо компоненты с нуля. Помните: при прочих равных всегда выбираем более «дешевое» (в том числе и с точки зрения временного ресурса) решение.
Универсальность
Здорово, когда ваши решения максимально универсальны и масштабируемы. Это означает, что их можно использовать не только в одном конкретном сценарии, но и в других аналогичных. Такой подход сэкономит в том числе и ресурс разработки, так как воспроизводить (пусть и с небольшими изменениями) готовые решения быстрее, чем продумывать абсолютно новые.
Принцип универсальности можно применить и к адаптивам: если в десктопном, планшетном и мобильном разрешении UI будет работать по одинаковым правилам, это определенно сэкономит время разработчику.
Впрочем, это не должно быть во вред пользовательскому опыту. Иногда уместен и кастом, и нестандартные решения.
Оптимизация
Задача дизайнера — спроектировать интерфейс так, чтобы в нем не было ничего ненужного. Лишние запросы, поля и компоненты не только усложняют пользовательский путь, но и затягивают процесс разработки.
Пользователь должен видеть на экране только то, что может ему пригодиться для решения текущей задачи. Определить необходимый набор функциональности поможет глубокая проработка бизнес-процесса, а также понимание пользовательских и бизнесовых задач.
Важно, однако, не перегнуть палку и не сделать UI блеклым и непривлекательным. Минимальная декоративность и, например, элементы геймификации, могут положительно сказаться на пользовательском опыте.
Осознанный дизайн
Как я уже сказал, важно понимать задачи бизнеса и потребности клиента. А еще важно рефлексировать над тем, что делаешь, и осознанно подходить к проектированию UI.
Если готовить макеты по принципу «Так сказал продакт» или «Тупо скопировал конкурентов», ничего хорошего не получится.
Скорее всего, результатом поверхностного подхода к дизайну станут многочисленные правки из-за множества неучтенных моментов. Хорошо, если эти правки получится внести до начала разработки. В противном случае это приведет к затягиванию ее сроков.
Другие посты тут: https://t.me/na_produkte
Си ю.
