Петербург
+7 (981) 980-38-54
Телеграм
Вконтакте
Gmail
hh.ru
Задача
Закрытый мультиязычный мессенджер для приватной коммуникации внутри ограниченного круга людей
Особенность
Клиенту был нужен сервис без регистрации, телефона, имени и публичного профиля. Приложение не должно было знать, кто общается, и не должно было иметь доступ к сообщениям, документам и файлам
Стек
Discovery, UX/UI, MVP, roadmap, брендинг
Мессенджер без пользователя
2026
Что значит «без пользователя»?
Варианты
Путь
Риск
ID
Скопировать или продиктовать
-> ввести
-> подтвердить
Ошибка при вводе. Передача 3-им лицам
Код
Получить код
-> ввести
-> подтвердить
Код устарел или введен неверно. Передача 3-им лицам
Bluetooth
Включить доступы
-> найти устройство
-> подтвердить
Разрешения
Поиск устройства
Сбои соединения
QR
Навести камеру
empty
Перевел запрос клиента в продуктовые требования
Продукт — это привычный мессенджер с надстройкой в виде усиленной безопасности
Запрос клиента
Требования к продукту
Не знает, кто я
Без регистрации, телефона, имени и email
Не знает, с кем я общаюсь
Без поиска по номеру и адресной книги
Не знает, о чем я говорю
Без доступа к переписке и файлам
Не хранит лишнего
Минимум данных на стороне сервиса
Помогает контролировать разговор
Видны действия собеседника в чате и звонке
Почему не взять готовый мессенджер?
Сначала я проверил, можно ли решить задачу готовым продуктом
Briar был ближе всех по логике. Но клиенту нужен был свой сервис: свой дизайн, свой доступ, без посторонних пользователей.
QR выигрывал по UX: знакомый паттерн, меньше шагов, меньше ошибок, быстрее старт общения.
Контакт называет сам пользователь. Сервис не получает имя, а пользователь может скрыть реальную связь за нейтральным названием
Сервис
Что было близко
Почему не подошел
Signal
Защита переписки
Нужен номер телефона
Session
Без телефона и email
Открытый продукт, не закрытый круг
SimpleX
Нет постоянного user ID
Не подходил как кастомный закрытый сервис
Briar
QR-контакт после личной встречи
Близко по логике, но не по задаче клиента
Threema
ID вместо обязательного телефона
Все равно внешний продукт со своей моделью
Как назвать человека без профиля?
Если у пользователя нет аккаунта, сервис не может брать имя из профиля
Варианты
Путь
Риск
Публичное имя
Пользователь задает имя при входе
Сервис получает персональные данные
Технический ID
В чате видно набор символов
Непонятно, кто «перед тобой»
Имя от собеседника
Человек сам передает свое имя
Имя уходит в систему
Локальное имя
Пользователь сам называет контакт
empty
Команда разработки выбрала сквозное шифрование. Сообщение закрывается у отправителя, проходит через сервер закрытым и открывается только у получателя
Как шифровать содержимое переписок?
Техническое решение согласовывалось с разработкой. Мне было важно понять принцип
Итак, лозунг нашего МВП — «Защитить то, чем уже пользуются»
Сроки и бюджет уже были сжаты.Предложил собрать MVP вокруг ключевых сценариев клиента. Остальное — в backlog. Не потому что «неважно», а потому что первая версия должна была быстро заменить привычное общение на защищенное
Онбординг как первый trust-механизм
Я собрал структуру и тексты онбординга вокруг одной задачи — показать, где пользователь сможет контролировать свою безопасность
Варианты
Путь
Риск
Обычное серверное хранение
Сообщения хранятся на сервере
Сервис потенциально видит данные
P2P
Устройства общаются напрямую
Сложнее стабильность и доставка
Сквозное шифрование
Сообщение шифруется у отправителя
и расшифровывается у получателя
empty
Что клиент уже делает в обычных мессенджерах, но делает с риском, тревогой или ограничением?
На уровне базовой коммуникации:
Контекст
Где риск в мессенджерах
Что нужно в MVP
Клиент может находиться в России или зарубежом
Один маршрут подключения может быть нестабильным
Proxy
На уровне контекста использования:
Что важно для продукта
Где риск в мессенджерах
Что нужно в MVP
Приложение передается дальше закрытому кругу
Новые пользователи не обязаны верить клиенту «на слово»
Онбординг с принципами защиты.
Security-лейблы в чувствительных сценариях
Пользователь хочет понимать, что защита работает
Безопасно выглядит абстрактно
Статус защищенного соединения на главном экране и в настройках
Пользователь хочет убрать следы устройства
Непонятно, что остается после удаления
Удаление локальных данных
На уровне доверия и контроля
Что клиенту нужно делать
Где риск в мессенджерах
Что нужно в MVP
Добавить человека из закрытого круга
Контакт создается через номер, username
или адресную книгу
Альтернативное решение без персональных данных
Вести переписку
Обычный чат раскрывает активность и прочтение
Исключаем индикатор прочитанных сообщений.
Исключаем статус online у пользователей.
Отправлять документы и фото
Файлы уходят через привычные, но небезопасные каналы
Нужен принцип шифрования содержания чатов
Звонить по важным вопросам
Обычный звонок не дает контроля над условиями разговора
Индикаторы действий собеседника. Видеть включенную громкую связь, mute режим, включенный bluetooth
Как спроектировать приложение без персональных данных и каков будет принцип шифрования?
Как не потерять защищенное соединение?
Продумал статусную модель
Proxy выглядел как простая настройка: Local, Global и Auto-selection. Но за ней скрывалась логика сбоев, fallback-маршрутов и восстановления соединения
Приватность как визуальный язык
3 подхода:
Изучил, каким методом пользуются существующие мессенджеры:
Очевидно, что нужен нейтральный гротеск
Решил, что для MVP лучше подходит нативный подход, так как бюджета на собственную гарнитуру нет, а один универсальный шрифт на обе платформы
=> Раз шрифт нейтральный, значит характер продукта сложится из цвета, композиции и графики.
мог вызывать ощущение чужеродности интерфейса.
Требования
Почему важно
Легко читать
Мессенджер держится на переписке. Текста много, читать его будут каждый день.
Работать на iOs и Android
Интерфейс должен выглядеть своим на каждой платформе
Поддерживать языки
Первая версия — английский. Дальше — арабский и китайский.
Продукт
Подход
Телеграм
Нативная типографика (Sf pro/android)
Вацап
Нативная типографика (Sf pro/android)
VK
Собственная гарнитура
Подход
Как работает
Риск
1 шрифт на всё
Одна кроссплатформенная система для iOS
и Android
Может выглядеть чужим на обеих платформах
Нативная типографика
iOS использует свою системную пару,
Android — свою
Нужно держать визуальный характер не шрифтом,
а всей системой
Брендовая гарнитура
Свой шрифт как часть айдентики
Дороже, сложнее, не нужно для MVP
Made on
Tilda