Lement Pro

Sodis Lab разрабатывает программное обеспечение для цифровизации строительства. Low‑code платформа Lement Pro  — их флагман. Система, в которой руководители проектов, инженеры и прорабы ведут стройку от графика работ до финального акта сдачи. Это не стартап с чистого листа — когда я пришел, продуктом уже пользовались около 11 тысяч человек. Живая кодовая база, реальные клиенты, годы легаси-решений.

За 4 года я прошел путь от единственного дизайнера до лида: выстроил дизайн‑процессы, внедрил систему исследований, проверку гипотез и превратил дизайн из сервисной функции в инструмент, который влияет на то, каким продукт станет, а не только на то, как он выглядит.

ConTech · B2B SaaS · 2021–2025 · Lead Product Designer

Контекст

Стройка — это сотни подрядчиков, тысячи задач и согласования, которые обязаны идти по строгим процессам. Большинство команд использовали для этого разные инструменты  и узнавали о проблеме, только когда она уже наступала.

Но главный вызов был не в экранах, а в том, как принимались решения. В команде продукта был продакт-оунер, который отвечал на любой продуктовый вопрос одинаково: «Раньше было так». Почему интерфейс устроен именно так? Потому что так было в старом продукте. Логика легаси воспроизводила сама себя — и продукт, который параллельно перестраивался с нуля, рисковал унаследовать все решения, причины которых уже никто не помнил.

Единственным противовесом аргументу «так было всегда» могли стать данные.
Так исследования стали не частью процесса, а способом вообще получить право на продуктовые решения.

Старая версия продукта: интерфейс, выросший из логики разработки, а не из задач пользователей.

Процесс

80

интервью

15

юзабилити-тестов

Я выстроил исследовательский процесс с нуля, до меня в компании не было ни одного систематического канала обратной связи, который влиял бы на продуктовые решения. Формат — custdev-интервью, коридорные тесты, глубинные интервью: за четыре года 80 интервью и 15 юзабилити-тестов.

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

Исследования стали фильтром для всего, что описано ниже.

Что пришлось менять вокруг продукта.

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

Портфель

Первый экран, который видит руководитель портфеля — таблица проектов с живыми данными, а не списком названий. Прогресс, бюджет с фактическим расходом, число критичных замечаний, ближайшая контрольная точка. Если у проекта статус «At risk» и 70 открытых замечаний — это видно сразу, без захода внутрь.

Шесть метрик в шапке держат общую картину портфеля: прогресс, активные задачи, открытые issues, просрочки, отклонение от графика, стоимость портфеля.

Виджеты

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

Виджеты говорят на языке стройки: план/факт по дисциплинам, выполнение объемов, матрица рисков, аналитика согласований. Каждый собирает свой набор под свою роль.

Задачи

Список, Гант, Календарь показывают одну и ту же иерархию задач без ручной синхронизации между видами. Переключение между ними не сбрасывает контекст — меняется только угол зрения, а не данные.

В списке сразу видно, где задача реально стоит без захода в карточку.

Карточка строится вокруг состава работ, а не статуса: чек-лист, связанные задачи и атрибуты, важные именно для стройки — бюджет, приоритет, наблюдатели.

Графики

Над графиком работ 3D-модель здания в текущей стадии. Это прямой ответ на сценарий, который повторялся на интервью: «В таблице 60% готово, а на площадке так не выглядит». Прогресс на Ганте можно сверить с тем, что физически построено, а не верить процентам.

Визуальная привязка графика к модели делает расхождения между «на бумаге» и «на объекте» очевидными.

В масштабе целого проекта несколько уровней вложенности по WBS, зависимости между задачами и линия «сегодня», которая держит график честным.

Нагрузка

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

Перегрузка видна сразу — интерфейс подсвечивает проблему, не заставляя считать часы в голове.

Замечания

До редизайна замечания с площадки — это фотография в чате, которая тонет в переписке через час. Я спроектировал «замечания» так, чтобы они не могли существовать без привязки к конкретному элементу здания.

Это решение меняет саму механику работы с проблемами на объекте: замечания больше не теряются, они физически привязаны к месту, где возникло.

Список замечаний с привязкой к элементам 3D-модели, выбираешь замечание — на модели подсвечивается элемент.

Согласования

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

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

Cписок всех согласований по всем проектам. Один список на весь портфель — сразу видно, что зависло и на ком, без захода в каждый проект по очереди.

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

Среда общих данных (СОД)

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

Структура папок с дисциплинарными тегами и версионированием. Структура папок повторяет реальную структуру строительной документации.

Результат

+35%

скорость согласования

−40%

ручные уточнения

+20%

вовлеченность пользователей

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

Но самое устойчивое изменение не в экранах, а в том, как компания стала принимать решения. Появились демо, появилась привычка спорить на макетах, а не на проде, и появился ответ сильнее, чем «раньше было так»: слова реальных пользователей. Дизайн пришел в компанию как услуга, а остался как способ думать о продукте.