Этот проект я делал как самостоятельный pet-project, чтобы на практике пройти полный цикл проектирования мобильного интерфейса — от аналитики и продуктовой логики до финального UI. Для меня это был первый осознанный опыт работы с мобильным продуктом и iOS-гайдлайнами, без готовых шаблонов и подсказок.
Работа велась итерационно, с регулярными ревью и разбором решений с ментором. Основная цель проекта — не «красивые экраны», а понимание того, как продукт собирается как система.
На старте у проекта не было ни готового приложения, ни продуктовой логики. Я сознательно взял за основу существующий фирменный стиль Berlingo и не пытался его переосмысливать — задача была аккуратно адаптировать визуальный язык бренда под мобильный интерфейс и выстроить логичную структуру продукта.
В рамках проекта я последовательно прошёл следующие этапы:
— анализ конкурентов и рынка;
— формирование продуктовой гипотезы;
— продумывание бизнес-модели;
— проектирование пользовательских сценариев;
— работа с iOS Human Interface Guidelines;
— разработка иконок и UI-компонентов;
— сборка UX/UI мобильного приложения.
Анализ конкурентов
На этапе исследования я разобрал основные решения конкурентов и зафиксировал повторяющиеся проблемы:
— визуально устаревшие интерфейсы с агрессивными контрастами;
— перегруженность экрана за счёт обводок и декоративных элементов;
— отсутствие внятной иерархии информации;
— избыточное количество экранов без реальной продуктовой ценности.
Этот анализ стал точкой отсчёта для всех дальнейших решений: интерфейс должен быть спокойным, читаемым и собранным вокруг сценариев, а не вокруг функций.
Аналитика и структура
На старте я сформировал базовую структуру будущего приложения и набор пользовательских сценариев. Проработал user-story, возможные точки роста продукта и потенциальные фичи, которые могли бы масштабироваться в будущем.
Задача на этом этапе была простой по формулировке и сложной по сути — не сделать лишнего. Я сознательно отбрасывал функции, которые не усиливали основной сценарий, и постоянно проверял решения на необходимость.
Бизнес-логика продукта
Перед началом проектирования я сформировал базовую бизнес-модель на основе анализа сегментов целевой аудитории. Она использовалась как опорная рамка для продуктовых решений и помогала отсекать лишние функции ещё на этапе прототипирования.
Основные процессы продукта строились вокруг маркетинга, доставки и ценообразования. Я рассматривал продукт не как витрину товаров, а как сервис регулярного потребления, где ключевым становится удобство повторных покупок и снижение когнитивной нагрузки.
Монетизация
Модель монетизации построена вокруг подписки на канцтовары. Подписка рассматривалась как более выгодная и удобная альтернатива разовым наборам и классической рознице.
Пользователь может выбрать удобный способ получения товаров: постамат, ближайший магазин или доставку до дома за небольшую доплату.
Цены внутри подписки ниже розничных, но не опускаются ниже оптовых. Разница с розницей составляет около 10 %.
Для запуска продукта предполагалась стратегия постепенного роста стоимости подписки: сниженные цены на старте и акционные предложения для привлечения первых пользователей с последующим повышением.
Для пользователя подписка даёт предсказуемость и контроль. За фиксированную абонентскую плату он получает набор услуг, который можно гибко настраивать — расширять или сокращать без дополнительных капитальных затрат.
Для бизнеса подписочная модель формирует долгосрочную связь с пользователем и создаёт стабильный источник дохода. Это не разовая транзакция, а договорённость о регулярном взаимодействии.
За счёт выстроенных долгосрочных связей подписка становится более удобной и экономичной альтернативой наборам и тем более розничной продаже.
Прототипирование
После аналитики и бизнес-модели я перешёл к прототипированию. Первые экраны собирались как быстрые гипотезы и регулярно отправлялись на разбор. Изменения вносились итерационно, без попыток «сразу сделать идеально».
В процессе я осознанно опирался на принцип Бритвы Оккама: если элемент не усиливает сценарий — он не нужен. Это помогло убрать из интерфейса лишний функционал ещё до стадии визуального дизайна.
Иконографика
На этапе прототипирования стало очевидно, что без собственной иконографики интерфейс не будет работать ни визуально, ни функционально. Использование растра в таком продукте сразу снижало бы аккуратность и масштабируемость.
Я начал разрабатывать иконки с нуля. Первый подход оказался неудачным — я недооценил важность референсов и системности. После отдельного ресёрча я пересобрал сетку, оптический вес и логику иконок, постепенно доведя их до цельного набора.
Маскот
Так как доступ к исходным материалам редизайна Berlingo был ограничен, фирменного персонажа пришлось перерисовывать вручную, ориентируясь только на растровые изображения.
Это стало отдельной задачей на аккуратность и внимательность к деталям: сохранить характер персонажа и при этом привести его к единому визуальному стилю приложения.
Результаты
После серии итераций я пришёл к чистому и функциональному решению. В процессе был полностью убран tab-bar, переработана навигация и улучшена читаемость ключевых экранов.
Проект стал для меня первым законченным мобильным интерфейсом, в котором удалось совместить фирменные цвета, маскота, собственную иконографику и продуманную структуру экранов без ощущения перегруженности.
Выводы
Этот проект стал для меня точкой входа в системный UI/UX-дизайн. Именно здесь я впервые прошёл полный цикл разработки — от анализа конкурентов и проектирования бизнес-логики до финального интерфейса. Это помогло мне на практике понять главный принцип: дизайн должен решать задачи продукта, а не просто быть набором экранов.
В ходе работы я сфокусировался на создании логичной структуры и аргументации каждого визуального решения. Опыт работы с гайдлайнами, итерациями и защитой своих идей перед «заказчиком» заложил прочный фундамент. Я научился видеть продукт целиком и понимать, как информационная архитектура влияет на итоговый пользовательский опыт.
ты думал здесь что-то будет?
