Nano Banana AI

iOS-приложение для генерации изображений на базе Nano Banana

Я работал продуктовым дизайнером в небольшой команде над iOS-приложением для быстрого создания изображений на базе генеративной модели Nano Banana. Заказчик — официальный партнёр Google, который занимался продвижением модели и хотел упаковать её в понятный массовому пользователю продукт: открыл приложение, ввёл промпт, при желании добавил референсы — получил результат, сразу отредактировал и пошёл дальше.

На старте мы очень быстро поняли, что «сделать ещё один генератор картинок» — не вариант. Задача была в скорости и предсказуемости: чтобы пользователь не думал, куда нажимать, не терялся в настройках и не чувствовал себя новичком, даже если он впервые видит prompt-поле.

Что было самым важным в продукте

Мы сфокусировались на двух вещах. Первое — короткий путь до результата. Второе — ощущение контроля: пользователь должен понимать, что именно он делает (генерация с нуля или ремикс), и что будет на выходе. В генеративке это критично: если интерфейс «разговаривает» сложными словами и кидает в настройки, люди просто закрывают приложение.

Анализ конкурентов и выводы

Перед тем как рисовать, мы разобрали несколько прямых и косвенных конкурентов: приложения, которые генерируют изображения, и продукты, которые “упаковывают” генеративку в понятные сценарии (генерация, ремикс, стилизация, улучшение).

Очень быстро проявились повторяющиеся проблемы, на которых многие спотыкаются:

1. Слишком длинный путь до первой генерации. Часто пользователя встречают экраны с выбором стиля, тарифов, сложных параметров, объяснениями — и всё это до того, как он увидит хотя бы один результат.
2. Перегруженные настройки, которые не дают ценности большинству. В итоге интерфейс выглядит “профессионально”, но ощущается тяжёлым, а ошибки в промпте раздражают сильнее.
3. Слабая связка “результат → следующий шаг”. Пользователь получил картинку, и дальше начинается хаос: где ремикс, где вариации, где «сделай похоже, но иначе», где история, как не потерять удачный результат.

После этого мы сформулировали для себя понятный принцип: приложение должно вести пользователя по сценарию “сначала результат, потом контроль”. То есть сначала быстрый успех, потом уже расширение возможностей — ремиксы, уточнения, повторные генерации и т.д.

Как мы собирали основной флоу

Мы сделали два базовых режима, которые покрывают большую часть потребностей.

Первый — генерация с нуля: короткий экран, где пользователь добавляет (или не добавляет) референсы, пишет промпт и запускает генерацию.

Второй — ремикс: когда пользователь уже получил картинку и хочет изменить её без ощущения “начинай всё сначала”. В этом режиме особенно важно, чтобы человек видел исходник, понимал, что меняется, и мог итеративно улучшать результат.

На уровне UX мы много внимания уделяли состояниям: генерация — штука не мгновенная, и если интерфейс в этот момент молчит, пользователи начинают нажимать всё подряд. Поэтому мы продумывали загрузки, ошибки, отмену, возврат в историю, повтор генерации, и то, как аккуратно объяснять ограничения модели человеческим языком.

Визуальный стиль

Дальше был выбор визуального направления. Мы хотели, чтобы продукт ощущался как лёгкий инструмент, а не как сложный редактор. В итоге пришли к светлому, чистому интерфейсу с ярким акцентом на главном действии. Визуально приложение должно было говорить: “всё просто — попробуй”.

Мы специально избегали “тяжёлой” эстетики с бесконечными панелями и микроконтролами. Вместо этого сделали интерфейс аккуратным, с понятной типографикой, большим воздухом и акцентными кнопками. За счёт этого даже сложные сценарии вроде ремикса выглядят легко: картинка в центре, действие снизу, текст — там, где он нужен, без визуального шума.

Дизайн-система и работа с разработчиками

Параллельно мы собирали дизайн-систему, потому что продукт быстро обрастает состояниями и экранами: генерация, история, ремиксы, прогресс, ошибки, пустые состояния, paywall и т.д. Если это не зафиксировать компонентами, всё развалится через две недели разработки.

Мы сделали набор базовых компонентов и правил, которые реально помогают команде: кнопки, поля ввода, карточки изображений, состояния загрузки, системные сообщения, модальные окна, элементы навигации. Отдельно договорились о принципах сетки и отступов, чтобы интерфейс выглядел консистентно на разных экранах и в разных сценариях.

С разработчиками работали плотно. В таких приложениях всегда есть технические нюансы: скорость генерации, ограничения по размерам, обработка ошибок API, очереди, сохранение истории, работа с загрузкой референсов. Мы регулярно сверялись, где дизайн можно упростить без потери UX, а где наоборот нужно добавить шаг, чтобы пользователь не терялся. За счёт этого финальный продукт получился очень близким к макетам — без ситуации “в дизайне было одно, а на деле — другое”.

Итог

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