Архитектура цифрового инструмента: от исследования к браузерному прототипу

Третий день DØMO ARCHITOYS был посвящён внутренней архитектуре цифрового инструмента. Разговор шёл не о том, как быстрее добавить очередной ползунок или сделать эффектную трёхмерную сцену, а о более фундаментальном вопросе: как профессиональное знание архитектора превращается в понятную и работающую цифровую систему.

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

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

исследование → классификация → карта параметров → техническое задание → правила → интерфейс → результат → проверка → новая версия.

Цифровой инструмент как архитектурный объект

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

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

Если эта структура не продумана, приложение может выглядеть завершённым, но оставаться непонятным. Кнопки присутствуют, однако не влияют на модель; параметров много, но их смысл неясен; результат появляется, но пользователь не понимает, почему он получился именно таким.

Поэтому работа начинается не с интерфейса. Сначала необходимо спроектировать предметную и логическую основу инструмента.

Четыре исходных вопроса

Перед созданием первой версии полезно письменно ответить на четыре вопроса.

Для кого создаётся инструмент?
Для студента, преподавателя, архитектора, исследователя, заказчика, специалиста администрации или человека без профессиональной подготовки?
Какую задачу он решает?
Помогает понять типологию, собрать предварительную модель, проверить ограничения, сравнить варианты, подготовить задание или представить проект в контексте?
Какие данные входят в систему?
Размеры участка, назначение здания, геометрия, этажность, рельеф, ориентация, состав помещений, материалы, карта, фотография или другой исходный материал?
Что пользователь получает на выходе?
Трёхмерную модель, план, схему, расчёт, изображение, набор параметров, ссылку, файл для продолжения работы или несколько сравнимых вариантов?

Ответ лучше сформулировать одним предложением:

Пользователь задаёт исходные данные, последовательно меняет ключевые параметры и получает конкретный результат, который помогает ему решить определённую архитектурную задачу.

Если эта фраза не складывается, границы продукта пока не определены.

Шаг 1. Исследовать предметную область

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

Для конфигуратора павильона это означает выяснить:

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

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

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

Шаг 2. Превратить исследование в классификацию

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

Слой	Что в него входит	Пример для павильона
Пользователь и задача	адресат, цель, стадия работы	студент первого курса, ранний поиск
Участок и контекст	размеры, ориентация, рельеф, окружение	поляна, аллея, берег водоёма
Типология	назначение и пространственный тип	открытый павильон, кафе, галерея, сцена
Геометрия	габариты, форма, этажность, состав объёмов	линейная, компактная, кольцевая, блочная схема
Конструкции	несущая система и шаг элементов	каркас и его связь с формой
Фасад	открытость, витражи, глухие элементы, пластика	глубокая рама, витраж, экраны
Материалы и образ	покрытия, цвет, характер	лёгкий, пластичный, более массивный вариант
Представление	3D, план, генплан, карта, режимы	дневной и вечерний вид
Результат	расчёты, файлы, сохранение и обмен	изображение, параметры, модель

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

Шаг 3. Отобрать параметры

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

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

Для каждого параметра следует записать:

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

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

Шаг 4. Составить техническое задание

Техническое задание связывает профессиональную модель объекта и будущую реализацию. Для учебного архитектурного HTML-инструмента можно использовать следующую структуру.

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

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

Шаг 5. Спроектировать механику

Ключевая единица механики — причинная связь:

действие пользователя → правило системы → изменение модели → видимый результат.

Примеры из разбора прототипов:

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

Если элемент интерфейса не запускает такую цепочку, он либо ещё не реализован, либо не нужен в текущей версии. Наличие кнопки нельзя считать наличием функции.

Шаг 6. Выстроить пользовательский маршрут

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

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

Пользователь должен видеть результат на каждом этапе, а не только после последней кнопки. Модель, план и показатели желательно обновлять сразу после изменения параметра.

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

Шаг 7. Разделить большую систему на модули

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

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

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

Шаг 8. Определить минимальную версию

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

Для каждой функции полезно установить статус:

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

Такое разделение защищает проект от бесконечного расширения и позволяет честно описывать состояние прототипа.

Что показали браузерные прототипы

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

Процедурный ландшафт

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

Проект на карте

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

Модель затопления

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

Жилая застройка

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

Физкультурно-досуговый центр

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

Павильон

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

Возможности и статус функций

Запись третьего дня позволяет различить показанные эксперименты и направления, которые только предлагалось исследовать.

Возможность	Статус по материалам дня
Интерактивное изменение трёхмерной модели	показано в нескольких прототипах
Процедурное окружение и режим от первого лица	показано в отдельном эксперименте
План, генплан и выбор части здания	показано на примере жилого конфигуратора
Карта и модель затопления	показаны как отдельные эксперименты
Сохранение изображения	показано в прототипе павильона
Сохранение набора параметров в JSON	показано на разборе прототипа павильона
Восстановление и передача той же конфигурации	предложено как практическое использование сохранённых параметров
Сценарии «у воды», «на поляне», «у аллеи»	предложены для следующей версии павильона
Библиотека хороших проектов и подач	предложена как дополнительный учебный модуль
Привязка к реальному участку через карту	предложена для отдельной разработки
Семантически разделённый экспорт в профессиональную среду	поставлен как исследовательская задача
Подключение внешних ИИ-сервисов через API	обозначено как возможное дальнейшее развитие

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

Шаг 9. Проверить и довести прототип

Работающая версия появляется итерациями. Практический цикл можно организовать так:

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

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

Для проверки полезно передать прототип человеку, который не участвовал в его создании. Если без устных пояснений непонятно, с чего начать, что изменяет параметр и как сохранить результат, пользовательский маршрут требует доработки.

Чек-лист первой рабочей версии

Перед публикацией прототипа стоит проверить:

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

Что такой инструмент делает — и чего не делает

Архитектурный конфигуратор не заменяет профессиональную программу и не создаёт законченный проект одной кнопкой. Его ценность в другом.

Он может:

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

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

Главный итог

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

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

Именно эта последовательность — от исследования темы к параметрической карте, от карты к механике, от механики к проверяемому браузерному прототипу — стала методической основой третьего дня DØMO ARCHITOYS.