Розбір Booking.com з точки зору дизайну та доступності. Чому навіть такі проєкти мають помилки

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

Мене звати Олег Антонюк, я співпрацюю з ЕРАМ у ролі старшого дизайнера. Нещодавно в рамках дизайн-спільноти XD Community ми з колегою провели експрес-розбір сайту Booking.com у форматі імпровізованого батлу UX Busters. В ході аналізу я зі здивуванням помітив багато типових помилок дизайнера-початківця, які, здавалося б, неможливі у популярному комерційному продукті. Як так сталося?

Спробуємо розібратись в цьому дописі. Також розглянемо сервіс з точки зору доступності для користувачів з різними вадами (accessibility) та подивимось, як його можна покращити за допомогою штучного інтелекту.

Огляд візуальної складової дизайну

Так само як і людина, продукт справляє перше враження через свою візуальну складову. У Booking.com з цим повний порядок: нейтральна кольорова схема, великі фотографії нерухомості, стилізовані ілюстрації, пропрацьована візуальна ієрархія елементів, короткі та місткі тексти. Мені як користувачу одразу зрозуміло, з чого почати та що подивитись, якщо я ще не знаю, що шукаю.

Але диявол, як завжди, ховається у деталях. І якщо до головної сторінки небагато претензій, то опис конкретного об’єкта нерухомості змушує рухатись залишки волосся на макітрі:

• Колір. Різні елементи сторінки можуть застосовувати один і той самий колір у різних відтінках. Синій колір зустрічається мінімум у трьох варіаціях з різною насиченістю. Помилки акцентуються червоним, але від яскраво-рожевого до світло-червоного. Складається враження, що в дизайн-системі відсутні кольорові стилі, адже скрізь ми бачимо щось унікальне.

• Іконки. Тут панує цілковитий хаос. В рамках одного екрану можна спостерігати два набори іконок, які дублюють один одного та при цьому виконані у різних стилях. Зверніть увагу на властивості апартаментів й популярні властивості. Перші виконані іконками з заливкою, а у другому випадку — контурні. Прокрутивши сторінку далі, можна побачити табличку з доступними апартаментами. Придивившись, ви побачите іконку дивану й... труну? А можливо, що це і двоспальне ліжко, тут важко зрозуміти. Якщо без жартів, то видно, що іконки малювали різні графічні дизайнери або їх брали з різних сетів.

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

• Повідомлення про помилки. За традицією, повідомлення про помилки зустрічаються в різних виконаннях: пласкі зі стрілочкою (наче бульбашка діалогу в коміксах), об’ємні з бліком і тінню, з подвійним обведенням, у вигляді модального вікна, а також як текст з іконкою.

• Модальні вікна. Вони також бувають різні. Одні з’являються по центру, інші мають вирівнювання по правій стороні. Деякі містять велику кнопку з текстом, щоб закрити вікно. Інші навпаки — аскетичні та обмежуються іконкою хрестика у верхньому правому кутку.

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

Повернувшись до головної сторінки, можна помітити, що ілюстрації виконані у різному стилі. Так що тут в біса відбувається?

Спроба віднайти корінь проблем

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

В нас часто трапляються ситуації, які призводять до проблем, схожих на ті, що зустрічаються на Booking.com — якщо команди працюють автономно без обміну досвідом, то може з’явитись декілька рішень однієї й тієї ж задачі.

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

Схоже, що Booking.com також розділив зони відповідальності на декілька команд, які не так часто обмінюються досвідом. Також треба враховувати, що на великих проєктах зміни вносяться дуже повільно. Тому все описане з візуальною частиною може бути відомо команді, але на усунення потрібно багато часу.

Не треба забувати й про A/B тести, які постійно проводять продуктові компанії. Можливо, ми потрапили на один з них. Або попереднє тестування виявило, що використані візуальні елементи збільшують конверсію, тому команда не хоче нічого змінювати.

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

Шляхи виходу із ситуації

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

Огляд доступності (accessibility)

Вдало пропрацьована доступність дозволяє ефективно користуватись сайтом людям з певними фізичними вадами, що автоматично підвищує комфорт для всіх. У Booking.com з цим все досить непогано, але місце для покращення залишається:

• Контраст тексту та іконок на високому рівні та вибиває оцінку AAA за критеріями WCAG (Web Content Accessibility Guidelines) у більшості випадків. Та деяким поодиноким іконкам не завадить збільшити контраст для кращого розпізнавання.
• Розмір ключових текстових елементів перевищує 12-14 pt (еквівалент 1-1.2 em або 16-19 px). Але зустрічаються і досить маленькі написи з розміром гарнітури меншим за 12 px, що обов’язково викличе проблеми зі сприйняттям інформації у людей з дислексією. Тому обов’язково це виправляємо.
• У фотографій та ілюстрацій прописаний альтернативний текст, який може бути прочитаний браузером для людей з вадами зору. Але для апартаментів він однаковий і не несе ніякої користі, окрім того факту, що людина усвідомить, що це фотографія. А що саме там зображено зрозуміти неможливо. В наступному розділі я запропонував, як це можна покращити, застосувавши спеціалізовані нейромережі.
• Послідовність фокусування елементів інтерфейсу за допомогою клавіатури (клавішею Tab) в більшості випадків логічна, але часом фокус неочікувано перестрибує на протилежний бік екрана. Тому виправляємо послідовності перемикання елементів для комфортнішого досвіду.
• Іноді при використанні фільтрів для пошуку нерухомості доводиться додатково прокручувати сторінку назад, а також постійно чекати оновлення даних перш ніж додати ще один критерій. Тому додаємо кнопку «Оновити», яка дозволяє змінити групу фільтрів за один раз.

Як покращити доступність за допомогою штучного інтелекту

У попередньому розділі я згадав про однотипний альтернативний текст до фотографій апартаментів, який ігнорує фактичне зображення, тобто, що саме там можна побачити.

Уявіть, як круто було б мати можливість послухати детальний опис кожної фотографії людям з вадами зору! З сучасними темпами розвитку штучного інтелекту це можна зробити. ChatGPT четвертої версії має можливість працювати з зображеннями та відкрив доступ до API за допомогою плагінів (потрібно подати заявку).

Таким чином розробникам після отримання доступу буде достатньо за допомогою коду відправити кожне фото в базі та запросити текстовий опис, який потім вставити як альтернативний текст.

Як альтернатива можна пошукати щось дотичне серед сотень доступних натренованих моделей в агрегаторі Hugging Face. Є цілий розділ з моделями для виявлення об’єктів. І хоча тут все буде набагато складніше, ніж з ChatGPT, але можна хоча б виявляти типові предмети (меблі, елементи декору та освітлення тощо) а вже потім створити з них опис.

Наостанок

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

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