Самостоятельная работа: от идеи к пользовательскому сценарию

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

Одновременно участники комментировали проекты друг друга и предлагали улучшения. Обсуждение шло сразу на трёх уровнях:

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

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

От идеи к последовательности действий

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

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

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

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

Пошаговая логика пяти инструментов

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

01. Коллективная идея — «Чертёж → трёхмерное пространство»

Основная идея — превратить плоский архитектурный материал в пространственный объект, который можно рассматривать как цифровой макет.

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

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

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

Возможное применение: быстрый переход от эскиза к объёму, учебные занятия, демонстрация проектной идеи и создание интерактивных архитектурных макетов.

02. Варвара — «Фотография → форма + палитра»

Проект Варвары использует фотографию как источник архитектурной формы, цвета и композиционного характера.

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

Пользователь выбирает тип будущего объекта — например, жилой дом, библиотеку или другое общественное здание.
Загружает фотографию, которая станет источником образа.
Инструмент извлекает из изображения основные цвета и формирует палитру.
Анализирует композицию, ритм, соотношение светлых и тёмных участков.
Эти свойства связываются с архитектурными параметрами: членением объёма, характером фасада, материалами и цветом.
Система создаёт первый архитектурный вариант.
Пользователь сравнивает несколько интерпретаций или уточняет отдельные параметры.
Выбранная форма и палитра сохраняются как основа для дальнейшей разработки концепции.

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

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

03. Дмитрий — онлайн-конфигуратор здания

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

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

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

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

04. Андрей — персональный городской музей

Проект Андрея объединяет архитектурный дневник, карту и справочную информацию о городских объектах.

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

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

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

05. Роза — Archi Helper

Archi Helper Розы развивается как инструмент предварительного разбора студенческой архитектурной подачи. Он не должен заменять преподавателя или выставлять окончательную оценку. Его задача — помочь студенту до просмотра обнаружить формальные недостатки и увидеть направления доработки.

У проекта уже опубликованы две версии интерфейса.

Первый вариант Archi Helper опубликован с названием интерфейса ArchiAI Studio и предлагает загрузить планшет или чертежи. В описании заявлены распознавание планов, разрезов, фасадов и схем; поиск недостающих элементов; предварительная 3D-модель; разбор по критериям МАРХИ; помощник и экспорт PDF, GLB и PNG.
Archi Helper — детализируемая версия уточняет русскоязычный сценарий. Интерфейс описывает сопоставление с 16 награждёнными работами МАРХИ и паттернами из 8 преподавательских разборов, четыре кейса «до / после» и оценку по 100-балльной шкале. Процесс разделён на распознавание, сравнение, преподавательский разбор и конкретную правку.

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

Следующая пошаговая логика соединяет сильные стороны двух вариантов:

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

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

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

Комментарии как основа будущего тестирования

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

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

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

Механика. Прослеживается ли связь между введёнными данными и изменением результата? Не возникает ли необъяснимых переходов? Может ли пользователь контролировать процесс?

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

Такой чек-лист может помочь не только исправлять отдельные детали, но и точнее формулировать идею проекта. Если механику приходится долго объяснять устно, это сигнал проверить, достаточно ли ясно она выражена в интерфейсе.

Где могут работать эти инструменты

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

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

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

Итог второго дня

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

На основе этой работы для дальнейших итераций предложена последовательная система действий:

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

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

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