Проектируем и разрабатываем приложения, дорабатываем существующие продукты и приводим интерфейсы к единой дизайн-системе. Связываем клиентский сценарий с работой команды, данными и внешними сервисами.
Опишите основной сценарий приложения или пришлите ссылку на текущую версию.
Владивосток и Приморский край. Работаем удалённо по всей России.
Разделяем три задачи: создание продукта, развитие готового приложения и дизайн интерфейсов. Выбираем объём по состоянию проекта, а не навязываем полную переделку.
Пользовательские роли, основные сценарии, API и серверная часть, интеграции, тестирование. Сначала проверяем первую полезную версию, затем развиваем продукт.
На выходе: первая полезная версия с планом развития.
Изучаем исходный код и доступы, зависимости и архитектуру. Исправляем ошибки, добавляем экраны и функции, улучшаем скорость. До изменений создаём тестовый контур.
На выходе: контролируемый релиз существующего приложения.
Исследуем сценарии, собираем прототип, состояния экранов и UI-кит. Прорабатываем пустые состояния, ошибки, загрузку и адаптацию к устройствам, а не только красивые главные экраны.
На выходе: единая дизайн-система приложения.
Релевантные интерфейсы из наших проектов. Статус каждого примера указан рядом — от проектирования до работающего продукта.
Проектирование
Приложение для клиента частной авиации
Запрос перелёта, персональные предложения, выбор самолёта и «Мои перелёты». Четыре экрана дизайн-концепции; запуск приложения и CRM-интеграция не заявляются.
Разобрать проект
Реализованный продукт
Рабочий цифровой сервис
Персональная лента и мини-приложения как пример продукта с общими API и данными.
Разобрать проект
Реализованный продукт
Сервис для клиентов застройщика
Каталог привилегий, проверка контакта и сохранённые купоны в мини-приложении.
Разобрать проектВ Лилиентале связали в интерфейсах запрос на перелёт, подбор вариантов, PDF-предложение и переписку. В кабинете менеджера предусмотрены сценарии создания КП из заявки и после звонка.
Доработка приложения — управляемые релизы, а не набор случайных исправлений. Сохраняем полезную архитектуру, определяем приоритеты и проверяем критические сценарии перед обновлением.
Описание задачи, доступная сборка или ссылка на продукт, исходники и сведения о backend. Для нового приложения — аудитория, ключевые сценарии и список систем, с которыми нужно обмениваться данными.
Нажмите на вопрос, чтобы раскрыть подробный ответ.
Да, после технического аудита. Проверяем возможность собрать проект, права на исходники, зависимости и доступ к серверной части. Если обнаружим существенные риски, предложим план до начала основной разработки.
Да. Отдельный этап включает согласованные сценарии, прототип, UI-кит и макеты состояний для передачи разработчикам. Реализация и публикация оцениваются отдельно.
Готовим согласованный пакет и помогаем с подачей. Решение о допуске принимает площадка. Аккаунты, политики, права и требования к контенту проверяем заранее.
Да. Можно отдельно спроектировать сценарии, макеты и UI-кит. Такой результат не означает выпуск нового приложения: реализацию, интеграции и публикацию согласуем отдельно.
По воспроизводимым задачам, состоянию исходников, API и сборки. До оценки релиза проверяем, кто управляет сервером, ключами и аккаунтами публикации.
Создаём клиентские приложения и рабочие интерфейсы команды. Если продукт уже существует, сначала проверяем код и сценарии: можно исправить отдельную функцию, обновить UX/UI или разработать новую версию без ненужного переписывания.
Определяем роли, ключевой сценарий, модель данных и API. Выбираем платформы и состав первой версии по задаче; нативный и кроссплатформенный подход обсуждаем после проверки требований.
Изучаем репозиторий, сборку, зависимости и серверную часть. Изменения проверяем на отдельном контуре, согласуем миграцию данных и способ выпуска обновления.
Пересматриваем навигацию, формы и состояния, а не только внешний вид. Готовим прототип, UI-кит и спецификацию; внедрение дизайна и публикация сборки имеют отдельные критерии приёмки.
Приложение уместно, когда есть повторяющийся мобильный сценарий: обращения, подбор, личный кабинет или работа сотрудника. Для разового знакомства с услугой обычно достаточно сайта. Перед разработкой проверяем требования к уведомлениям, камере, работе без сети и публикации в магазинах.
Согласуем список платформ, роли, состояния загрузки и ошибок, тестовые устройства и сценарий обновления. Для дизайна результатом служат макеты и спецификация; для разработки — проверяемая сборка и серверная часть в согласованном объёме. Публикация и передача аккаунтов оговариваются отдельно.
Оцениваем не число нарисованных экранов, а пользовательские роли, платформы, серверную логику и связи с другими системами. Для существующего приложения сначала проверяем сборку и исходники. Дизайн, реализацию и публикацию разделяем в оценке: готовые макеты не равны выпущенному приложению.
Опишите основной сценарий приложения или пришлите ссылку на текущую версию.
Обсудить задачуВыберите нужный формат. Точный состав и оценку зафиксируем после знакомства с исходными данными.
Первая полезная версия для одного основного сценария.
Проверенное изменение действующего продукта без полной переделки.
Понятные пользовательские сценарии и единый набор экранов и состояний.
Написать в Telegram