

Контекст
Стартап для ремонта и комплектации интерьера. Как единственный дизайнер, сделала MVP для проверки гипотез фаундеров за 9 месяцев.
Задачи
Проверить гипотезу через MVP, а затем развить продукт до полноценной B2B-платформы и маркетплейса
Создать систему, которая позволит пользователям вести расчёты и управлять заказами быстрее, чем табличка в Excel
Результаты
За 9 месяцев работы получилось понять потребности целевой аудитории, сделать MVP и MMP продукта, а также сделать несколько фич «на вырост». Продукт стал инструментом, в котором собрать смету удобнее и быстрее, чем табличку в Excel.
Я занималась проектированием и дизайном сценариев для MVP:
— создавать и комплектовать смету удобным для них способом;
— группировать по помещениям или этапам работ;
— создавать несколько вариантов дизайна, например, «Кухня в стиле джапанди» или «Кухня в скандинавском стиле»;
— сравнивать разные варианты сметы;
— подбирать товары для сметы из каталога или добавлять свои собственные;
— создавать заказы для покупки материалов.
Главным результатом стал продукт, который объединил большое количество ролей и сценариев. В 2025 году состоялся мягкий запуск продукта.
Моя роль на проекте
Главный дизайнер. Работала в паре с арт директором.
В чём была сложность
Платформа объединяла проекты, сметы, варианты дизайна, комплектации, товары, версии и заказы. Все сущности зависели друг от друга, но пользователь должен был понимать, что именно он сейчас меняет.
Например, одна смета могла включать два варианта интерьера: скандинавский и классический. Это были не разные сметы, а альтернативные решения внутри одного проекта.
У каждого варианта было несколько комплектаций под разный бюджет. В скандинавском интерьере пользователь мог сравнить базовый и более дорогой набор материалов: разные виды ламината, мебели и отделки.
Кроме того, дизайнер и клиент могли сохранять новые версии после правок.
Получалась трёхуровневая вариативность:
вариант дизайна определял стиль интерьера;
комплектация определяла состав и бюджет внутри этого стиля;
версия сохраняла изменения конкретного варианта или комплектации.
Если смешать эти понятия, пользователь не понимает, создал ли он новый дизайн, изменил бюджет или перезаписал согласованное решение.


Построила модель продукта
Сначала мы описали основные сущности и их отношения:
проект → смета → вариант дизайна → комплектация → товары → заказ.
Для каждого уровня я определила доступные действия и последствия изменений. Бизнес-логику прорабатывала вместе с клиентом.
Например, замена товара в бюджетной комплектации не должна была менять дорогую комплектацию или другой вариант дизайна. Новая версия должна была сохранять историю изменений, а не создавать ещё одну несвязанную смету.

Разделила сценарии дизайнера и клиента
Дизайнер создавал проект, собирал смету и готовил варианты. Клиент просматривал предложения, сравнивал стоимость, вносил изменения и возвращался к сохранённым версиям.
Для каждой роли мы оставили только нужные действия. При этом обе стороны работали с одной структурой проекта и видели актуальное состояние сметы.
Пользователь всегда должен был понимать:
— какой проект открыт;
— с каким вариантом дизайна он работает;
— какая комплектация выбрана;
— изменена ли текущая версия;
— какие решения уже согласованы.
Связала смету с закупкой
На следующем этапе смета становилась основой заказа.
Пользователь мог выбрать согласованную комплектацию, собрать товары для закупки у разных поставщиков и отслеживать статус заказа и движение товаров.
Так система не заканчивалась на планировании интерьера. Она сопровождала проект до реальной комплектации объекта.
Что я вынесла из проекта
— как выстраивать доверие с заказчиком через аргументацию и прозрачность;
— как упрощать сложные интерфейсы без потери смысла;
— как согласовывать дизайн и разработку при высокой сложности логики.
Этот проект научил меня не бояться сложных систем и искать простоту и красоту в ограничениях.
Отзыв клиента

Бонус
Наш красивый кейс на Behance



