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

Краткое содержание

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

Аннотация

Сложные проблемы в сфере государственных услуг, обладающие признаками так называемых «злых проблем» (wicked problems), включая участие множества субъектов, фрагментированность информации, размытость границ ответственности и отсутствие единственного неоспоримого решения, трудно структурировать в условиях рутинного административного управления. В данной статье представлен систематический протокол визуализации сервисного дизайна для низкорисковых государственных услуг и консультационных процессов, под которыми понимаются административные услуги, не определяющие тактику медицинского лечения, правовой статус, право на финансовую помощь, защиту детей, дисциплинарные меры или иные критически важные решения, влияющие на права граждан. Протокол объединяет картирование стейкхолдеров, картирование пути пользователя в государственной службе, совместное проектирование по методу «Двойного алмаза» (Double Diamond) и тестирование низкодетализированных прототипов для преобразования фрагментированных административных проблем в реализуемые, совместно разработанные концепции услуг и их оценки с помощью симуляционных заданий. В репрезентативном сценарии низкорискового административного процесса тестирование симуляционных заданий с участием 28 человек (112 записей выполнения заданий до внедрения и 112 после) показало сокращение времени выполнения заданий (178.4 ± 49.6 s–121.7 ± 38.2 s), уменьшение количества ошибок (1.86 ± 0.91–0.79 ± 0.63 ошибок на задание) и повышение успешности выполнения заданий (62.5%–82.1%) после ознакомления с материалами, созданными по данному протоколу. Эти результаты представляют собой доказательства юзабилити на основе выполнения заданий, поскольку фиксированная последовательность «до/после» может включать эффекты обучения. Данный воспроизводимый протокол предлагает структурированный, визуально ориентированный подход к диагностике сложных проблем государственных услуг и прототипированию решений в низкорисковых административных средах.

Введение

Организации государственного сектора все чаще сталкиваются со сложными проблемами, которые невозможно решить простыми административными корректировками. Эти проблемы характеризуются участием множества сторон, фрагментацией ответственности, неравным доступом к информации и противоречием между стандартизированными административными процедурами и разнообразными потребностями пользователей. Вместо того чтобы утверждать, что такие проблемы могут быть решены с помощью полностью воспроизводимой формулы, данный протокол рассматривает их как ограниченные по масштабу и малорисковые сервисные задачи с признаками «злокачественных» (wicked) проблем, которые можно структурировать, визуализировать и исследовать с помощью воспроизводимых этапов фасилитации^1,2. В повседневном процессе оказания государственных услуг такие проблемы проявляются как операционные сбои: гражданам трудно определить перечень необходимых документов, сотрудники фронт-офисов сталкиваются с повторяющимися запросами, а администраторы применяют правила, которые не очевидны для конечных пользователей.

Чтобы справиться с этими сложностями, инновации в сфере государственных услуг сместились от реформ внутренней эффективности в сторону партисипативных, ориентированных на пользователя подходов. Современные исследования показывают, что совместное создание (co-creation) и совместное производство (co-production) позволяют гражданам, профессионалам и организациям совместно вносить вклад в инновации в сфере услуг^3,4,5. Однако этот переход к партисипативности создает методологическую проблему. Хотя различные заинтересованные стороны могут согласиться с тем, что услуга неэффективна, они редко приходят к консенсусу относительно того, где именно происходит структурный сбой, на кого он влияет сильнее всего или какие конкретные меры вмешательства необходимы.

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

По сравнению с отдельным анализом стейкхолдеров, картированием пути пользователя или партисипаторными семинарами, предлагаемый рабочий процесс объединяет картирование акторов, детальный разбор сервисов на каждом этапе, совместную формулировку проблемы и симулированное тестирование прототипов в рамках единой проверяемой последовательности. Такая интеграция помогает командам избежать перехода от общей неудовлетворенности напрямую к идеям по решению проблемы без предварительного определения того, кто именно подвержен воздействию, на каком этапе происходит сбой и какие материалы можно безопасно протестировать. Современные обзоры по совместному проектированию в государственном секторе и сфере общественного здравоохранения также подчеркивают необходимость прозрачных процессов, явной фасилитации и тщательной оценки участия и динамики распределения власти^4,6,7,8,9.

Проектирование услуг (сервис-дизайн) предлагает практическую основу для решения этой проблемы с помощью визуальных, партисипативных и прототипно-ориентированных методов^6,8,10. Вместо того чтобы рассматривать сбои в предоставлении услуг как абстрактные недостатки политики, сервис-дизайн анализирует взаимодействия между пользователями, персоналом, точками контакта и закулисными процессами. Вследствие этого в государственном управлении все чаще предлагается совместное проектирование (со-дизайн) как средство привлечения граждан к определению сложных проблем^4,7,11. Однако инициативы по совместному проектированию часто оказываются недостаточно эффективными, если в них отсутствует структурированный механизм преобразования субъективного опыта заинтересованных сторон в тестируемые материалы государственных услуг или если не осуществляется явное управление разницей в статусе и влиянии участников.

Строгий методологический переход требует последовательной интеграции конкретных аналитических инструментов. Картирование стейкхолдеров служит диагностической базой, позволяя прояснить степень участия акторов, их влияние, зависимости и информационную асимметрию¹². Затем используется картирование пути пользователя (journey mapping) для выявления конкретных «болевых точек» и неопределенностей в распределении ответственности на последовательных этапах оказания услуги¹³. Впоследствии модель Double Diamond обеспечивает структурированный путь преобразования выявленных сбоев в конкретные дизайнерские задачи, разделяя этап дивергентного исследования проблемы и этап конвергентной разработки решения^7,8,14. Наконец, тестирование низкодетализированных прототипов позволяет безопасно оценить совместно разработанные концепции перед их внедрением — это критически важный этап для государственных служб, где преждевременные изменения могут ограничить доступ граждан или увеличить административную нагрузку^15,16.

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

В данной статье представлен систематический протокол визуализации проектирования услуг, разработанный для структурирования сложных проблем с участием множества субъектов в области инноваций в государственных услугах с низким уровнем риска^4,6,16,17. Протокол, созданный специально для процессов консультирования и применения в государственном секторе, последовательно объединяет картирование стейкхолдеров, картирование пути пользователя (journey mapping), воркшоп по методу «Двойного алмаза» (Double Diamond) и тестирование прототипа. Общая цель состоит в том, чтобы предоставить исследователям и практикам высоковоспроизводимый пошаговый подход для перехода от разрозненных жалоб на качество услуг к визуальной диагностике, объективному определению проблемы и эмпирическому тестированию совместно разработанных концепций услуг.

Протокол

Репрезентативное применение, описанное в данной статье, было одобрено Комитетом по этике защиты прав человека Городского университета Макао (Макао, Китай) (номер одобрения 260AL2401; срок действия с 10 января 2026 г. по 10 января 2028 г.). До начала участия от всех добровольцев было получено письменное или электронное информированное согласие. Протокол не предполагал медицинского вмешательства, работы с уязвимыми группами населения, использования обмана, забора биологических образцов, доступа к частным финансовым данным, оценки индивидуальных показателей или доступа к официальным административным записям. Инструменты исследования, использованные в протоколе, перечислены в Таблица материалов.

1. Набор участников и определение контекста

1. Выберите для оценки приложение или процесс консультирования в сфере государственных услуг с низким уровнем риска, например, муниципальный, университетский или общинный административный процесс, который требует поиска информации, уточнения критериев приемлемости, подготовки материалов, подачи заявления, обработки, уведомления и последующей поддержки.
2. Исключите контексты, связанные с медицинским лечением, ведением судебных дел, иммиграционным статусом, защитой детей, определением финансовой помощи, дисциплинарными процедурами, принятием решений в чрезвычайных ситуациях или официальными административными записями.
3. Считайте проблему государственной службы подходящей для данного протокола, если она обладает по крайней мере тремя сложными или «злонамеренными» (wicked) характеристиками: участие нескольких групп заинтересованных сторон, нечеткие границы ответственности, повторяющиеся сбои в координации между участниками, неполная или противоречивая информация об услуге и отсутствие единого согласованного решения.
   ПРИМЕЧАНИЕ: Не представляйте данный протокол как решение полностью «злонамеренной» проблемы. Представляйте его как структурирование ограниченной проблемы государственной службы с низким уровнем риска для диагностики, совместного проектирования и имитационного тестирования.
4. Привлеките от 80 до 120 участников для этапа анкетирования на основании их знакомства с использованием, предоставлением, координацией или управлением государственными услугами.
5. Используйте этот размер выборки в качестве прагматичной цели планирования для обеспечения стабильных описательных профилей заинтересованных сторон в нескольких ролевых группах, оставаясь при этом в рамках осуществимого неинтервенционного исследования сервисного дизайна.
6. Подберите участников, представляющих все основные роли заинтересованных сторон, задействованных в процессе предоставления государственной услуги.
7. Сформируйте подгруппу из 20–30 участников для участия в семинаре по совместному проектированию и на этапах тестирования прототипа.
8. Создайте 4–6 групп для семинаров с разными ролями, при этом каждая группа должна оставаться достаточно малой для обеспечения активного участия.
9. Убедитесь, что каждая смешанная группа включает по крайней мере три категории заинтересованных сторон, таких как граждане, сотрудники первой линии обслуживания, социальные работники или администраторы.
10. Разделите граждан и поставщиков услуг во время первоначальных обсуждений по картированию заинтересованных сторон, если ожидается дисбаланс власти.
11. Проведите синтез с участием разных ролей после первоначальных обсуждений. Во время такого синтеза используйте структурированную очередность высказываний, письменную фиксацию идей в тишине, анонимную подачу карточек и анонимное голосование точками, чтобы администраторы или профессиональный персонал не доминировали над предложениями граждан.
12. Уделите пристальное внимание подбору участников, подготовке ролей и условиям, которые позволяют пользователям предлагать идеи, а не просто отвечать на проблемы, определенные экспертами7,9,18.
13. Инструктируйте всех участников не разглашать идентифицируемые имена, идентификационные номера, домашние адреса, номера телефонов, ID дел, медицинские записи, судебные записи, данные о доходах или файлы о деятельности агентства.
14. Присвойте участникам неидентифицируемые коды (например, P01 и P02).
15. Обучите всех фасилитаторов перед сбором данных, используя один и тот же сценарий фасилитации, образцы карточек «болевых точек», рубрику дизайнерских задач и примеры оценки прототипов.
16. КРИТИЧЕСКИЙ ШАГ: Проведите калибровку фасилитаторов, попросив их независимо классифицировать как минимум пять образцов «болевых точек» и пять черновиков формулировок «Как бы мы могли» (How might we).
    ПРИМЕЧАНИЕ: Фасилитаторы должны достичь согласия не менее чем в 80% случаев по вопросам включения, кластеризации и пересмотра решений, прежде чем приступать к работе.
17. Обсуждайте расхождения до тех пор, пока фасилитаторы не достигнут согласия не менее чем в 80% случаев по вопросам включения, кластеризации и пересмотра решений.
18. По возможности используйте как минимум двух фасилитаторов: одного ведущего фасилитатора для управления дискуссией и одного наблюдателя для фиксации времени, баланса участия и отклонений от протокола.
19. Если несколько фасилитаторов ведут параллельные группы, проводите 15–20-минутный разбор после каждого основного этапа и фиксируйте любые различия в подсказках или правилах интерпретации в контрольном листе.
    ПРЕДОСТЕРЕЖЕНИЕ: После завершения подбора участников, получения согласия, обучения фасилитаторов и подготовки материалов исследователи могут сделать паузу перед началом этапа 1. Продолжайте работу только после подтверждения того, что всем участникам присвоены коды и что все рабочие листы не содержат идентифицирующей информации.

2. Подготовка материалов для протокола

1. Подготовьте материалы протокола перед началом реализации.
2. Подготовьте информационный листок участника, анонимный опросник на основе ролей, рабочий лист по картированию стейкхолдеров, лист пятибалльной оценки стейкхолдеров, шаблон картирования пути получения государственных услуг, карточки «болевых точек», шаблон проектного задания, карточки решений, лист выбора прототипа, рубрику калибровки фасилитатора, листы с симулированными заданиями, контрольный список эквивалентности наборов заданий, рубрику оценки прототипа, кодировочный лист, заметки по синтаксису анализа или рабочему процессу, а также контрольный список по деидентификации данных.
3. Присвойте каждому специфическому материалу исследования стабильный внутренний идентификатор и номер версии.
4. Разделите шаблон картирования пути на семь стандартных этапов: поиск информации, уточнение соответствия критериям или требований, подготовка материалов, подача заявления, межведомственная обработка, уведомление о результате и последующая поддержка.
5. Изменяйте названия этапов только после документирования того, чем выбранная услуга отличается от стандартного пути подачи административного заявления с низким уровнем риска.
6. Сохраните ту же последовательность точек взаимодействия, ответственных лиц, входных данных, результатов, болевых точек и последующих последствий.
7. Разработайте сценарии симуляции государственных услуг для листов с заданиями по прототипированию, не используя реальные персональные, административные данные или данные ведомств.
8. Обратитесь к Таблице 1 для ознакомления с этапами, распределением времени, материалами и предопределенными результатами, необходимыми для протокола.
9. Обратитесь к Таблице 2 для ознакомления с пунктами сбора данных, правилами оценки, порогами валидности и мерами контроля защиты данных.
10. Используйте методы сервисного дизайна, чтобы сделать сложные проблемы государственных услуг видимыми, доступными для обсуждения и тестирования19.

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

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

3. Этап 1: Картирование стейкхолдеров

1. Попросите участников с помощью рабочего листа по картированию стейкхолдеров индивидуально перечислить от пяти до восьми субъектов, задействованных в выбранном процессе оказания государственной услуги.
2. Отведите на этап картирования стейкхолдеров 25–35 min.
3. Общая схема протокола визуализации представлена на Рисунке 1.
4. Предложите участникам оценить каждого перечисленного субъекта по четырем параметрам, используя пятибалльную шкалу с фиксированными значениями (1 = очень низкий; 5 = очень высокий): влияние на результат оказания услуги, зависимость от других субъектов, доступ к информации об услуге и давление в вопросах координации.
5. Предоставьте письменные примеры до того, как участники приступят к оценке.
6. Определите «высокое влияние» как характеристику субъекта, чье решение, задержка или интерпретация существенно влияют на результат оказания услуги.
7. Определите «высокую зависимость» как характеристику субъекта, который не может завершить процесс оказания услуги без информации, подтверждения или действий со стороны других субъектов.
8. Вычислите средний балл для каждой группы стейкхолдеров по каждому параметру.
9. Различие в два балла и более между группами стейкхолдеров по одному и тому же параметру отметьте как разрыв в восприятии, поскольку это соответствует сдвигу как минимум на 40% пятибалльной шкалы и является достаточно значимым для обсуждения на воркшопе, в отличие от незначительного шума при оценке.
10. Вынесите каждый отмеченный разрыв в восприятии на обсуждение в рамках воркшопа.
11. Используйте результаты картирования стейкхолдеров, чтобы визуализировать роли субъектов, их зависимости, влияние и информационную асимметрию до начала работы по редизайну20.
12. Сформируйте профиль взаимоотношений субъектов, включающий категории стейкхолдеров, средние баллы по параметрам и отмеченные разрывы в восприятии.

Рисунок 1Общая схема протокола визуализации проектирования государственных услуг. Рабочий процесс состоит из четырех взаимосвязанных этапов: картирования стейкхолдеров, картирования пути пользователя при получении государственных услуг, совместного проектирования по модели «Двойной алмаз» (Double Diamond) и тестирования прототипа. Результаты включают профили взаимоотношений участников, матрицы путей стейкхолдеров, формулировки задач проектирования, концепции прототипов и отзывы о юзабилити на ранних стадиях. Фазы «Открытие» (Discover), «Определение» (Define), «Разработка» (Develop) и «Реализация» (Deliver) структуры «Двойного алмаза» выделены для иллюстрации перехода от дивергентного исследования к конвергентной разработке решения. Пожалуйста, нажмите здесь, чтобы просмотреть увеличенную версию этого рисунка.

4. Этап 2: Картирование пути пользователя в государственных службах

1. Руководствуйте подгруппой семинара при картировании семиэтапного процесса оказания услуг.
2. Выделите на этот этап 45–60 min.
3. Инструктируйте участников зафиксировать для каждого этапа основного актора, входную информацию, выходную информацию, канал связи, типичную задержку, «болевую точку», степень серьезности и последующие последствия.
4. Попросите участников оценить степень серьезности каждой «болевой точки» по пятибалльной шкале (1 = незначительное неудобство; 5 = серьезный сбой, который, вероятно, повлияет на доступ к услугам, приведет к подаче официальной жалобы или вызовет серьезную эскалацию).
5. КРИТИЧЕСКИЙ ШАГ: Объединяйте «болевые точки» только в том случае, если они относятся к одному и тому же этапу пути, связаны с одним и тем же типом информационного пробела или неопределенностью ответственности и приводят к схожим последующим последствиям.
6. Сохраняйте в файле первичного кодирования «болевые точки», отмеченные только одним участником. Не приоритизируйте эти точки, если только они не получили оценку серьезности 4 или 5.
7. Сформируйте интегрированную матрицу пути стейкхолдеров (Figure 2) для визуализации наличия «болевых точек» (P), информационных пробелов (I), неопределенности ответственности (R) и возможностей редизайна (O) в ячейках матрицы.
8. Используйте картирование пути для локализации сбоев в обслуживании в последовательных точках взаимодействия, а не рассматривайте неудовлетворенность или задержку как единый совокупный результат21.

Рисунок 2Интегрированная матрица пути стейкхолдеров для визуализации проблем в сфере государственных услуг. Матрица объединяет семь этапов оказания государственных услуг на горизонтальной оси и основные группы заинтересованных сторон на вертикальной оси. Каждая ячейка указывает на наличие конкретных проблем в обслуживании, которые обозначаются следующими сокращениями: P = болевая точка; I = информационный пробел; R = неопределенность ответственности; O = возможность редизайна. Матрица служит визуальным связующим звеном между картированием заинтересованных сторон и совместным проектированием, объединяя роли стейкхолдеров с проблемами, характерными для конкретных этапов оказания услуг. Пожалуйста, нажмите здесь, чтобы просмотреть увеличенную версию этого рисунка.

5. Этап 3: Семинар по совместному проектированию по методу «Двойного алмаза»

1. Проведите семинар по совместному проектированию по методу «Двойного алмаза» (Double Diamond) в рамках сессии продолжительностью 2,5–3 ч.
2. Применяйте структуру «Двойного алмаза», чтобы разделить этап дивергентного исследования и этап конвергентного принятия решений7,8,14.
3. Обеспечьте участие граждан, медицинских работников первичного звена, администраторов и партнерских организаций в совместном создании или совместном проектировании, не полагаясь исключительно на внутренние реформы под руководством экспертов4,2.
4. Реализуйте этап «Исследование» (Discover) (30–40 мин).
5. Поручите участникам изучить матрицу пути стейкхолдеров и добавить недостающие карточки с «болевыми точками».
6. Убедитесь, что в каждой корректной карточке «болевой точки» зафиксированы этап пути, затронутый субъект, сбой в оказании услуги, информационный пробел или неопределенность ответственности, а также последующие последствия.
7. Реализуйте этап «Определение» (Define) (40–50 мин).
8. Попросите каждого участника самостоятельно выбрать три карточки «болевых точек», которые наилучшим образом представляют собой наиболее серьезные сбои в оказании услуг, затрагивающие нескольких субъектов.
9. Используйте анонимное голосование точками или письменное ранжирование перед открытым обсуждением, чтобы минимизировать влияние статуса и дисбаланс власти.
10. Сгруппируйте выбранные карточки в соответствии с этапом пути, затронутым субъектом, информационным пробелом или неопределенностью ответственности, а также последующими последствиями.
11. Попросите фасилитатора зачитать каждую группу вслух и подтвердить, что участники согласны с тем, что карточки описывают один и тот же сбой в оказании услуги.
12. Преобразуйте каждую группу в одну формулировку задачи по проектированию в формате «Как бы мы могли» (How might we).
13. Убедитесь, что каждая формулировка задачи по проектированию определяет затронутого субъекта, проблемный этап пути, сбой в оказании услуги и желаемое направление улучшений.
14. Проверьте каждую задачу по проектированию с помощью рубрики из четырех пунктов, оценивающей конкретику, ясность определения субъекта, связь с картированными доказательствами и осуществимость тестирования на низкодетализированном прототипе.
15. Пересмотрите любую формулировку, в которой пропущен субъект, объединено несколько несвязанных сбоев, преждевременно предлагается решение или которую невозможно протестировать с использованием имитационных материалов по оказанию услуг.
16. Запишите первоначальный вариант, причину пересмотра и окончательную утвержденную формулировку в аудиторский лист.
    ПРЕДОСТЕРЕЖЕНИЕ: Исследователи могут сделать перерыв после утверждения окончательных формулировок задач по проектированию и возобновить работу, когда будут подготовлены карточки решений и листы выбора прототипов.
17. Реализуйте этап «Разработка» (Develop) (50–60 мин).
18. Поручите участникам разработать идеи по улучшению услуг для каждой задачи по проектированию и зафиксировать их в карточках решений.
19. Исключите идеи, требующие реальных данных по случаям, индивидуальных записей о праве на получение услуги, серьезных законодательных или политических изменений или идентифицируемых административных файлов.
20. Реализуйте этап «Передача» (Deliver) (30–40 мин).
21. Попросите участников оценить каждую идею решения по пятибалльной шкале в соответствии с ожидаемым влиянием на качество услуги, осуществимостью внедрения, согласием стейкхолдеров и пригодностью для тестирования с помощью имитационных задач.
    ПРИМЕЧАНИЕ: Выбирайте концепции прототипов со средним баллом не менее 4,0 как по осуществимости, так и по тестируемости. Этот порог необходим для того, чтобы прототипы были жизнеспособны для тестирования с помощью имитационных задач без возникновения препятствий при внедрении. 

6. Этап 4: Тестирование низкоточного прототипа

1. Разработайте низкодетализированные прототипы для приоритетных концепций.
2. Подготовьте три формата прототипов: одностраничный контрольный список требований к услуге, макет отслеживания статуса услуги и схему последующих действий или эскалации.
3. КРИТИЧЕСКИЙ ШАГ: Перед тестированием создайте два сопоставимых набора заданий. Убедитесь, что наборы заданий сбалансированы по количеству шагов принятия решений, объему текста для чтения, количеству обязательных полей, сложности сценария и ожидаемому времени выполнения.
4. Сопоставьте наборы заданий по количеству шагов принятия решений, объему текста для чтения, количеству обязательных полей, сложности сценария и ожидаемому времени выполнения.
5. Проведите пилотное тестирование сопоставимых наборов заданий с участием трех-пяти пользователей, не участвующих в основном исследовании.
6. Пересмотрите наборы заданий, если среднее время выполнения различается более чем на 10%.
7. Проведите симуляцию задач по оказанию государственных услуг для оценки прототипов.
8. По мере возможности используйте контрбалансировку или дизайн с контрольной группой, чтобы отличить эффект привыкания к заданию от эффекта взаимодействия с прототипом.
9. Если все участники выполняют базовые задания до заданий с использованием прототипа, отметьте это как потенциальный риск эффекта обучения в разделах «Протокол», «Результаты» и «Обсуждение».
10. Предоставьте каждому участнику четыре сценария базовых заданий до взаимодействия с прототипом.
11. После взаимодействия с прототипом предоставьте четыре сопоставимых, но не идентичных сценария заданий.
12. Установите максимальный лимит времени 5 min для каждого задания.
13. Зачитывайте каждому участнику идентичные инструкции к заданиям.
14. Не давайте подсказок во время выполнения задания. Ограничьте пояснения только процедурными вопросами.
15. Измеряйте время выполнения задания в секундах от момента предъявления задания до окончательного ответа.
16. Если участник не выполняет задание в течение 5 min, отметьте задание как незавершенное, присвойте время выполнения 30 s и закодируйте успех выполнения задания как 0.
17. Кодируйте задание как успешно выполненное только в том случае, если участник выбирает правильный ответ или выполняет все необходимые шаги принятия решения в установленный срок.
18. Рассчитайте количество ошибок, подсчитав пропущенные, неправильные или излишние шаги принятия решений.
19. Сразу после каждого задания измеряйте субъективную оценку ясности участником, используя пятибалльную шкалу (1 = совсем неясно; 5 = очень ясно).
20. После завершения всех заданий попросите участников оценить удобство использования прототипа и намерение по его внедрению.
    ПРИМЕЧАНИЕ: Тестирование прототипа оценивает ясность и удобство использования материалов, созданных на основе протокола, в контексте выполнения конкретных задач, а не улучшение показателей эффективности государственных услуг23.

7. Анализ данных и контроль качества

1. Исключите ответы на опросник, заполненные менее чем за 3 min, ответы с более чем 20% пропущенных значений, идентичные ответы по всем пунктам шкалы Лайкерта или ответы, содержащие противоречивую информацию о роли респондента. 
2. Обобщите данные опросника, используя средние значения и стандартные отклонения для непрерывных переменных, а также частоты и проценты для категориальных переменных. 
3. Закодируйте данные стейкхолдеров и карты пути пользователя (journey mapping), используя структурированный лист кодирования. Два исследователя должны независимо закодировать не менее 20% материала перед обсуждением для достижения консенсуса, после чего следует указать процент согласия и коэффициент каппа Коэна или эквивалентный статистический показатель надежности. 
4. Проанализируйте результаты воркшопа путем подсчета валидных карточек «болевых точек», кластеров проблем, формулировок задач проектирования, идей решений, оценок осуществимости и отобранных концепций прототипов. 
5. Рассчитайте специфический для протокола балл юзабилити на основе пяти пунктов пятибалльной шкалы: ясность требований, видимость статуса, ясность следующего шага, легкость выполнения задачи и уверенность в использовании материала. Преобразуйте необработанный балл (в диапазоне от 5 до 25) в шкалу 0-10 по формуле: 
   балл юзабилити = (необработанный балл - 5) / 20 x 1017
6. Проанализируйте данные тестирования прототипа для извлечения показателей ясности и юзабилити на основе задач. Используйте IBM SPSS Statistics (Analyze > Compare Means > Paired-Samples T Test; Analyze > Nonparametric Tests > Related Samples; Analyze > Descriptive Statistics > Crosstabs > Statistics > McNemar) или эквивалентные команды R (t.test(..., paired = TRUE), wilcox.test(..., paired = TRUE) и mcnemar.test()) для экспорта тестовой статистики, точного P value, 95% доверительного интервала (при наличии) и величины эффекта. 
7. Интерпретируйте P values дескриптивно с заранее определенным уровнем значимости альфа 0.05, уделяя особое внимание направлению, величине и согласованности эффекта по всем показателям24.
8. Агрегируйте записи о повторяющихся задачах до уровня участника или используйте подходящую модель с повторными измерениями, если четыре задачи на каждое условие анализируются одновременно. 
   ПРИМЕЧАНИЕ: Не рассматривайте все записи задач как статистически независимые, если данное допущение не обосновано явным образом.
9. КРИТИЧЕСКИЙ ЭТАП: Документируйте все решения по очистке данных, кодированию, сопоставлению наборов задач и статистическому анализу в аудиторском листе для обеспечения воспроизводимости. Убедитесь, что все обезличенные данные хранятся в защищенных паролем файлах, доступных только исследовательской группе.

Результаты

Включение участников и осуществимость протокола
Протокол был успешно реализован: получено 10 валидных ответов на анкету (доля заполнения составила 89,3%), а выделенная подгруппа из 28 участников прошла этапы семинара и тестирования прототипа. В число оставшихся участников вошли представители семи категорий стейкхолдеров, вовлеченных в процесс оказания государственных услуг: граждане или пользователи услуг (n = 32), сотрудники первой линии обслуживания (n = 18), социальные работники (n = 14), администраторы государственных учреждений (n = 12), межведомственные координаторы (n = 8), представители третьего сектора (n = 10) и персонал службы поддержки цифровых платформ (n = 6).

28 участников семинара были разделены на пять групп со смешанными ролями, при этом каждая группа включала представителей как минимум трех категорий заинтересованных сторон. Все группы выполнили картирование заинтересованных сторон, картирование пути пользователя, совместное проектирование по методу Double Diamond и тестирование прототипа, в результате чего были созданы профили взаимосвязей участников, матрицы путей заинтересованных сторон, подтвержденные формулировки задач по проектированию, концепции прототипов и записи симуляционного тестирования задач (Таблица 3). Этапы структурированного картирования потребовали меньше вмешательств фасилитатора, чем фазы определения проблемы.

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

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

На этапе картирования пути пациента было сформулировано 126 первичных утверждений о «болевых точках». После структурированного объединения по этапам пути и последующим последствиям было отобрано 38 уникальных сбоев в обслуживании, из которых 12 соответствовали заранее определенным критериям приоритетности (частота ≥10% или степень тяжести ≥4.0). Большинство приоритетных сбоев происходило во время подготовки материалов, уточнения соответствия критериям включения и межведомственной обработки. Эти результаты были обобщены в интегрированной матрице пути заинтересованных сторон (Рисунок 2).

Трансформация совместного проектирования и создание прототипов
В ходе семинара по совместному проектированию по методу «Double Diamond» участники составили 94 валидных карточки с «болевыми точками», которые были сгруппированы в 14 проблемных областей. Из 17 первоначальных формулировок задач по проектированию шесть потребовали доработки, так как в них отсутствовало направление для улучшения, слишком широко определялся затронутый субъект или предлагалось решение до четкого определения проблемы. После пересмотра на основе критериев оценки были сохранены 11 формулировок задач по проектированию.

На этапе разработки участники предложили 32 идеи по улучшению обслуживания. Применение заранее определенных пороговых значений осуществимости и тестируемости (баллы ≥4.0) позволило сократить этот список до шести основных концепций. Для проведения тестирования на основе заданий были выбраны три концепции низкодетализированных прототипов: одностраничный контрольный список требований к обслуживанию, макет отслеживания статуса обслуживания и определенный путь эскалации (Рисунок 3). Численные результаты всех этапов визуализации и совместного проектирования обобщены в Таблице 4.

Рисунок 3Путь трансформации от проблемной точки к прототипу. На рисунке представлены три пути преобразования приоритетных проблемных точек в формулировки задач проектирования и концепции низкодетализированных прототипов. Задачи проектирования представлены в формате «Как мы могли бы» (How might we) — методе совместного проектирования, который используется для формулирования проблем в виде открытых возможностей для поиска решений. Показаны следующие примеры: (1) от нечетких или противоречивых требований к материалам к одностраничному контрольному списку требований к услуге; (2) от неясного статуса услуги и ответственного исполнителя к макету системы отслеживания статуса услуги; и (3) от неопределенности дальнейших действий после задержек, отказов или запросов на исправление к схеме последующих действий или эскалации. Пожалуйста, нажмите здесь, чтобы просмотреть увеличенную версию этого рисунка.

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

Результаты тестирования прототипа на основе выполнения задач
В ходе применения протокола было получено 24 записи о выполнении симулированных задач от 28 участников, включая 12 записей исходного уровня (baseline) и 12 записей после использования прототипа. Материалы, созданные с помощью протокола, были связаны с повышением эффективности при выполнении симулированных задач. Мы провели анализ парных выборок на уровне участников (n = 28), чтобы учесть внутрииндивидуальные корреляции при повторном выполнении задач. Среднее время выполнения задачи значимо сократилось со 178.4 ± 35.8 s на исходном уровне до 121.7 ± 28.4 s после использования прототипа (средняя разность = −56.7 s; 95% CI, −68.3 – −45.1 s; Cohen’s dz = −1.92; парный t-критерий, P < 0.01). Аналогично, среднее количество ошибок на одного участника снизилось с 1.86 ± 0.61 до 0.79 ± 0.4 (средняя разность = −1.07 ошибок; 95% CI, −1.27 – −0.87; Cohen’s dz = −2.05; парный t-критерий, P < 0.001). Показатели успешности выполнения задач анализировались с помощью критерия знаковых рангов Уилкоксона для долей успеха на уровне участников, что показало значимое улучшение (Z = −4.12, P < 0.01). Средние оценки ясности также значимо улучшились на уровне участников, увеличившись с 3.1 ± 0.5 до 4.2 ± 0.4 (средняя разность = 1.10 баллов; 95% CI, 0.94–1.26; Cohen’s dz = 2.71; парный t-критерий, P < 0.01).

Общий показатель успешного выполнения задач увеличился с 62,5% (70/12 записей о задачах) на исходном этапе до 82,1% (92/12 записей о задачах) после использования прототипа, что представляет собой увеличение на 19,6 процентных пункта (95% ДИ: от 8,2 до 31,1 процентного пункта; сравнение двух пропорций, P = 0,01). Поскольку совокупные данные указывают на 2 дополнительные успешные записи о задачах после использования прототипа, все возможные таблицы парных расхождений дали точный результат по критерию Макнемара ниже P < 0,01, что подтверждает тот же вывод о направлении изменений, позволяя избежать реконструкции недоступных несогласованных пар на индивидуальном уровне.

Результаты, сообщенные участниками, соответствовали этим операционным данным. Средние оценки четкости увеличились с 3,1 ± 0,7 до 4,2 ± 0,5 по пятибалльной шкале (n = 12 записей задач на каждое условие; средняя разница = 1,10 балла; 95% ДИ: от 0,94 до 1,26; стандартизированная средняя разница на сводном уровне = 1,81; сводный P < 0,01). Итоговые материалы получили оценку юзабилити для конкретного протокола 78,4 ± 9,6 и оценку намерения по внедрению 4,1 ± 0,6 (Рисунок 4). Эти показатели юзабилити были рассчитаны на основе пяти пунктов исследования, специфичных для протокола, а не на основе стандартизированной шкалы юзабилити системы (SUS). Ответы в открытой форме подтвердили эти результаты: 21 из 28 участников отметили улучшение визуальной четкости матрицы пути стейкхолдера, 17 из 28 сообщили о более четком определении ролей акторов, 19 из 28 отметили более четкое разделение этапов оказания услуги и 20 из 28 подтвердили практическую применимость материалов прототипа.

Рисунок 4Результаты ясности выполнения задач и удобства использования после ознакомления с прототипом. (A) Среднее время выполнения задачи (с). (B) Среднее количество ошибок на задание. (С) Доля успешно выполненных задач (%). (D) Оценка четкости участниками (шкала 1–5). Дополнительные показатели на панели (D) включают оценку удобства использования конкретного протокола и намерение по его внедрению. Столбцы представляют средние значения на уровне участников, а планки погрешностей указывают стандартное отклонение (SD). Сравнения между исходным состоянием и состоянием после использования прототипа проводились на уровне участников и были статистически значимыми (P < 0,01) для времени выполнения, количества ошибок, ясности и доли успешного выполнения задач. Пожалуйста, нажмите здесь, чтобы просмотреть увеличенную версию этого рисунка.

Обсуждение

   Данный протокол представляет собой систематический, воспроизводимый метод структурирования сложных проблем в государственных сервисах с низким уровнем риска. За счет последовательной интеграции картирования стейкхолдеров, картирования пути пользователя, совместного проектирования по методу «Двойного алмаза» (Double Diamond) и тестирования низкодетализированных прототипов, этот метод позволяет преобразовать разрозненные жалобы множества участников в проверяемые сервисные интервенции, сохраняя при этом четкое различие между данными о юзабилити в симуляции и реальными показателями административной эффективности. Репрезентативные результаты показывают, что проблемы в государственном секторе редко ограничиваются одним процедурным этапом; напротив, они распределены между пользователями, сотрудниками первой линии и администраторами бэк-офиса. Ключевым преимуществом данного протокола является возможность визуализировать эти многосторонние зависимости и информационную асимметрию еще до начала разработки решений.

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

Структурированное применение концепции «двойного алмаза» (Double Diamond) обеспечивает контролируемый переход от исследования проблемы к реализации перепроектирования услуги. Результаты показывают, что переход от общих жалоб к конкретным формулировкам задач по проектированию «Как бы мы могли...» часто является самым сложным этапом процесса, требующим активной фасилитации, четких критериев отбора и документирования правок. Без этих структурных ограничений (определения затронутого субъекта, этапа пути, сбоя в оказании услуги и ожидаемого улучшения) сессии совместного проектирования могут привести к созданию шаблонных решений, которые не устраняют выявленные недостатки услуги. Прямая связь между приоритетной «болевой точкой» (например, неясные требования к материалам) и соответствующим ей прототипом (например, одностраничный контрольный список) подтверждает генеративную валидность данного протокола.

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

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

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

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

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

Материалы

Список материалов, использованных в этой статье

Имя	Компания	Каталожный номер	Комментарии
Заметки по синтаксису анализа или рабочему процессу	Исследовательская группа	PSD-VP-S17 v1.1	Для документирования рабочего процесса в SPSS или эквивалентном R для парных сравнений, критериев Вилкоксона, проверок чувствительности Макнемара, размеров эффекта, доверительных интервалов и отчетности по результатам.
Анонимный опросник на основе ролей	Исследовательская группа	PSD-VP-S02 v1.1	Для сбора информации о ролях заинтересованных сторон и базовых представлений о выбранном процессе государственного обслуживания.
Контрольный список деидентификации	Исследовательская группа	PSD-VP-S14 v1.1	Для обеспечения того, чтобы имена участников, идентификационные номера, адреса, ID дел и административные записи не собирались и не разглашались.
Шаблон проектирования проблемы	Исследовательская группа	PSD-VP-S07 v1.1	Для преобразования сгруппированных «болевых точек» в структурированные, проверяемые формулировки типа «Как мы могли бы...».
Рубрика калибровки фасилитатора	Исследовательская группа	PSD-VP-S15 v1.1	Для стандартизации подготовки фасилитаторов, кодирования примеров, пересмотра формулировок проблем и обеспечения согласованности между фасилитаторами.
Пятибалльный лист оценки заинтересованных сторон	Исследовательская группа	PSD-VP-S04 v1.1	Для оценки влияния, зависимости, доступа к информации и давления в вопросах координации для каждой заинтересованной стороны.
IBM SPSS Statistics	IBM Corporation	Version 26.0 или более поздняя	Для проведения описательного анализа, парных t-критериев, критериев знаковых рангов Вилкоксона и критериев Макнемара для результатов тестирования прототипа.
Материалы низкодетализированного прототипа	Исследовательская группа	PSD-VP-S10 v1.1	Для разработки и тестирования материалов обслуживания на ранней стадии, включая контрольный список требований, макет статуса услуги и схему последующих действий.
Microsoft Excel	Microsoft Corporation	Microsoft 365 или эквивалент	Для организации данных опросников, расчета описательной статистики, ведения листов кодирования и подготовки сводных таблиц.
Карточки болевых точек	Исследовательская группа	PSD-VP-S06 v1.1	Для фиксации сбоев в обслуживании, информационных пробелов, неопределенности ответственности, затронутых субъектов и последующих последствий.
Информационный листок участника	Исследовательская группа	PSD-VP-S01 v1.1	Для разъяснения целей исследования, процедур, прав участников и требований к согласию перед началом участия.
Хранилище данных с парольной защитой	Компьютерная система учреждения или исследовательской группы	Доступ ограничен исследовательской группой	Для безопасного хранения деидентифицированных данных опросников, результатов семинаров, файлов кодирования и записей о тестировании задач.
Рубрика оценки прототипа	Исследовательская группа	PSD-VP-S12 v1.1	Для оценки ясности прототипа, юзабилити, успеха выполнения задачи, количества ошибок и намерения использовать продукт.
Лист выбора прототипа	Исследовательская группа	PSD-VP-S09 v1.1	Для выбора концепций прототипов, которые соответствуют заранее определенным порогам осуществимости и тестируемости.
Шаблон картирования пути государственного обслуживания	Исследовательская группа	PSD-VP-S05 v1.1	Для картирования процесса государственного обслуживания: от поиска информации, уточнения требований, подготовки материалов, подачи заявки, обработки и уведомления до последующей поддержки.
Листы симуляции задач	Исследовательская группа	PSD-VP-S11 v1.1	Для оценки завершения задачи, точности принятия решений и ясности до и после ознакомления с прототипом.
Карточки решений	Исследовательская группа	PSD-VP-S08 v1.1	Для документирования идей по улучшению обслуживания, разработанных в ходе семинара по совместному проектированию по методу «Double Diamond».
Рабочий лист картирования заинтересованных сторон	Исследовательская группа	PSD-VP-S03 v1.1	Для идентификации 5–8 субъектов, участвующих в процессе государственного обслуживания, и визуализации ролей и зависимостей субъектов.
Структурированный лист кодирования	Исследовательская группа	PSD-VP-S13 v1.1	Для кодирования данных картирования заинтересованных сторон, результатов картирования путей, групп болевых точек и итогов семинара.
Контрольный список эквивалентности наборов задач	Исследовательская группа	PSD-VP-S16 v1.1	Для документирования соответствия базовых задач и задач после внедрения прототипа по этапам принятия решений, объему чтения, обязательным полям, сложности и времени выполнения в пилотном исследовании.