Нативний дизайн VS веб-елементи: що краще (Частина 2)

Що краще – нативний дизайн чи веб-елементи – ця суперечка постійно точиться між дизайнерами, розробниками та продакт-менеджерами. Сьогодні ми пропонуємо вам 2-гу частину цікавих роздумів дизайнера Артема Щапа – про те, чому в мобільній розробці краще використовувати нативний дизайн замість веб-елементів.

Першу частину можна прочитати тут

Частина 2

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

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

В iOS і Android різна архітектура побудови екранів

Для iOS додатків навігація будується лінійно за допомогою Tapbara. Глобально в додатку існують кілька основних гілок. Перебуваючи на одній гілці, ви не можете перейти на іншу.

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

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

За допомогою кнопки «Назад», як і в iOS, ви повертаєтеся по кроку назад до самого початку. Використовуючи кнопку «Вгору», ви потрапляєте з будь-якого екрану в початок гілки. В такому випадку дуже важливо правильно побудувати і пропрацювати сценарії цих кнопок, щоб не заплутати користувача.

Анімація

Нерідко клієнт хоче особливу анімацію – «ось так, щоб піни падали на карту і ще меню пошарово виїжджало». Доречна і красива анімація покращує досвід взаємодії. Недоречна – збільшує терміни і коштує дорого.

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

Потрібні вони для того, щоб показати користувачеві, звідки береться контент і куди зникає. Це покращує взаємодію з додатком.

Використовувати свою кастомную анімацію дорого. Так, це красиво і створює правильні очікування, але чи окупиться вона? Це дійсно кратно вплине на показники програми? Бажано використовувати нативну анімацію і обережно ставитися до кастомної.

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

Буває, клієнт приходить з дизайном 10-15 основних екранів, думаючи, що на цьому робота дизайнера завершена. Втрачені сценарії виливаються в довгий термін доробок і погоджень. Нерідкі такі розмови:

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

Р: Так його немає на дизайні.

К: Це стандартна річ, я думав, і так зрозуміло.

Деталізація стану елементів і сценаріїв залежить від вашої впевненості в розробнику. Якщо такої впевненості немає, на дизайні детально опрацювати всі сценарії і стану. Це заощадить час і нерви при розробці. І допоможе написати детальне технічне завдання.

Що робити

  • Переконайтеся, що дизайнер знає вимоги операційних систем і використовує нативні елементи. Знає особливості логіки побудови екранів для Android і iOS.
  • Хочете намалювати ненативний елемент? Ок, звірте з бізнес-завданнями. Якщо ви впевнені, що це кратно вплине на показники програми (наприклад, збільшить відсоток реєстрацій) або на продажі (конверсія, покупки), тоді робіть.

_______

Шукайте більше цікавих матеріалів у нашій рубриці “Лонгріди

Залишити відповідь