Когда лучше оптимизировать UX приложения?

Практически невозможно интересоваться ИТ-решениями и не слышать о том, насколько полезной может быть оптимизация UX. Хороший пользовательский опыт связан с понятным, удобным интерфейсом и простым рабочим процессом. Речь идет о том, чтобы изменить систему, которая нас раздражает, на ту, которой нам нравится пользоваться и которая экономит наше время. Не стоит удивляться тому, что изменения, делающие приложения более удобными, могут принести нам больше клиентов. Тем не менее, не все делают UX приоритетом.

Задумывались ли вы о том, что сейчас самое время оптимизировать UX вашего приложения? Возможно, прямо сейчас у вас только появилась идея приложения, а может быть, у вас уже есть готовый к использованию продукт. Иногда существует так много вещей, которые можно сделать с вашим проектом, чтобы сделать приложение более доступным для пользователя, что это становится вещью, которую вы планируете сделать когда-нибудь, но так и не доводите до конца. Так когда же наступает тот самый момент, когда стоит задуматься об улучшении UX?

До начала разработки

Лучше всего задуматься о UX еще до начала кодирования. Когда у вас есть идея приложения, естественно, сначала подумать о том, как оно должно работать с точки зрения пользователя. То же самое относится и к добавлению новой функциональности в уже существующее приложение. Вам может показаться, что будет быстрее начать с туманного представления о том, как может выглядеть ваше приложение, и внести изменения позже, но зачастую это не так. Если разработчики будут точно видеть, как должно быть построено каждое представление, это сэкономит им время, поскольку команде не придется тратить его на многократное переделывание одних и тех же вещей.

Планирование особенно важно, если ваше приложение очень сложное. Видя все сценарии возможного поведения пользователя, вы подготовитесь к тем случаям, которые вы не ожидали увидеть. Это также поможет исключить концепции, которые не будут работать. Наличие "чистого листа" позволит команде не ограничивать свои идеи тем, с чем они работали ранее, и каждый сможет взглянуть на прототип свежим взглядом.

Процесс создания и анализа макетов, конечно, отнимает много времени, но он поможет вам и вашей команде узнать много нового о приложении. Недавно, работая над новыми функциональными возможностями Catalyst, приложения для клинической коммуникации и совместной работы, я и остальные члены команды очень тщательно планировали, как должен выглядеть каждый сценарий. Я сделал пиксельно идеальный макет для каждого вида, связанного с новой функциональностью, которую мы хотели создать. Конечно, можно обойтись и проволочными схемами, но более детальный прототип позволит получить более качественную обратную связь в процессе тестирования. Создав прототип, мы смогли протестировать, что пользователь может делать на каждом этапе своего рабочего процесса.

Для нас было очень важно иметь постоянную обратную связь. Мы регулярно проводили совещания, на которых обсуждали каждую точку зрения. Частые мозговые штурмы очень хорошо работают, потому что, когда у вас есть меньшая часть новых разработок, у вашей команды есть больше времени, чтобы обсудить каждую деталь. Теперь, когда мы работаем над реализацией наших идей, у нас есть точные инструкции о том, как должен выглядеть конечный продукт. Макеты и прототипы также являются прекрасным материалом, который можно использовать в презентациях для заинтересованных сторон и отдела продаж. Этот процесс проектирования оказался настолько эффективным, что теперь мы используем его для создания еще большего количества решений.

Во время разработки

Что делать, если у вас нет такого количества времени на точное планирование и вам нужно быстро получить работающий продукт? Имеет ли смысл тогда думать об улучшении пользовательского опыта? Да, имеет, и это еще можно сделать. Команда разработчиков может использовать фреймворки для быстрого создания скелета вашего приложения. Команда сможет протестировать его, и наверняка найдутся вещи, которые можно улучшить. Вы сможете увидеть, какие задачи занимают у пользователей больше времени, чем должны, а какие могут вызвать путаницу.

Всегда следует обращать внимание на комментарии тестировщиков. Некоторая информация, которую вы предоставляете пользователю, может оказаться ненужной. Например, в компании Selleo при создании приложения Parkero, которое было создано для помощи пользователям в поиске и бронировании парковочных мест, на одном из просмотров нам удалось избавиться от нескольких ненужных вводов. Может показаться, что это не так уж и важно, но это сделало форму гораздо более понятной и удобной для пользователя.

После сбора обратной связи от пользователей

Когда приложение уже существует, можно собрать наиболее значимую обратную связь. Ваше приложение наконец-то могут использовать те, кто собирался использовать его в первую очередь, - ваши пользователи. Наиболее значимый вклад можно получить, проведя тестирование с группой, сопоставимой с вашими целевыми клиентами. Наблюдение за тем, как пользователи взаимодействуют с вашим приложением, может дать вам много поводов для размышлений. Понаблюдайте за тем, что нажимают ваши тестировщики, и проверьте, находятся ли данные, которые они ищут, там, где они ожидают их увидеть. То, что ваша команда считала очевидным, может оказаться довольно сложным для тех, кто не знаком с приложением раньше. Если у вас нет возможности организовать тестирование, вы всегда можете провести опрос и узнать, как пользователи относятся к вашему продукту.

Иногда даже не нужно искать отзывы так далеко. Можно проверить рейтинги и просмотреть комментарии в магазине приложений. Узнайте, соответствует ли приложение тому, что искали пользователи, и не возникло ли у них каких-либо проблем. Иногда можно даже найти запросы на функциональные возможности, которые уже есть в приложении! Возможно, некоторые функции показались вам незначительными и оказались погребены под менее важными для пользователей.

Пользователи также могут писать в вашу службу поддержки с проблемами, с которыми они столкнулись. Сотрудники команды должны создавать тикет для каждой проблемы. Они должны отмечать не только ошибки, но и те места в приложении, которые недостаточно просты в использовании.

Во время внесения других изменений

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

Тема UX должна подниматься и при редизайне. Вы должны сосредоточиться не только на том, чтобы приложение выглядело хорошо, но и на том, чтобы сделать его более простым в использовании. Многие пользователи не любят изменений, поскольку им приходится к ним привыкать. Но если изменения хороши и ускоряют работу, клиенты смогут понять, почему эти улучшения были необходимы, и оценят их по достоинству.

Выводы

Итак, как мы выяснили, об оптимизации UX можно думать независимо от стадии разработки приложения. Есть ли время, когда мы не должны думать об улучшении юзабилити? На самом деле нет. Мы всегда должны стремиться к улучшению опыта наших пользователей. Конкуренция на рынке со временем только усиливается, и мы не должны удивляться, когда кто-то решает сменить используемый инструмент на какое-то более удобное решение. Конечно, недостаток средств может помешать нам внести необходимые изменения. Однако в конечном итоге мы должны помнить, что UX также позволяет нам сэкономить деньги, обеспечивая более счастливых пользователей.