МИНОБРНАУКИ РОССИИ

федеральное государственное бюджетное образовательное учреждение

высшего образования
«Балтийский государственный технический университет «ВОЕНМЕХ»
им. Д.Ф. Устинова»
(БГТУ «ВОЕНМЕХ» им. Д.Ф. Устинова»)
БГТУ.СМК-Ф-4.2-К5-01

Факультет О Естественнонаучный
шифр наименование
Информационные системы и программная
Кафедра О7 инженерия
шифр наименование
Дисциплина Разработка пользовательских интерфейсов

КУРСОВАЯ РАБОТА
на тему
Разработка интерфейса “АРМ Врача”

Выполнил студент группы И597

Захаров В.Ю
Фамилия И.О.

РУКОВОДИТЕЛЬ

Фамилия И.О. Подпись

Оценка
« » 2022г.

САНКТ-ПЕТЕРБУРГ
2022 г.
 СОДЕРЖАНИЕ
ВВЕДЕНИЕ..............................................................................................................5

1 Анализ деятельности пользователя.................................................................6

1.1Цели и задачи потенциальных пользователей............................................6

1.2 Необходимые профили пользователей.......................................................6

1.3 Сценарии деятельности пользователя при решении профессиональных

задач .........................................................................................................................8

1.4 Требования пользователей и их спецификация.........................................9

1.4.1 Описание целевой аудитории.............................................................10

1.4.2 Требования пользователей..................................................................10

2 Структура диалога..........................................................................................12

2.1 Выбор типа диалога....................................................................................12

2.2 Разработка структуры диалога...................................................................14

2.3 Процессы ввода-вывода, необходимые для организации диалога.........16

3 Разработка статического прототипа..............................................................17

3.1 Рациональность размещения элементов интерфейса..............................18

3.2 Оценка трудоемкости на основе метода GOMS.......................................20

3.3 Цветовой спектр интерфейса.....................................................................23

3.4 Средства привлечения внимания пользователя.......................................24

4 Разработка средств поддержки пользователя..............................................26

4.1 Набор средств контекстной помощи.........................................................27

4.2 Разработка справочной системы................................................................27

4.3 Разработка фрагмента средства обучения пользователя.........................28

5 Юзабилити-тестирование программного продукта.....................................29

5.1 Выбор метода юзабилити-тестирования...................................................29

2
 5.2 Определение характеристик группы респондентов и её состав.............30

5.3 Тестовый сценарий......................................................................................31

5.4 Юзабилити-тестирование разработанного интерфейса...........................33

5.5 Выводы по результатам тестирования......................................................34

5.6 Отчет о тестировании интерфейса.............................................................34

ЗАКЛЮЧЕНИЕ.....................................................................................................36

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ:...........................................37

3
 ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
В настоящей пояснительной записке применяют следующие термины и
определения
АРМ — автоматизированное рабочее место ОС — операционная система
ПО ИС — программное обеспечение информационной системы ПК —
персональный компьютер
Статический прототип – изображений или серия изображений, которые
демонстрируют расположение элементов, но не дает возможности с ними
взаимодействовать

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

5
 1 Анализ деятельности пользователя
Пользователь данной системы работает в личном кабинете. Для
взаимодействия с системой пользователю необходимо иметь компьютер с
установленной и настроенной операционной системой (желательно последней
версии). Так как пользователь взаимодействует с клиентами на физическом уровне
– необходима возможность работы с периферийными устройствами (датчики,
сканеры и тд), а соответственно и пакеты стороннего программного обеспечения
для работы с ними. Так как требуются возможности записи на определённое время
и возможны пересечении по расписанию – в общей локальной сети должна
присутствовать база данных, которая поможет распределить данные о записях.
1.1 Цели и задачи потенциальных пользователей
На начальном этапе разработки пользовательского интерфейса, нам
необходимо определить цели и задачи потенциальных пользователей будущей
системы.
Цели:
– заполнение интерактивных документов;
– просмотр истории приемов;
– отправка / распечатка рекомендаций и рецептов по почте;
– аналитика отчетов пациентов по группам.
Задачи:
– создание документов из шаблонов;
– набор текста;
– редактирование текста;
– скан / распечатка документов.
1.2 Необходимые профили пользователей
Перед началом работы, необходимо обозначить профили пользователей, с
которыми нам предстоит работать. Далее, они будут отображены в таблице 1.

6
Социальные характеристики:
– пол;
– возраст;
– языки;
– образование;
– уровень занимаемой должности (специализация).

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

Рабочая среда:
– размер монитора;
– экранное разрешение;
– быстродействие компьютера;
– используемая ОС;
– язык ОС.

Мотивационно-целевая среда:
– цели пользователя;
– мотивация пользователя к использованию программы.

Таблица 1 – Характеристики пользователей

7
 Пользователи Менеджер заявок Врач
На
Женщины Мужчины, женщины
Социальные Возраст 20 – 55 лет Возраст 26 – 60 лет основании
характеристики Русскоязычные Русскоязычные

Средний уровень владения Низкий уровень владения

данных
компьютером компьютером
Умения и навыки Прошли предварительный Прошли предварительный таблицы 1
тренинг работы с системой тренинг работы с системой
можно
Пользователи Менеджер заявок Врач сделать
вывод, что
Необходимость, удобство Необходимость, удобство
Мотивационно для
целевая среда

Стандартизированные пк с Стандартизированные пк с
Windows 8(10), локальная сеть, Windows 8(10), локальная сеть,
Рабочая среда локальная телефонная линия локальная телефонная линия

Просмотр\фильтрация Просмотр\фильтрация
информации по заявкам, записям информации по заявкам,
Задачи пользователя Агрегация информации по записям
записям Создание записей
Создание заявок\записей Создание рецептов\назначений
Возможность использовать ПО Возможность использовать ПО
ИС в локальной сети ИС в локальной сети
Требования к ПО Возможность использования Возможность использования
программы при общении с программы при общении с
клиентом клиентом
Возможность формирования Время ожидания допустимое
новых записей\заявок для клиента
Возможность формирования
новых записей
пользователей требуется разработать интерфейс с большим набором опций, что
вызвано не только необходимостью удобства, но и требованиями к
профессиональной деятельности.
1.3 Сценарии деятельности пользователя при решении
профессиональных задач
Далее будут приведены сценарии теоретической деятельности пользователя
системы при решении конкретной задачи.
Сценарий 1- записи на прием.
Анна Болейн (менеджер заявок) общается с клиентом по телефону. По
просьбе клиента она предварительно просматривает расписание врача, к которому
клиент хочет записаться.

8
 Если время, на которое клиент хочет записаться, занято, А.Б. сообщает
клиенту о невозможности записи и предлагает свободное время.
Если предложенное время устраивает клиента, А.Б. вносит его в расписание
врача, с указанием: ФИО и время записи.

9
 Сценарий 2- первичного приема пациента.
Виталий Громыка (величайший лечащий врач) по итогу осмотра клиента
вносит дополнения в его мед карту: о дате осмотра, его итогах и рекомендации к
пациенту, если они уместны.
Сценарий 3 - просмотра истории болезней пациента.
Всё тот же небезызвестный Виталий Громыка по надобности может
просмотреть историю болезней клиента.
Для этого ему потребуется открыть мед карту пациента и открыть
посмотреть сводку всех его болезней.
Сценарий 4 - отправки/распечатки рекомендаций или рецептов.
По окончании приёма, врачу необходимо предоставить клиенту
рекомендации или рецепт.
Для этого, в программе, врачу будет необходимо составить
рецепт/рекомендацию, которую уже потом можно будет либо распечатать на
месте, либо переслать клиенту на почту.
1.4 Требования пользователей и их спецификация
Требуется разработать приложение “АРМ врача”, обеспечивающее
интерфейс пользователя с помощью электронного устройства вывода информации,
типа “монитор”. Приложение должно выполнять следующие функции:
1) запись на прием;
2) заполнение документов:
a) заполнение карты пациента,
b) заполнение справок,
c) заполнение рецептов;
3) просмотр истории:
a) просмотр истории посещений,
b) просмотр медицинской карты;

10
 4) аналитика:
a) просмотр данных о заболевших,
b) просмотр данных о возрасте;
5) выдача рекомендаций:
a) печать на месте,
b) отправка на почту.
1.4.1 Описание целевой аудитории
Во время анализа предметной области было выявлено две группы
пользователей, на которые может быть ориентирован проект: врачи и менеджеры
заявок. Для удобства, врачи видят поля записи только на своё имя, то есть, они не
могут подглядеть расписание приемов других врачей. Менеджеры же, видят
полную таблицу расписаний приемов. Возможности всех пользователей на проекте
одинаковы, поэтому разделение их на группы можно считать условным.
В качестве способа получения информации выбран опрос нескольких
потенциальных пользователей и дискуссии с ними.
1.4.2 Требования пользователей
Требования пользователей будут представлены в виде модели прецедентов.
Модель прецедентов необходимо построить для достижения полного
взаимопонимания между заказчиком и командой исполнителей проекта. Так как
заказчик и команда исполнителей — зачастую люди совершенно разных
специальностей, модель прецедентов является средством, позволяющим описать
работу проектируемой системы на понятном для обеих сторон формализованном
языке.
Описание возможностей для пользователей разрабатываемого приложения
для “АРМ врача” проиллюстрируем с помощью диаграммы прецедентов или
вариантов использования (рисунок 1).

11
Рисунок 1 – диаграмма прецедентов

12
 2 Структура диалога
Обмен информацией между пользователем и компьютером (точнее, его
программным обеспечением) по всем формальным признакам соответствует
понятию «диалог». Для того чтобы диалог был конструктивным, должны
соблюдаться следующие правила:
– участники диалога должны понимать язык друг друга;
– участники диалога не должны говорить одновременно;
– очередное высказывание должно учитывать, как общий контекст
диалога, так и последнюю информацию, полученную от собеседника.
Если собеседники обсуждают вопросы, относящиеся к какой-либо
специальной области, они должны придерживаться единой терминологии; при
объяснении следует сначала пояснить основные термины и понятия.
Очень краткие ответы и слишком большие паузы могут сбить собеседника с
толку, а злоупотребление специальными терминами или жаргонизмами вообще
может привести к преждевременному завершению беседы.
Перечисленные выше факторы существенно влияют на структуру диалога,
т.е. на форму общения.
Т.е. при проектировании диалога, необходимо определить:
– структуру диалога;
– возможный сценарий развития диалога;
– содержание управляющих сообщений и данных, которыми могут
обмениваться человек и приложение (семантику сообщений);
– визуальные атрибуты отображаемой информации (синтаксис
сообщений).
2.1 Выбор типа диалога
Используя профили пользователей, описанные в параграфе 1.2, заполняем
таблицу 2. Затем, исходя из полученных по таблице данных, выбираем
необходимый тип диалога.
Таблица 2 – Выбор структуры диалога для роли “менеджер заявок”.

13
 Выбор Тип диалога
Критерии пользователя Меню Вопрос- Язык Экранные
ответ команд формы
Цель:
Запрос + + + + +
Вычисления + + + +
Сложный выбор + +
Ввод данных + + +
Ввод данных + + + +
(большой объем)
Тип пользователя:
Программист + +
Непрограммист + + + + +
с опытом работы
Непрограммист + + * *
без опыта работы
Время обучения:
Очень малое + +

Менее 1 дня + + + ** **
Более 1 дня + +
Результат оценки 3 4 3** 2**

Таблица 3 – Выбор структуры диалога для роли “врач”.

Выбор Тип диалога
Критерии пользователя Меню Вопрос- Язык Экранные
ответ команд формы
Цель:
Запрос + + + + +
Вычисления + + + +
Сложный выбор + +
Ввод данных + + +
Ввод данных + + + +
(большой объем)
Тип пользователя:
Программист + +
Непрограммист + + + +
с опытом работы
Непрограммист + + + * *
без опыта работы

14
 Продолжение таблицы 3
Выбор Тип диалога
Критерии пользователя Меню Вопрос- Язык Экранные
ответ команд формы
Время обучения:
Очень малое + +

Менее 1 дня + + + ** **
Более 1 дня + +
Результат оценки 3 4 2*** 1***
По результатам Таблицы 2-3 видно, что наиболее подходящей структурой
диалога является «диалог на основе меню». С небольшим отставанием уступила
структура «Вопрос-ответ», которую мы будем использовать в случаях, где ее
применение оправданно.
2.2 Разработка структуры диалога
Далее, необходимо разработать структуру диалога для всего программного
средства в целом и для отдельных функциональных блоков. Описание этой
структуры содержится в таблице 4 и рисунке 2.
Таблица 4 - Таблица переходов

Условие перехода Следующая вершина

Для вершины N1 – Состояние «Авторизация»
C1 Успешная авторизация N2 Состояние «Картотека»
Для вершины N2 – Состояние «Картотека»
С2 Выбрано поле «Редактировать N4 Состояние «Редактирование медкарты»
медкарты»
С3 Нажата кнопка «Отправить N5 Состояние «Отправление данных на
результаты на почту» почту»
С4 Нажата кнопка «Сохранить N6 Состояние «Сохранение данных»
данные»
С5 Выбран пункт «Запись на прием» N3 Состояние «Запись на прием»
С6 Выбран пункт «Выход из N7 Состояние «Деавторизация»
аккаунта»
Для вершины N3 – Состояние «Запись на прием»
С7 Выбран пункт «Редактировать N8 Состояние «Форма редактирования
запись» записей»
С8 Нажата кнопка «Удалить запись» N9 Состояние «Форма удаления записей»
С9 Выбран пункт «Картотека» N2 Состояние «Картотека»

15
Продолжение таблицы 4
Условие перехода Следующая вершина
С10 Выбран пункт «Выход из N7 Состояние «Деавторизация»
аккаунта»
Для вершины N4 – Состояние «Редактирование медкарты»
С11 Подтверждение редактирования N10 Отображение информации об успешном
медкарты изменении данных
С12 Нажатие кнопки закрытия окна N2 Состояние «Картотека»
Для вершины N5 – Состояние «Отправление данных на почту»
С13 Подтверждение решения об N11 Отображение информации об успешном
отправке данных изменении статуса
С14 Нажатие кнопки закрытия окна N2 Состояние «Картотека»
Для вершины N6 – Состояние «Сохранение данных»
С15 Подтверждение решения о N11 Отображение информации об успешном
сохранении данных изменении статуса
С16 Нажатие кнопки закрытия окна N2 Состояние «Картотека»
Для вершины N7 – Состояние «Деавторизация»
C17 Нажата кнопка «Выход» N1 Состояние «Авторизация»
Для вершины N8 – Состояние «Форма редактирования записей»
C18 Нажата кнопка “Редактировать” N10 Отображение информации об успешном
изменении данных
С19 Нажата кнопка “Запись” N3 Состояние «Запись на прием»
Для вершины N9 – Состояние «Форма удаления записей»
C20 Удаление записей N10 Отображение информации об успешном
изменении данных
С21 Нажатие кнопки “Закрытие окна” N3 Состояние «Запись на прием»
Для вершины N10 – Состояние «Отображение информации об успешном изменении
данных»
С22 Нажатие кнопки закрытия окна N4 Состояние «Редактирование медкарты»
С23 Нажатие кнопки закрытия окна N8 Состояние «Форма редактирования
записей»
С24 Нажатие кнопки закрытия окна N9 Состояние «Форма удаления записей»
Для вершины N11 – Состояние «Отображение информации об успешном изменении
статуса»
С25 Нажатие кнопки закрытия окна N5 Состояние «Отправление данных на
почту»
С26 Нажатие кнопки закрытия окна N6 Состояние «Сохранение данных»

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

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

Рисунок 3 – Экран авторизации

Экран авторизации представляет собой два поля, в которые необходимо

ввести логин и пароль для входа в аккаунт, и кнопку входа, после нажатия на
которую пользователя пересылает в картотеку (рисунок 3).

Рисунок 4 – Окно картотеки

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

пациента.

Рисунок 5 – Меню записи на прием

Нажатием кнопки “Запись на прием”, из картотеки можно перейти в
календарь приемов. Здесь пользователю представлена возможность просмотреть
дату и время приема, на который записаны пациенты, а также возможность
добавления и удаления этих записей через кнопку “Редактировать”.
3.1 Рациональность размещения элементов интерфейса
Группировка, а также расположение объектов позволяют упростить
пользователю работу с интерфейсом. Плохо разработанный интерфейс не только
усложняет, но и сбивает при решении задач.
При создании прототипа интерфейса, основной упор был возложен на
структурированность элементов. Работая за ПК, в среднем, пользователь
расположен от дисплея на расстоянии 50-60 см. При таком расстоянии, человек
неспособен усвоить всю информацию, изображённую на дисплее, что подводит к
мысли о правильном расположении элементов в области экрана.

19
 При расположении объектов группами, у пользователя снизится
необходимость в использовании нескольких осей̆ для направления взгляда,
упростится процесс усваивания информации, что позволит повысить качество и
скорость выполняемой̆ работы.
На рисунках 6-7 представлен пример использования метода
прямоугольников.

Рисунок 6 – Оценка макета методом прямоугольников

Рисунок 7 – Оценка макета методом прямоугольников

20
 В результате видно, что блочная структура рационально использует
свободное место и одинаково заполняет каждый̆ «прямоугольник». Остальные
страницы имеют схожие результаты.
3.2 Оценка трудоемкости на основе метода GOMS
Одним из лучших подходов к количественному анализу моделей
интерфейсов является классическая модель GOMS (goals, objects, methods and
selection rules). Правила GOMS позволяют определить время, необходимое
пользователю для выполнения любой четко сформулированной задачи, для
которой данный интерфейс предусмотрен.
Расчет времени, необходимого для выполнения некоторого действия
начинают с разбиения его на элементарные действия, которые соответствуют
номенклатуре, приведенной в таблице 1. Проще всего выделить движения К, М, П,
В.

Таблица 5 – Номенклатура элементарных действий модели GOMS

Элементарное действие Время Обозначени
е
Нажатие клавиши клавиатуры, включая клавиши Alt, Ctrl, 0,28 с К
Shift
Нажатие клавиши мыши 0,1 с М
Указание – перемещение курсора мыши, чтобы указать 1,1 с П
какую-либо позицию на экране монитора
Перемещение- перенос руки пользователя с клавиатуры на 0,4 с В
мышь или обратно
Ментальная подготовка – мысленный выбор пользователем 1,2 Д
своего следующего элементарного действия
Ответ – реакция системы на элементарное действие - Р
пользователя
Проблему составляет определение моментов, когда пользователь должен
остановиться, чтобы выполнить бессознательную ментальную операцию.
Рассмотрим основные правила по выявлению этих моментов (таблица 2).

21
Таблица 6 – Алгоритм количественной оценки методом GOMS
Правило Выполняемое действие
Правило 0 Операторы Д следует устанавливать перед всеми операторами К
Начальная и М (нажатие клавиши), также перед всеми операторами П,
расстановка предназначенными для выбора команд. Но перед операторами
операторов Д П, предназначенными для указания на аргументы этих команд,
ставить оператор Д не следует.
Правило 1 Если оператор, следующий за оператором Д, является
Удаление полностью ожидаемым с точки зрения оператора,
ожидаемых предшествующего Д, то этот оператор Д может быть удален.
операторов Д Если пользователь перемещает мышь с намерением нажать на
ее кнопку по достижении цели движения, то в соответствии с
этим правилом следует удалить оператор Д, установленный по
правилу 0. Так последовательность действий П Д К
преобразуется в П К.
Правило 2 Если строка Д К Д К Д К… принадлежит когнитивной единице,
Удаление операторов то следует удалить все операторы Д, кроме первого.
Д внутри Когнитивной единицей является непрерывная
когнитивных единиц последовательность вводимых символов, которые образуют
название команды или аргумент. Например Y, перемещать,
4564.23 – это когнитивные единицы.
Правило 3 Если оператор К означает лишний разделитель, стоящий в конце
Удаление операторов когнитивной единицы (например, разделитель команды,
Д перед следующий сразу за разделителем аргумента этой команды), то
последовательными следует удалить оператор Д , стоящий перед ним.
разделителями
Правило 4 Если оператор К является разделителем, стоящим после
Удаление операторов постоянной строки (например, название команды или любая
Д, которые являются последовательность символов, которая каждый раз вводится в
прерывателями неизменном виде), то следует удалить оператор Д, стоящий
команд перед ним. (Добавление разделителя станет привычным
действием, и поэтому разделитель станет частью строки и не
будет требовать специального оператора Д.) Но если оператор К
является разделителем строки аргументов или любой другой
изменяемой строки, то оператор Д следует сохранить перед ним.
Правило 5 Любую часть оператора Д, которая перекрывает оператор Р,
Удаление означающий задержку, связанную с ожиданием ответа
перекрывающих компьютера, учитывать не следует.
операторов Д
В этих правилах:
– строка - некоторая последовательность символов.

22
 – разделитель - символ, которым обозначено начало или конец
значимого фрагмента текста, такого как, например, слово естественного языка или
телефонный номер. Так, пробел является разделителем для большинства слов, а
точка используется в конце предложений для разделения. В качестве разделителей
могут выступать скобки для ограничений пояснений или замечаний и т.д.
– аргумент данной команды - дополнительная информация, необходимая
для выполнения команды.
Далее будут рассмотрены и оценены методом GOMS несколько сценариев.
Сценарий 1 - запись на прием
П – перенос мыши на необходимую дату/время, М – нажатие ЛКМ по
выбранной ячейке,
П – перенос мыши на кнопку “Редактировать”, М – нажатие ЛКМ по
выбранной кнопке,
П – перенос мыши на поле “Интересующий врач”, М – нажатие ЛКМ по
полю,
18*К – ввод специальности и фамилии врача, П – перенос мыши на поле
“ФИО Пациента”, М – нажатие ЛКМ по полю,
28*К – ввод ФИО пациента,
П – перенос мыши на кнопку “Ок” сообщения об успешном сохранении
записи,
М – нажатие ЛКМ по кнопке.
П М П М П М 18*К П М 28*К П М
Расставим Д операторы:
П М П М П М Д 18*К П М Д 28*К П М
Расчёт:
1,1 + 0,1 + 1,1 + 0,1 + 1,1 + 0,1 + 1,2 + 18*0,28 + 1,1 + 0,1 + 1,2 + 28*0,28 +
1,1 + 0,1 = 21.28 сек

23
 Сценарий 2 - вход пользователя в профиль П – перенос мыши на поле
“Логин”,
М – нажатие ЛКМ по полю, 15*К – ввод логина,
П – перенос мыши на поле “Пароль”, М – нажатие ЛКМ по полю,
12*К – ввод пароля,
П – перенос мыши на кнопку “Вход”, М – нажатие ЛКМ на кнопку.
П М 15К П М 12К П М
Расставим Д операторы:
П М Д 15К П М Д 12К П М
1,1 + 0,1 + 1,2 +15*0,28 + 1,1 + 0,1 + 1,2 + 12*0,28 + 1,1 + 0,1 =
13.56 сек
Исходя из вышеперечисленного, можно сделать вывод, что для оптимизации
интерфейса, можно было бы предусмотреть улучшение поля истории болезней.
Например, добавив в него несколько вспомогательных форм для ввода данных, по
типу даты протекания болезни.
3.3 Цветовой спектр интерфейса
Подберем стандартную цветовую схему для разрабатываемого интерфейса.

Рисунок 8 – Цветовой спектр

24
 Данная комбинация цветов взаимно дополняет и подчеркивает элементы при
их комбинации. Цветовая гамма не напрягает и не усложняет восприятие
графических элементов, а умеренное использование темных оттенков не создает
угнетающее воздействие на пользователя. Преимущественно используются более
светлые оттенки для формирования блоков элементов, которые хорошо
подчеркивают и выделяют тёмный шрифт. Данные цветовая гамма
продемонстрирована раннее на изображениях разработанного прототипа
интерфейса. Также выбранные цвета являются одними из базовых цветов
операционной системы Windows 10 (они продемонстрированы на рисунке 9).
Рисунок 9 – Базовые цвета ОС Windows 10.

3.4 Средства привлечения внимания пользователя

Кнопки выполнены в отличном от фона оттенке, также они отделены
границей. Такой прием намекает на возможность сделать нажатие. Блоки с вводом
данных имеют выделенный цвет чуть более темного оттенка, что визуально делает
их легко отличимыми от фона. При вводе информации, текущее поле выделяется
рамкой (рисунок 10).

25
 Рисунок 10 – Рамка при вводе информации в поле

Если какое-нибудь из полей не заполнено и пользователь нажимает кнопку

сохранения, незаполненное поле подсвечивается красным цветом (рисунок 11), что
говорит о том, что поле обязательно должно быть заполнено.

Рисунок 11 – Привлечение внимания при неправильном вводе информации

26
 4 Разработка средств поддержки пользователя
На рисунках 12 – 13 представлены макеты окон, содержащие сообщения об
ошибках.

Рисунок 12 – Пример сообщения об ошибке при вводе данных в карту

пациента

Рисунок 13 – Пример сообщения об ошибке при попытке записи

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

27
 4.1 Набор средств контекстной помощи
В качестве контекстной помощи для данного интерфейса, были выбраны
всплывающие подсказки, пример приведен на рисунке 3. Всплывающая подсказка
– это небольшое всплывающее окно, появляющееся на некоторое время при
наведении указателя мыши (курсора) на объект. В этом окне размещается краткое
описание объекта. Это средство очень полезно для идентификации
аббревиатур/пиктограмм, внешний вид которых недостаточно ясно для
пользователя может идентифицировать соответствующий объект.

Рисунок 14 – Пример всплывающей подсказки

Также, стоит упомянуть и другие средства контекстной помощи, такие как
команда (Что это?) и строка состояния. Но, в данной работе, учитывая простоту и
ограниченность функционала интерфейса, нам хватит и простых всплывающих
подсказок.
4.2 Разработка справочной системы
Справочная система представляет собой отдельный раздел в главном окне,
наравне с Картотекой и Записью на прием. Содержит в себе справку по работе с
программой, описывающую все поля, кнопки, таблицы и способы их
использования. Перейти в данный раздел можно нажатием кнопки “Справка”.

28
 Рисунок 15 – Вид справочной системы
4.3 Разработка фрагмента средства обучения пользователя
В качестве средства обучения пользователя была выбрана запись
обучающего видеоролика по работе с данным программным обеспечением, потому
что видеофрагмент наглядно демонстрирует все возможности данной системы
пользователю и позволяет быстро освоится в ней, просто повторив действия из
ролика, что отчетливо видно на рисунке 16.

Рисунок 16 – Фрагмент обучающего видеоролика

29
 5 Юзабилити-тестирование программного продукта
В таблице 7, приведенной ниже, сформулированы цели и задачи,
поставленные перед тестированием.

Таблица 7 - Характеристика задач тестирования

Задача удобства Критерий Качество работы Условия
применения
После 10-минутного 80% пользователей; в Заполнить карту После 10-
тренинга 80% течение 2,5 мин. пациента минутного
пользователей в тренинга
состоянии заполнить
карту пациента в
течение 2,5 мин.
Количество ошибок: 80% пользователей; Успешно выполнить После
После выполнения не допустят более задачу выполнения
пяти сценариев задач двух ошибок пяти
80% пользователей сценариев
будут в состоянии задач
успешно выполнить
задачу
Простота изучения: Все пользователи; Успешно овладеть После 10-
После 10-минутного определенный продуктом минутного
тренинга все уровень владения тренинга
пользователи продуктом
достигнут
определенного уровня
владения продуктом
Отношение 80% пользователей; Степень После
пользователей: степень удовлетворенности выполнения
После выполнения удовлетворенности 8 пяти
пяти сценариев задач баллов по 10- сценариев
80% пользователей балльной системе задач
оценят степень своей
удовлетворенности
продуктом на 8 и
выше баллов (по 10-
балльной системе)
5.1 Выбор метода юзабилити-тестирования
Существует три основных метода юзабилити-тестирования: пассивное
наблюдение, поток сознания и активное вмешательство.

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

Группу респондентов будут составлять однокурсники и родственники,

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

Респондент 1 – девушка, 20 лет, обучается в медицинском университете,

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

31
 Респондент 3 – мужчина, 20 лет, студент, не имеет опыта работы в подобных
системах. Особенности: респондент имеет высокий уровень навыков работы с
персональным компьютером и различными видами программного обеспечения.
Респондент 4 – мужчина, 79 лет, пенсионер, не имеет опыта работы в
подобных системах. Особенности: в силу возраста респондент имеет минимальный
уровень навыков работы с персональным компьютером.
Респондент 5 – мужчина, 21 год, студент, не имеет опыта работы в подобных
системах. Особенности: респондент имеет высокий уровень навыков работы с
персональным компьютером и различными видами программного обеспечения.
Количественный состав респондентов определяется сложностью системы и
количеством пользовательских задач. В нашем случае, респонденты будут иметь дело
с прототипом системы, так что, для тестирования хватит 5 человек.
5.3 Тестовый сценарий
Необходимо разработать образец тестового сценария (не менее 5 тестовых
заданий), включающий пользовательские задачи, значимые эргономические
метрики, тестовые задания респондентам, признаки успешности выполнения.
Задание 1 - Поиск карты пациента по номеру. Точка входа: Окно
“Картотеки”.
Задача: найти карту пациента по её номеру (тестовое значение номера –
“780-550-31”).
Метрики и критерии: время выполнения задания, не более 25-ти секунд;
Количество ошибок, не более 1.
Задание 2 - Сохранение данных.

32
 Точка входа: Окно “Картотеки”.
Задача: сохранить данные карты пациента ( тестовые значения полей – номер
карты: 300-007-01, фамилия: Хенрингтон, имя: Билли, отчество: Харитонович, дата
рождения: 01.01.1973, возраст: 49, телефон: +79218888888, test@patient.ru, снилс:
787818568, пол: мужской) .
Метрики и критерии: Время выполнения задания, не более двух минут.
Количество ошибок, не более 1.

Задание 3 - Запись на прием.

Точка входа: Окно "Запись на прием".
Задача: записать пациента на прием (тестовые значения полей –
интересующий врач: Иванов Андрей, ФИО пациента: Харитонов Борис
Харитонович).
Метрики и критерии: Время выполнения задания, не более полутора минут.
Не более 80% пользователей совершили две ошибку.
Задание 4 - Неудачная запись на прием. Точка входа: Окно "Запись на
прием".
Задача: получить сообщение об ошибке при попытке записи пациента на
прием (тестовые значения полей – интересующий врач: Иванов Андрей, ФИО
пациента: оставить поле пустым).
Метрики и критерии: Время выполнения задания, не более минуты.

Задание 5 – Неудачный поиск карты пациента по номеру. Точка входа: Окно

“Картотеки”.
Задача: получить ошибку при поиске карты пациента по номеру и получить
предложение о создании новой карты (тестовое значение номера – “34521М”).
Метрики и критерии: Время выполнения задания, не более 25-ти секунд.

33
 5.4 Юзабилити-тестирование разработанного интерфейса
Используя тестовый сценарий из предыдущего параграфа, проведем
юзабилити-тестирование разработанного интерфейса.
Таблица 8 - результаты для тестовой задачи 1
Респонденты Метрика 1 Метрика 2
(Время выполнения) (Количество ошибок)
Респондент 1 26 сек. 0
Респондент 2 52 сек. 0
Респондент 3 29 сек. 0
Респондент 4 1мин. 39 сек. 1
Респондент 5 29 сек. 0
Результат ≤1 мин. (80%) ≤1 (80%)

Таблица 9 - результаты для тестовой задачи 2

Респонденты Метрика 1 Метрика 2
(Время выполнения) (Количество ошибок)
Респондент 1 1 минута 3 сек. 1
Респондент 2 1минута 57 сек. 0
Респондент 3 45 сек. 0
Респондент 4 2 минуты 56 сек. 2
Респондент 5 54 сек. 0
Результат ≤ 2 мин. (80%) ≤ 2 ошибки (100%)

Таблица 10 - результаты для тестовой задачи 3

Респонденты Метрика 1 Метрика 2
(Время выполнения) (Количество ошибок)
Респондент 1 19 сек. 0
Респондент 2 38 сек. 0
Респондент 3 12 сек. 1
Респондент 4 1 мин. 14 сек. 1
Респондент 5 13 сек. 0
Результат ≤ 30 сек. (60%) ≤2 (100%)

Таблица 11 - результаты для тестовой задачи 4

Респонденты Метрика 1
(Время выполнения)
Респондент 1 6 сек.
Респондент 2 4 сек.
Респондент 3 13 сек.
Респондент 4 36 сек.

34
 Продолжение таблицы 11
Респонденты Метрика 1
(Время выполнения)
Респондент 5 4 сек.
Результат ≤ 1 мин. (100%)

Таблица 12 - результаты для тестовой задачи 5

Респонденты Метрика 1
(Время выполнения)
Респондент 1 3 сек.
Респондент 2 2 сек.
Респондент 3 3 сек.
Респондент 4 6 сек.
Респондент 5 3 сек.
Результат ≤ 10сек. (100%)

5.5 Выводы по результатам тестирования

Согласно результатам тестирования, разработанный интерфейс является
понятным, доступным и эффективным для большинства пользователей.
Исследование обучаемости навыкам работы с системой показало, что с каждым
разом задача, отличающая незначительно от уже выполненной в прошлом,
выполняется большинством тестируемых все лучше и лучше.
5.6 Отчет о тестировании интерфейса
Интерфейс приложения выполняет свои функции, выдержан в приятной
цветовой гамме, прост в понимании для большинства своих пользователей и не
перегружен лишними элементами.
Частой проблемой является неочевидность создания новой записи во вкладке
“Запись на прием”.
Эта проблема решается путем добавления в каждую ячейку с записью
контекстной подсказки с указанием необходимых действий.
Следующей, уже частной проблемой, было то, что при создании записи есть
возможность вызвать окно записи множество раз подряд (рисунок 17)

35
 Рисунок 17 – Пример ошибки
Для решения данной проблемы было ограничено количество нажатий на
кнопку “РЕДАКТИРОВАТЬ”, если окно уже было вызвано.

36
 ЗАКЛЮЧЕНИЕ
С использованием Qt, Qt Designer была разработан удобный в использовании
интерфейс.
На основе профиля деятельности пользователей были сформулированы
требования, составлены профили пользователей, выявлены их цели и описаны
сценариев их деятельности, разработана структура диалога для различных
категорий пользователей, создан прототип интерфейса, который был оценен
методом GOMS. Были разработаны средства поддержки пользователя и проведено
юзабилити-тестирование.
Согласно результатам тестирования, разработанный интерфейс является
понятным, доступным и эффективным для большинства пользователей.
Исследование обучаемости навыкам работы с системой показало, что с каждым
разом задача, отличающая незначительно от уже выполненной в прошлом,
выполняется большинством тестируемых все лучше и лучше.

37
 СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ:
1. Не заставляйте меня думать / Стив Круг; [пер. с англ. М.А. Райтмана].
– 3-е издание. – Москва: Издательство «Э», 2017. – 256 с.
2. Руководство по использованию Qt Designer [Электронный ресурс]. -
URL: https://doc.qt.io/qt-5/qtdesigner-manual.html.
3. Гультяев А. К., Машин В. А. Проектирование и дизайн
пользовательского интерфейса - СПб.: КОРОНА принт, 2000. - 349 с.
4. Кесенбери У. Сторителлинг в проектировании интерфейсов. Как
создавать истории, улучшающие дизайн. — М.: Манн, Иванов и Фербер, 2013.
— 336 с.
5. ГОСТ 7.32 – 2017 Система стандартов по информации, библиотечному
и издательскому делу. Отчет о научно-исследовательской работе. Структура и
правила оформления. – М: Стандартинформ, 2017 – 28 с.

38