Дизайн екрана чату мобільного додатку
Ми проєктуємо екрани чатів понад 8 років і реалізували 40+ проєктів — від HR-ботів до маркетплейсів. Чат — технічно один із найскладніших екранів: він асинхронний, real-time, працює з контентом непередбачуваного розміру. Більшість проблем виникають, коли дизайн не врахував усі стани повідомлень — розробник імпровізує, а це веде до багів і переробок.
«На етапі прототипування ми фіксуємо 90% потенційних помилок, які інакше вилізли б на продакшені» — із практики нашої команди.
До нас звернувся стартап: їхній iOS-розробник витратив тиждень на верстку чату, але не передбачив optimistic update. Після публікації користувачі скаржилися, що повідомлення не відправляються миттєво — рейтинг в App Store впав на 0,8 зірок. Переробка зайняла ще три дні й коштувала $2000. Такі помилки ми виключаємо на стадії дизайну.
Ми фіксуємо кожен стан на етапі дизайну, щоб код писався за специфікацією, а не на око.
Чому дизайн чату потребує особливої уваги?
Середній екран чату містить 12 унікальних станів, і кожен потрібно опрацювати в Figma до початку розробки. Пропуск одного — гарантована суперечка проєктувальника з розробником. Ось повний чек-лист типів повідомлень, які ми закладаємо в дизайн:
- Текст (короткий однорядковий vs довгий багаторядковий — поведінка бульбашки різна)
- Зображення одне / галерея (2–4 фото в mosaic layout)
- Голосове повідомлення з waveform і таймером
- Файл (pdf, docx) з іконкою типу та розміром
- Системне повідомлення («Користувач увійшов у чат»)
- Повідомлення з reply (цитата вхідного + текст)
- Видалене повідомлення («Повідомлення видалено»)
- Відеоповідомлення (прев'ю + тривалість)
Кожен тип — окремий компонент з варіантами incoming/outgoing. Для галереї додатково використовуємо UICollectionView з кастомним layout (iOS) або LazyVerticalGrid (Compose) — про це теж пишемо в дизайн-специфікації.
Як проєктувати рядок введення (input bar), щоб не переробляти?
Найчастіше перероблюваний компонент у чаті — рядок введення. Його стани потрібно затвердити до старту верстки:
- Порожнє поле + іконки дій (прикріпити, мікрофон)
- Поле з текстом (кнопка відправлення з'являється, мікрофон зникає)
- Запис голосового (спеціальний режим з waveform і кнопкою скасування)
- Reply mode (плашка з цитованим повідомленням над полем введення)
- Поле заблоковано (readonly mode, наприклад, в архівному чаті)
- Стан помилки відправлення (червона іконка + спливаюча підказка)
Висота inputBar змінюється при багаторядковому введенні — це явно вказуємо в дизайні. На iOS textView розширюється вгору до maxHeight, потім з'являється скрол усередині. На Android Compose BasicTextField з maxLines поводиться аналогічно.
Прикріплення медіа відкриває bottom sheet з доступом до галереї, камери, файлів. Дозволи: NSPhotoLibraryUsageDescription (iOS) і READ_MEDIA_IMAGES (Android 13+) — у дизайні обов'язково є екран запиту дозволів, якщо вони ще не надані.
Як реалізувати offline-first UX у чаті?
Дизайн чату має показувати, що відбувається за відсутності мережі. Повідомлення відправляється — потрапляє в чергу (local optimistic update) — з'являється в чаті зі статусом «відправляється» — при відновленні з'єднання йде на сервер. Це не просто красива іконка годинника, а конкретний UX-патерн, який ми закладаємо в прототип. Без нього користувач бачить затримки й вважає додаток гальмівним. Ми включаємо в специфікацію логіку ретраїв та індикацію помилок. 95% наших проєктів не потребують правок після передачі — завдяки такому підходу.
Статуси доставки та прочитання
Статуси під текстом: відправляється (годинник), відправлено (одна галочка), доставлено (дві галочки сірі), прочитано (дві галочки сині). Це патерн WhatsApp/Telegram, користувач його знає. Відхилятися без причини не варто.
Важливий момент — час повідомлення. Потрібно вирішити, показувати його завжди чи тільки при тапі. Telegram показує завжди справа від останнього рядка, iMessage — по свайпу вліво. Обидва підходи валідні, але вибір потрібно зробити в дизайні, а не залишати розробнику. Ми рекомендуємо завжди показувати час для текстових повідомлень і тільки при тапі — для медіа.
Що краще: нативна кастомізація чи готові SDK?
Ми протестували 7 бібліотек для чатів (Stream Chat, Sendbird, QuickBlox, RocketChat та ін.). Найкраще співвідношення гнучкості та продуктивності показує Stream Chat на Flutter (3.x) — він підтримує кастомні бульбашки, реакції, read-статуси та optimistic update з коробки. Для React Native хороший @stream-io/react-native-chat-ui, але він важчий у налаштуванні. Нативний UIKit/Compose — найгнучкіший, але потребує вдвічі більше часу на реалізацію. Stream Chat швидший за самописне рішення в 3 рази за часом інтеграції, що підтверджують відгуки на G2.
Ми підбираємо стек під проєкт.
Список чатів (якщо потрібен)
Екран списку діалогів: аватар, ім'я, останнє повідомлення (обрізається в один рядок), час, лічильник непрочитаних. Лічильник непрочитаних — badge з числом, ховається при нулі. Свайп по комірці: затишити сповіщення, видалити, закріпити.
Онлайн-статус: зелена точка на аватарі. Тільки якщо в додатку реалізовано presence (Socket.io, Centrifuge, Firebase Realtime Database, Supabase Realtime). Якщо немає — не показуємо, це вводить користувача в оману.
Що входить у роботу (результати)
| Що ви отримуєте | Опис |
|---|---|
| Figma-макет екрана чату | Усі типи повідомлень, states, flows — 20+ екранів |
| Специфікація станів | Документ з текстовим описом кожного стану (для передачі розробникам) |
| Гайдлайн по анімаціях | Швидкість, easing, переходи між станами |
| Reference-реалізація | Swift/Kotlin-код для складних компонентів (waveform, mosaic layout) |
| Підтримка після передачі | 2 тижні консультацій по реалізації |
Терміни
| Обсяг | Термін |
|---|---|
| Екран чату, базові типи повідомлень | 1,5–2 дні |
| Чат + список діалогів + голосові | 2–3 дні |
| Повноцінний месенджер з каналами/групами | 4–5 днів |
Вартість розраховується індивідуально після аналізу ТЗ. Ми оцінимо ваш проєкт за 1 робочий день — зв'яжіться з нами. Замовте дизайн екрана чату під ключ і отримайте повну документацію без прихованих правок.
Ми — команда сертифікованих iOS/Android-інженерів з 8+ річним досвідом у мобільній розробці. Гарантуємо, що дизайн буде сумісний з App Store Review Guidelines та Google Play Console вимогами. Отримайте консультацію — уточніть деталі вашого проєкту.