Избегайте плохих практик в дизайне iOS и Android

Сколько обычных людей вы видели, использующих устройства iOS и Android одновременно ? Официальные цифры, согласно этому исследованию, колеблются от 10% до 20%, но эта цифра включает и пользователей Mac, а не только пользователей мобильных устройств. На практике люди, как правило, используют только один телефон или планшет в течение определенного периода времени. Если они используют два устройства, чаще всего на обоих будет работать одна и та же ОС.

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

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

Почему это все еще проблема?

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

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

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

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

Сосредоточьтесь на пользователях, а не на внешнем виде

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

Начиная со среднего бюджета, люди решают тратить на технологии в месяц ( iPhone: 100,88 долларов США, Android: 50,83 долларов США ) , пропуская количество селфи, которые они делают в день для iPhone: 12, Android: 7 , и получая тексты, которые они отправляют каждый день iPhone : 57, Android: 26 , легко заметить, что различия существенны, и мы можем заключить, что существует расхождение в поведении, которое определяет то, как люди используют свои устройства.

Итак, на чем мы должны сосредоточиться при разработке приложений для обеих платформ одновременно?

Прежде всего, по возможности используйте нативные элементы. Даже если вы используете кросс-платформенный фреймворк, большинство компонентов основаны на чисто нативных представлениях; так что, если вам действительно не нужно что-то нестандартное — придерживайтесь основ. Людям нравится использовать то, к чему они привыкли, и вы сэкономите время на разработку более важных функций (и проверки кода!).

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

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

Как подходить к различным компонентам дизайна

Как правило, всегда помните, что каждая платформа имеет свои собственные рекомендации по дизайну. Набор подходов Android основан на Material Design, в то время как Apple доверяет Human Interface Design. Что касается конкретных компонентов, которые мы должны учитывать при планировании нашего дизайна, то есть несколько основных частей, на которых следует сосредоточиться:

1. Общий стиль: если мы не говорим о кросс-платформенном приложении, мы должны учитывать общие принципы стиля для каждой платформы. В целом дизайн iOS имеет тенденцию быть более плоским, в то время как Android использует более многоуровневый подход.

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

2. Аппаратные особенности и шаблоны навигации: это, вероятно, один из самых ярких примеров негатива прямого клонирования вашего приложения. Большинство устройств Android по-прежнему имеют удобную дополнительную панель навигации (будь то аппаратное или программное обеспечение на разных устройствах), включая кнопку «Назад». Поскольку iOS не предоставляет этого, приложения должны учитывать, где и когда предоставлять кнопку «Назад», обычно в верхнем левом углу каждого экрана.

   Кнопка меню (квадратная кнопка в этом примере) также может предоставлять дополнительные функции для приложений Android. Где это актуально? Например, при открытии меню настроек или аналогичной функции навигации.

   

   До недавнего времени в iPhone также использовалась традиционная кнопка «Домой» от Apple, но с момента появления iPhone X она была отодвинута на второй план, и поток в iOS теперь основан на жестах. Если смахивание является важной частью вашего приложения, убедитесь, что между краем контейнера приложения и областью смахивания достаточно места, чтобы избежать сложных совпадений смахивания.

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

3. Глобальные элементы (строки состояния, заголовки и т. д.): компоненты, которые появляются на всех страницах вашего дизайна, такие как строка состояния, навигационный заголовок и т. д., должны быть строго нацелены на создание естественного ощущения, поэтому мы не должны их менять. высота и стиль этих баров. Существуют небольшие различия в том, как стилизуются глобальные элементы на обеих платформах. Например, Android использует текст, выровненный по левому краю, а iOS — заголовок по центру. Строка состояния — это встроенный компонент, поэтому вам не нужно об этом беспокоиться, но имейте в виду различные выемки и соотношения сторон экрана при планировании верхней части вашего приложения.

   

   

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

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

   

5. Типографика: обе платформы имеют свои шрифты по умолчанию — San Francisco для iOS и Roboto для Android. Если вы не собираетесь использовать собственный шрифт, точно соответствующий вашему общему стилю приложения, вам следует придерживаться значений по умолчанию. Имейте в виду, что пользователи могут изменить свой системный шрифт по умолчанию, и это не повлияет на представления, которые вы настроили с помощью определенного шрифта.

   Например, у пользователей с дислексией может быть не лучшее время в вашем приложении, если они заменили шрифт по умолчанию на шрифт, который специально соответствует их потребностям. Если вы поддерживаете пользователей, которые могут использовать нелатинские шрифты (например, кириллицу, арабский и т. д.), убедитесь, что ваши пользовательские шрифты также предоставляют эти дополнительные символы. Если вы увлекаетесь играми, вы, вероятно, видели те таблицы лидеров с высокими баллами, достигнутыми российскими игроками, чьи имена выделяются из-за их другого шрифта. Это всего лишь незначительная ошибка, допущенная на этапе разработки, а не «функция» для конкретных игроков, и хотя она, вероятно, не заставит пользователей отказаться от вашего приложения, она определенно может привести к ухудшению пользовательского опыта или привести к жалобам или плохим отзывам.

   

6. Другие компоненты: кнопки, экранные переходы, анимация, микровзаимодействия, листы действий, оповещения и все другие типы управления потоком выходят за рамки этой статьи, но они должны следовать общему принципу, который мы применяли до сих пор к другим элементам дизайна — обе платформы не одобряют чрезмерное количество настраиваемых элементов, поскольку они могут отвлекать и сбивать с толку пользователя; когда дело доходит до дизайна, первое впечатление обычно оказывается последним для многих пользователей, и именно поэтому так важно с самого начала привлечь внимание пользователей и заставить их чувствовать себя, так сказать, как дома.

В реальном мире вы можете увидеть некоторые очень популярные исключения из обсуждаемых нами правил — приложения для iOS, которые следуют рекомендациям по материальному дизайну, и некоторые продукты для Android, соответствующие рекомендациям Apple по человеческому интерфейсу, но эти приложения имеют свой собственный, проверенный стиль. Пользователи знакомы с приложениями и их дизайном, и для них имеет смысл предоставить немного более индивидуальное ощущение.

Кроссплатформенный подход реализован правильно

С другой стороны, если ваш проект основан на кросс-платформенном решении (например, React Native, Flutter, Xamarin и т. д.), вам следует подумать, на какой основной платформе вы хотите сосредоточиться, и начать с нее.

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

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

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

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

Хороший дизайн учитывает привычки пользователей

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

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

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