Почему хороший дизайн начинается раньше, чем первые картинки
От качества работы дизайнеров зависит многое, но дизайн — лишь часть продукта. В этой статье я хочу поделиться мнением о том, какие проблемы могут привести к плохому дизайну помимо самого дизайна, а так же почему хороший дизайн начинается гораздо раньше, чем рисование кнопочек и картинок.
В разработке ПО часто встречается одна и та же ситуация: люди выравнивают пиксели, перерисовывают иллюстрации, меняют пользовательские сценарии, пользовательский интерфейс. Но имеют при этом проблемы в работе ключевых функций, несогласованность отделов, непонятное клиентам название, странную рекламу и массу других проблем.
Ниже приведены типичные проблемы, которые я наблюдал в своей практике (и не только), приводящие к плохому дизайну, а так же советы что с ними делать.
Проблемы с коммерческой частью
Сколько будет стоить продукт? Какие планируются способы оплаты? Какой набор опций будет включать в себя каждый тариф? Без каких данных можно обойтись на этапе покупки или регистрации? Обязательно ли привязывать банковскую карту, чтобы активировать пробный период? Обычно эти вопросы решаются на самом верху, согласовываются с фин. работниками и приходят дизайнерам как данность. Каким бы идеальным не был интерфейс привязки банковской карты, но если это делается при регистрации, то сервис потеряет очень много клиентов.
Что делать?
Вопросы тарифной политики и финансов должны решаться как можно раньше, совместно с ux-дизайнерами и тестироваться вместе с прототипом сервиса. Этап выбора и покупка продукта не должны восприниматься отдельно от его использования. Проблемы в этой части могут отразиться и на интерфейсе.
Проблемы с маркетингом
Кто наши покупатели? Чем их не устраивает имеющееся положение дел? Какие функции продукта наиболее важные? За что люди готовы платить? Какие функции включить в первую версию?
Ответы на эти вопросы часто ищет кто угодно, но только не тот, кто должен. Дизайнерам и программистам говорят: «У нас теперь lean-подход, вот вам идея продукта и книжка на вечер. Завтра пойдете делать customer development, потом нарисуете дизайн и сделаете прототип». В результате может получиться так, что функциями продукта будет удобно пользоваться, только не теми, которые нужны. А те, что нужны, запрятаны далеко вглубь и сделаны по остаточному принципу.
Что делать?
Именно продакт-менеджер и маркетолог должны найти ответы на эти вопросы и как можно раньше. Не без помощи коллег, конечно, но и нельзя пускать процесс на самотек. Без этой информации, дизайнеры будут ориентироваться на свое мнение, либо проведут исследование самостоятельно, но от этого не выигрывают ни дизайнеры, т.к. они будут заниматься не своим делом, ни бизнес, т.к. он рискует получить не то, что ожидает. Методам исследования рынка и поиску рыночной ниши можно научить, но это отдельная наука и парой стартаперских мастер-классов тут не обойтись.
Проблемы с управлением проектом
Времени всегда не хватает и нужно быстрее пилить продукт. Дизайн уйдет в работу без юзабилити-тестирования. Аналитик, поглядывая на макеты напишет бизнес-требования, а разработчики, не дожидаясь требований, начнут программировать. В итоге продукт получится далеко не таким, как ожидалось, с кучей функций, но с гораздо большей кучей багов.
Что делать?
Не нужно бросаться поскорее писать код, как только появился первый вариант дизайна, и тем более, когда дизайна еще нет. Это наиболее критично в новых продуктах и нишах, когда нет ни приличных аналогов, ни собственных данных о поведении пользователей. Все знают, что стоимость внесения изменений в проект минимальна в начале и максимальна в конце, но почему-то забывают об этом, когда доходит до дела.
Проблемы в орг. структуре и бизнес-процессах
Даже самые простые продукты могут иметь несколько каналов взаимодействия, разные этапы и стадии, на которых находится клиент. На каждом этапе клиент взаимодействует с разными отделами, людьми и технологиями. Когда процессы подразделений запутаны, а взаимодействие не налажено, интерфейс тоже будет сложным и запутанным.
Что делать?
Перед тем, как автоматизировать и «оцифровывать» бизнес-процессы, их нужно упрощать. Так принцип единого окна в госструктурах потребовал сначала перестройки процессов внутри ведомств и только потом был реализован в виде простого интерфейса — собственно, единого окна.
Проблемы с реализуемостью функций
Дизайнер может нарисовать сколько угодно красивый и удобный интерфейс, но он не будет реализован из-за технических ограничений.
Что делать?
Технологии должны своевременно адаптироваться к требованиям продукта, иначе продукт будет вынужден адаптироваться к возможностям технологий. Очень часто успех редизайна интерфейса зависит от архитектурного и технологического редизайна. Команда проекта должна быть к этому готова.
Интерфейс продукта для клиента и есть сам продукт. Но для компании-разработчика интерфейс — это лишь вершина айсберга, за которой скрываются технологии, процессы, структура и прочие особенности кухни. Пользователь не хочет и не должен вникать в них. Но нельзя забывать, что каждый процесс и каждое решение могут улучшить или ухудшить интерфейс продукта, а значит и сам продукт.
