Дизайн экрана чата мобильного приложения
Мы проектируем экраны чатов более 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 требованиями. Получите консультацию — уточните детали вашего проекта в личном кабинете.