Що краще – нативний дизайн чи веб-елементи – ця суперечка постійно точиться між дизайнерами, розробниками та продакт-менеджерами. Сьогодні ми пропонуємо вам 2-гу частину цікавих роздумів дизайнера Артема Щапа – про те, чому в мобільній розробці краще використовувати нативний дизайн замість веб-елементів.
Першу частину можна прочитати тут
Частина 2
Дизайн-архітектура
Кажучи про дизайн мобільного додатка, ми маємо на увазі не тільки візуальні рішення, але і його архітектуру. Навігація в додатку і правильна структура контенту продумуються в першу чергу.
В iOS і Android різна архітектура побудови екранів
Для iOS додатків навігація будується лінійно за допомогою Tapbara. Глобально в додатку існують кілька основних гілок. Перебуваючи на одній гілці, ви не можете перейти на іншу.
Наприклад, повернутися з третього кроку відразу на нульовий не можна, вам потрібно лінійно повертатися на попередній крок. З третього повернутися на другий, з другого на перший і тільки тоді – до початку гілки.
Для Android сценарій будується трохи інакше. Навігація відбувається за допомогою кнопок «Назад» і «Вперед і вгору». Перемикатися між вкладеннями екрану можна не тільки лінійно.
За допомогою кнопки «Назад», як і в iOS, ви повертаєтеся по кроку назад до самого початку. Використовуючи кнопку «Вгору», ви потрапляєте з будь-якого екрану в початок гілки. В такому випадку дуже важливо правильно побудувати і пропрацювати сценарії цих кнопок, щоб не заплутати користувача.
Нерідко клієнт хоче особливу анімацію – «ось так, щоб піни падали на карту і ще меню пошарово виїжджало». Доречна і красива анімація покращує досвід взаємодії. Недоречна – збільшує терміни і коштує дорого.
iOS і Android мають кілька десятків нативних анімацій. Наприклад, перегортання екранів, анімація спливаючих вікон, натискання на кнопки і очікування завантаження.
Потрібні вони для того, щоб показати користувачеві, звідки береться контент і куди зникає. Це покращує взаємодію з додатком.
Використовувати свою кастомную анімацію дорого. Так, це красиво і створює правильні очікування, але чи окупиться вона? Це дійсно кратно вплине на показники програми? Бажано використовувати нативну анімацію і обережно ставитися до кастомної.
Деталізація сценаріїв
Буває, клієнт приходить з дизайном 10-15 основних екранів, думаючи, що на цьому робота дизайнера завершена. Втрачені сценарії виливаються в довгий термін доробок і погоджень. Нерідкі такі розмови:
К: Я думав, після натискання буде вікно з підтвердженням!
Р: Так його немає на дизайні.
К: Це стандартна річ, я думав, і так зрозуміло.
Деталізація стану елементів і сценаріїв залежить від вашої впевненості в розробнику. Якщо такої впевненості немає, на дизайні детально опрацювати всі сценарії і стану. Це заощадить час і нерви при розробці. І допоможе написати детальне технічне завдання.
Що робити
- Переконайтеся, що дизайнер знає вимоги операційних систем і використовує нативні елементи. Знає особливості логіки побудови екранів для Android і iOS.
- Хочете намалювати ненативний елемент? Ок, звірте з бізнес-завданнями. Якщо ви впевнені, що це кратно вплине на показники програми (наприклад, збільшить відсоток реєстрацій) або на продажі (конверсія, покупки), тоді робіть.
_______
Шукайте більше цікавих матеріалів у нашій рубриці “Лонгріди“