NormaCS Specification
Моя роль: Senior Product Designer.
Команда: Product manager, QA, Backend и Frontend разработчики.
Инструменты: Figma, Confluence, Jira.
Год: 2022.
1. О проекте
NormaCS Specification — это база знаний в области стандартизации. Сервис содержит требования, извлечённые из текстов нормативно-технических документов. К ним привязаны коды параметров, процессов и категорий объектов, моделей зданий и сооружений, которые содержатся в строительных классификаторах. Сервис позволяет пользователю выполнять все стадии проектирования объекта и оценивать степень соответствия проекта действующим стандартам.
Требование — это выражение в виде текста, изображения, формул и таблиц правил с однозначной трактовкой. Требования извлекаются из нормативных документов постановления 985. Они могут быть технического, экономического или правового характера, которые определяют регламенты осуществления градостроительной деятельности, архитектурно-строительного проектирования и так далее.

2. Проблема
Специалисты в сфере строительства тратят много времени на работу с документацией. Нет возможности группировать данные по проектам из обширного каталога документации. Поэтому процессы с подготовкой строительных работ и их аудитом занимают много времени.
3. Задача
Спроектировать специализированный продукт из линейки NormaCS, который позволяет навигироваться по данным из нормативно-технической документации с помощью кодов МССК, КСИ и IFC, которые используются для создания информационной модели ОКС и прохождения экспертизы.
4. Решение
Web-сервис должен иметь лаконичный и доступный дизайн, соответствующий стандарту доступности интерфейса WGAG 2.9 с уровнем контраста компонентов АА и ААА. Также следует использовать минимальное количество анимации, учитывая, что потенциальные пользователи могут пользоваться устаревшими компьютерами с низкой производительностью.
5. Дизайн продукта
5.1. Роли в сервисе
Специалист. Эксперты, проектировщики, архитекторы. Их основной инструмент — это поиск и просмотр требований / терминов для выполнения работ по проверке трёхмерных моделей и аудиту в организациях.
Разработчик. Пользователь сервиса, отвечающий за наполнение и согласованность базы данных и терминологии, требований, классификаторов и привязкой требований к классификаторам. В его обязанности входит формирование и поддержка базы данных.
5.2. Интерфейс специалиста
5.2.1. Поиск
После авторизации специалист попадает на страницу поиска и просмотра технических требований, созданных разработчиком. Чтобы сформировать подборку требований, специалисту нужно воспользоваться поиском по требованиям или терминам, также можно воспользоваться классификатором, точка входа которого расположена слева от поиска.
Воспользовавшись поиском, система начнёт искать по базе данных и предложит варианты, совпадающие с введённым запросом. В поиске реализован механизм индексирования записей на основе выделения фонем для быстрого поиска по: словоформам и разговорным фразам с учётом морфологии русского языка.

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

5.2.2. Классификатор
Классификатор — это модульный раздел с древовидной структурой и несколькими сущностями: иконкой р — отображается раздел, иконкой х — характеристики. Раздел это список разделов и подразделов, в которые специалист может проваливаться и выбирать нужные ему данные. Характеристики — это классификатор, в котором можно установить значения. Например, характеристика C35: Двери — имеет параметры ширины и высоты, к которым можно указать значения в миллиметрах и добавить операцию отношения при необходимости. В отличии от разделов, в характеристиках специалист может выбрать только конечный элемент.


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

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

Если специалист сталкивается с большим количеством контента, он может внутри классификатора использовать поиск, чтобы сузить область поиска.

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

5.2.3. Просмотр требований
Далее специалист взаимодействует с просмотром технических требований. Интерфейс разделен на три функциональные зоны: тулбар с основными элементами управления, область просмотра документов, сформированных через поиск или классификатор, и окно подробного просмотра документа.
С помощью такой компоновки специалист может независимо работать с двумя областями. Например, оставить в правой части информацию из выбранного документа и продолжить слева просмотр. Если специалисту нужно сосредоточиться на изучении документа, он может перейти в режим полноэкранного просмотра, чтобы полноценно работать с конкретным требованием.
В печатном виде, нормативный документ содержит иерархию в виде глав, подразделов и так далее. Данную структуру в интерфейсе NormaCS Specification преобразуется в древовидный список, который можно свернуть или развернуть.


5.2.4. Избранное
Из ленты с требованиями специалист может составлять списки в разделе избранное. Списки могут быть личными и общими для организации. Нажав на иконку звезды в карточке требования, специалист добавит контент в список, который установлен по-умолчанию. Если имеются другие списки, специалисту предоставится выбор в какой список сохранить требование. Список имеет даты последнего изменения и просмотра, а также индикацию прогресса выполнения работы с содержимым списка.

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

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


Для списка доступны контекстные действия. Есть отображение тегов “по умолчанию” и “в общем списке”. Для понимания прогресса выполнения работ с документами в списке присутствует индикатор выполнения.


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

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

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

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

5.3. Интерфейс Разработчика
Если компании выделен доступ и к общей базе требований, то можно посмотреть существующие требования. Для показа требований по какому-либо конкретному документу разработчик может воспользоваться фильтром по требованиям.

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

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

Карточка требования идентична карточке для роли эксперта. К ней добавляются контролы управления иерархией и статус.

Интерфейсы разработчика и специалиста схожи. Поскольку эти роли связаны, важна последовательность в интерфейсе без кардинальных изменений. Разработчик может управлять иерархией документа, чтобы внести изменения. Он может использовать стрелки «вверх/вниз» на карточке требований или переместить ее с помощью Drag&Drop.
Справа в окне детального просмотра разработчик может менять содержимое требования через wysiwyg-редактор и настраивать параметры, переключившись на одноимённый таб.

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

5.3.2. Работа с классификаторами
Разработчик имеет два способа добавления классификаторов: создать новый или импортировать из файла.

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


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


5.3.4. IFC
В параметрах раздела также указывается общая информация (код раздела, название раздела, определение и прочее). Имеется возможность синхронизировать данные с IFC (формат данных с открытой спецификацией, которая не контролируется ни одной компанией).

С помощью IFC можно получить доступ к базе данных в САПР программе NanoCAD. Данные импортируются путём анализа 3d модели. Есть два способа импорта: по всей модели или по выбранной части модели.

5.3.5. Связка с классификатором
После создания требований разработчик должен связать их с классификатором. Для этого есть соответствующий интерфейс. Слева расположены требования, а справа разработчик выбирает классификатор для привязки. Можно выбрать несколько разделов/характеристик.

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

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



5.3.7. Документы
Список документов — это источник нормативных требований для каждого объекта информационной модели. В параметрах документа указываются индекс, номер документа-источника, наименование документа, статус документа-источника, статус значимости (обязательное или добровольное), раздел и пункт документа-источника.


В разделе «Структура документа», разработчик настраивает разделение на главы и статьи.

6. Мобильная версия
Учитывая пользовательские сценарии работы с сервисом, в мобильной версии не нужен весь функционал. Для мобильной версии мы оставили только функционал поиска по терминам, раздел «Избранное», личный кабинет и уведомления от администратора. Эти ограничения помогут предоставить оптимизированный сервис для смартфонов.

7. UI-Kit
Параллельно с дизайном сервиса формировался ui-kit, который NormaCS взяла за основу для имплементации компонентов в Storybook. Всего было создано более 150 компонентов от атомов до организмов, описаны все состояния.