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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Анимация

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

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

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

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

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

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

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

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

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

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

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

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

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

Что делать

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

Почему в примерах "натив/не натив" приятнее смотреть на ненативный дизайн?

5
Ответить

наверное, потому что вы смотрите на дизайн моб. приложения, удобно расположившись перед компом. В реальной жизни в приложении редко рассматривают "приятность", а требуется функциональность и понятность.
Автор говорит о том, что если вы делаете дизайн приложения - делайте в соответствии с гайдлайнами, т. е. обратитесь к тому, кто знает их.
Отступать от них можно, если знать, зачем. Отступление предполагает удорожание разработки и поддержки.
По-моему, это очевидно)
Встречаю приложения, которые вообще выглядят, как моб. версия сайта.

3
Ответить
Комментарий удалён модератором
Комментарий удалён модератором

Foma, спасибо за комментарий.
Нативную навигацию можно и нужно совмещать с фирменным стилем. В чем Вы видите противоречие?
Если мы не берем игры или специфические ниши, то привычная понятная навигация облегчает задачу продуктовую дизайну. Не надо учить и объяснять, какой элемент за что отвечает. Но если задача за счет нестандартной навигации и элементов выделиться, то отлично – давайте делать.

Ответить

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

Так, ладно, а если она опережает свое время на пару поколений, она все-равно со следующим обновлением будет визуально устаревшей?

Глобальная навигация проекта через «гамбургер меню» — это проблема.

Для iOS проблема, а для Android норм?

Используя кнопку «Вверх», вы попадаете из любого экрана в начало ветки.

https://material.io/guidelines/patterns/navigation.html#navigation-up-back-buttons в документации написано по-другому — up возвращает пользователя по экранам внутри приложения, back - то же самое, но по глобальной истории переходов (может быть через несколько приложений)

Хотелось бы пожелать авторам статьи больше работать над аргументацией и языком (а то большая часть аргументов выглядит как "надо делать вот так, потому что так вот надо делать"), а редакторам vc не пропускать подобный шлак

3
Ответить

А еще у авторов сайт будто бы семилетней давности и с лобстером и гельветикой, оок)

2
Ответить