Разработка UX/UI-дизайна информационной системы для проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями

Мария Мухортова

Разработка UX/UI-дизайна информационной системы для проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями

Данная работа посвящена этапам разработки UX/UI-дизайна информационной системы для проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями, включающим разработку дизайна мобильного приложения для пациентов и веб-приложения для врачей. Разработка информационной системы необходима для проверки гипотезы, заключающейся в том, что при обеспечении актуальными данными о субъективном восприятии терапии пациентом врач сможет более эффективно организовать лечение, чем при получении только технических данных терапии. В первой главе представлено описание сложившейся в мире ситуации относительно респираторных заболеваний, а также существующие способы борьбы с наиболее распространенным хроническим респираторным заболеванием — ХОБЛ. Кроме этого в главе представлены общие сведения о разрабатываемой информационной системе и о процессе реализации проекта. Во второй главе представлены основные этапы работы над созданием дизайна информационной системы, включающие разработку информационной архитектуры, пользовательских сценариев, визуального стиля и прототипа высокой детализации для мобильного и веб- приложений. В результате работы был разработан UX/UI-дизайн информационной системы для проведения клинического исследования, включающий дизайн мобильного и веб- приложений. В рамках работы над дизайном мобильного приложения были разработаны: информационная архитектура, 9 пользовательских сценариев, стайлгайд, UI-kit и высокодетализированный прототип, включающий 18 экранов и 2 модальных окна на английском и немецком. В рамках работы над дизайном веб-приложения были разработаны: информационная архитектура, 21 пользовательский сценарий, стайлгайд, UI-kit и высоко детализированный прототип, включающий 3 экрана и 10 модальных окон.

Информатика

Диссертации

Вуз: Национальный исследовательский Томский государственный университет (ТГУ)

ID: 60db0f09e4dde5000191e65d

UUID: b62faee0-bb01-0139-3709-0242ac180005

Язык: Русский

Опубликовано: больше 3 лет назад

Просмотры: 80

21.7

Мария Мухортова

Национальный исследовательский Томский государственный университет (ТГУ)

Комментировать 0

Рецензировать 0

Скачать - 8,1 МБ

Поделиться работой

АННОТАЦИЯ Данная работа посвящена этапам разработки UX/UI-дизайна информационной системы для проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями, включающим разработку дизайна мобильного приложения для пациентов и веб-приложения для врачей. Разработка информационной системы необходима для проверки гипотезы, заключающейся в том, что при обеспечении актуальными данными о субъективном восприятии терапии пациентом врач сможет более эффективно организовать лечение, чем при получении только технических данных терапии. В первой главе представлено описание сложившейся в мире ситуации относительно респираторных заболеваний, а также существующие способы борьбы с наиболее распространенным хроническим респираторным заболеванием — ХОБЛ. Кроме этого в главе представлены общие сведения о разрабатываемой информационной системе, в том числе ее технические характеристики, и о процессе реализации проекта. Во второй главе представлены основные этапы работы над созданием дизайна информационной системы, включающие разработку информационной архитектуры, пользовательских сценариев, визуального стиля и прототипа высокой детализации для мобильного и веб- приложений. В результате работы был разработан UX/UI-дизайн информационной системы для проведения клинического исследования, включающий дизайн мобильного и вебприложений. В рамках работы над дизайном мобильного приложения были разработаны: информационная архитектура, 9 пользовательских сценариев, стайлгайд, UI-kit и высокодетализированный прототип, включающий 18 экранов и 2 модальных окна на английском и немецком. В рамках работы над дизайном веб-приложения были разработаны: информационная архитектура, 21 пользовательский сценарий, стайлгайд, UIkit и высокодетализированный прототип, включающий 3 экрана и 10 модальных окон.

ОГЛАВЛЕНИЕ Введение 6 1 Анализ предметной области. Общие положения об информационной системе для проведения клинического исследования 9 1.1 Респираторные заболевания: причины, последствия, ситуация в мире 9 1.2 Методы борьбы с симптомами хронической обструктивной болезни легких 10 1.3 Задачи информационной системы, команда и подходы к организации этапов реализации проекта 13 1.3.1 Задачи и функции информационной системы 13 1.3.2 Скрам как подход к организации работы команды над проектом 15 1.3.3 Распределение ролей и задач в команде 17 1.4 Технические характеристики информационной системы 2 Этапы разработки UX/UI-дизайна информационной системы для проведения клинического исследования 18 20 2.1 Информационная архитектура информационной системы 20 2.2 Разработка пользовательских сценариев 29 2.3 Разработка визуального стиля информационной системы 54 2.3.1 Разработка стайлгайда 54 2.3.2 Разработка UI kit 61 2.4 Разработка прототипа высокой детализации 69 Заключение 78 Список использованной литературы 79 5

ВВЕДЕНИЕ На сегодняшний день информационные технологии стали неотъемлемой частью жизни каждого человека отдельно. Наш век называют веком информационных технологий, поскольку все основные сферы жизни характеризуются их присутствием: образование, транспорт, развлечения и другие. Медицина также включена в процесс трансформации под влиянием информационных технологий: например, появилась телемедицина — дистанционное предоставление медицинских услуг и взаимодействие медицинских работников между собой с помощью телекоммуникационных технологий [Клейменова, 2021]. Телемедицина предстает в разных формах: к ней можно отнести удаленные консультации со специалистом, удаленный мониторинг состояния пациента, обмен данными между специалистами и многое другое. Инструменты телемедицины экономят время и силы как пациента, так и врача, поскольку благодаря им многие процедуры могут быть проведены дистанционно с использованием современных технологий: дистанционные консультации позволяют пациентам не тратить время на больничные очереди, а современное мониторинговое оборудование — врачам на ручные замеры показателей здоровья пациентов. Телемедицина стала актуальна как никогда в текущих условиях эпидемии коронавируса, когда для многих людей с заболеваниями, находящимися в группе риска, посещение больницы могло иметь опасность для жизни. В группу риска тяжелого течения заболевания вошли в числе прочих люди, страдающие от хронических респираторных заболеваний, таких как астма, эмфизема и хроническая обструктивная болезнь легких [24]. Актуальность данной работы обусловлена необходимостью поиска новых решений в сфере телемедицины хронических респираторных заболеваний. Люди с такими серьезными заболеваниями как ХОБЛ (хроническая обструктивная болезнь легких) и астма нуждаются в эффективном лечении, которое, как правило, требует постоянного наблюдения со стороны врача. По данным исследований около 545 миллионов людей во всем мире страдали от хронических респираторных заболеваний в 2017 году, а ХОБЛ и астма составляли 3,9% и 3,6% соответственно от общего числа случаев всех заболеваний [Labaki, Han, 2020]. С появлением в нашей жизни широко распространившейся коронавирусной инфекции ситуация может стать только хуже, поскольку по данным некоторых исследований тяжелое течение болезни может приводить к осложнениям и возникновению у пациентов впоследствии хронических заболеваний дыхательных путей [Фройнд А., Елкина, 2020]. Таким образом можно сказать, что в настоящий момент существует необходимость в повышении внимания к проблеме хронических респираторных заболеваний и разработке новых эффективных способов их лечения. 6

Одним из шагов на пути к возможному эффективному решению может стать разработка информационной системы для проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями. Цель создания информационной системы состоит в проверке гипотезы, заключающейся в том, что при обеспечении актуальными данными о субъективном восприятии терапии пациентом врач сможет более эффективно организовать лечение, чем при получении только технических данных терапии. Объектом данной квалификационной работы является процесс передачи субъективного восприятия терапии пациентом лечащему врачу. Предметом является UX/UI-дизайн информационной системы для проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями. Целью работы является разработка UX/UI-дизайна информационной системы для проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями. Для достижения поставленной цели были сформулированы следующие задачи. 1. Определить специфику процесса терапии хронического респираторного заболевания с использованием аппарата ИВЛ серии prisma VENT. 2. Выявить основные характеристики существующих программных решений для аппаратов ИВЛ от компании Löwenstein Medical на основе анализа продуктов компании ООО «МЦЦ Томск». 3. Разработать информационную архитектуру и пользовательские сценарии для мобильного и веб- приложений. 4. Разработать визуальную концепцию дизайна интерфейса, включающую стайлгайд и UI-кит, для мобильного и веб- приложений. 5. Разработать высоко детализированные прототипы для мобильного и вебприложений. Теоретическая база исследования основана на статьях из области медицины острых и хронических респираторных заболеваний (Фройнд, Елкина, Татарский, Бабак, Кирюхин, Уайз, Баскаков, Сорьяно, Labaki, Han), а также работ, посвященных разработке пользовательских интерфейсов (Гродская, Жолудова, Нарижный, Руд, Савин, Свеженцева,). Научная новизна состоит в разработке UX/UI-дизайна информационной системы для проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями, не имеющей полного аналога на рынке. 7

Теоретическая значимость работы заключается в классификации и описании способов борьбы с хроническими респираторными заболеваниями, а также описании опыта разработки в команде, что может дополнить теоретическую базу в этой области. Практическая значимость работы заключается в разработке информационной системы с разработанным дизайном для проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями, а в случае подтверждения гипотезы исследования — применении информационной системы для повышения эффективности терапии пациентов этой группы заболеваний. В работе применялись такие методы исследования и разработки проекта как метод синтеза и анализа, метод дизайн-мышления, метод построения информационной архитектуры, методы построения Userflow, методы создания UI-kit. Структура данной магистерской диссертации включает введение, две главы (теоретическую и практическую), заключение и список литературы. В первой главе представлено описание сложившейся в мире ситуации относительно респираторных заболеваний, а также существующие способы борьбы с наиболее распространенным хроническим респираторным заболеванием — ХОБЛ. Кроме этого в главе представлены общие сведения о разрабатываемой информационной системе, включающие ее технические характеристики, и о процессе реализации проекта. Во второй главе представлены основные этапы работы над созданием дизайна информационной системы, включающие разработку информационной архитектуры, пользовательских сценариев, визуального стиля и прототипа высокой детализации. В заключении приведены краткие результаты и выводы о проведенной научноисследовательской работе. Список литературы представлен 30 источниками, в том числе зарубежными и изданными не позднее 5 лет. Результаты проектной работы были представлены на XXIII международной конференции молодых ученых «Актуальные проблемы социальных наук». 8

1 Анализ предметной области. Общие положения об информационной системе для проведения клинического исследования 1.1 Респираторные заболевания: причины, последствия, ситуация в мире В связи со сложившейся на сегодняшний день ситуацией в мире медицина респираторных заболеваний стала актуальна как никогда. Распространившаяся в конце 2019 - начале 2020 года коронавирусная инфекция напомнила человеку о важности проблемы заболеваний дыхательных путей. На начало июня 2021 года отмечено около 170 миллионов случаев заболевания COVID-19 во всем мире, из которых 3,54 миллиона — с летальным исходом [Coronavirus Pandemic (COVID-19) – the data, 2021]. Начиная с весны 2020 года жизнь людей во всем мире изменилась: локдауны, закрытие границ, новые правила поведения в общественных пространствах, и все из-за глобального распространения одной острой респираторной инфекции. Однако коронавирусная инфекция – далеко не единственная опасность для здоровья дыхательных путей современного человека. Респираторные заболевания включают широкий спектр заболеваний, начиная от относительно простых острых сезонных расстройств, таких как кашель, грипп и острый бронхит, до хронических прогрессирующих заболеваний, таких как хронический бронхит и ХОБЛ. Хронические респираторные заболевания в какой-то степени даже более опасны, чем острые, поскольку остаются с человеком до конца его жизни и могут прогрессировать при отсутствии надлежащего лечения. В настоящее время такие заболевания относятся к числу наиболее распространенных неинфекционных заболеваний во всем мире. В соответствии с «Исследованием глобального бремени болезней, травм и факторов риска» [Сорьяно Дж. и др., 2020] в 2017 году зафиксировано около 545 миллионов случаев хронических респираторных заболеваний, что на 39,8% больше, чем в 1990 году. При этом, по результатам исследования, они оказались наиболее распространены в регионах с высоким доходом, в то время как в Южной Азии и Тропической Африке процент заболеваний оказался наиболее низким. В 3,9 миллионах случаев хроническое респираторное заболевание стало причиной смерти пациента, что на 18% чаще, чем в 1990 году. Причиной сложившейся ситуации исследователи называют устоявшийся образ жизни современного человека, поскольку к основным факторам риска возникновения хронических заболеваний дыхательных путей и легких ВОЗ относит курение, загрязнение воздуха внутри помещений, загрязнение атмосферного воздуха, аллергены, а также различные профессиональные факторы риска 9 и уязвимость [8]. Исследования

подтверждают, что уровень загрязнения окружающей среды твердыми частицами и озоном, а также уровень подверженности воздействию загрязнения воздуха дымом и пылью на рабочем месте значительно увеличились в период с 1990 по 2017 год. Кроме этого, во многих странах по-прежнему наблюдается рост эпидемии курения, особенно среди женщин и подростков [26]. К факторам риска возникновения хронических респираторных заболеваний у детей также относят пассивное курение [25]. Лидерами по распространенности во всем мире среди хронических респираторных заболеваний являются хроническая обструктивная болезнь легких и астма, на 2017 год составляющие 3,9% и 3,6% соответственно от общего числа всех случаев заболеваний. Хроническая обструктивная болезнь легких (ХОБЛ) — это прогрессирующее угрожающее жизни заболевание легких, вызывающее одышку (изначально при физической нагрузке) и предрасполагающее к обострению и тяжелому заболеванию [Хроническая обструктивная болезнь легких (ХОБЛ), 2017]. Болезнь характеризуется возникновением обструкции, т. е. преграды, в дыхательном тракте и ограничением воздушного потока в легких. Сам термин «ХОБЛ» в основном характеризует симптомы и отчасти рассматривается как «конечная фаза заболевания». В настоящее время ХОБЛ включает в себя ряд хронических респираторных заболеваний: хронический обструктивный бронхит, хронический гнойный обструктивный бронхит, вторичную эмфизему лёгких, пневмосклероз, лёгочную гипертензию и хроническое лёгочное сердце [Татарский, Бабак, Кирюхин, Баскаков, 2004]. В некоторых случаях ХОБЛ может быть вызвана продолжительным заболеванием астмой. ХОБЛ неизлечима, однако лечение может смягчить симптомы, улучшить качество жизни и сократить риск смерти. Эта болезнь является наиболее распространенной формой заболевания в своем роде, объединяющей ряд других хронических респираторных заболеваний, а значит она угрожает жизни наибольшего числа людей, по сравнению с другими заболеваниями этой группы. Именно поэтому так важен поиск способов улучшения эффективности лечения ХОБЛ. 1.2 Методы борьбы с симптомами хронической обструктивной болезни легких Существует несколько способов облегчить ХОБЛ у пациентов. Самым первым и самым эффективным шагом в начале лечения этого заболевания у курящих людей считается отказ от курения. Именно отказ от курения замедляет, хотя полностью и не останавливает, скорость снижения функции легких и повышает долговременную выживаемость [Уайз, 2020]. Существует ряд стратегий, помогающих пациенту отказаться от курения: методы модификации поведения, групповые занятия, никотин-заместительная 10

терапия, врачебная поддержка и другие. Наиболее успешных результатов можно достичь при применении нескольких стратегий одновременно. Кроме того, для лечения ХОБЛ также активно применяется медикаментозная терапия. Основу медикаментозного лечения ХОБЛ составляют ингаляционные бронходилататоры, направленные на расширение бронхов и облегчение процесса дыхания. Они делятся на два вида: 1) короткодействующие препараты — бета-агонисты или М-антихолинергические препараты для быстрого купирования резко возникающих симптомов; 2) препараты для постоянного длительного применения — бронходилататоры длительного действия, позволяющие контролировать симптомы заболевания на длительном периоде. Для доставки препарата используются ингаляторы различных видов: дозирующиеаэрозольные, порошковые, «мягкие» аэрозоли и небулайзеры. Одновременно с бронходилататорами для лечения обострений ХОБЛ иногда также используются кортикостероиды — препараты, обладающие противовоспалительными свойствами. Кортикостероиды бывают представлены в виде ингаляторов, таблеток или растворов для капельницы. В качестве дополнения к медикаментозной терапии пациентам с ХОБЛ иногда также назначается легочная реабилитация, которая включает в себя физические упражнения, образовательные программы и поведенческие методики. Реабилитация помогает пациентам получить большую независимость и толерантность к физическим нагрузкам, а пациентам с тяжелым течением ХОБЛ – преодолеть психологические ограничения и получить реальные надежды на улучшение состояния. Хирургическое лечение тяжелых форм ХОБЛ включает такие варианты как уменьшение объема легких и трансплантацию легких. В качестве хирургического лечения некоторым пациентам с ХОБЛ также производят установку эндобронхиальных клапанов – устройств, имплантирующихся в дыхательные пути и позволяющих пациенту дышать с использованием здоровой части легких, что является более продуктивным, поскольку дыхание с помощью пораженных частей легких может приводить к невозможности выдоха. Помимо вышеописанных способов для лечения пациентов с ХОБЛ также применяются технические решения, одно из которых — аппараты для оксигенотерапии. Оксигенотерапия (или кислородотерапия) – это применение кислорода в целях лечения и профилактики заболеваний, прежде всего, дыхательной и сердечно-сосудистой систем [7]. Из-за развивающейся дыхательной недостаточности некоторые пациенты с тяжелой или 11

прогрессирующей ХОБЛ могут иметь очень низкий уровень кислорода в крови. Для обеспечения пациентов необходимым уровнем кислорода на сегодняшний день существует ряд технических решений – аппаратов, с помощью которых пациент вдыхает воздух с повышенным содержанием кислорода. Для использования в домашних условиях в настоящий момент распространены кислородные концентраторы, выделяющие молекулы кислорода из окружающей атмосферы и выдающие поток воздуха с повышенной концентрацией кислорода. Однако аппараты для оксигенотерапии – не единственное техническое решение, позволяющее облегчить симптомы у пациентов с хроническими респираторными заболеваниями, такими как ХОБЛ. Существуют также аппараты СИПАП-терапии – это аппараты искусственной вентиляции легких, представляющие собой небольшой компрессор, подающий постоянный поток воздуха под определенным давлением в дыхательные пути через гибкую трубку и герметичную носовую маску. Таким образом, СИПАП-аппарат не даёт дыхательным путям смыкаться и блокировать поступление воздуха (и необходимого организму кислорода). В результате исключается риск внезапной смерти от отсутствия кислорода, а также обеспечивается нормальный сон. СИПАПаппараты используют для лечения хронических респираторных заболеваний, сопровождающихся обструкцией дыхательных путей, например, для таких как ХОБЛ и синдром обструктивной остановки дыхания во сне. К аппаратам СИПАП-терапии относятся аппараты искусственной вентиляции легких серии prisma VENT, которые производит компания Löwenstein Medical и для которых была разработана информационная система для проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями. Важно отметить, что данные аппараты ИВЛ очень мобильны и их возможно использовать для лечения пациентов с ХОБЛ как в клинике, так и в домашних условиях. При этом для того, чтобы получить аппарат из серии prisma VENT для использования на дому, пациенту необходимо обратиться в немецкую клинику, оборудование которой поставляет Löwenstein Medical, с подходящими жалобами о своем здоровье. При соответствующем диагнозе лечащий врач может назначить пациенту терапию с использованием аппарата ИВЛ серии prisma VENT и наблюдать состояние пациента во время плановых приемов, а также с использованием облачного сервиса prisma CLOUD, на который аппарат ИВЛ с помощью встроенного модема отправляет технические данные о терапии. Однако технических данных о терапии с аппарата ИВЛ и плановых приемов может оказаться недостаточно для своевременного принятия врачом решения о вмешательстве в 12

терапию пациента при возникновении проблем и непредвиденных ситуаций. При отсутствии необходимого оперативного вмешательства в лечение пациента может снизиться его эффективность, что является неблагоприятной ситуацией как для самого пациента, так и для его лечащего врача. Именно поэтому компанией Löwenstein Medical было решено провести клиническое исследование эффективности терапии пациентов с респираторными заболеваниями, гипотеза которого заключается в том, что при обеспечении регулярными данными о субъективном восприятии терапии пациентом врач сможет более эффективно организовать лечение, чем при регулярном получении только технических данных с аппарата. Конечной целью проведения исследования является при подтверждении гипотезы внедрение средств, с помощью которых терапия пациентов с хроническими респираторными заболеваниями, такими как ХОБЛ, с использованием аппаратов ИВЛ серии prisma VENT станет еще более эффективной. Для проведения этого клинического исследования была разработана информационная система, описанная далее. 1.3 Задачи информационной системы, команда и подходы к организации этапов реализации проекта 1.3.1 Задачи и функции информационной системы Для решения поставленной задачи проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями была разработана информационная система, состоящая из мобильного и веб- приложений, а также серверной части. Разработка системы проходила в рамках компании ООО «МЦЦ Томск», занимающейся производством программного обеспечения. Основной деятельностью компании на данный момент является разработка программного обеспечения для медицины сна; продукты компании обеспечивают качественное взаимодействие пациентов с хроническими респираторными заболеваниями и врачей, работающих в этой области медицины, с аппаратами искусственной вентиляции легких, которые производит немецкая компания Löwenstein Medical. В число продуктов, разрабатываемых компанией ООО «МЦЦ Томск», входят вебсервисы для врачей и мобильные приложения для пациентов, позволяющие обеим сторонам процесса производить мониторинг состояния терапии хронического респираторного заболевания на основании технических данных, полученных с аппарата искусственной вентиляции легких, а также дистанционно управлять настройками аппарата, таким образом управляя режимом терапии. 13

Информационная система разрабатывалась по заказу представителя немецкой компании Löwenstein Medical, занимающейся производством медицинского оборудования, такого как наркозные аппараты, аппараты реанимационной вентиляции легких, аппараты в области неонатологии, аппараты мониторинга дыхания и сердечных ритмов и т. д. [29] В число разрабатываемого компанией оборудования входят аппараты искусственной вентиляции легких, которые могут использоваться как в клинических, так и в домашних условиях ввиду их высокой мобильности. Это такие аппараты ИВЛ как LUISA, VENTIlogic LS, prisma30ST-C и аппараты серии prisma VENT. Именно для аппаратов ИВЛ prisma VENT был получен заказ на разработку информационной системы для проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями. Данная информационная система предполагает две основных аудитории пользователей. Первая – пациенты с хроническим заболеванием органов дыхания, приписанные к одной из немецких клиник, которым Löwenstein Medical поставляет оборудование, и проходящие терапию с использованием аппарата искусственной вентиляции легких серии prisma VENT. Вторая аудитория пользователей – это врачи, работающие в соответствующих клиниках, за которыми закреплены вышеописанные пациенты. Соответственно, была поставлена задача разработать такое программное решение, которое бы учитывало и удовлетворяло сразу две категории пользователей – пациентов и врачей. В связи с этим было принято решение разработать информационную систему, состоящую из трех компонентов: 1) мобильное приложение с регулярными опросами о состоянии терапии для пациентов; 2) веб-приложение, позволяющее контролировать течение терапии пациентов, для врачей; 3) серверная часть. Для разработки мобильного приложения были поставлены следующие задачи: ● определить требования к структуре и дизайну мобильного приложения; ● определить технические требования к мобильному приложению; ● на основании требований к структуре и дизайну разработать дизайн мобильного приложения; ● на основании технических требований разработать клиентскую часть мобильного приложения с применением разработанного дизайна; ● обеспечить передачу данных между клиентом и сервером. Для разработки веб-приложения были поставлены следующие задачи: 14

● определить требования к структуре и дизайну веб-приложения; ● определить технические требования к веб-приложению; ● на основании требований к структуре и дизайну разработать дизайн вебприложения; ● на основании технических требований разработать клиентскую часть вебприложения с применением разработанного дизайна; ● обеспечить передачу данных между клиентом и сервером. Для всей информационной системы стояла общая задача разработки серверной части, на которой будет храниться информация системы, и обеспечения подключения к серверу клиентской части, что позволит мобильному приложению и веб-приложению передавать друг другу данные. 1.3.2 Скрам как подход к организации работы команды над проектом Работа над созданием информационной системы проходила по методике скрам. Скрам – это набор базовых элементов и правил, предназначенный для разработки и поддержки сложных продуктов [Швабер, Сазерленд, 2016]. Скрам является гибкой методологией разработки, так как приветствует изменения в требованиях в любой момент. Главным элементом методики скрам является скрам-команда – небольшая группа людей, которая работает над продуктом. Обычно скрам-команда включает в себя от трех до девяти человек. Основной задачей скрам-команды является разработка продукта, являющегося ценностью, которую создает команда. В качестве ценности может выступать программный продукт, мероприятия маркетинга, организационные изменения, инженерный проект, проект внедрения и прочие результаты деятельности команды. В нашем случае ценностью был разрабатываемый программный продукт – информационная система для проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями. Процесс работы над продуктом проходил спринтами – короткими циклами, которые имеют фиксированную продолжительность и следуют один за другим без перерывов и промежутков [Лобасев, 2017]. Длительность спринта обычно составляет от одной до четырех недель, в данном случае было решено ограничить длительность спринта двумя неделями. Немаловажную роль в методике скрам играет Product Owner – именно он определяет приоритет работ над продуктом, то, какую именно ценность, например, функции системы, скрам-команда будет разрабатывать в первую очередь, а какую отложит и разработает при наличии временных и других ресурсов. Все идеи и пожелания относительно продукта хранятся в бэклоге продукта, которым управляет Product Owner. 15

Структура спринта по скраму включает в себя ряд важных этапов и мероприятий. Начинается спринт как правило с планирования – встречи, на которой определяется цель спринта и составляется бэклог. На встрече должна присутствовать скрам-команда в полном составе, а также Product Owner, ведь именно он определяет цель и составляет бэклог спринта. В случае нашей команды Product Owner не присутствовал на планировании спринта, его задачи выполнял менеджер команды. Помимо планирования в методологии скрам также предусмотрены ежедневные встречи. Во время встречи команда собирается у доски задач и каждый участник скрам-команды по очереди отвечает на 3 вопроса: Что я сделал вчера? Что сделаю сегодня? Что меня тормозит и мешает двигаться вперед? Такие встречи имеют жесткое ограничение по времени — около 15 минут, из-за чего в процессе встречи происходит только выявление проблем, в то время как поиск решения выносится за рамки ежедневной встречи. В работе над данным проектом при выявлении проблем во время ежедневной встречи обсуждение решений происходило сразу после окончания встречи. Немаловажным мероприятием в скраме является обзор спринта – встреча, во время которой скрам-команда и Product Owner встречаются с заказчиком, а в лучшем случае и с конечными пользователями, и демонстрируют результаты работы, проделанной за этот спринт, отвечают на вопросы. Во время этой встречи могут вноситься коррективы в уже выполненную работу либо в дальнейшие планы работы над продуктом. В процессе работы над данным проектом обзор спринта начал проводиться не с начала работы над проектом, хотя с самого начала мы работали в рамках спринтов, а в тот момент, когда уже была технически реализована часть функционала как в мобильном, так и в вебприложении, с применением дизайна. До этого момента коммуникация происходила исключительно между Product Owner-ом и заказчиком, либо между менеджером команды и заказчиком, которые в дальнейшем доносили обратную связь, как правило, о дизайне системы, до команды. В завершение спринта обязательно проводится ретроспектива, во время которой скрам-команда обсуждает прошедший спринт: что было хорошо, какие возникали затруднения, что нового узнали в процессе работы. На ретроспективе могут обсуждаться как технические особенности процесса работы, так и взаимоотношения внутри команды. Цель этой встречи в том, чтобы команда не стояла на месте, а постоянно развивалась, совершенствовалась и работала эффективнее. В процессе работы над данным проектом также проводились регулярные ретроспективы, которые позволяли выявить проблемные места и точки роста, а иногда помогали решить проблемы личностных взаимоотношений 16

между членами команды и побороть недостаток мотивации. Роль скрам-мастера в нашей команде выполнял менеджер, который отвечал за проведение всех скрам-мероприятий. 1.3.3 Распределение ролей и задач в команде Над разработкой информационной системы работала команда из четырех человек, являющихся сотрудниками ООО «МЦЦ Томск». В команде были представлены следующие роли: 1) product Owner, 2) менеджер, 3) фулстек разработчик, 4) дизайнер. В роли Product Owner-а команды выступал Игорь, занимающий должность менеджера по разработке программного обеспечения в компании Löwenstein Medical и по совместительству являющийся руководителем разработки ПО в ООО «МЦЦ Томск». В обязанности Игоря входило обсуждение с заказчиком пожеланий и дальнейшее формирование требований к разрабатываемому продукту. Кроме того, Игорь занимался контролем разрабатываемой системы на всех этапах разработки. Роль менеджера проекта заняла Людмила, в ее обязанности входило формирование бэклога проекта, контроль разрабатываемой системы на всех этапах разработки, проведение скрам-мероприятий, тестирование, а также презентация результатов работы над проектом заказчику. Можно обратить внимание, что часть обязанностей Product Owner-a в случае нашей команды выполняла менеджер команды, однако, с нашей точки зрения, самой важной обязанностью Product Owner-a является общение с заказчиком и передача его видения команде, поэтому мы считаем, что в качестве Product Owner-a следует выделить Игоря как основного посредника между Löwenstein Medical и командой. В качестве фулстек-разработчика в проекте принимал участие Максим, старший разработчик компании ООО «МЦЦ Томск». Максим полностью взял на себя разработку программной части мобильного и веб-приложений, начиная с разработки архитектуры информационной системы и заканчивая реализацией UI-решений. На начальном этапе работы, при создании архитектуры системы, в проекте в качестве консультанта также принимал участие Артур, технический директор компании ООО «МЦЦ Томск». В роли дизайнера команды в проекте принимала участие Мария, дизайнер компании ООО «МЦЦ Томск», автор данной магистерской диссертации. Обязанности дизайнера включали: ● создание информационной архитектуры и пользовательских сценариев; 17

● разработку визуального стиля системы; ● создание макетов высокой детализации с применением разработанного визуального стиля. 1.4 Технические характеристики информационной системы Мобильное приложение для пациентов разрабатывалось с использованием кроссплатформенного фреймворка React Native, позволяющего писать код приложения на языке программирования JavaScript и автоматически компилирующего написанный код в нативный для целевых платформ разработки мобильных приложений, в которые входили iOS и Android. В основе написания компонентов лежит библиотека React, благодаря чему имплементация получается максимально близка к нативной. Преимущество данной библиотеки заключается в использовании компонентного подхода, т. е. в повторном использовании уже написанного кода, что ускоряет разработку и прототипирование системы. Главным плюсом библиотеки является ее нововведение Virtual DOM (Document Object Model), которое при правильном использовании позволяет оптимизировать рендеры и обновление страниц и компонентов с наименьшими потерями в производительности. Узким местом в производительности мобильного приложения является тот факт, что обмен данными происходит через мост между потоком JavaScript и нативным кодом, однако при правильной имплементации оно не является критичным. Таким образом, использование фреймворка обоснованно наличием знаний у разработчика в области web-разработки по части фронтенда и позволяет производить разработку приложения, не имея знаний в нативной разработке. Для коммуникации между клиентом и сервером используется JavaScript-библиотека Axios и push-нотификации. Веб-приложение для врачей реализовано на языке программирования JavaScript с использованием библиотек React, Redux и React Query. Преимущества использования библиотеки React описаны выше, а вот на библиотеках Redux и React Query остановимся подробнее. Библиотека Redux позволяет запрашивать данные с сервера и временно хранить глобальное состояние веб-приложения на клиенте. Однако мы стараемся уходить от использования библиотеки Redux и увеличить использование библиотеки React Query, которая кэширует запросы от сервера и позволяет исключить хранение состояния вебприложения в дополнительном объекте. Для коммуникации между клиентом и сервером используется JavaScript-библиотека Axios. Серверная часть информационной системы написана на платформе .NET Core 5.0 на языке C#. Такой выбор инструмента разработки обусловлен тем, что на сегодняшний день .NET Core является кроссплатформенной и позволяет развернуть сервис на любой из 18

архитектур Windows, MacOS и Linux. Сервер в нашем случае отвечает за следующие функции: ● авторизация пациентов и докторов; ● реализация бизнес-логики, т. е. менеджмент сущностей: создание, редактирование и удаление пациентов, врачей, исследований, опросов и т. д.; ● хранение данных. Таким образом, все API защищены авторизацией и разделены по группам на принадлежащие пациентам и принадлежащие лечащим врачам. Пациент не может получить данные врача, а доктор — данные пациента, каждый получает информацию в том виде, в котором она ему может быть доступна в рамках бизнес-логики. На данный момент веб-сервис представляет собой монолит, но в случае, если будет решено развивать функционал системы, сервер будет разделен на ряд микросервисов, которые будут действовать в зонах своей ответственности. В таком случае сервер будет представлять собой стек с использованием микросервисной архитектуры, где сервисы будут общаться между собой по закрытой сети, а пользователь — с внешним шлюзом и UI. Для хранения данных в информационной системе используется СУБД PostgreSQL, для авторизации и аутентификации — IdentityServer от Microsoft. В качестве хостинга используется облачная платформа Microsoft Azure. В информационной системе также присутствует возможность интеграции с другим основным продуктом компании — prisma CLOUD, посредством Rest API. Далее в данной работе описаны особенности процесса решения третьей задачи первых двух компонентов разрабатываемой информационной системы, особенности процесса разработки дизайна мобильного и веб- приложений. 19

2 Этапы разработки UX/UI-дизайна информационной системы для проведения клинического исследования 2.1 Информационная архитектура информационной системы Первым этапом в работе над дизайном мобильного и веб- приложений стала разработка информационной архитектуры как мобильного, так и веб-приложения на основании предъявленных заказчиком требований. Важно отметить, что анализ требований и выявление необходимого к разработке функционала проводились Product Owner-ом и менеджером команды и дизайн системы производился на основании обозначенных соответствующими членами команды требований и скетчей — очень обобщенных эскизов будущих экранов, предоставленных Product Owner-ом. Требования к дизайну системы на момент разработки дизайна не были зафиксированы документально и обсуждались во время встреч скрам-команды, на тот момент состоявшей из Product Owner-а, менеджера и дизайнера — разработчики были подключены к работе над проектом позже, когда большая часть дизайна была уже готова. Более того, в процессе демонстрации и обсуждения выполненного дизайна с заказчиком требования дополнялись в соответствии с новыми идеями того, что необходимо включить в систему, что является характерным признаком работы по гибкой методологии, в нашем случае работы по скраму. Ниже представлены письменно сформулированные для этой магистерской диссертации требования к дизайну информационной архитектуры двух компонентов разрабатываемой информационной системы: к мобильному приложению и к вебприложению, которые вошли в финальный продукт, а также результаты работы по разработке информационной архитектуры обоих компонентов на основании перечисленных требований. Требования к дизайну информационной архитектуры мобильного приложения для пациентов можно обозначить следующим образом: Мобильное приложение для пациентов должно: 1) предоставлять возможность авторизации пользователя с помощью кода исследования и кода пациента, генерируемого и передаваемого ему лечащим врачом; 2) предоставлять возможность прохождения пользователем регулярных ежедневных и ежемесячных опросов о состоянии его здоровья и симптоматики заболевания, а также регулярного или вручную активированного лечащим врачом опроса-контроля уровня приспособленности пациента к прохождению терапии с использованием аппарата искусственной вентиляции легких серии prisma VENT; 20

3) предоставлять пользователю информацию о сроке, выделенном на прохождение опроса; 4) напоминать пользователю о необходимости прохождения опроса или о необходимости использования дополнительного мониторингового оборудования (prisma CHECK); 5) предоставлять пользователю возможность самостоятельной активации опросапроверки уровня приспособленности к прохождению терапии с использованием аппарата искусственной вентиляции легких серии prisma VENT при возникновении проблем; 6) предоставлять пользователю инструкцию к использованию дополнительного мониторингового оборудования (prisma CHECK); 7) предоставлять пользователю информацию о технических данных прохождения терапии, полученных с аппарата искусственной вентиляции легких — время использования аппарата и число утечки воздуха, — в доступной для пользователя форме за каждый день прохождения терапии с начала исследования; 8) предоставлять пользователю обобщенную информацию об исследовании и о назначении мобильного приложения; 9) предоставлять пользователю доступ к материалам о необходимой ежедневной физической активности; 10) мотивировать пользователя к выполнению необходимой ежедневной физической активности; 11) предоставлять пользователю возможность передачи лечащему врачу факта выполнения необходимой ежедневной физической активности. На основании вышеперечисленных требований была разработана информационная архитектура мобильного приложения, представленная на Рисунке 1. 21

Рисунок 1 – Информационная архитектура мобильного приложения для пациентов На представленной схеме на Рисунке 1 отражены основные блоки информационной архитектуры мобильного приложения с точки зрения их дальнейшей визуализации. Для некоторых блоков в схеме также было указано содержимое этих блоков с целью разъяснить назначение блока и подчеркнуть необходимость его присутствия в приложении. На схеме была применена цветовая индикация блоков с целью визуально объединить тесно связанные между собой блоки и в целом упростить визуальное восприятие схемы. Между блоками установлены связи, изображенные в виде стрелок. Были выбраны стрелки для отображения связей между блоками с целью отразить 22

естественную последовательность, в соответствии с которой пользователь будет двигаться от одного блока к другому при достижении определенной цели. Подробные пути пользователя при решении определенной задачи будут представлены далее в пользовательских сценариях. Возле связи мы также указали наименование структурного элемента, с помощью которого будет визуально представлен блок, если он не является полноценным экраном, либо же указали наименование элемента, который пользователю необходимо активировать, чтобы перейти к следующему блоку, представленному экраном. Некоторые блоки, представленные в схеме, не имеют связей с другими блоками: это блоки «Модальное окно-напоминание об опросе», «Экран отсутствия подключения к интернету» и «Экран загрузки». Такие блоки могут появиться при взаимодействии с мобильным приложением независимо от пути, который проходит пользователь, либо же появляются с некоторой регулярностью на разных этапах взаимодействия. Было принято решение отразить их в схеме, поскольку такие блоки имеют важное значение для информационной архитектуры мобильного приложения и без них его реализация была бы неполноценной. Из представленной схемы информационной архитектуры мобильного приложения можно сделать вывод, взаимодействовать что основным блоком, пользователь-пациент, является с которым экран будет дашборда. чаще всего Исходя из определения, данного в статье на ресурсе SendPulse Blog, дашборд — это интерактивная панель с важной информацией, сгруппированной на одном экране [Веселов, 2020]. В нашем случае с помощью дашборда пациент имеет следующие возможности: 1) просмотр информации о необходимых для прохождения опросах (ежемесячный опрос и опрос-контроль терапии), такой как наименование, срок и статус (новый/начат) в карточке в разделе «Напоминания»; 2) переход к прохождению ежемесячного опроса или опроса-контроля терапии с помощью карточки в разделе «Напоминания»; 3) переход к инструкции к использованию дополнительного мониторингового оборудования (prisma CHECK) с помощью карточки в разделе «Напоминания»; 4) самостоятельная активация опроса-контроля терапии; 5) прохождение ежедневного опроса о состоянии здоровья и симптоматики заболевания пациента в разделе «Ежедневный опрос»; 6) просмотр информации о технических данных прохождения терапии, полученных с аппарата искусственной вентиляции легких, за каждый день прохождения терапии с начала исследования в карточках в разделе «Ежедневный отчет»; 23

7) переход к источнику с материалами о необходимой ежедневной физической активности с помощью ссылки на внешние ресурс (Youtube) в карточке «Контроль физической активности»; 8) отчет о выполнении необходимой ежедневной физической активности с помощью чекбокса в карточке «Контроль физической активности»; 9) переход к просмотру общей информации об исследовании, контактах клиники и возможных настройках с помощью иконки «Инфо». Кроме того, именно на экране дашборда после авторизации пользователя-пациента в мобильном приложении планировалось расположить модальное окно-напоминание о необходимости прохождения ежемесячного опроса или опроса-контроля терапии, срок жизни которого скоро истекает. Решение использовать в мобильном приложении такой инструмент как дашборд и поместить на него доступ ко всему основному функционалу приложения было принято с целью увеличить эффективность взаимодействия пользователя-пациента с приложением за счет сокращения количества шагов, которые ему необходимо пройти для получения какой-либо информации или достижения той или иной цели. Реже всего пациент-пользователь мобильного приложения в идеальной ситуации будет взаимодействовать с блоками «Приветственный экран» и «Экран авторизации». Такая ситуация обуславливается тем, что в мобильном приложении не предусмотрен функционал выхода пользователя из своего аккаунта. Командой было принято решение ограничить пользователя-пациента в этом действии по той причине, что пациент не может самостоятельно прекратить свое участие в клиническом исследовании. Прекращение участия в исследовании происходит строго после согласования данного действия с лечащим врачом и только лечащий врач имеет полномочия прекратить участие пациента в исследовании. Для прекращения участия пациента в клиническом исследовании был разработан соответствующий функционал в веб-приложении для врача, о котором и пойдет речь дальше. Требования к дизайну информационной архитектуры веб-приложения для врачей можно обозначить следующим образом: Веб-приложение для врачей должно: 1) предоставлять возможность авторизации пользователя с помощью логина и пароля, либо с помощью Azure Active Directory; 2) предоставлять пользователю возможность просмотра списка всех участников исследования; 24

3) предоставлять пользователю краткую информацию о каждом участнике исследования, включающую идентификационный номер пациента, усредненные значения данных с аппарата ИВЛ за последние 3 дня (время использования аппарата и утечка воздуха), средние значения результатов опросов за последнее время, группу риска и заголовок последней заметки, для наиболее эффективной работы со списком; 4) предоставлять пользователю возможность добавления новых участников возможность поиска списку участников исследования в список вручную; 5) предоставлять пользователю по исследования; 6) предоставлять пользователю возможность прекращения участия пациента в исследовании; 7) предоставлять пользователю общую информацию об участнике исследования, включающую в себя серийный номер аппарата ИВЛ, тип аппарата, дату последней синхронизации с интегрированным облачным сервисом prisma CLOUD, расположение пациента (в клинике или на дому), разрешение на звонки (получено или отсутствует), статус кода для авторизации и дату последнего использования мобильного приложения; 8) предоставлять пользователю возможность генерации кода пациента для авторизации в приложении; 9) предоставлять пользователю возможность экспорта отчета о технических данных о терапии пациента из интегрированного сервиса prisma CLOUD; 10) предоставлять пользователю возможность перехода к странице пациента в интегрированном сервисе prisma CLOUD; 11) предоставлять пользователю анамнез пациента; 12) предоставлять пользователю возможность заполнения начального опроса, соответствующего анамнезу пациента; 13) предоставлять пользователю заполнение финального опроса по окончанию периода исследования для пациента; 14) предоставлять пользователю возможность просмотра, добавления, редактирования и удаления заметок о взаимодействии с пациентом; 15) предоставлять пользователю средние значения результатов опросов за последнее время, которое конкретизируется для ежедневного опроса как последние 5 недель, для ежемесячного — последние 5 месяцев, для опроса-контроля терапии — последние 5 случаев прохождения опроса пациентом; 16) предоставлять пользователю возможность подробного просмотра результатов ежедневного опроса за неделю; 25

17) предоставлять пользователю возможность подробного просмотра результатов ежемесячного опроса и опроса-проверки терапии, включающего просмотр значений ответов на конкретные вопросы опроса и средних значений результата; 18) предоставлять пользователю возможность просмотра результатов ежедневных, ежемесячных опросов и опросов-контроля терапии за все время исследования; 19) предоставить пользователю информацию о количестве случаев выполнения пациентом необходимой ежедневной физической активности за все время исследования. На основании вышеперечисленных требований была разработана информационная архитектура веб-приложения, представленная на Рисунке 2. 26

Рисунок 2 – Информационная архитектура веб-приложения для врачей На представленной информационной схеме архитектуры на Рисунке веб-приложения 2 с отражены точки зрения основные блоки их дальнейшей визуализации. Для некоторых блоков в схеме также было указано содержимое этих блоков с целью разъяснить назначение блока и подчеркнуть необходимость его присутствия в веб-приложении. На схеме была применена цветовая индикация блоков с целью визуально объединить тесно связанные между собой блоки и в целом упростить визуальное восприятие схемы. Между блоками установлены связи, изображенные в виде стрелок. Мы 27

выбрали стрелки для отображения связей между блоками с целью отразить естественную последовательность, в соответствии с которой пользователь будет двигаться от одного блока к другому при достижении определенной цели. Подробные пути пользователя при решении определенной задачи будут представлены далее в пользовательских сценариях. Возле связи мы также указали наименование структурного элемента, с помощью которого будет визуально представлен блок, если он не является полноценным экраном, либо же указали наименование элемента, который пользователю необходимо активировать, чтобы перейти к следующему блоку, представленному экраном. В некоторых частях схемы структурный элемент перехода от одного блока к другому, реализующийся в виде кнопки, не указан в целях экономии пространства и сохранения читаемости представленной схемы Некоторые блоки, представленные в схеме, не имеют связей с другими блоками — это блоки «Отсутствие результатов поиска» и «Отсутствие синхронизации с prisma CLOUD». Такие блоки могут появиться при взаимодействии с веб-приложением независимо от пути, который проходит пользователь, либо же появляются с некоторой регулярностью на разных этапах взаимодействия. Было принято решение отразить их в схеме, поскольку такие блоки имеют важное значение для информационной архитектуры веб-приложения и без них его реализация была бы неполноценной. На представленной схеме информационной архитектуры веб-приложения можно обратить внимание, что основным инструментом врача для взаимодействия с приложением становится таблица участников исследования, так называемый «дашборд врача». В этом блоке приложения пользователь-врач имеет следующие возможности: 1) добавление новых участников исследования в таблицу пациентов вручную с помощью кнопки с соответствующей иконкой; 2) поиск по списку участников исследования с помощью поля поиска; 3) просмотр краткой информации о каждом участнике исследования в свернутой карточке пациента и принятие решения о вмешательстве в терапию на основании его группы риска; 4) просмотр общей информации, анамнеза, заметок и результатов опросов за последнее время в развернутой карточке пациента; 5) прекращение участия пациента в исследовании в развернутой карточке пациента; 6) генерация кода пациента для его дальнейшей передачи и авторизации пациента в приложении в разделе «Общая информация» развернутой карточки пациента; 7) экспорт отчета о технических данных о терапии пациента из интегрированного сервиса prisma CLOUD в разделе «Общая информация» развернутой карточки пациента; 28

8) переход к странице пациента в интегрированном сервисе prisma CLOUD в разделе «Общая информация» развернутой карточки пациента; 9) переход к заполнению начального опроса, соответствующего анамнезу пациента, в разделе «Анамнез» развернутой карточки пациента; 10) переход к заполнению финального опроса по окончанию периода исследования для пациента в разделе «Анамнез» развернутой карточки пациента; 11) просмотр и редактирование последних заметок в разделе «Заметки» развернутой карточки пациента; 12) добавление новой заметки в разделе «Заметки» развернутой карточки пациента; 13) переход к просмотру всех заметок в разделе «Заметки» развернутой карточки пациента; 14) переход к подробному просмотру результатов ежедневного опроса за неделю в разделе «Опросы» развернутой карточки пациента; 15) переход к подробному просмотру результатов ежемесячного опроса и опросапроверки терапии в разделе «Опросы» развернутой карточки пациента; 16) переход к просмотру результатов ежедневных, ежемесячных опросов и опросовконтроля терапии за все время исследования в разделе «Опросы» развернутой карточки пациента; 17) просмотр информации о количестве случаев выполнения пациентом необходимой ежедневной физической активности за все время исследования в разделе «Опросы» развернутой карточки пациента. Кроме того, блоки «Отсутствие результатов поиска» и «Отсутствие синхронизации с prisma CLOUD» в дальнейшей визуализации также являются состояниями страницы таблицы участников исследования. Решение отразить основной функционал вебприложения с использованием дашборда было принято с целью сохранить консистентность визуализации нового продукта с дизайном уже существующего продукта — prisma CLOUD, который активно использует целевая группа пользователей-врачей, работающих с аппаратами искусственной вентиляции легких от Löwenstein Medical. В соответствующем блоке работы, касающимся непосредственно процесса визуализации интерфейса это будет описано подробнее. 2.2 Разработка пользовательских сценариев Следующим этапом в работе над информационной системой стало составление пользовательских сценариев. Пользовательский сценарий — это наглядное схематическое представление того, как пользователь решает свою задачу с помощью 29

сайта, что ему помогает и что мешает в достижении цели [Пользовательские сценарии: что это такое, как и для чего их нужно строить, 2017]. Форма визуализации пользовательского сценария не закреплена конвенционально: существуют сценарии, оформленные в виде таблиц, рассказов, схем, представляющих как отдельный пользовательский сценарий, так и одновременно все множество сценариев, характеризующих систему. В работе над дизайном нашей информационной системы было решено создавать пользовательские сценарии в виде Userflow. Userflow – это визуальное представление последовательности действий, которые пользователь выполняет для достижения своей цели. В нашем случае были разработаны низко детализированные экраны мобильного и веб-приложений, отражающие шаги, которые проходит пользователь, для достижения цели и структурные элементы приложения, которые он для этого задействует. С нашей точки зрения использование визуализации позволяет наиболее эффективно передать видение дизайнера другим членам команды и заказчику. Важно отметить, что в нашем случае работа над проектом производилась по гибкой методологии разработки, в результате чего функционал мобильного и веб-приложений мог дополняться на разных этапах работы над дизайном информационной системы: начиная с этапа создания макетов низкой детализации для согласования контента заканчивая этапом создания макетов высокой детализации с применением визуального стиля. В результате влияния гибкой методологии пользовательские сценарии также разрабатывались на разных этапах работы над дизайном мобильного и веб- приложений с появлением нового функционала, что обуславливает разницу в их визуальном оформлении: в детализации, расположении информационных блоков, а также в присутствии элементов визуального стиля. Ниже представлены результаты работы по разработке пользовательских сценариев мобильного приложения для пациентов. Прежде чем начать работу с мобильным приложением, пользователь-пациент должен: 1) ознакомиться с условиями и документально подтвердить свое участие в клиническом исследовании; 2) получить код исследования и код пациента, необходимые для авторизации, от лечащего врача; 3) скачать мобильное приложение. После совершения этих действий пациент может начать свое участие в клиническом исследовании и, соответственно, взаимодействие с мобильным приложением. Ниже представлен пользовательский сценарий авторизации, которую 30

проходит пользователь-пациент после скачивания мобильного приложения и получения кода исследования и кода пациента от лечащего врача. Рисунок 3 – Пользовательский сценарий авторизации пользователя-пациента в мобильном приложении Как мы можем видеть на Рисунке 3 для того, чтобы авторизоваться в мобильном приложении, пользователь пациент проходит несколько шагов: 1. Пользователь запускает мобильное приложение, после чего попадает на приветственный экран, который содержит краткую информацию о цели исследования и назначении приложения. 2. После ознакомления с информацией на приветственном экране пользователь с помощью нажатия на кнопку «Начать» или на кнопку «Пропустить» попадает на экран авторизации, где ему необходимо ввести корректные код исследования и код пациента для успешной авторизации в приложении. 31

3. Если введенные данные авторизации корректны, после нажатия на кнопку «Начать исследование» пользователь попадает на экран дашборда, с помощью которого и будет происходить его дальнейшее взаимодействие с мобильным приложением. 4. Если введенные данные авторизации некорректны, пользователь попадает на экран ошибки авторизации, поля ввода подсвечиваются красным, сигнализируя об ошибке, описание которой представлено под полями. После успешной авторизации в приложении и начала участия в клиническом исследовании пользователю-пациенту открывается ряд сценариев взаимодействия с мобильным приложением. Самую важную роль играют сценарии, связанные с прохождением пациентом регулярных опросов, поэтому их мы рассмотрим в первую очередь. Рисунок 4 – Пользовательский сценарий прохождения ежемесячного опроса или опросаконтроля терапии авторизованным пользователем-пациентом в мобильном приложении На Рисунке 4 представлен ряд шагов, которые преодолевает авторизованный пользователь-пациент при прохождении ежемесячного опроса или опроса-контроля терапии, заключающихся в следующем: 32

1. Авторизованный пользователь самостоятельно, либо при получении пушуведомления о новом опросе запускает мобильное приложение, после чего попадает на экран дашборда. 2. На экране дашборда в разделе «Напоминания» пользователь нажимает на карточку ежемесячного опроса или опроса-контроля терапии, что ведет его к стартовому экрану опроса. 3. После ознакомления с общей информацией об опросе пользователь с помощью нажатия на кнопку «Начать» переходит к экранам вопросов. 4. Пользователь перемещается между экранами вопросов до тех пор, пока не дойдет до последнего вопроса, кнопка «Далее» на экране которого перенесет его к экрану подтверждения отправки ответов — классическому приему дизайна, который обычно помещают перед необратимым действием, таким образом давая пользователю возможность в случае необходимости вернуться назад и изменить свой выбор. 5. Когда пользователь полностью уверен в своих ответах, он подтверждает их отправку с помощью кнопки «Отправить» и переходит к экрану благодарности за заполнение опроса. 6. С помощью кнопки «Завершить» пользователь отправляется на экран дашборда, где может продолжить взаимодействие с мобильным приложением. На Рисунке 4 представлен только один из возможных сценариев прохождения ежемесячного опроса или опроса-контроля терапии пользователем-пациентом в мобильном приложении. Однако в нашем приложении пользователь имеет также альтернативный сценарий прохождения этих опросов, представленный на Рисунке 5. 33

Рисунок 5 – Альтернативный пользовательский сценарий прохождения ежемесячного опроса или опроса-контроля терапии авторизованным пользователем-пациентом в мобильном приложении На схеме, представленной на Рисунке 5, можно заметить, что шаги, которые совершает пользователь, и экраны, через которые он проходит, немногим отличаются от шагов и экранов пользовательского сценария, представленного на Рисунке 4. Основная разница здесь заключается в Шаге 2, с помощью которого пациент попадает на стартовый экран опроса. В данном случае после запуска приложения самостоятельно, либо при получении пуш-уведомления об опросе с истекающим сроком жизни на Шаге 1 пользователь попадает на экран дашборда, поверх которого находится модальное окно, призывающее пользователя пройти опрос, срок жизни которого истекает сегодня. После нажатия на кнопку «Начать» пользователь попадает на стартовый экран опроса, начиная с которого сценарий взаимодействия пациента с приложением аналогичен сценарию, представленному на Рисунке 4. Решение, ввести такое модальное окно, напоминающее об опросе с истекающим сроком жизни, было принято с целью направить внимание пользователя на наиболее важный в настоящий момент элемент приложения и 34

подтолкнуть пациента к прохождению такого опроса, так как отсутствие ответов пациента на опрос снижает качество данных, полученных по участнику исследования, что, соответственно, негативно влияет на качество результатов всего исследования установленной гипотезы. Кроме ежемесячных опросов и опросов-контролей терапии в разделе «Напоминания» также появляется карточка с призывом использования пациентом в определенный день дополнительного мониторингового оборудования prisma CHECK и инструкцией к соответствующему оборудованию. Prisma CHECK — это модуль для измерения SpO2 и частоты пульса, интегрируемый во все модели приборов линейки Prisma Line [30]. Модуль позволяет контролировать эффективность применения терапии, производимой пациентом в домашних условиях, а также удаленно корректировать лечебные давления в режиме реального времени в условиях стационара или сомнологического центра. Ниже представлен сценарий взаимодействия пользователя с приложением при ознакомлении с инструкцией к prisma CHECK. Рисунок 6 – Пользовательский сценарий ознакомления авторизованного пользователяпациента с инструкцией к мониторинговому оборудованию prisma CHECK в мобильном приложении На Рисунке 6 представлен ряд шагов, которые преодолевает авторизованный пользователь-пациент при ознакомлении с инструкцией к мониторинговому оборудованию prisma CHECK, заключающихся в следующем: 1. Авторизованный пользователь запускает мобильное приложение, после чего попадает на экран дашборда. 2. В разделе «Напоминания» дашборда пользователь выбирает карточку Prisma CHECK и переходит к экрану с инструкцией к использованию модуля, который содержит текст и изображения. 35

3. После ознакомления с инструкцией пользователь нажимает на кнопку «ОК» и возвращается на экран дашборда, при этом карточка с напоминанием об использовании модуля не исчезает из раздела «Напоминания», а остается там до конца дня. Помимо ежемесячных опросов и опросов-контролей терапии мобильное приложение также содержит ежедневные опросы о состоянии здоровья пациента, однако визуально они представлены иной сущностью, нежели вышеописанные опросы. Подробнее с тем, как устроено взаимодействие пользователя с ежедневными опросами, можно познакомиться ниже с помощью схемы, представленной на Рисунке 7. Рисунок 7 – Пользовательский сценарий прохождения ежедневного опроса авторизованным пользователем-пациентом в мобильном приложении На схеме, представленной на Рисунке 7, можно увидеть, что для прохождения пользователем ежедневного опроса было решено выделить отдельный информационный блок дашборда. Такое решение принято с целью привлечь внимание пациента к такому немаловажному сегменту системы, как ежедневные опросы — выделяя ежедневный опрос в отдельно визуально представленный блок мы выделяем его из ряда других опросов и подчеркиваем его значимость для пользователя. Таким образом, ежедневные опросы не затеряются среди остальных опросов, а всегда будут на виду у пользователя в качестве отдельного элемента дашборда. Необходимость выделения ежедневного опроса среди всех опросов обусловлена коротким сроком его жизни — результаты такого опроса сохраняются в конце каждого дня и в случае, если ежедневный опрос не был заполнен пользователем до этого момента, считается, что пациент не дал ответ на него ответ, что, опять же, влияет на качество полученных данных и, соответственно, результатов всего исследования. Кроме этого текущее визуальное представление ежедневного опроса облегчает взаимодействие с ним — для ответа на опрос нет необходимости переходить на 36

другие экраны, просмотр опроса и осуществление ответа происходит прямо на экране дашборда. Таким образом, для прохождения ежедневного опроса в мобильном приложении пользователь-пациент проходит следующие шаги: 1. Авторизованный пользователь запускает мобильное приложение, после чего попадает на экран дашборда. 2. На экране дашборда пользователь находит блок с ежедневным опросом и отвечает на вопрос о состоянии одышки выбором соответствующей иконки, после чего остальные иконки ответов меняют свой цвет на серый, сигнализируя приоритет выбранной иконки перед прочими, а также появляется кнопка для редактирования ответа. 3. В случае, если пользователь захочет изменить свой ответ на ежедневный опрос, он нажимает на кнопку редактирования и все иконки ответов снова окрашиваются в свои цвета, сообщая о переходе в активное состояние. При этом важно отметить, что вопрос, на который отвечают пользователи при прохождении ежедневного опроса, всегда остается неизменным и звучит следующим образом: «Как часто вы сегодня ощущали одышку?», что позволяет размещать ежедневный опрос и неизменные ответы-иконки для взаимодействия с ним прямо на экране дашборда. Мобильное приложение, помимо напоминания о прохождении регулярных опросов и использования дополнительного мониторингового оборудования, также предоставляет пациенту возможность следить за качеством проводимой терапии с помощью технических данных, полученных с аппарата искусственной вентиляции легких. Подробности взаимодействия пользователя-пациента с отчетом о технических данных терапии представлены ниже на Рисунке 8. 37

Рисунок 8 – Пользовательский сценарий просмотра авторизованным пользователемпациентом в мобильном приложении ежедневного отчета о технических данных терапии, полученных с аппарата ИВЛ Для просмотра ежедневного отчета о технических данных терапии, полученных с аппарата ИВЛ, пользователю пациенту необходимо осуществить следующие шаги. 1. Авторизованный пользователь запускает мобильное приложение и попадает на экран дашборда, где видит карточку ежедневного отчета о технических данных терапии, полученных с аппарата ИВЛ, за сегодняшний день. 2. Если пользователь захочет посмотреть данные за предыдущие дни, он листает карточки влево до тех пор, пока не перейдет к нужной карточке, либо пока не достигнет карточку с техническими данными терапии за первый день участия в исследовании. Кроме технических данных терапии, таких как длительность использования аппарата ИВЛ и утечка воздуха, было решено также поместить в карточку ежедневного отчета результат прохождения ежедневного опроса, чтобы пользователь-пациент мог самостоятельно следить за динамикой своего состояния здоровья и, соответственно, за динамикой терапии. В целом введение блока ежедневного отчета в структуру приложения среди прочих блоков было произведено для того, чтобы мобильное приложение не только способствовало предоставлению пациентом качественного отчета о субъективном восприятии терапии, но и увеличивало вовлеченность пользователя в прохождение терапии, делая его более эффективным. На более поздних этапах работы над дизайном мобильного приложения было решено добавить пользователю возможность самому запускать опрос-контроль терапии для получения своевременной помощи при возникновении у пациента проблем с приспособлением к прохождению терапии 38 и использованию аппарата ИВЛ.

Пользовательский сценарий взаимодействия с соответствующей функцией мобильного приложения представлен на Рисунке 9. Рисунок 9 — Пользовательский сценарий прохождения авторизованным пользователемпациентом вручную активированного опроса-контроля терапии в мобильном приложении Разница между пользовательскими сценариями, представленными на Рисунке 9 и Рисунке 4, заключается только в Шаге 2: если в схеме, на Рисунке 4, пользователь переходит к опросу-контролю терапии с помощью карточки соответствующего опроса в разделе «Напоминания», то в схеме, на Рисунке 9, пациент совершает переход посредством отдельной кнопки, находящейся в том же разделе. Таким образом, пациент может запустить опрос-контроль терапии самостоятельно в любой момент, не дожидаясь, когда подойдет время этого опроса в соответствии с расписанием. По расписанию опросконтроль терапии появляется в мобильном приложении пациента в конце первой и второй недель, а также во время последней недели участия в исследовании. Однако существует вероятность, что прохождение опроса-контроля терапии по расписанию и дальнейшее взаимодействие с лечащим врачом по результатам опроса могут не исчерпать проблемы, 39

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

На схеме, представленной на Рисунке 10 можно увидеть, что для прохождения контроля физической активности авторизованный пользователь-пациент проходит несколько шагов: 1. Авторизованный пользователь запускает мобильное приложение и попадает на экран дашборда. 2. Пользователь листает экран вниз до раздела «Контроль физической активности». 3. В карточке раздела «Контроль физической активности» пользователь читает мотивационный текст и переходит по ссылке на внешний источник Youtube. 4. На сайте или в приложении Youtube пользователь просматривает видеоролик с упражнениями и самостоятельно выполняет данные упражнения, таким образом выполняя необходимую регулярную физическую активность. 5. После выполнения упражнений пользователь возвращается в мобильное приложение с помощью кнопки или жеста «Назад», стандартного для интерфейса мобильных телефонов, и отмечает факт выполнения физической активности с помощью чекбокса в карточке в разделе «Контроль физической активности». 6. Чекбокс переходит в активное состояние, иконка и текст в карточке изменяют свои значения на вознаграждающие. 7. Если пользователь по какой-то причине хочет отменить последнее действие, он нажимает на активированный чекбокс, после чего тот переходит в неактивное состояние, иконка и текст изменяют свои значения на мотивирующие. Важно отметить, что результаты контроля физической активности, как и результаты ежедневного опроса, отправляются на сервер в конце дня, так что если по какой-то причине пациент ошибся и отметил факт выполнения физической активности случайно, это никак не повлияет на счетчик в таблице пациентов врача, если пациент деактивирует чекбокс до конца дня. Кроме того в процессе работы над пользовательскими сценариями мобильного приложения был также разработан сценарий для взаимодействия пациента с разделом приложения «Инфо». Соответствующий сценарий представлен ниже на Рисунке 11. 41

Рисунок 11 – Пользовательский сценарий просмотра авторизованным пользователемпациентом информации об исследовании в мобильном приложении Как можно видеть на схеме, представленной на Рисунке 11, данный пользовательский сценарий характеризуется следующими шагами: 1. Авторизованный пользователь запускает мобильное приложение и попадает на экран дашборда; 2. В верхней навигационной панели дашборда пользователь нажимает на иконку «Инфо» и попадает на страницу с перечислением разделов, которые входят в раздел «Инфо», представленных в виде строк-кнопок; 3. После нажатия на строку «Об исследовании» пользователь попадает на страницу с информацией об исследовании, с которой он может познакомиться при необходимости. Изначально в раздел «Инфо» планировалось поместить разделы «Об исследовании», «Настройки», «Неотложная помощь» и «Контакты». «Неотложная помощь» впоследствии превратилась в кнопку ручной активации опроса-контроля терапии в разделе «Напоминания», а контент для разделов «Настройки», «Об исследовании» и «Контакты» так и не был проработан, и разделы оказались неактуальны для заказчика в текущий момент работы над дизайном приложения. Информационный блок «Инфо» с большой вероятностью не войдет в первый релиз мобильного приложения, однако в будущем вполне вероятна его доработка и реализация. Всего на этом этапе работы над мобильным приложением было разработано 9 пользовательских сценариев, все сценарии представлены в тексте работы. Кроме пользовательских сценариев взаимодействия пациента с мобильным приложением были также разработаны сценарии взаимодействия врача с вебприложением. Поскольку пользовательских сценариев для веб-приложения получилось значительно большее количество, чем для мобильного приложения, в основном тексте данной работы будет представлены только сценарии, затрагивающие основной 42

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

1. Пользователь заходит в веб-приложение с использованием рабочего компьютера, после чего попадает на страницу авторизации. 2. В окне авторизации пользователь вводит логин и пароль, после чего с помощью нажатия на кнопку «Войти» авторизуется в веб-приложении и попадает на экран таблицы пациентов. 3. Если пользователь ввел неверные данные, он попадает на экран ошибки авторизации: поля с неверными данными выделены красной рамкой, под полями располагается текст ошибки. Важно отметить, что в веб-приложении для врача не предусмотрена регистрация пользователя через интерфейс приложения. Данные пользователя для авторизации создаются в базе данных, после чего с их использованием возможно войти в систему. Однако авторизация с использованием логина и пароля — не единственный способ войти в аккаунт веб-приложения. Альтернативный способ авторизации в веб-приложении представлен ниже на Рисунке 13. Рисунок 13 – Пользовательский сценарий авторизации пользователя-врача в вебприложении с использованием стороннего сервиса Azure Active Directory Отличие данного способа авторизации заключается в том, что пользователю-врачу не нужно вводить логин и пароль, соответственно, нет необходимости создавать пользователей в базе данных. Вместо этого во время Шага 2 врач с помощью кнопки «Авторизоваться через Azure AD» сразу же попадает на экран таблицы пациентов. 44

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

иконки, окрашенной в определенный цвет, существует тултип, содержащий числовое значение и дату, когда оно было получено. Тултип появляется при наведении курсора на иконку, т. е. после совершения пользователем Шага 2 на схеме, представленной на Рисунке 14. Следующая важная функция веб-приложения, которую часто использует врач, — это добавление новых пациентов в таблицу исследования. С пользовательским сценарием к данной функции можно познакомиться на схеме, представленной на Рисунке 15. Рисунок 15 – Пользовательский сценарий добавления пользователем-врачом нового пациента в таблицу пациентов в веб-приложении Для добавления нового пациента в таблицу пациентов исследования пользователюврачу нужно пройти следующий путь, представленный на схеме на Рисунке 15: 1. Пользователь заходит в веб-приложение с использованием рабочего компьютера, после чего попадает на экран таблицы пациентов. 2. После нажатия на кнопку добавления нового пациента в правой нижней части экрана поверх таблицы появляется модальное окно с формой добавления пациента. 3. Пользователь заполняет поля формы и нажимает кнопку «Сохранить», после чего модальное окно закрывается, и врач снова оказывается на экране таблицы пациентов, в которой появилась новая строка. Можно обратить внимание, что форма добавления пациента содержит небольшое количество полей: чтобы добавить пациента нужно ввести серийный номер аппарата искусственной вентиляции легких, с помощью которого он проходит терапию, дату начала исследования, а также локацию расположения пациента (дома или в клинике) и отметить разрешение или его отсутствие на совершение звонков. Такой размер формы добавления пациента обуславливается тем, что при добавлении нового пациента в базу данных информационной системы происходит интеграция с сервисом prisma CLOUD по серийному номеру аппарата ИВЛ, указанному в форме, и, соответственно, в вебприложение поступают данные о пациенте, хранящиеся в prisma CLOUD. Кроме того, 46

благодаря синхронизации пациента в данной информационной системе с пациентом в prisma CLOUD становится возможным отображение в таблице пациентов информации о средней длительности использования аппарата ИВЛ и утечке воздуха, а также отображение этих показателей в мобильном приложении пациента. Еще одной функцией, без которой невозможно взаимодействие врача и пациента внутри нашей информационной системы является функция генерации кода, необходимого для авторизации пациента в мобильном приложении. Пользовательский сценарий, характеризующий взаимодействие врача с веб-приложением для достижения цели генерации кода авторизации, представлен на Рисунке 16. Рисунок 16 – Пользовательский сценарий повторной генерации пользователем-врачом нового кода авторизации в веб-приложении Как можно видеть на схеме, представленной на Рисунке 16, для повторной генерации кода пациента пользователю-врачу необходимо пройти ряд шагов: 1. Пользователь заходит в веб-приложение с использованием рабочего компьютера, после чего попадает на экран таблицы пациентов. 2. С помощью нажатия на иконку стрелки в правой части карточки пациента пользователь разворачивает карточку и попадает на детализированный просмотр карточки пациента. 47

3. В развернутой карточке пациента, в разделе «Общая информация», пользователь находит строку «Статус кода для авторизации», в которой находится кнопка повторной генерации кода авторизации. После нажатия на кнопку появляется модальное окно с предупреждением о том, что после повторной генерации кода авторизации пациент не сможет авторизоваться в мобильном приложении с помощью старого кода. 4. Пользователь подтверждает уверенность в своих действиях нажатием кнопки «Сгенерировать», после чего модальное окно подтверждения сменяется окном с кодом. 5. После копирования нового кода авторизации пользователь завершает взаимодействие с окном кода нажатием на иконку крестика в правом верхнем углу окна и возвращается к детализированному просмотру карточки пациента. 6. Если пользователь, находясь на этапе подтверждения, передумает генерировать новый код авторизации, он нажимает на кнопку «Отмена» и возвращается к детализированному просмотру карточки пациента. Решение – представить в тексте работы пользовательский сценарий именно повторной генерации кода авторизации, было принято по причине того, что сценарий первой генерации кода авторизации для пациента отличается от выше представленного сценария только отсутствием модального окна подтверждения. Таким образом, для представления в тексте работы был выбран более сложный сценарий, включающий в себя этапы более простого. Кроме просмотра последних полученных средних значений результатов опроса в строке таблицы пациентов в веб-приложении пользователь-врач может также просмотреть более подробную информацию о результатах опросов. Пользовательские сценарии, связанные с подробным просмотром результатов опросов представлены на Рисунке 17 и Рисунке 18. 48

Рисунок 17 – Пользовательский сценарий подробного просмотра пользователем-врачом в веб-приложении результатов ежедневного опроса На схеме, представленной на Рисунке 17, можно увидеть, что для подробного просмотра результатов опроса пользователю-врачу необходимо выполнить следующие шаги: 1. Пользователь заходит в веб-приложение с использованием рабочего компьютера и попадает на страницу таблицы пациентов. 2. С помощью нажатия на иконку стрелки в правой части карточки пациента пользователь разворачивает карточку и попадает на детализированный просмотр карточки пациента. 3. В разделе «Опросы» в правой части карточки пользователь может увидеть разделы по типам опросов: «Опрос-контроль терапии», «Ежедневный опрос», «Ежемесячный опрос» и «Контроль физической активности». В каждом из первых трех разделов находятся иконки, окрашенные в различные цвета, отражающие средние значения пяти последних полученных результатов опросов в соответствующей категории; после нажатия на одну из иконок в разделе «Ежедневный опрос», символизирующих средние значения опросов, полученные за последние пять недель, появляется модальное окно, содержащее результаты ежедневного опроса за каждый день выбранной недели и среднее значение результатов за неделю. 49

4. После ознакомления с подробными результатами опроса пользователь закрывает модальное окно с помощью иконки крестика в правой верхней части окна и возвращается к детализированному просмотру карточки пациента. Выше представлен пользовательский сценарий для просмотра подробных результатов ежедневного опроса, однако сценарии просмотра подробных результатов ежемесячного опроса и опроса-контроля терапии практически идентичны данному сценарию. Получить доступ к подробному просмотру одного из пяти последних полученных результатов ежемесячного опроса или опроса-контроля терапии можно также в разделе «Опросы», доступном в режиме детализированного просмотра карточки пациента. Однако если в подробном просмотре результатов ежедневного опроса представлены результаты опроса за каждый день выбранной недели и среднее значение результатов за неделю, то в подробном просмотре результатов ежемесячного опроса и опроса-контроля терапии представлены значения ответов на каждый из вопросов опроса и среднее значение, складывающееся из этих ответов. Просмотра пяти последних результатов опросов может быть недостаточно для построения полной картины субъективной оценки пациентом эффективности терапии, поэтому в веб-приложении также присутствует возможность просмотра пользователемврачом результатов опросов за весь период исследования. Пользовательский сценарий, характеризующий взаимодействие врача с данной функцией веб-приложения, представлен на Рисунке 18. 50

Рисунок 18 – Пользовательский сценарий просмотра пользователем-врачом в вебприложении результатов ежемесячных опросов за весь период исследования Как видно на схеме, представленной на Рисунке 18, для того, чтобы достичь цели, пользователю-врачу нужно преодолеть ряд шагов: 1. Пользователь заходит в веб-приложение с использованием рабочего компьютера и попадает на страницу таблицы пациентов. 2. С помощью нажатия на иконку стрелки в правой части карточки пациента пользователь разворачивает карточку и попадает на детализированный просмотр карточки пациента. 51

3. В разделе «Опросы» в правой части карточки пользователь может увидеть разделы по типам опросов: «Опрос-контроль терапии», «Ежедневный опрос», «Ежемесячный опрос» и «Контроль физической активности». После нажатия на самую правую иконку с надписью «Посмотреть все» в разделе «Ежемесячный опрос» открывается модальное окно с таблицей результатов ежемесячных опросов за весь период исследования. 4. После ознакомления с результатами ежемесячных опросов за весь период исследования пользователь закрывает модальное окно с помощью иконки крестика в правой верхней части окна и возвращается к детализированному просмотру карточки пациента. Выше представлен только пользовательский сценарий просмотра пользователемврачом в веб-приложении результатов ежемесячных опросов за весь период исследования, однако сценарии просмотра результатов ежедневных опросов и опросов-контролей терапии аналогичны данному сценарию и включают в себя те же шаги. Разница между всеми тремя сценариями заключается только в точке доступа к просмотру результатов: для каждого из опросов иконка-кнопка для перехода к просмотру результатов за весь период исследования находится в соответствующем разделе блока «Опросы» развернутой карточки пациента. Последний сценарий, который достаточно важен для взаимодействия врача и пациента, чтобы отразить его в тексте работы, описывает процесс внеочередного окончания участия пациента в клиническом исследовании. Пользовательский сценарий к данному процессу представлен на Рисунке 19. 52

Рисунок 19 – Пользовательский сценарий внеочередного окончания пользователемврачом участия пациента в клиническом исследовании с помощью веб-приложения Для того чтобы достичь цели и окончить участие пациента в клиническом исследовании пользователю-врачу необходимо пройти через следующие шаги: 1. Пользователь заходит в веб-приложение с использованием рабочего компьютера и попадает на страницу таблицы пациентов. 2. С помощью нажатия на иконку стрелки в правой части карточки пациента пользователь разворачивает карточку и попадает на детализированный просмотр карточки пациента. 3. В правой нижней части карточки пользователь находит кнопку «Окончить участие в исследовании» и нажимает на нее, после чего открывается модальное окно подтверждения действия. 4. Если пользователь уверен в том, что хочет окончить участие пациента в исследовании, он нажимает на кнопку «Окончить», после чего возвращается на страницу таблицы пациентов. 5. Если пользователь передумал совершать действие, он нажимает на кнопку «Отмена» и возвращается к детализированному просмотру карточки пациента. Важно еще раз отметить, что использование окна подтверждения, которое появляется после Шага 3, необходимо в сценарии совершения необратимого действия, такого как прекращение участия пациента в клиническом исследовании. В случае, если 53

пользователь-врач каким-то образом нажал на кнопку по ошибке, при наличии в сценарии взаимодействия с системой окна подтверждения действия у него все еще есть шанс вернуться к прежнему состоянию системы без совершения необратимого действия. Всего этом этапе работы над веб-приложением было разработано 21 пользовательских сценариев, 8 из которых представлено в тексте работы. 2.3 Разработка визуального стиля информационной системы 2.3.1 Разработка стайлгайда Следующим шагом в разработке информационной системы стало определение визуального стиля ее компонентов: мобильного и веб- приложений. Первым шагом в работе над визуальным стилем стало создание стайлгайда. Стайлгайд — это коллекция предварительно созданных элементов и правил, которым дизайнеры и разработчики должны следовать, чтобы убедиться, что разные страницы и части дизайна смотрятся целостно и выполнены в едином стиле [Создание стайлгайда для проекта, 2015]. Часто стайлгайд создают при работе над проектом в команде дизайнеров: стайлгайд помогает сохранить стилистическую целостность проекта при работе над ним нескольких дизайнеров. Однако стайлгайд может быть также полезен при коммуникации дизайнера и разработчика: разработчику оказывается намного проще работать с четко очерченным сводом правил относительно стилей проекта, чем с его отсутствием. В работе над данным проектом стайлгайд создавался с целью упростить коммуникацию дизайнера и разработчика и увеличить скорость имплементации дизайна, поскольку на основании правил стайлгайда возможно создание соответствующих стилей в проекте и их дальнейшее упрощенное применение. Например, если в стайлгайде указан определенный цвет для всех ссылок, с использованием инструмента в стилях проекта возможно задать в одном месте цвет ссылок и все ссылки, в дальнейшем созданные в проекте, будут окрашены в указанный цвет. Стайлгайд, созданный в процессе работы над данным проектом, включает в себя палитру и стили типографики мобильного и веб- приложений, а также правила их использования. Кроме того, элементом стайлгайда также можно назвать UI-kit, про него будет сказано отдельно в следующем параграфе. Работа над созданием стайлгайда мобильного приложения для пациентов началась с подбора цветовой палитры. Цветовая палитра подбиралась на основании согласования референсов медицинских приложений и приложений-напоминаний с Product Owner-ом и создании высокодетализированных макетов дашборда с применением различных палитр. 54

Референсы медицинских приложений и приложений-напоминаний представлены на Рисунке 20. Рисунок 20 – Референсы к цветовой палитре мобильного приложения для пациентов Референсы 1-3, изображенные на Рисунке 20, подбирались с использованием вебсайта Behance, предназначенного для публикации дизайнерами своих работ и поиска заказчиков. В палитре мобильного приложения, представленного на Референсе 1, преобладают светлые, чистые цвета; яркий холодный фиолетовый используется в качестве акцентного и появляется на кнопках и важных элементах интерфейса. В мобильном приложении, изображенном на Референсе 2, яркий холодный голубой наоборот окрашивает фон экранов приложения, на котором белый используется как акцентный. Референс 3 был выбран с целью показать альтернативное первым двум вариантам цветовое решение: на изображенных экранах мобильного приложения в качестве акцентного используется теплый оранжевый цвет. По результатам согласования референсов был выбран Референс 1, а также отмечен интерес к Референсу 3, после чего было разработано несколько версий экрана дашборда мобильного приложения с применением цветовой палитры. В процессе согласования референсов был также получен запрос на разработку варианта дизайна дашборда с применением палитры другого продукта компании – мобильного приложения prisma App для пациентов, позволяющего производить мониторинг состояния терапии хронического респираторного заболевания на основании технических данных, полученных с аппарата искусственной вентиляции легких, а также дистанционно управлять некоторыми настройками аппарата. Такой дизайн экрана дашборда также был разработан для дальнейшего согласования. Варианты дизайна экрана дашборда мобильного приложения представлены на Рисунке 21. 55

Рисунок 21 – Варианты экрана дашборда мобильного приложения с применением различной цветовой палитры Как можно видеть на Рисунке 21, во всех вариантах преобладают светлые оттенки, яркие цвета используются только для того, чтобы акцентировать внимание на важных элементах интерфейса. Такое использование цветов соответствует согласованному Референсу 1. В Варианте 1 и Варианте 2 в качестве акцентных выбраны холодные цвета, в Варианте 3 — теплые. Вариант 4 и Вариант 5 разрабатывались с использованием цветовой гаммы другого продукта компании — мобильного приложения prisma App. По результатам согласования экранов дашборда для дальнейшей работы над дизайном был выбран Вариант 5, цветовая гамма и стиль которого соответствуют цветовой гамме и стилю мобильного приложения prisma App. Цветовая палитра мобильного приложения для проведения клинического исследования представлена на Рисунке 22. 56

Рисунок 22 – Цветовая палитра мобильного приложения Цветовая палитра мобильного приложения для клинического исследования, представленная на Рисунке 22, только позаимствовала некоторые основные цвета мобильного приложения prisma App в начале разработки и в дальнейшем развивалась независимо от этого продукта компании. В качестве основного цвета, с использованием которого в мобильном приложении выполнены иллюстрации и некоторые фоновые элементы, выступает зеленый цвет, ассоциирующийся с медициной, здоровьем, жизненной силой. Акцентными в приложении стали темно-синий, вызывающий доверие, и голубой, ассоциирующийся со спокойствием. Такие цвета отлично подходят для мобильного приложения в области медицины, вызывая у пользователей-пациентов необходимые ассоциации. Выбор основного и акцентных цветов обусловлен не только символичным значением, которые они передают, но также их сочетаемостью друг с другом. В мобильном приложении также используется много белого цвета: он является основным фоновым цветом приложения и ассоциируется у европейского пользователя с 57

чистотой. Надписи и текстовые блоки в мобильном приложении выполнены в основном в черном и темно-сером цветах, создающих хороший контраст с белым фоном. Достаточный контраст текста и фона необходим мобильному приложению, поскольку его целевая аудитория — пациенты с хроническими респираторными заболеваниями. Очень часто такие заболевания развиваются именно у людей в возрасте, которые также могут страдать от нарушений зрения. Поэтому так важно обеспечить читаемость текста в приложении, которая зависит в том числе от контраста цветов текста и фона. Серые цвета используются в приложении для окраски элементов в неактивном состоянии, например, неактивных кнопок, а также для визуализации второстепенных элементов — подписей, подсказок, второстепенных иллюстраций. Для передачи негативной информации в приложении вместо ярко красного было решено использовать терракотовый и оранжевый цвета с целью смягчить негативные ассоциации пациента при восприятии информации о своем здоровье. Эти цвета, например, используются для окраски иконок-ответов, соответствующих значениям «Ужасно» и «Плохо», на ежедневный вопрос о состоянии одышки пациента. Отдельного внимания заслуживают цвета уровней согласия. Это те цвета, в которые окрашивается шкала ответа, появляющаяся в вопросах с оценкой по шкале Лайкерта в дополнительном опросе-проверке проблем с аппаратом, являющимся частью опроса-контроля терапии. Пример того, как выглядит шкала ответа при выборе различных значений представлен ниже на Рисунке 23. Рисунок 23 – Экраны опроса-проверки проблем с аппаратом ИВЛ, для ответов в котором используется шкала Лайкерта, окрашивающаяся в различные цвета в зависимости от ответа Все вопросы опроса-проверки проблем с аппаратом ИВЛ описывают негативные ситуации, такие как, например, «У меня проблемы с управлением аппаратом ИВЛ и 58

увлажнителем», и предполагают оценку по шкале от 0 до 9, где 0 соответствует ответу «Полностью согласен», а 9 — «Абсолютно не согласен». Расположением ответов на шкале обусловлен и выбор цветов: если пользователь выбирает значение ближе к левой части шкалы, то есть значение согласия с негативным высказыванием, шкала окрашивается в цвет, который ближе к терракотовому; если же пользователь выбирает значение в правой части шкалы, то есть значение несогласия, цвет шкалы становится ближе к зеленому. Таким образом, цветовая индикация шкалы позволяет пользователю быстрее понять качество ответа, который он дает на вопрос. Не менее важным элементом стайлгайда является описание правил использования типографики. В качестве основного и единственного шрифта в мобильном приложении был выбран Montserrat – шрифт без засечек, имеющий 18 начертаний и отлично подходящий как для заголовков, так и для основного текста. Особенностью шрифта является его легкая читаемость благодаря геометрическому виду букв и их ширине. Выбор типографики, как и описанный выше выбор цветов высокой контрастности, обусловлен стремлением сделать мобильное приложение более доступным для целевой аудитории. Цветовая палитра веб-приложения была подобрана таким образом, чтобы выглядеть максимально нейтрально и не отвлекать пользователя-врача от рабочего процесса. При этом была поставлена цель обеспечить определенный уровень соответствия между палитрой мобильного приложения для пациентов и палитрой веб-приложения для врачей, чтобы избежать потери смысла при передачи общей для пациента и врача информации, а также сохранить стилистическую однородность внутри информационной системы. Цветовая палитра веб-приложения представлена ниже на Рисунке 24. 59

Рисунок 24 – Цветовая палитра веб-приложения Как можно видеть на Рисунке 24, цветовая палитра веб-приложения имеет множество пересечений с цветовой палитрой мобильного приложения. В качестве основного цвета здесь используется тот самый темно-синий, который используется в мобильном приложении как акцентный. В оттенки основного цвета в веб-приложении для врача окрашены все активные элементы: кнопки, иконки, ссылки. Активные элементы ярко выделяются на фоне белого и самого светло-серого цветов, преобладающих в вебприложении. Типографика веб-приложения оформлена в черном и темно-сером цветах с той же целью, что и в мобильном приложении для пациентов — повысить доступность веб-приложения для пользователей в возрасте, страдающих от нарушений зрения, которые могут также оказаться среди врачей. В целом цветовая палитра веб-приложения подобрана таким образом, чтобы настраивать пользователя-врача на рабочий лад и не отвлекать от информации, массу которой предоставляет врачу веб-приложение. 60

Серые цвета используются в веб-приложении также как и в мобильном приложении для обозначения неактивных и второстепенных элементов, а также для окраски текстов некоторых подписей и иногда для фонов. Цвета иконок результатов опросов, отображающихся в таблице пациентов, соответствуют цветам иконок-ответов на ежедневный опрос, использованным в мобильном приложении. Такое решение было принято с целью сохранить определенный уровень соответствия той информации, которую получает пациент, и той, которую получает врач. При обозначении позитивной и негативной информации одними и теми же цветами для врача и для пациента возможно минимизировать разницу в ее восприятии этими группами пользователей и, соответственно, улучшить качество результатов клинического исследования. Кроме того, таким образом сохраняется стилистическая однородность информационной системы. В палитру веб-приложения для врача были также добавлены более светлые оттенки уже заимствованных цветов, необходимые для окраски фона элементов интерфейса, также имеющих ранжирование значений от негативных к позитивным — это такие элементы как поле группы риска в свернутой карточке пациента, а также строка среднего значения опроса, появляющаяся в модальных окнах детального просмотра результатов опроса и просмотра результатов опроса за все время исследования. Решение не отходить от основной палитры информационной системы и использовать светлые оттенки уже присутствующих в ней цветов также принято с целью сохранить стилистическую однородность как внутри системы, так и внутри ее компонента — веб-приложения. Типографика в веб-приложении подобрана по тем же принципам, что и в мобильном приложении. В качестве используемого шрифта выбран также Montserrat с целью сделать мобильное приложение более доступным для целевой аудитории. 2.3.2 Разработка UI kit Следующим этапом в работе над визуальным стилем информационной системы стала разработка UI kit. UI Kit — это набор всех элементов, с использованием которых строится пользовательский интерфейс продукта; это визуализация каждого из элементов на любом этапе соприкосновения пользователя с интерфейсом [Что такое UI Kit и для чего он нужен вашей компании, 2019]. Под элементами имеются в виду такие составляющие пользовательского интерфейса как кнопки, поля, карточки, чекбоксы, свитчеры, то есть все те инструменты, с помощью которых пользователь взаимодействует с интерфейсом. При составлении UI kit для каждого из этих элементов прорабатываются все его возможные состояния: какого цвета будет кнопка при наведении и при нажатии, как будет 61

выглядеть поле ввода при вводе неверных данных, каким образом будет меняться тень карточки при наведении и т. д. Часто в UI kit включают более крупные элементы, собранные из более мелких: модальные окна, формы ввода и подобные элементы. Обычно это делается для более крупных проектов, где необходимо сохранить стилистическое единство элементов интерфейса при работе команды дизайнеров. В работе над информационной системой для проведения клинического исследования такие крупные элементы почти не попали в UI-kit. Кроме того, в UI-kit часто включают элементы визуального оформления интерфейса, например, иконки. Наш UI-kit включает иконки, иллюстрации и анимации. При разработке UI-kit для мобильного приложения были разаботаны такие разделы как «Элементы навигации», «Поля ввода», «Кнопки», «Карточки», «Шкала», «Иконки», «Иллюстрации», «Анимации» и «Прочее». Больше всего элементов и их состояний попало в раздел «Кнопки», что закономерно, так как именно с помощью различных кнопок пользователь перемещается между экранами мобильного приложения. Фрагмент UI-kit мобильного приложения, посвященный кнопкам, представлен на Рисунке 25. Рисунок 25 – Фрагмент UI-kit мобильного приложения, иллюстрирующий раздел «Кнопки» На Рисунке 25 можно увидеть, что форма представления кнопок может быть совершенно различной. Это могут быть классические прямоугольники с наименованием действия, а могут быть круглые кнопки с иконкой вместо текста; это могут также быть кнопки-ссылки, состоящие только из текста наименования, кнопки-ссылки с иконками, 62

кнопки в виде иконок. Такое разнообразие форм кнопок обусловлено различными целями их использования и различным контекстом, в котором они появляются. Например, кнопкаиконка «Инфо» появляется в верхней навигационной панели мобильного приложения, что обуславливает ее размер — прямоугольная кнопка с текстом в навигационную панель просто бы не поместилась. Кнопки для ежемесячного же опроса являются основным контентом на странице вопроса и нажатие на них должно быть максимально быстрым и удобным, чем объясняется их размер и яркий цвет. Как можно видеть на Рисунке 25, почти для всех кнопок были проработаны три основных состояния: состояние покоя, нажатие и неактивное состояние. Для некоторых кнопок, например, кнопок опросов, нет необходимости разрабатывать неактивное состояние, поскольку в соответствии с пользовательскими сценариями эти кнопки всегда будут активны. В UI-kit для мобильного приложения были разработаны также комплексные элементы: карточки, модальные окна, составные ответы. Соответствующие разделы UI-kit представлены на Рисунке 26. Рисунок 26 – Фрагменты UI-kit мобильного приложения, иллюстрирующие разделы «Карточки» и «Другое» На Рисунке 26 представлены комплексные элементы UI-kit, включающие в себя ряд простых элементов. Например, карточки напоминаний и ежедневного отчета включают в себя текст и иконки, контроль физической активности состоит из текста, иконки, ссылки и чекбокса, а модальные окна – из иконки, текста и кнопки. Включение 63

комплексных элементов в UI-kit необходимо для дальнейшей удобной работы разработчика по созданию соответствующих компонентов в мобильном приложении. Кроме того, UI-kit содержит все состояния этих элементов: на Рисунке 26 можно увидеть, что для карточки ежедневного отчета указаны все возможные состояния как самой карточки, так и ее составляющих элементов (шкалы прогресса и иконки маски); для карточки контроля физической активности представлены состояния содержимого карточки при активированном и пустом чекбоксе, а для ответов ежедневного опроса — то, в какой цвет будет окрашена каждая из иконок при ее выборе в качестве ответа на опрос. Отображение всех состояний элемента в одном месте упрощает работу разработчика по описанию этих компонентов в приложении. Помимо активных элементов, благодаря которым происходит взаимодействие пользователя с интерфейсом мобильного приложения, в рамках UI-kit были разработаны элементы визуального оформления, представленные на Рисунке 27. Рисунок 27 – Фрагменты UI-kit мобильного приложения, иллюстрирующие разделы «Иконки» и «Иллюстрации» На Рисунке 27 представлены иконки и иллюстрации, разработанные для мобильного приложения. В качестве элементов визуального оформления были также разработаны анимации, но включение их в текст работы не имеет смысла, поскольку носитель не сможет передать сути анимированных изображений. Иллюстрации, анимации 64

и иконки приложения было решено выполнить в стиле Outline, который использует простые, четкие линии и выглядит достаточно нейтрально, что хорошо подходит для медицинского приложения. Иллюстрации выполнялись в основных цветах мобильного приложения — в оттенках зеленого, чтобы поддерживать необходимую для передачи ассоциацию при взаимодействии пациента с интерфейсом. В основном иллюстрации применялись в мобильном приложении как пояснительный материал — на Рисунке 27 можно увидеть иллюстрации, созданные для инструкции к мониторинговому модулю prisma CHECK. Данные иллюстрации были созданы с целью визуализировать действия, которые необходимо совершить пациенту для правильного подключения модуля, и, соответственно, облегчить восприятие и улучшить понимание пациентом инструкции. Всего было создано 5 иллюстраций: 4 для инструкции к prisma CHECK и 1 для приветственного экрана. Можно обратить внимание, что размер всех иконок на Рисунке 27 кратен четырем: такое решение при создании иконок было принято ввиду технических особенностей устройства носителя — экрана мобильного телефона. Дело в том, что дисплеи современных мобильных устройств обладают высокой плотностью пикселей, что обеспечивает более четкое изображение. При этом фактическое число пикселей может превышать базовое разрешение экрана в несколько раз, в результате чего все элементы интерфейса приходится увеличивать, чтобы их размеры соответствовали базовому разрешению экрана и сами элементы отображались корректно. Число пикселей на дюйм у большинства современных мобильных устройств кратно восьми, поэтому при масштабировании элементов интерфейса для различных устройств лучше, чтобы значения их высоты и ширины укладывались в число, кратное восьми. Если использовать для размеров элементов мобильного интерфейса нечетные значения высоты или ширины, могут возникнуть проблемы с рендерингом таких элементов. Например, при адаптации элемента размером в пять пикселей под устройство с разрешением в полтора раза больше оригинального, произойдет смещение пикселя, так как при умножении чисел 5 и 1,5 мы получаем не целое число, а значит и не целый пиксель. Использование элементов с размерами, кратными четырем пикселям, допустимо, так как число восемь кратно числу четыре. Такой подход является менее жестким, чем восьмипиксельный, и дает больше свободы в оформлении элементов интерфейса. Иконки мобильного приложения были разработаны с целью использования внутри кнопок и карточек для дополнительной передачи смысла наравне с текстом или для замещения текста элементом с символическим смыслом, при правильном использовании 65

которого смысл считывается лучше, чем при использовании текста. Повсеместное применение такого графического инструмента как иконки снижает информационную нагрузку на пользователя, что в целом вызывает получение им более позитивного опыта от взаимодействия с мобильным приложением. Всего для мобильного приложения было разработано 37 иконок. Кроме иконок и иллюстраций в рамках UI-kit были разработаны анимации, также выполненные в стиле Outline. Всего было создано 6 анимаций, в состав которых входит анимация стартового экрана загрузки приложения, анимация загрузки внутри приложения, анимация экрана отсутствия подключения к интернету, анимация экрана благодарности за участие в опросе, а также две анимации микровзаимодействия, появляющиеся при активации и деактивации чекбокса в карточке контроля физической активности соответственно. Анимации были добавлены в интерфейс с целью увеличить вовлечение и позитивный опыт пациента, такой необходимый в приложении, напоминающем пользователю о его недугах. Процесс и цели создания UI-kit веб-приложения для врача значительно отличаются от таковых при создании UI-kit мобильного приложения для пациентов. В рамках UI-kit веб-приложения не было создано ни одной иллюстрации или анимации. Веб-приложение для врача представляет собой рабочий инструмент, с помощью которого пользователь может получить доступ к результатам хода клинического исследования, соответственно врач будет пользоваться веб-приложением в рабочее время и выполнять с его помощью рабочие задачи. Вследствие этого при создании дизайна веб-приложения не стояло задачи вызвать дополнительные положительные эмоции и вовлечение пользователя в работу с интерфейсом, поскольку дополнительно мотивировать пользователя к взаимодействию с продуктом не было необходимости. Более того, иллюстрации и анимации не были использованы в дизайне ввиду высокой информационной загруженности экранов вебприложения — на них просто не осталось места для этих элементов визуального оформления. Несмотря на отсутствие иллюстраций и анимаций UI-kit веб-приложения получился обширнее, чем UI-kit мобильного приложения, поскольку включил себя большее число элементов интерфейса, а также большее число состояний этих элементов ввиду технических особенностей устройства носителя. Если базовое поведение элементов мобильного приложения включает в себя такие состояния как состояние покоя, нажатие и неактивное состояние, то в веб-приложении к этим состояниям добавляется состояние наведения, возможное только на устройствах, где в качестве инструмента работы с 66

интерфейсом выступает курсор, а не палец. Пример оформления элементов UI-kit для вебприложения представлен на Рисунке 28. Рисунок 28 – Фрагмент UI-kit веб-приложения, иллюстрирующий раздел «Кнопки» Как можно видеть на Рисунке 28, раздел «Кнопки», входящий в UI-kit вебприложения, включает большее число состояний элементов, чем соответствующий раздел UI-kit мобильного приложения. При этом для состояний наведения и нажатия характерно затемнение элемента с различной интенсивностью, а также увеличение радиуса отбрасываемой тени. Данное решение является имитацией физических характеристик объектов в реальном мире: при приближении к одному объекту (в случае описанной системы — к кнопке) другого объекта (в случае описанной системы — курсора) приближающийся объект перекрывает собой источник света, и, соответственно отбрасывает тень на первый объект, вызывая его затемнение. Увеличение тени, отбрасываемой объектом, связано с имитацией встречного приближения объекта к курсору — таким образом демонстрируется, что объект активен и готов к использованию. Еще одной особенностью UI-kit веб-приложения является то, что наведение курсора на элемент интерфейса может сопровождаться не только изменением самого элемента, но и появлением дополнительного элемента — тултипа, поясняющего значение выбранного объекта. Такой прием очень часто используется в дизайне интерфейса вебприложения, при том, что использование данного приема в интерфейсе мобильного приложения невозможно ввиду отсутствия у элементов такого состояния как «наведение». 67

Использование тултипов позволяет снизить информационную нагруженность экранов вебприложения и демонстрировать пользователю информацию только в тот момент, когда она ему необходима. В разрабатываемом веб-приложении тултипы использовались для дополнения содержания иконки, отражающей среднее значение полученных результатов, в свернутой карточке пациента числом, которому соответствует цвет иконки. Всего UI-kit веб-приложения включил в себя 6 разделов: «Кнопки», «Поля ввода», «Карточка пациента», «Тултипы», «Символы» и «Иконки». Важно отметить, что самым богатым на количество составляющих элементов стал раздел UI-kit «Иконки»: в него вошло 86 иконок. Фрагмент UI-kit веб-приложения с соответствующим разделом представлен на Рисунке 29. Рисунок 29 – Фрагмент UI-kit веб-приложения, иллюстрирующий раздел «Иконки» Как можно видеть на Рисунке 29, раздел «Иконки» UI-kit веб-приложения включает в себя массу иконок различных размеров. Большая часть этих иконок входит в кнопки веб-приложения в качестве вспомогательной составляющей наряду с текстом, либо как единственная и основная составляющая кнопки. Использование такого большого количества иконок в веб-приложении вместо текста или в качестве дополнения к тексту было произведено с целью снизить информационную нагрузку на пользователя-врача, поскольку хорошо подобранные иконки быстрее и эффективнее передают необходимый смысл, чем текст. Разработанные для веб-приложения иконки можно считать эффективными в передаче смысла, так как каждая иконка создавалась на основании исследования визуальных референсов с использованием сервисов поиска изображений и иконок. 68

2.4 Разработка прототипа высокой детализации Следующим шагом в работе над системой после построения пользовательских сценариев и разработки визуального стиля стало создание прототипа высокой детализации. Важно отметить, что в ходе разработки пользовательских сценариев был разработан прототип низкой детализации для мобильного и веб-приложений, на который впоследствии и накладывался разработанный визуальный стиль, в результате чего был создан прототип высокой детализации. При разработке высоко детализированных макетов мобильного приложения практически все экраны были уже отрисованы в виде макетов низкой детализации, поэтому перевод их в новое качество с помощью наложения визуального стиля не составил труда. Экранами, которые при переходе претерпели структурные изменения, стали приветственный экран, представленный на Рисунке 30, и экран дашборда, представленный на Рисунке 31. Рисунок 30 – Предоставление приветственного экрана мобильного приложения в макетах низкой и высокой детализации На макетах, представленных на Рисунке 30, можно увидеть, что изначально в мобильном приложении должен был быть ряд приветственных экранов, подробно информирующих пациента о целях исследования. Приветственный блок изначально делился на следующие разделы: «Об исследовании», «Ваша роль» и «Соглашение», принимая которое пациент соглашался с условиями участия в исследовании, после чего мог авторизоваться в приложении. Однако в ходе работы над дизайном мобильного приложения не был получен соответствующий контент для этих экранов — подробная информация об исследовании и условиях участия, поэтому было решено отразить на 69

приветственном экране общую информацию о приложении и о его назначении, что сократило приветственный блок до одного экрана. Рисунок 31 – Представление экрана дашборда мобильного приложения в макетах низкой и высокой детализации На макетах, представленных на Рисунке 31, можно увидеть, что при разработке макета высокой детализации изменения в основном коснулись порядка и количества разделов дашборда. Изменения по порядка разделов обусловлены изменением восприятия приоритетности различных разделов дашборда Product Owner-ом и заказчиком: изначально считалось, что самым важным разделом для пациента станет «Ежедневный отчет», однако позже было решено, что пользователю лучше в первую очередь показывать «Напоминания» как самый важный для исследования и для качества его результатов блок, поскольку, чем больше опросов пользователь проходит в срок, тем больше результатов получает врач, вследствие чего ему легче делать выводы о субъективном восприятии 70

терапии пациентом. Изменения количества разделов обусловлены дополнением требований заказчика к мобильному приложению на поздних стадиях работы над его дизайном. На макете высокой детализации на Рисунке 31 можно также заметить, что функция «Помощь с терапией» была перенесена из блока «Инфо» в блок «Напоминания». Было решено перенести эту функцию на дашборд, чтобы поместить ее у пользователя на виду и тем самым облегчить ее поиск, поскольку дашборд — экран, с которым у пользователя будет наиболее частое взаимодействие. Остальные экраны мобильного приложения не претерпели значительных структурных изменений при переходе от низкой к высокой детализации. Примеры некоторых из таких экранов мобильного приложения до и после перехода представлены на Рисунке 32. Рисунок 32 – Примеры экранов мобильного приложения, структура которых не претерпела значительных изменений при переходе от низкой детализации к высокой 71

Можно обратить внимание, что экраны, представленные на Рисунке 32, претерпели только изменения в визуализации, структура же их осталась прежней. В число экранов, созданных сразу с применением визуального стиля вошли стартовый экран загрузки приложения, экран загрузки приложения и экран отсутствия подключения к интернету. В процессе работы над мобильным приложением для пациентов был разработан дизайн 18 экранов высокой детализации и 2 модальных окон на английском и немецком языках. Был также разработан интерактивный прототип мобильного приложения для согласования с заказчиком и Product Owner-ом, а также для лучшего понимания командой структуры пользовательских сценариев и особенностей работы системы. Процесс разработки прототипа высокой детализации веб-приложения для врачей значительно отличался от вышеописанного процесса работы над мобильным приложением для пациентов. В первую очередь важно отметить, что визуализация вебприложения изначально отталкивалась от дизайна уже существующего продукта компании — веб-сервиса prisma CLOUD. Такое решение было принято с целью сделать более низким порог входа для пользователей на начальных этапах взаимодействия с разрабатываемым веб-приложением, поскольку вышеуказанный веб-сервис prisma CLOUD уже знаком целевой группе пользователей — лечащим врачам пациентов, проходящих терапию хронического респираторного заболевания с использованием аппаратов ИВЛ от Löwenstein Medical. Использование уже знакомых для пользователя паттернов взаимодействия с интерфейсом может облегчить восприятие им нового, незнакомого продукта и сократить время, необходимое на обучение и привыкание к его использованию. Из интерфейса prisma CLOUD в дизайн разрабатываемого вебприложения были позаимствованы общая структура таблицы пациентов и поведение карточки пациента. Дизайн интерфейса таблицы пациентов веб-сервиса prisma CLOUD представлен на Рисунке 33. 72

Рисунок 33 – Дизайн интерфейса таблицы пациентов в prisma CLOUD На фрагменте интерфейса, представленном на Рисунке 33, можно увидеть, что таблица пациентов состоит из строки с заголовками столбцов и строк-пациентов, которые, помимо общей информации о пациенте, содержат графическое отображение значений технических характеристик терапии, полученных с аппарата ИВЛ. В дизайне интерфейса разрабатываемого веб-приложения также было решено представить пациентов-участников исследования в виде таблицы, представленной на Рисунке 34. 73

Рисунок 34 – Дизайн интерфейса таблицы пациентов в веб-приложении для врачей Как можно видеть на экране интерфейса веб-приложения, представленном на Рисунке 34, таблица пациентов также содержит строку с заголовками столбцов и строкикарточки пациентов, включающие в себя как общую информацию — идентификационный номер пациента, так и графическое отображение значений результатов опросов и значений технических характеристик терапии, полученных с аппарата ИВЛ. Кроме того, строка пациента в веб-приложении, вместо отображения приоритета пациента, используемого в prisma CLOUD и оценивающего уровень необходимости вмешательства в терапию, содержит значение группы риска пациента, представленное в виде окраски соответствующего поля в красный, желтый или зеленый цвет. Цветовая индикация оценки необходимости вмешательства более удобна для пользователя, чем представление значения в процентах, поскольку цвет обрабатывается человеческим мозгом быстрее, чем число. Строки таблицы пациентов разрабатываемого веб-приложения располагаются в порядке убывания необходимости вмешательства, также как и строки таблицы пациентов в prisma CLOUD. Помимо общего вида таблицы пациентов из дизайна prisma CLOUD было также позаимствовано поведение карточки отдельного пациента. На Рисунке 35 представлены фрагменты дизайна развернутой карточки пациента в prisma CLOUD и в разрабатываемом веб-приложении. 74

Рисунок 35 – Фрагменты дизайна развернутой карточки пациента в prisma CLOUD и в разрабатываемом веб-приложении для врачей При нажатии на карточку пациента в prisma CLOUD карточка разворачивается, отодвигая ниже строки пациентов, которые идут после нее. В развернутой карточке пациента содержится подробная информация о пациенте, а также подробные технические данные об аппарате ИВЛ: детализация полученных значений терапии, а также настройки терапии. В разрабатываемом веб-приложении карточку пациента также возможно развернуть с помощью нажатия на стрелку в правой части карточки. Было решено сделать отдельную кнопку для возможности развернуть карточку пациента ввиду присутствия в карточке других активных элементов — иконок опросов, также доступных для нажатия. Содержимое развернутой карточки пациента в разрабатываемом веб-приложении обширнее, чем содержимое карточки пациента в prisma CLOUD, однако можно наблюдать пересечения в их дизайне: визуальное оформление разделов «Общая информация» и «Анамнез» в веб-приложении для проведения клинического исследования напоминает оформление информации в карточке пациента в prisma CLOUD. Особенностью работы над прототипом высокой детализации для веб-приложения стало то, что только его малая часть была получена применением визуального стиля к макетам низкой детализации. В форме макетов низкой детализации были проработаны только самые сложные экраны и элементы веб-приложения: экран таблицы пациентов, развернутое состояние карточки пациента, а также просмотр результатов ежемесячного и ежедневного опросов за весь период исследования. Однако несмотря на то, что для этих экранов и элементов были разработаны макеты низкой детализации, в созданные затем на их основе макеты высокой детализации была внесена масса изменений по причине постоянно меняющихся требований к дизайну, что характерно для работы над проектом в соответствии с гибкой методологией разработки. Так что можно сказать, что работа над структурой экранов происходила непрерывно на всех этапах разработки дизайна веб- 75

приложения. В качестве доказательства ниже представлен пример начального и конечного варианта визуализации экрана таблицы пациентов веб-приложения. Рисунок 36 – Начальная и конечная версии экрана таблицы пациентов веб-приложения На Рисунке 36 можно увидеть, что в начале работы над дизайном было предусмотрено гораздо большее количество информации в свернутой карточке пациента в соответствии с запросом Product Owner-а. Большая часть этой информации впоследствии была перемещена в развернутый вид карточки по запросу заказчика. Также изначально 76

дизайн предусматривал возможность фильтрации карточек пациентов по определенным параметрам для более удобной навигации по таблице в случае большого количества пациентов, однако идея введения фильтрации была отвергнута Product Owner-ом ввиду приоритизации другого функционала. Кроме того, в первой версии дизайна все значения опросов и технических данных терапии отображались в карточке в виде чисел; в дальнейшем по запросу заказчика отображение значений было заменено на иконки. Также можно заметить, что изначально в таблице не была предусмотрена колонка «Заметки», поскольку идея пришла к Product Owner-у и заказчику позже, чем был разработана первая версия дизайна. В целом можно увидеть, что дизайн структуры таблицы пациентов претерпел значительные преобразования. После разработки визуального стиля и применения его к макетам низкой детализации было разработан еще ряд экранов, изначально создававшихся в высокой детализации, включающий: ● экран авторизации; ● модальные окна результатов ежедневного, ежемесячного опроса, опроса-контроля терапии; ● экран отсутствия результатов поиска; ● модальное окно с формой добавления пациента; ● модальные окна генерации кода авторизации; ● модальное окно детализированного просмотра заметок; ● модальное окно просмотра результатов опроса проверки-терапии за весь период исследования. В процессе работы над веб-приложением для врачей был разработан дизайн 3 экранов, в которые входил экран таблицы пациентов с детализированным просмотром карточки пациента, и 10 модальных окон. Был также разработан интерактивный прототип веб-приложения для демонстрации заказчику, а также для лучшего понимания командой структуры пользовательских сценариев и особенностей работы системы. 77

ЗАКЛЮЧЕНИЕ В рамках данной работы был разработан UX/UI-дизайн информационной системы для проведения клинического исследования эффективности терапии пациентов с хроническими респираторными заболеваниями, включающий дизайн мобильного приложения для пациентов и веб-приложения для врачей. В ходе работы были выполнены следующие задачи: 1) разработана информационная архитектура для мобильного и веб- приложений; 2) разработано 9 пользовательских сценариев для мобильного приложения; 3) разработан 21 пользовательский сценарий для веб-приложения; 4) разработан стайлгайд для мобильного и веб-приложений; 5) разработан UI-кит для мобильного приложения, включающий 116 элементов и их состояний, в том числе 37 иконок, 5 иллюстраций и 6 анимаций; 6) разработан UI-кит для веб-приложения, включающий 178 элементов и их состояний, в том числе 86 иконок; 7) разработан высоко детализированный прототип мобильного приложения, включающий 18 экранов и 2 модальных окна; 8) разработан высоко детализированный прототип веб-приложения, включающий 3 экрана и 10 модальных окон. Результатом работы стало применение разработанного дизайна в технической реализации информационной системы, система в данный момент находится на стадии разработки. В дальнейшем с использованием созданной информационной системы будет проведено клиническое исследование эффективности терапии пациентов с хроническими респираторными заболеваниями, а в случае подтверждения гипотезы исследования система будет использована для повышения эффективности терапии пациентов этой группы заболеваний. 78

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 1. Веселов В. Дашборд как интерактивная альтернатива табличным отчетам // SendPulse Blog. – 2020. – URL: https://sendpulse.com/ru/blog/dashboard (дата обращения: 21.05.2021). 2. Гродская Н. Модульные сетки в работе UX-дизайнера. Инструкция по применению // Medium. – 2019. – URL: https://medium.com/design-spot/модульные-сетки-в-работе-uxдизайнера-инструкция-по-применению-410cfc1df74d (дата обращения: 28.05.2021). 3. Жолудова О. Теория цвета для дизайнеров, часть 1: Значение цвета // UxJournal. – 2016. – URL: https://ux-journal.ru/teoriya-tsveta-dlya-dizajnerov-chast-1-znachenie-tsveta.html (дата обращения: 10.04.2021). 4. Клейменова Л. Что такое телемедицина? // РБК. – (дата https://trends.rbc.ru/trends/innovation/5d8e297f9a79478c40cd4369 – 2021. URL: обращения: 02.06.2021). 5. Лобасев Д. Что такое Scrum и как он работает // OnAgile Consulting. – 2017. – URL: https://onagile.ru/trends/agile/what-is-scrum (дата обращения: 19.05.2021). 6. Нарижный Д. Пользовательские сценарии: что это такое, как и для чего их нужно строить // Медиа Нетологии. – 2017. – URL: https://netology.ru/blog/users-scenarios (дата обращения: 24.05.2021). 7. Оксигенотерапия // Семейный доктор. – URL: https://www.fdoctor.ru/oksigenoterapiya/ (дата обращения: 01.06.2021). 8. О хронических респираторных заболеваниях // Всемирная организация здравоохранения. – URL: https://www.who.int/respiratory/about_topic/ru/ (дата обращения: 26.04.2021). 9. Пушкарев А. Гибкая методология разработки «Scrum» // Хабр. – 2015. – URL: https://habr.com/ru/post/247319/ (дата обращения: 19.05.2021). 10. Руд А. 20 лучших шрифтов Google. Как их использовать? // Hyper Host. – 2019. – URL: https://hyperhost.ua/info/ru/20-luchshih-shriftov-google-kak-ih-ispolzovat (дата обращения: 27.05.2021). 11. Савин В. Для чего компании нужен UI KIT? (Front + Design) // Vc.ru. – 2020. – URL: https://vc.ru/design/187208-dlya-chego-kompanii-nuzhen-ui-kit-front-design (дата обращения: 28.05.2021). 12. Самые легко читаемые шрифты для интернета и печати // Print Peppermint. – 2020. – URL: https://www.printpeppermint.com/ru/cамые-легко-читаемые-шрифты-для-Интернетаи-печати (дата обращения: 10.04.2021). 79

13. Свеженцева А. ТОП-6 правил моушн-дизайна в интерфейсах: практические советы по созданию продуманной UI анимации // UxJournal. – 2020. – URL: https://uxjournal.ru/top-6-pravil-moushn-dizajna-v-interfejsah.html (дата обращения: 10.04.2021). 14. Создание стайлгайда для проекта // Spark.ru. – 2015. – URL: https://spark.ru/startup/peoplie/blog/6846/sozdanie-stajlgajda-dlya-proekta (дата обращения: 27.05.2021). 15. Татарский А. Р., Бабак С. Л., Кирюхин А. В., Баскаков А. В. Хроническая обструктивная болезнь легких // Consilium medicum. – 2004. – Т. 6, № 4. 16. Уайз Р. А. Лечение стабильной ХОБЛ // Справочник MSD, Профессиональная версия. – 2020. – URL: https://www.msdmanuals.com/ru-ru/профессиональный/легочныенарушения/хроническая-обструктивная-болезнь-легких-и-сопутствующиезаболевания/лечение-стабильной-хобл (дата обращения: 01.06.2021). 17. Фройнд А., Елкина А. Может ли коронавирус привести к долгосрочным проблемам со здоровьем? // Deutsche Welle. – 2020. – URL: https://www.dw.com/ru/можетли-коронавирус-привести-к-долгосрочным-проблемам-со-здоровьем/a-52899695 (дата обращения: 9.04.2021). 18. ХОБЛ – симптомы, как лечить, диагностика // Мое здоровье. – URL: https://moezdorovie.ru/medical-book/pulmonologija/hronicheskaja-obstruktivnaja-boleznlegkih-466/#kak-lechit (дата обращения: 01.06.2021). 19. Хроническая обструктивная болезнь легких (ХОБЛ) // Всемирная организация здравоохранения. – 2017. – URL: https://www.who.int/ru/news-room/fact- sheets/detail/chronic-obstructive-pulmonary-disease-(copd) (дата обращения: 26.04.2021). 20. Что такое UI Kit и для чего он нужен вашей компании // Evergreen. – 2019. – URL: https://evergreens.com.ua/ru/articles/ui-kit.html (дата обращения: 28.05.2021). 21. Швабер К., Сазерленд Дж. Руководство по Скраму / К. Швабер, Дж. Сазерленд. – Scrum.Org and ScrumInc, 2016. – 23 с. 22. Экраны и плотность пикселей. Основы UI дизайна // Uxpub. – 2020. – URL: https://ux.pub/ekrany-i-plotnost-pikseley-osnovy-ui-dizayna/ (дата обращения: 28.05.2021). 23. Coronavirus Pandemic (COVID-19) – the data // Our World In Data – URL: https://ourworldindata.org/coronavirus-data (дата обращения: 01.06.2021). 24. COVID-19. Кто в группе риска? // Euromed Clinic. – 2020. – URL: https://euromed.ru/news/covid-19-kto-v-gruppe-riska/ (дата обращения: 02.06.2021). 25. Data and statistics. Chronic respiratory diseases // World Health Organization Europe. – URL: https://www.euro.who.int/en/health-topics/noncommunicable-diseases/chronic-respiratorydiseases/data-and-statistics (дата обращения: 26.04.2021). 80

26. GBD 2017 Risk Factor Collaborators. Global, regional, and national comparative risk assessment of 84 behavioural, environmental and occupational, and metabolic risks or clusters of risks for 195 countries and territories, 1990–2017: a systematic analysis for the Global Burden of Disease Study 2017 // The Lancet. – 2018. – Т. 392, № 10159. – С. 1923-1994. 27. GBD Chronic Respiratory Disease Collaborators. Prevalence and attributable health burden of chronic respiratory diseases, 1990–2017: a systematic analysis for the Global Burden of Disease Study 2017 // The Lancet Respiratory Medicine. – 2020. – Т. 8, № 6. – С. 585–596. 28. Labaki W. W., Han M. K. Chronic respiratory diseases: a global view // The Lancet Respiratory Medicine. – 2020. – Т. 8, № 6. – С. 531–533. 29. Löwenstein Medical Russia / Loewenstein Medical International Sites – 2021. – URL: https://ru.hul.de/ (дата обращения: 20.05.2021). 30. Prisma CHECK – SpO2 модуль // Спиро Медикал. – URL: https://www.spiromedical.ru/product/prisma-check-spo2-modul/ (дата обращения: 24.05.2021). 81

Отчет о проверке на заимствования №1 Автор: miharukoto@gmail.com / ID: 6929213 Проверяющий: (miharukoto@gmail.com / ID: 6929213) Отчет предоставлен сервисом «Антиплагиат» - users.antiplagiat.ru ИНФОРМАЦИЯ О ДОКУМЕНТЕ ИНФОРМАЦИЯ ОБ ОТЧЕТЕ № документа: 2 Начало загрузки: 13.06.2021 19:59:56 Длительность загрузки: 00:00:04 Имя исходного файла: ВКР Мухортова М., 251901.pdf Название документа: ВКР Мухортова М., 251901 Размер текста: 133 кБ Cимволов в тексте: 136149 Слов в тексте: 16712 Число предложений: 656 Начало проверки: 13.06.2021 20:00:01 Длительность проверки: 00:00:05 Комментарии: не указано Модули поиска: Интернет ЗАИМСТВОВАНИЯ САМОЦИТИРОВАНИЯ ЦИТИРОВАНИЯ ОРИГИНАЛЬНОСТЬ 0,7% 0% 0% 99,3% Заимствования — доля всех найденных текстовых пересечений, за исключением тех, которые система отнесла к цитированиям, по отношению к общему объему документа. Самоцитирования — доля фрагментов текста проверяемого документа, совпадающий или почти совпадающий с фрагментом текста источника, автором или соавтором которого является автор проверяемого документа, по отношению к общему объему документа. Цитирования — доля текстовых пересечений, которые не являются авторскими, но система посчитала их использование корректным, по отношению к общему объему документа. Сюда относятся оформленные по ГОСТу цитаты; общеупотребительные выражения; фрагменты текста, найденные в источниках из коллекций нормативноправовой документации. Текстовое пересечение — фрагмент текста проверяемого документа, совпадающий или почти совпадающий с фрагментом текста источника. Источник — документ, проиндексированный в системе и содержащийся в модуле поиска, по которому проводится проверка. Оригинальность — доля фрагментов текста проверяемого документа, не обнаруженных ни в одном источнике, по которым шла проверка, по отношению к общему объему документа. Заимствования, самоцитирования, цитирования и оригинальность являются отдельными показателями и в сумме дают 100%, что соответствует всему тексту проверяемого документа. Обращаем Ваше внимание, что система находит текстовые пересечения проверяемого документа с проиндексированными в системе текстовыми источниками. При этом система является вспомогательным инструментом, определение корректности и правомерности заимствований или цитирований, а также авторства текстовых фрагментов проверяемого документа остается в компетенции проверяющего. № Доля в отчете Источник Актуален на Модуль поиска [01] 0,28% СИПАП http://ru.wikipedia.org 05 Фев 2018 Интернет [02] 0,26% Measuring progress and projecting attainment on the basis of past trends of the health-related Sustainable Development Goals in 188 countries: an analysis from the Global Burden of Disease Study 2016 https://core.ac.uk 01 Ноя 2020 Интернет [03] 0,16% здесь http://kpfu.ru 08 Фев 2017 Интернет

Рецензии:

Авторизуйтесь, чтобы добавить рецензию

- у работы пока нет рецензий -

Отзывы:

Авторизуйтесь, чтобы оставить отзыв