Привет, я Кир, дизайнер интерфейсов. В ходе работы над цифровой системой комплексного проектирования и организации дорожного движения (КСОДД) я столкнулся с рядом вызовов, характерных для создания государственных информационных систем. Цифровой КСОДД — это масштабный проект, целью которого является создание комплексной схемы организации дорожного движения на срок от 15 лет, позволяющей структурировать мероприятия по планированию и оптимизации дорожной инфраструктуры. Проект включал 12+ пользовательских ролей из различных структур: от заявителей и секретарей до архитекторов и сотрудников ГИБДД. Каждая роль требовала своего уровня доступа и уникальных функций в системе.

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

Аннотация:

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

Цель статьи:

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

8 отличий между государственными и коммерческими проектами:

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

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

• Цель и подход к задачам
  В госструктурах дизайн интерфейса направлен на адаптацию и улучшение общественных процессов из реального мира, а задачи — на упрощение и повышение эффективности работы госслужащих. Дизайнер задается вопросами вроде - "Нужно ли сохранять шапку в цифровом заявлении или объяснительной?" В коммерческих проектах задачи чаще связаны с привлечением и удержанием пользователей для роста прибыли и укрепления конкурентных позиций.

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

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

• Сложность системы и количество ролей
  Государственные проекты включают множество ролей с уникальными задачами, что требует сложной архитектуры доступа и функционала. В коммерческих системах наличие 10ти и более ролей является, скорее, исключением.

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

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

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

Методики

Анализ аудитории с учетом возраста и технических навыков

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

Применение строгих стандартов доступности

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

Строгая иерархия ролей и распределение прав доступа

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

Минималистичный визуальный стиль для упрощения восприятия

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

Долгосрочная документация

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

Ниже приведу несколько уникальных кейсов, с которыми я столкнулся при проектировании КСОДД.

Кейс 1: Автоматизация процесса согласования заявок

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

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

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

Механика автоматического формирования презентации: После рассмотрения заявки система автоматически генерировала презентацию, включающую ключевую информацию:

• Тип заявки (например, График ограничений - строительство)

• Затронутые улицы и дороги

• Маршруты общественного транспорта, которые необходимо перенаправить

• Документы и выписки, связанные с заявкой

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

Преимущества

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

Кейс 2: Архивирование и документирование заявок для комплексного отслеживания документов

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

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

Основные задачи и функции Архивариуса включали:

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

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

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

Поддержка актуальности и систематизация данных

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

Кейс 3: Архитектура взаимодействия между департаментами

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

Структура взаимодействия и разграничение доступа

Архитектура с разграничением доступа и переносом авторизации пользователя через сторонний специализированый сервис "СУДИР" стала ключевым элементом для безопасного и эффективного функционирования системы. Она позволяла каждому департаменту и роли работать с определенной частью данных, ограничивая доступ к информации, не касающейся их задач. Например, на определенных этапах заявитель мог взаимодействовать с архитектором, управлением ГИБДД и прочими ответственными за свою структуру ролями, что требовало временного доступа к совместно используемым данным. Это требовало проработки так называемой «паутины взаимодействия» — структуры, которая позволяла роли пересекаться только в рамках строго определённых задач, чтобы минимизировать риск нарушения безопасности данных. Благодаря этому система могла поддерживать конфиденциальность данных, повышать устойчивость к ошибкам и обеспечивать высокий уровень контроля.

Важность фиксации точек соприкосновения

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

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

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

Полезные практики

На основе опыта с проектом КСОДД можно выделить ряд полезных практик. Эти советы пригодятся всем, кто работает над масштабными и многоуровневыми системами, особенно в государственных структурах.

Чтобы эффективно структурировать взаимодействие:

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

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

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

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

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

• Используйте понятные и привычные метафоры. Многие пользователи привыкли к определенным визуальным метафорам, например, к кнопкам «Назад», «Вперед», стандартным иконкам «поиск» и «настройки».

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

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

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

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

• Поддерживайте единообразие элементов. Единообразие элементов — ключ к интуитивному интерфейсу. В КСОДД все кнопки, иконки и поля ввода следовали единому стилю, что позволило сократить количество ошибок и упростить процесс обучения.

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

Создание подробной дизайн-системы для документирования и передачи

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

• Стандарты обеспечивают единообразие. Все элементы системы — от кнопок до сложных виджетов — были описаны с чёткими инструкциями по использованию.

• Сценарии взаимодействия. Каждое состояние элемента (например, «активное», «наведённое», «заблокированное») было проработано и задокументировано. Это упростило реализацию в коде.

• Удобство масштабирования. Дизайн-система позволила легко добавлять новые элементы и адаптировать систему под дополнительные требования без необходимости кардинальных изменений.

• Инструменты документирования. Для фиксации всех правил я использовал Figma и Confluence. Это обеспечило лёгкий доступ к информации для команды и ускорило процесс согласования.

Взгляд на будущее гос- и коммерческих проектов

Цифровизация государственных услуг

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

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

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

Умные города

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

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

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

Взаимное влияние гос- и коммерческих проектов

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

Из коммерции в госструктуры: инновации и гибкость
Государственные проекты в будущем будут всё больше применять практики из коммерческих систем — гибкость обновлений, внедрение UX/UI подходов, разработка под нужды конечного пользователя. Применение инновационных методов и решений помогает госструктурам быстрее адаптироваться к изменяющимся потребностям общества.

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

Заключение

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

Спасибо за внимание!