«Дизайн сделает знакомый веб-дизайнер, а мобильную разработку закажем отдельно» Статьи редакции

Арт-директор студии разработки WOXAPP Артем Щап о том, почему в мобильной разработке лучше использовать нативный дизайн вместо веб-элементов.

К нам часто приходят клиенты с готовым дизайном, сделанным без учета требований операционных систем iOS и Android. Хорошие веб-дизайнеры рисуют проблемный для мобильной разработки интерфейс.

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

Собрали несколько рекомендаций, как этого избежать.

Написанное является нашим опытом в нативной мобильной разработке. Будем рады, если поделитесь своим опытом, комментариями и дополнениями.

У Apple и Google свои принципы построения интерфейсов и свой визуальный язык.

• Для Android это концепция Material Design.
• Для iOS – iOS Human Interface Guidelines.

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

Многие называют это «нативным дизайном».

Чем грозит использование «ненативных» элементов при создании дизайна?

1) Увеличение и сроков, и затрат.

Например, вам захотелось необычный свитчер, как у вас на сайте. Вместо стандартного элемента, который добавляется одной строчкой кода, вы прорабатываете все состояния элемента (включен, выключен, зажат, неактивен), адаптируете его под ориентации экрана и так далее. Это увеличивает время и деньги. Добавить нативный элемент можно за 0-3 часа, а сделать свой – за 1-2 дня.

2) Поддержание старых версий операционных систем.

С выходом новой операционной системы или API вам придется поддерживать красивый вебовский элемент для всех предыдущих версий.

Давайте на пальцах. Вам нужна переключалка на Android.

Вариант первый. Вы берете нативную переключалку (Switch).

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

Вариант второй. Вы рисуете «свою», красивую, не как у всех, переключалку. С обновлением операционной системы эта переключалка меняться не будет, она такой и останется. Во-первых, в свежей ОС будет ваш визуально устаревший элемент. Во-вторых, на всех ранних версиях нужно следить за корректностью работы и поддерживать этот элемент. Оно вам надо?

Слева – экран приложения с ненативными элементами. Справа – с нативными.

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

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

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

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

Дизайн для Android и iOS это два разных дизайна. На примере – один экран приложения для такси для разных платформ.

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

Глобальная навигация проекта через «гамбургер меню» — это проблема. Например, в iOS это порождает довольно много проблем, так как нативная архитектура приложения строится «веточно» через TabBar, нативного элемента «гамбургер» нет.

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

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

В iOS и Android разная архитектура построения экранов

Для iOS приложений навигация строится линейно при помощи Tapbara. Глобально в приложении существуют несколько главных веток. Находясь на одной ветке, вы не можете перейти на другую.

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

Для Android сценарий строится немного иначе. Навигация строится при помощи кнопок «Назад» и «Вверх». Переключаться между вложенностями экрана можно не только линейно.

При помощи кнопки «Назад», как и в iOS, вы возвращаетесь по шагу назад до самого начала. Используя кнопку «Вверх», вы попадаете из любого экрана в начало ветки. В таком случае очень важно правильно построить и проработать сценарии этих кнопок, чтобы не запутать пользователя.

Нередко клиент хочет особую анимацию — «вот так, чтобы пины падали на карту и еще меню послойно выезжало». Уместная красивая анимация улучшает опыт взаимодействия. Неуместная — увеличивает срок и стоит дорого.

iOS и Android имеют несколько десятков нативных анимаций. Например, перелистывания экранов, анимация всплывающих окон, нажатия на кнопки и ожидания загрузки.

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

Использовать свою кастомную анимацию дорого. Да, это красиво и создает правильные ожидания, но окупится ли она? Это действительно кратно повлияет на показатели приложения? Желательно использовать нативную анимацию и осторожно относиться к кастомной.

Бывает, клиент приходит с дизайном 10-15 основных экранов, думая, что на этом работа дизайнера завершена. Упущенные состояния и сценарии выливаются в долгий срок доработок и согласований. Нередки такие разговоры:

К: Я думал, после нажатия будет окно с подтверждением!

Р: Так его нет на дизайне.

К: Это стандартная вещь, я думал, и так понятно.

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

1. ​Убедитесь, что дизайнер знает требования операционных систем и использует нативные элементы. Знает особенности логики построения экранов для Android и iOS.
2. Хотите нарисовать ненативный элемент? Ок, сверьте с бизнес-задачами. Если вы уверены, что это кратно повлияет на показатели приложения (например, увеличит процент регистраций или возвращаемость в приложение) или на продажи (конверсия, покупки), тогда делайте.

#Интерфейсы #iOS #Android #Material_Design