Як створити дизайн аплікації в 2026 році?
Вітаю, для тих хто тут вперше, хотів би представитись - моє імʼя Артем Гаража, я соло розробник андроїд аплікацій. Ця діяльність для мене відносно нова. Мій пілотний проєкт має назву "Pin Up Retro Manner". "Pin Up Retro Manner" це аплікація читалка, яка присвячена неймовірному стилю 50х років під назвною Pin Up. Якщо хочете більше дізнатись про мою аплікацію - заходьте на сайт аплікації "Pin Up Retro Manner", або підписуйтесь на мою сторінку в інстаграм - Артем Гаража.
Отже, з чим я стикнувся при аналізі ринку.
Коли я починав створювати свою першу аплікацію, я був типовим молодим інді-розробником. У мене була ідея, базові навички програмування і величезне бажання нарешті зробити щось своє.
Спочатку я думав, що найважливіше - написати код. Потім зрозумів, що не менш важливо пояснити користувачу, що саме я створив і навіщо це йому потрібно.
Саме тут почалася моя робота над дизайном.
Але я вирішив не починати з кольорів, шрифтів і красивих кнопок. Спочатку я почав шукати статистику про поведінку користувачів мобільних застосунків.
І цифри досить швидко змінили моє уявлення про хороший дизайн.
Перша проблема - користувачі дуже швидко йдуть. Однією з найважливіших статистик для мене став retention.
За даними OneSignal Mobile App Benchmarks, середній retention мобільних застосунків становить 28,29% на наступний день після встановлення, 17,86% на сьомий день і лише 7,88% на 30-й день. Дані охоплюють різні категорії мобільних застосунків. Якщо уявити 100 нових користувачів, то приблизно 28 із них залишаються активними наступного дня, а через місяць - лише близько 8.
Для мене це стало важливим сигналом. Я зрозумів, що дизайн першого екрану не може бути просто красивим. Він повинен якомога швидше показати користувачу цінність продукту. Цей графік фактично визначив мою першу дизайнерську ціль: не змусити користувача захоплюватися інтерфейсом, а допомогти йому зрозуміти продукт у перші секунди. Тому я змінив onboarding.
Спочатку я хотів зробити довгий onboarding із декількома слайдами.На кожному екрані планував розповісти про окрему функцію: що вміє аплікація, як працює пошук, які є налаштування і чому користувачу варто залишитися. Зараз я розумію, що це було б схоже на інструкцію до холодильника ще до того, як людина відкрила його дверцята. Я скоротив onboarding до найважливішого. Кожен екран повинен був відповідати на одне питання:
«Що я отримаю від цієї аплікації?»
Цікаво, що статистика OneSignal також показує зв'язок onboarding із подальшим залученням: компанія повідомляє, що застосунки, які використовують onboarding-повідомлення, мають вищий 30-day retention, а також наводить 24% вищу install-to-purchase conversion для таких застосунків. Це не означає, що будь-який onboarding автоматично покращує продукт, але для мене це стало аргументом на користь продуманого першого досвіду.
Тому я вирішив не відмовлятися від onboarding - я вирішив зробити його коротким і корисним.
Я почав видаляти функції Наступна проблема була навіть складнішою. Як розробнику мені хотілося показати користувачу все, що я вже встиг зробити. Є функція - треба показати її на головному екрані. Є налаштування - треба додати меню. Є додаткова можливість - чому б не зробити ще одну кнопку? Але поступово мій головний екран перетворювався на панель керування літаком. Тоді я поставив собі просте питання:
Яка одна дія є найважливішою для користувача?
Після цього я почав прибирати все, що заважало цій дії. Це був один із найважливіших уроків мого першого проєкту: іноді хороший дизайн - це не те, що ти додав, а те, що ти зміг видалити. Я почав дивитися не тільки на retention. Після retention я звернув увагу на те, які метрики Google Play використовує для оцінки якості застосунків.
Google прямо зазначає, що використовує такі сигнали, як uninstalls/user loss, DAU і MAU, а також враховує usability, performance, рекламне навантаження та глибину контенту або функціональності порівняно з іншими застосунками.
Особливо мене зацікавив показник DAU/MAU.
DAU - це кількість активних користувачів за день, MAU за місяць. Google вказує поріг DAU/MAU понад 8% як один із критеріїв для певних quality treatments у Google Play. User loss rate при цьому має бути нижчим за 5%. Це не означає, що 8% - універсальна «хороша оцінка» для кожної аплікації. Це конкретний поріг Google для певних механізмів оцінки якості.
Але для мене це дало правильний напрямок мислення. Я почав думати не тільки про те, як отримати встановлення, а й про те, чому людина повинна повернутися завтра.
Але є ще одна проблема - аплікація повинна нормально працювати. Під час роботи над дизайном я спочатку майже не думав про crashes і ANR. Здавалося, що це вже технічна частина, яка не має стосунку до дизайну.
Тепер я думаю інакше.
Google Play прямо зазначає, що Android vitals впливають на технічну якість і видимість застосунку в Google Play. До core vitals належать user-perceived crash rate та user-perceived ANR rate.
Для мене особливо показовими стали два пороги. Google визначає 1,09% user-perceived crash rate як загальний bad behavior threshold і 0,47% user-perceived ANR rate. Якщо застосунок перевищує ці значення, це може негативно впливати на його видимість у Google Play.
Технічна якість — теж частина UX.
Це змінило навіть моє ставлення до анімацій. Спочатку мені хотілося зробити багато красивих переходів, ефектів і складних компонентів. Потім я подумав: якщо анімація не допомагає користувачу зрозуміти інтерфейс, навіщо вона взагалі потрібна?
У першій версії я саме тому віддав перевагу простим переходам, швидкому завантаженню і передбачуваній поведінці. Красива аплікація, яка зависає - це поганий дизайн. Я почав проектувати шлях користувача. Після цього я перестав малювати окремі екрани. Я почав малювати сценарії. Користувач встановлює аплікацію 👉 Відкриває її 👉 Розуміє, що вона робить 👉 Виконує основну дію 👉 Отримує перший результат 👉 Потім закриває аплікацію.
І головне питання стало таким:
Що повинно змусити його відкрити її завтра?
Це повністю змінило моє сприйняття дизайну.
Я почав дивитися на кожен екран як на частину одного маршруту, а не як на самостійну красиву картинку. Що я зрозумів як молодий інді-розробник, до створення першої аплікації я думав, що дизайн - це переважно Figma, кольори, шрифти, іконки та композиція.
Тепер я думаю інакше.
Дизайн — це спосіб вирішувати проблеми користувача.
Статистика OneSignal показала мені, наскільки швидко користувачі залишають мобільні застосунки: від 28,29% retention на першому дні до 7,88% на 30-му.
Google Play показав іншу сторону проблеми: важливі не тільки встановлення, а й user loss, DAU/MAU, crashes, ANR та загальна технічна якість. Тому я почав створювати свою аплікацію від цифр.
Не тому, що статистика може сказати мені, який колір кнопки вибрати. Вона не може. Але статистика може підказати, яку проблему потрібно вирішувати в першу чергу. Якщо користувачі не повертаються — потрібно досліджувати цінність продукту та перший досвід. Якщо люди встановлюють, але не виконують основну дію - потрібно дивитися на onboarding і навігацію.
Якщо застосунок падає або зависає - проблема вже не в кольорі кнопки.
А якщо люди регулярно повертаються, виконують основну дію і залишаються активними - тоді можна починати думати про те, чи достатньо красивий інтерфейс.
Саме так я створював дизайн своєї першої аплікації.
Спочатку — користувач. Потім — статистика. Потім — дизайн.
І тільки після цього — код.
Для інді-розробника це, мабуть, один із найважливіших уроків: коли у тебе немає великої команди та необмеженого бюджету, твоїм головним інструментом стає не кількість функцій, а здатність приймати правильні рішення на основі даних.
І якщо Вам сподобалась ця стаття, будь ласка підписуйтесь на сторінку моєї аплікації у Facebook - Pin Up Retro Manner . Та якщо є бажання ви завжди можете зʼвязатись з автором цього блогу, та творцем Pin Up Retro Manner, Артемом Гаражей, або пишіть на електронну адресу.
Коментарі
Дописати коментар