Між швидкістю MVP та інклюзивністю: як адаптувати мобільний застосунок під VoiceOver та TalkBack

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Привіт! Мене звати Тимофій, я Product Owner в Uklon. Нещодавно ми завершили адаптацію застосунку до міжнародних стандартів інклюзивності. Ця робота тривала протягом року, і спойлер: це лише початок нашого шляху. Далі я розповім про специфіку адаптації, технічні виклики та що потрібно врахувати, щоб зробити ваш продукт більш інклюзивним.

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

Проте з часом стало очевидно: точкових покращень замало. Виникла потреба комплексно переглянути та проаналізувати всі користувацькі сценарії з погляду доступності, щоб зробити інтерфейс максимально зручним для людей з інвалідністю.

Окрім очевидних візуальних чи технічних змін, нам було важливо отримати об’єктивну, незалежну оцінку продукту та підсвітити приховані бар’єри. Для цього ми залучили експертів із цифрової доступності з компанії Access Lab. Результатом цього комплексного аудиту став чіткий план дій та рекомендації, які наблизять наш застосунок до відповідності міжнародним стандартам.

Технічний виклик № 1: Чому найскладнішим етапом став повний перегляд UI-тегів

Робота VoiceOver та TalkBack базується на правильній розмітці екрана: кожен UI-елемент повинен мати відповідні атрибути й теги, які зчитуються скрінрідерами.

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

Нам довелося детально проаналізувати та заново налаштувати весь інтерфейс: виявити невідповідності, повністю переписати accessibility-лейбли, структурувати їх та локалізувати, щоб забезпечити правильне й чітке озвучування кожної дії користувача.

Технічний виклик № 2: Адаптація динамічного real-time екрана

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

Щоб забезпечити якісну та своєчасну комунікацію, ми розділили розв’язання цієї проблеми на два рівні:

  • Оптимізація динамічного екрана (In-App): Ми налаштували фокус скрінрідерів так, щоб вони коректно та без затримок озвучували найважливіші зміни безпосередньо в інтерфейсі застосунку під час його оновлення.
  • Дублювання через системні сповіщення: Кожна критична зміна статусу супроводжується інформативними push-нотифікаціями. Коли водій призначений, під’їжджає чи чекає, користувач отримує чітке сповіщення. Скрінрідери миттєво перехоплюють такі повідомлення, тож людина завжди поінформована, що відбувається із замовленням.

Міф про те, що accessibility «вбиває» дизайн

Потребу в покращенні контрастності ми чітко усвідомили після аудиту, але на практиці адаптація виявилася значно простішою за наші побоювання. Нас урятувала зріла дизайн-система: замість ручної перебудови інтерфейсу чи радикальних компромісів зі стилем, ми просто скоригували колірні токени окремих елементів до нормативних показників (відповідно до міжнародних стандартів).

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

Марафон завдовжки в рік: головні інсайти аудиту

Наша співпраця з Access Lab тривала протягом року, і з боку партнерів ми отримали максимальне залучення у тестування продукту. Цей досвід приніс нашій команді кілька фундаментальних інсайтів:

  1. Охопити все за один спринт — неможливо. Коли ми побачили реальний обсяг результатів аудиту, одразу стало зрозуміло: «мало роботи не буде». Ми тверезо оцінили ресурси та розбили реалізацію рекомендацій на кілька ітерацій, розподілених на весь рік.
  2. Доступність — це частина повсякденних процесів. Головне відкриття полягає в тому, що робота над доступністю легко інтегрується в щоденну рутину команди. Якщо правильно побудувати процеси та автоматизувати базові перевірки, адаптація стає органічною частиною розробки та мінімально навантажує команду.
  3. Стовідсоткова доступність — це міф. Навіть після релізу основних покращень наша робота не зупиняється. Досягти абсолютного 100% покриття вкрай складно, адже завжди існують специфічні корнер-кейси. Продукт оновлюється, з’являються нові фічі, тому увагу accessibility потрібно приділяти під час кожного релізу.

Валідація інтерфейсу відбувалася за безпосередньої участі респондентів від Access Lab — людей із порушеннями зору та моторики. Якщо на перших запусках вони регулярно стикалися із критичними бар’єрами й подекуди просто не могли завершити флоу замовлення авто, то фінальні тести довели: час на оптимізацію коду був витрачений недарма. Респонденти відзначили, що весь шлях від відкриття застосунку до виклику авто тепер проходить гладко й без бар’єрів. Почути від людей такий фідбек — це найкраща метрика успіху для нашої команди.

Що далі: баланс між MVP та інклюзивністю

Якщо говорити про специфічні корнер-кейси та розширення основного флоу — роботи попереду ще дуже багато. Наш головний виклик зараз — зробити так, щоб безбар’єрність стала одним з основних пріоритетів команди та критерії доступності враховувалися під час створення кожної нової фічі.

Крім того, Uklon — це вже давно не лише райдхейлінг. Усі інші продукти нашої екосистеми так само потребують детального аналізу та адаптації. Звісно, коли ми створюємо нові сервіси, бізнес вимагає швидкого запуску MVP. Проте у нас є залізне правило: можемо не відкривати нову послугу для широкого загалу, доки повністю не адаптуємо її інтерфейс. Користувач не повинен ставати бета-тестувальником у сирому середовищі — він має від самого початку отримувати якісний сервіс без бар’єрів.

Безбар’єрність не обмежується лише екраном смартфона, — паралельно з адаптацією застосунка ми активно розвиваємо фізичну доступність наших сервісів. Зокрема, масштабуємо «Інклюзивний» клас авто, створений для людей, які користуються кріслом колісним. Ми постійно розширюємо перелік додаткових опцій, які полегшують взаємодію людей з інвалідністю із сервісом та водіями-партнерами, забезпечуючи гідну та зручну логістику на кожному етапі поїздки.

Замість висновку: порада для Product Owner-ів та Тімлідів

Наш головний досвід можна звести до трьох тез:

  • Впроваджуйте доступність від самого початку. Починайте закладати критерії інклюзивності ще на етапі проєктування та створення MVP. Що сильніше масштабується і розростається продукт, то складніше, довше й дорожче буде інтегрувати зміни пізніше.
  • Побудуйте систему регулярного контролю. Доступність — це не чек-лист, який можна закрити раз і назавжди. Це безперервний процес валідації кожного релізу.
  • Усвідомте соціальну відповідальність. Зважаючи на виклики, які долає Україна, цифрова безбар’єрність сьогодні — це обов’язок кожного українського бізнесу. Ми маємо будувати продукти так, щоб абсолютно кожна людина мала змогу отримати необхідну послугу.
👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Підписатись на коментарі