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

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

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

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

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

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

Следование гайдлайнам

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

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

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

0c16eff0250ce6.png
6d6f8066f11b65.png

Использование ненативных элементов в дизайне

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

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

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

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

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

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

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

01383c7d53c210.png

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

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

9bc4213289ae45.png

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

6330a8e2de3e16.png

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

ddfe0f657ee16b.png

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

ebd28c99cc240e.png

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

90c6d224964dc3.png

Элементы кочуют с iOS в Android и обратно

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

355e871211ba31.png

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

ea74ded33832d0.png
c59132579ed429.png
47b3523dc6c93d.png
0e497e5b3eabe4.png
2189c7a80c296c.png

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

Меню «гамбургер»

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

755d852c54a127.png

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

9784f13677e104.png
Изменение паттерна навигации и отказ от «гамбургер меню» повлекли за собой увеличение сеансов (+ 70%) и возвращение пользователей (+ 65% DAU).

Дизайн-архитектура

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

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

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

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

3fd05669bbb129.png

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

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

5adb496149b231.png

Анимация

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

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

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

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

Детализация сценариев

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

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

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

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

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

6e69928c5faa7d.png

Что делать

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

©  vc.ru