UX для недизайнеров, или что должен учитывать разработчик мобильных приложений

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

В статье мы рассмотрим типичные проблемы в UX, которые встречаются в приложениях как стартапов, так и больших корпораций.

UX — user experience, пользовательский опыт — термин, под который сложно подобрать точное определение, но важность которого сложно переоценить. UX во многом определяет то, какие впечатления останутся у пользователя от взаимодействия с приложением.

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

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

Но за этими широкими мазками часто не прописываются мелкие, но важные детали. Как должна вести себя кнопка при нажатии? Должен ли ввод текста начинаться с большой буквы? Показывать ли автоматически клавиатуру?

Очень часто такие вещи не детализируются в задаче, которая попадает к разработчику. Я наблюдал такое и в стартапах, и в корпорациях (особенно в тех, что «с атмосферой стартапа»), и ранее в нашей студии.

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

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

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

Сделали фичу – протестируйте её. Все ли продумано, все ли удобно нажимать, все ли работает так, как ожидаешь? Приходится ли делать лишние движения, чтобы сделать целевое действие? Если да, стоит подумать, как спрямить взаимодействие пользователя с приложением.

Далее мы рассмотрим типичные кейсы, которые могут предотвратить разработчики, и которые часто не описываются в тасках и макетах.

В Android размеры области нажатия должны быть в ширину и высоту не меньше, чем 48 dp, в iOS не менее 44 points. Мнение Google и Apple.

Частый сценарий: что делать, если у вас картинка 24 dp x 24 dp? Нужно сделать элементу внутренний отступ (padding) во все стороны по 12 dp (пример для Android).

Таким образом, кликабельная зона будет 48 dp, но элемент выглядит как 24 dp. Реакция на нажатие подскажет пользователю, что реальная зона нажатия побольше.

Если у этой картинки есть внешние отступы (margin) от других элементов, то увеличенный размер самой картинки надо не забыть учесть при высчитывании margin-ов. То есть, если картинка у вас (или в макете) была 24dp, margin справа был 16dp, то теперь margin справа станет 4 dp, так как 12dp съел padding.

У кликабельных элементов должна быть реакция на нажатие. Это важно, потому что:

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

Часто можно встретить такую проблему: на экране есть несколько элементов, расположенных вертикально друг за другом. На большом экране все хорошо, но на маленьком оказывается, что нижние элементы не видны, так как нет скролла. Или проблема может всплыть, если повернуть экран в landscape.

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

Особенно это может быть проблемой, если есть поле для ввода и что-то под ним — если покажется клавиатура, то посмотреть, что под ней, можно только скрыв ее, что неудобно.

Частая ошибка. Например, у вас открывается экран поиска. Или открывается диалог, в котором нужно ввести название чего-нибудь. Или экран с вводом кода из смс. В общем, если в 9 случаях из 10 пользователь на этом экране тут же нажмет на форму ввода текста, то стоит ему помочь: автоматически установить фокус в поле ввода и открыть клавиатуру.

Впрочем, тут стоит знать меру. Если UI довольно сложный, и пользователю нужно видеть его весь, есть хорошая вероятность, что он не начнёт сразу вводить текст, то клавиатуру показывать не стоит.

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

Ошибка встречается на Android: пользователь ввел данные, нажал «Submit», экран сменился, или диалог закрылся, а клавиатура осталась. Хотя поля для ввода уже нет. Или вариация: на «submit» клавиатура закрывается, но не закрывается, если пользователь уходит с экрана через кнопку назад в левом верхнем углу в тулбаре. Клавиатуру в таких ситуациях нужно автоматически закрывать.

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

Более того — для многих случаев, например, мессенджера, начало каждого предложения должно быть с большой буквы. Реализуется это просто, в каждой операционной системе это есть из коробки, достаточно указать полю ввода верные свойства.

Допустим, у вас несколько полей для ввода. Например, при заполнении данных в профиле или при регистрации.

Здесь, если пользователь заполнил поле «Имя», то при нажатии на клавиатуре «Enter» (кнопка должна автоматически называться «Далее»), фокус должен автоматом перейти на следующее поле ввода. На Android система обычно делает это автоматически (но за ней стоит проверить), на iOS это поведение надо задавать вручную.

Проблема возникает при заполнении данных в какой-нибудь форме. Например, пользователь вводит данные для логина. Или вводит что-то в диалоговом окне. Или на отдельном экране.

Чаще всего после заполнения последнего поля, пользователь сразу готов к отправке формы. Поэтому при нажатии им на enter на клавиатуре, нужно вызвать отправку формы программно, как если бы пользователь нажал на кнопку «Submit».

Тут, например, если пользователь, после того, как введет пароль, нажмет на клавиатуре «Enter», автоматически должен произойти submit (то есть то же самое, что и нажатие на кнопку «Войти»).

Кстати, на клавиатуре надпись на кнопке enter можно выбирать из нескольких предложенных системой вариантов, чтобы пользователю было еще понятнее, что будет при нажатии.

Допустим, пользователь нажал на «Submit» при регистрации. Обязан быть какой-то индикатор того, что запрос ушел, например, где-то на экране должен появится спиннер. По-хорошему, этот индикатор должен рисовать дизайнер. Если дизайнер не нарисовал, и с ним по какой-то причине не связаться, есть ряд типовых решений.

Если речь идет не про отправку, а про загрузку данных, то опять же нужен индикатор. Типовые решения: вместо места, где будут данные, показать спиннер. Если список с pull-to-refresh, можно показать pull-to-refresh.

Было упомянуто в предыдущем пункте. Допустим, на экране логина пользователь ввел данные, нажал кнопку «Войти». Если кнопка не заблокировалась, то, пока идет общение с сервером, пользователь может нажать на неё еще раз.

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

Например, у вас есть выдвижная панель. Если она выглядит так, как будто ее можно убрать плавно свайпом, то такая возможность должна быть. Причем панель должна адекватно следовать за пальцем, а не работать в духе «свайп вверх = скрытие панели».

Актуально для андроида. Иногда нажатие на системную кнопку назад ведет себя слишком агрессивно. Например, посмотрим на все тот же экран с выдвижным элементом на часть экрана:

На нём выдвинута шторка сверху. Нажатие на кнопку назад не должно переходить на предыдущий экран или закрывать приложение — оно должно просто закрыть эту шторку. Подобное верно для различных диалогов и прочего.

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

Мы описали не все, но наиболее частые проблемы. Не допускать их достаточно легко, нужно лишь обращать внимание на детали. И помните, что самое главное — всегда ставить себя на место пользователя!

Мы в студии Doubletapp всегда стараемся сделать максимально качественный продукт, который будет полностью соответствовать ожиданиям пользователя и не будет его раздражать. К чему призываем и вас.

#ux #mobile #android #ios