Сегодня мы поговорили с директором по продукту Rubrain.com Александром Жулином о его опыте работы над UI и UX, о том как предугадать действия и реакциии пользователей, на что стоить обратить особое внимание и о том, как важно делать регулярные обновления, связанные c пользовательским интерфейсом и опытом.
Саша, расскажи, пожалуйста, про свою работу над UI.
Я работаю над продуктами в стартапах в качестве продакт менеджера, UX/UI дизайнера или арт-директора. Также меня часто привлекают в проектные работы на разных стадиях.
Существуют ли какие-либо отличительные особенности для этой отрасли?
Наверно, как и везде. В целом, сложно отделить эту область от IT в целом. Так что особенности, думаю, будут схожими.
По какому алгоритму происходит выбор и утверждение макетов?
В случае, когда ты отвечаешь за продукт, тем более в стартапе, то защищаешь решения внутри команды, а затем непосредственно перед пользователями. Слушаешь фидбэк, взаимодействуешь с бизнесом, оптимизируешь решения. Ты всегда можешь сразу анализировать живые цифры. Это замечательно, но не всегда возможно. А вот в проектной работе все сложнее. Тут приходится идти на компромиссы — убедить заказчика, что решение оптимальное, что бизнес-задачи в таком же приоритете как и опыт пользователя. И если с ux это сделать чуть проще. То с ui все более субъективно. Даже если ты покажешь результаты А/Б теста — у многих заказчиков будут неконструктивные замечания. Тут только спокойная и планомерная работа с заказчиком — его надо выводить на конструктивный диалог по важным вопросам. Тут, кстати, помогает перед работой принять гайдлайн, к которому заказчики незаслуженно относятся несерьезно. Это всегда хороший аргумент в будущих неконструктивных спорах. Работа с заказчиком это вообще отдельная тема для разговора.
Как понять, что пользователю что-то покажется удобным / не удобным?
Если говорить про совсем ранний этап проектирования, то пройти путь самому, протестировать в сервисах на этапе прототипов, определить основные профили пользователей и прописать под них кейсы. Все кейсы, разумеется, должны заканчиваться «успешно» (критерии и параметры успешности тоже надо определить). Но всё это детали, потому что основная часть проблем уйдет с опытом. Появится ощущение и понимание поведения пользователей, их паттерны взаимодействия. Все это появится и сэкономит много времени на начальных этапах в будущем.
Расскажи про то, что тебе удалось / не удалось просчитать? Приходилось ли что-то менять после запуска? Почему?
Те времена, когда между версиями могло проходить больше года давно прошли. Все стало быстрее, да и средства позволяют быть более гибким. В текущем мире бизнес-цели, задачи и среда меняются гораздо быстрее, чем продукт выходит в релиз. Так что — конечно. Продукт это не монолит. Это система, которая должна меняться и подстраиваться под изменяющуюся среду с одной стороны и бизнес-задачи с другой.
На что в UI ты бы посоветовал обратить внимание другим компаниям, готовящимся к запуску продукта?
Должен быть простой, понятный и при этом эмоциональный и выразительный визуальный язык, по возможности еще до начала работы над экранами. Стиль, рифмы, приемы, ограничения. Все эти моменты надо описать и продумать. Сформулировать и оформить. Можно протестировать стиль на офлайн носителях и даже на полиграфии. Это никогда не будет лишним, зато в будущем вы избавитесь от проблем несогласованности продукта и маркетинга, презентаций, документаций, офлайн материалов, лендингов и рекламы. Многие почему-то упускают этот момент. Но если всю работу начать с формирования общего визуального языка (стиля), то это почти ничего не стоит и сильно облегчит всю работу сразу в нескольких направлениях в будущем. Даже если сейчас вам кажется это абсолютно лишним.
Спасибо за отличные советы!