Проектирование интуитивно-понятного Человеко-Машинного Интерфейса настольного приложения «Расходник»: Методологическое обоснование на основе стандартов ГОСТ Р ИСО 9241 и принципов HCI

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

Настоящий курсовой проект посвящен разработке концепции и детальному проектированию человеко-машинного интерфейса (ЧМИ) настольного приложения «Расходник», призванного решить эту проблему. Целью работы является создание проекта ЧМИ, который будет максимально интуитивным и дружелюбным для пользователя без глубоких технических знаний, обеспечивая при этом высокую результативность, эффективность и удовлетворенность от использования. Для достижения этой цели были поставлены следующие задачи:

1. Исследовать и систематизировать теоретические основы человеко-компьютерного взаимодействия (HCI), юзабилити и эргономики.
2. Обосновать применение стандартов серии ГОСТ Р ИСО 9241 как методологической основы проектирования.
3. Провести детальный анализ целевой аудитории и контекста использования приложения «Расходник».
4. Разработать концептуальное решение информационной архитектуры и реляционной модели данных, являющейся фундаментом приложения.
5. Спроектировать ключевые экраны интерфейса с учетом принципов минимизации когнитивной нагрузки и эвристик юзабилити.
6. Сформировать структуру и содержание руководства пользователя, ориентированного на не-IT аудиторию.

Актуальность работы обусловлена растущей потребностью в простых и надежных цифровых инструментах для личного использования, а также необходимостью строгого следования академическим и инженерным стандартам при их проектировании. Научная новизна заключается в интеграции принципов HCI, эвристик юзабилити и методологии HCD, закрепленной в ГОСТ Р ИСО 9241, с детальной проработкой инженерных аспектов, таких как проектирование базы данных, что позволяет создать целостное и обоснованное решение. Практическая значимость проекта состоит в разработке готовой концепции ЧМИ и технического задания, которые могут стать основой для дальнейшей реализации настольного приложения «Расходник».

Теоретические основы и нормативная база проектирования ЧМИ

Сфера человеко-компьютерного взаимодействия (HCI), возникшая в 1980-х годах на стыке информатики, эргономики, психологии и дизайна, сегодня стала краеугольным камнем в создании любого программного продукта. От того, насколько комфортно и эффективно человек взаимодействует с машиной, зависит успех всей системы; это обуславливает, насколько критически важным для «Расходника» является понимание фундаментальных концепций HCI и их нормативное закрепление.

Формальные определения и критерии качества ЧМИ

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

Человеко-машинный интерфейс (ЧМИ) – это совокупность средств, методов и правил взаимодействия человека с программно-аппаратными системами. По сути, это точка контакта между пользователем и приложением, через которую передаются команды и отображаются результаты. Хорошо спроектированный ЧМИ становится невидимым, позволяя пользователю сосредоточиться на своих задачах, а не на борьбе с программой.

Юзабилити (Usability) – это фундаментальное свойство ЧМИ. Согласно международному стандарту ГОСТ Р ИСО 9241-11-2010 «Эргономика взаимодействия человек-система. Часть 11. Руководство по юзабилити», юзабилити определяется как «свойство системы, продукции или услуги, при наличии которого установленный пользователь может применить продукцию в определенных условиях использования для достижения установленных целей с необходимой результативностью, эффективностью и удовлетворенностью». Разберем эти три столпа:

• Результативность (Effectiveness): Степень, в которой пользователи достигают поставленных целей. Для «Расходника» это означает, что автовладелец легко и безошибочно может ввести данные о замене масла и получить своевременное напоминание.
• Эффективность (Efficiency): Соотношение между достигнутой результативностью и затраченными ресурсами (временем, умственными усилиями). Чем быстрее и с меньшими усилиями пользователь выполняет задачу, тем выше эффективность.
• Удовлетворенность (Satisfaction): Субъективное восприятие пользователем комфорта, удобства и приятности использования. Если приложение не вызывает раздражения, работает предсказуемо и выглядит приятно, пользователь будет удовлетворен.

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

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

Принципы человеко-ориентированного дизайна (HCD)

Фундамент для создания по-настоящему удобных интерфейсов заложен в принципах человеко-ориентированного дизайна (Human-Centered Design, HCD), которые учитывают особенности человеческого восприятия и принятия решений. Среди них выделяются как эмпирически выведенные «законы» UX, так и принципы, сформулированные классиками HCI.

Закон Фикса (Fitts’ Law) гласит: время, необходимое человеку, чтобы попасть в цель (например, кнопка в интерфейсе), прямо пропорционально расстоянию до этой цели и обратно пропорционально её размеру. Математически это выражается формулой:

T = a + b ⋅ log2(2D/W)

где:

• Т — среднее время для завершения движения;
• а — начальное время/перехват, отражающий задержку реакции устройства;
• b — наклон, или коэффициент скорости устройства;
• D — расстояние от начальной точки до центра цели;
• W — ширина цели (размер), измеряемая вдоль оси движения.

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

Закон Хика (Hick’s Law) описывает взаимосвязь между количеством доступных вариантов выбора и временем, необходимым для принятия решения: время, необходимое для принятия решения, увеличивается логарифмически с ростом количества и сложности имеющихся вариантов. Формула закона Хика:

T = b ⋅ log2(n + 1)

где:

• Т — среднее время реакции;
• b — эмпирическая константа, зависящая от когнитивных способностей человека;
• n — количество вариантов выбора.

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

Принципы Дона Нормана: Дон Норман, один из пионеров HCI, в своей книге «Дизайн привычных вещей» сформулировал ряд ключевых принципов человеко-ориентированного дизайна:

• Возможность (Affordance): Свойство объекта, явно указывающее на то, как его можно использовать. Например, кнопка «выглядит» так, будто на неё можно нажать. В «Расходнике» элементы управления должны быть очевидны: кнопка «Сохранить» должна быть похожа на кнопку, а не на текстовое поле.
• Означающее (Signifiers): Дополнительные подсказки, которые явно указывают на наличие возможности и способ её использования. Текстовая подпись под иконкой или стрелка, указывающая на кликабельный элемент, являются означающими.
• Обратная связь (Feedback): Система должна всегда информировать пользователя о том, что происходит, подтверждая успешность действия или указывая на ошибку. Например, после сохранения записи о замене расходника, приложение должно вывести сообщение «Данные успешно сохранены».
• Концептуальные модели: Упрощенные объяснения того, как работает система. Пользователь формирует свою ментальную модель приложения. «Расходник» должен быть спроектирован так, чтобы его логика соответствовала интуитивным представлениям пользователя о ведении журнала обслуживания автомобиля.
• Наглядность (Discoverability): Все функции приложения должны быть легко обнаруживаемы. Пользователь не должен искать, как добавить новую запись или просмотреть историю.
• Проекции (Mapping): Соответствие между элементами управления и их действиями. Например, ползунок громкости на реальном устройстве связан с уровнем звука. В «Расходнике» элементы, управляющие датой, должны выглядеть как календарь.
• Ограничения (Constraints): Использование ограничений для предотвращения ошибок и упрощения выбора. Например, если в поле «Пробег» ожидается число, система не должна позволять вводить буквы.

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

Эвристики юзабилити Якоба Нильсена

В дополнение к фундаментальным принципам Нормана, 10 эвристик юзабилити Якоба Нильсена (Nielsen’s 10 Usability Heuristics) служат практическим набором правил для оценки и проектирования пользовательских интерфейсов. Они являются мощным инструментом для выявления потенциальных проблем и обеспечения интуитивности. Для приложения «Расходник», предназначенного для не-IT пользователей, особенно важны следующие эвристики:

1. Видимость состояния системы (Visibility of system status): Система всегда должна информировать пользователя о том, что происходит, через соответствующую обратную связь в разумные сроки.
   • Применение: При добавлении или сохранении данных «Расходник» должен показывать индикатор загрузки, а после завершения операции – сообщение об успешном выполнении. Если расчеты напоминаний происходят в фоне, пользователь должен об этом знать.
2. Соответствие между системой и реальным миром (Match between system and the real world): Система должна говорить на языке пользователя, используя знакомые слова, фразы и концепции, а не системно-ориентированную терминологию. Информация должна отображаться в естественном и логическом порядке.
   • Применение: Вместо абстрактных терминов вроде «CRUD-операция» или «ID записи» в «Расходнике» будут использоваться «Добавить расходник», «Редактировать историю», «Номер по каталогу». Иконки, отображающие автомобиль, гаечный ключ или календарь, должны быть метафоричными и легко узнаваемыми.
3. Контроль и свобода пользователя (User control and freedom): Пользователи часто выполняют действия по ошибке. Им необходим «аварийный выход» из нежелательного состояния без необходимости проходить через серию диалогов. Поддержка отмены и повтора действий (Undo/Redo).
   • Применение: В «Расходнике» должна быть реализована возможность отмены последнего действия (например, удаления записи), а также подтверждение перед выполнением необратимых операций (например, «Вы уверены, что хотите удалить эту запись?»).
4. Последовательность и стандарты (Consistency and standards): Пользователи не должны задумываться, означают ли разные слова, ситуации или действия одно и то же. Соблюдать платформенные конвенции.
   • Применение: Все кнопки «Сохранить» должны выглядеть одинаково и находиться в предсказуемом месте. Дата всегда должна быть в одном формате (например, ДД.ММ.ГГГГ), а цвета для обозначения напоминаний (например, красный для просроченных, желтый для приближающихся) должны быть унифицированы.
5. Предотвращение ошибок (Error prevention): Еще лучше, чем хорошие сообщения об ошибках, является продуманный дизайн, который предотвращает возникновение проблем в первую очередь.
   • Применение: Использование масок ввода для полей (например, для VIN-кода), автоматическая подстановка единиц измерения (км, дни), а также предварительная валидация данных (например, невозможность ввести отрицательный пробег).
6. Распознавание важнее запоминания (Recognition rather than recall): Сделать объекты, действия и опции видимыми. Пользователь не должен запоминать информацию из одной части диалога, чтобы использовать её в другой.
   • Применение: Вместо того чтобы просить пользователя запомнить номер детали для поиска, «Расходник» должен предлагать список уже использованных деталей или автозаполнение. Важные данные, такие как срок следующей замены, должны быть всегда на виду, а не скрыты в подменю.
7. Гибкость и эффективность использования (Flexibility and efficiency of use): Акселераторы (невидимые для неопытных пользователей) могут ускорить взаимодействие для опытных пользователей.
   • Применение: Хотя основной акцент делается на простоте, возможно, для продвинутых пользователей можно предусмотреть горячие клавиши для частых операций (Ctrl+S для сохранения).
8. Эстетика и минималистичный дизайн (Aesthetic and minimalist design): Диалоги не должны содержать нерелевантную или редко используемую информацию. Каждая дополнительная единица информации конкурирует с релевантной и снижает её относительную видимость.
   • Применение: Интерфейс «Расходника» должен быть чистым, без избыточных декоративных элементов. Важная информация (дата следующей замены, текущий пробег) должна быть выделена и легко читаема, а второстепенная – доступна по запросу или скрыта в менее заметных блоках.
9. Помощь пользователям в распознавании, диагностике и исправлении ошибок (Help users recognize, diagnose, and recover from errors): Сообщения об ошибках должны быть выражены простым языком (без кодов ошибок), точно указывать на проблему и конструктивно предлагать решение.
   • Применение: Вместо «Ошибка 0x0000000A» должно быть «Поле ‘Пробег’ не может быть пустым. Пожалуйста, введите текущий пробег автомобиля».
10. Справка и документация (Help and documentation): Даже если система может быть использована без документации, может потребоваться предоставление помощи. Такая помощь должна быть легкодоступной, сосредоточенной на задаче пользователя, содержать конкретные шаги и не быть слишком объемной.
    • Применение: В «Расходнике» должна быть встроена контекстная справка, а также полное руководство пользователя, написанное простым языком.

Особый акцент на Эвристиках №2 (Соответствие реальному миру) и №6 (Распознавание важнее запоминания) позволит создать интерфейс, который будет интуитивно понятен и легок в освоении для нашей целевой аудитории — автовладельцев без специфических IT-навыков. Разве не это является ключевым требованием к продукту, который призван упростить жизнь, а не усложнить её?

Глава 2. Методология проектирования и анализ предметной области

Разработка любого программного обеспечения, а тем более его интерфейса, требует систематизированного подхода. Методология человеко-ориентированного проектирования (Human-Centered Design, HCD) предоставляет именно такой каркас, гарантируя, что конечный продукт будет максимально соответствовать потребностям и ожиданиям пользователя. В нашем случае мы будем строго следовать принципам, изложенным в национальных стандартах, чтобы обеспечить академическую и инженерную корректность проекта.

Итеративный процесс человеко-ориентированного проектирования

ГОСТ Р ИСО 9241-210-2016 «Эргономика взаимодействия человек-система. Часть 210. Человеко-ориентированное проектирование интерактивных систем» является ключевым нормативным документом, определяющим методологию HCD. Этот стандарт подчеркивает, что процесс проектирования должен быть итеративным, то есть состоящим из повторяющихся циклов, где каждый последующий цикл улучшает результат предыдущего. Такой подход позволяет своевременно выявлять и исправлять ошибки, адаптироваться к изменяющимся требованиям и постоянно совершенствовать пользовательский опыт.

ГОСТ Р ИСО 9241-210-2016 выделяет четыре основных итеративных вида деятельности, которые лежат в основе нашей проектной части:

1. Понимание и определение контекста использования (Understand and specify the context of use): На этом этапе происходит глубокое погружение в среду, в которой будет функционировать приложение. Кто будет пользоваться «Расходником»? Какие задачи они будут решать? На каком оборудовании? В каких условиях? Этот вид деятельности включает анализ пользователей, их целей, окружения (например, настольный ПК).
2. Определение пользовательских требований (Specify the user requirements): После понимания контекста, необходимо четко сформулировать, что пользователи ожидают от системы. Какие функции им нужны? Какие данные необходимо вводить и получать? Требования должны быть измеримыми и проверяемыми.
3. Разработка проектных решений (Produce design solutions): На основе определенных требований создаются концептуальные и детальные проектные решения. Это включает разработку информационной архитектуры, схем взаимодействия (User Flows), эскизов (Wireframes) и интерактивных прототипов.
4. Оценка проектных решений (Evaluate the design against requirements): Разработанные решения тестируются на соответствие пользовательским требованиям. Это может быть как экспертная оценка (например, с использованием эвристик Нильсена), так и тестирование с реальными пользователями. Полученная обратная связь используется для корректировки и улучшения проекта на следующих итерациях.

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

Анализ целевой аудитории и контекста использования

Первым и одним из важнейших шагов в соответствии с ГОСТ Р ИСО 9241-210-2016 является глубокое понимание нашей целевой аудитории и контекста, в котором будет использоваться приложение «Расходник».

Целевая аудитория: Автовладельцы, активно использующие свои транспортные средства и заинтересованные в поддержании их технического состояния.

• Особенности:
  • Низкая ИТ-грамотность: Большинство пользователей не являются IT-специалистами. Они могут быть знакомы с базовыми офисными приложениями или мобильными мессенджерами, но сложные интерфейсы или специфическая компьютерная терминология могут вызвать у них затруднения и отторжение.
  • Высокая важность надежности данных: Информация о регламентах замены и истории обслуживания автомобиля критически важна. Ошибка в дате или пробеге может привести к несвоевременному обслуживанию, что чревато поломками и финансовыми затратами.
  • Ограниченное время: Пользователи не готовы тратить много времени на освоение программы или сложные рутинные операции. Приложение должно быть максимально быстрым и интуитивным.
  • Мотивация: Желание продлить срок службы автомобиля, сэкономить на ремонте, вести упорядоченный учет.

Контекст использования: Локальное настольное приложение.

• Оборудование: Персональные компьютеры (ПК) или ноутбуки под управлением популярных операционных систем (Windows, macOS).
• Среда: Домашняя или офисная обстановка, где пользователь имеет возможность спокойно работать с приложением.
• Ключевые сценарии использования (User Flow):
  1. Добавление нового автомобиля: Пользователь запускает приложение, вводит данные о своем автомобиле (марка, модель, VIN, текущий пробег).
  2. Добавление нового расходного материала/работы: Пользователь добавляет информацию о конкретной запчасти (название, номер по каталогу, цена) или виде работ (например, «Замена масла»).
  3. Создание регламента замены: Для каждой запчасти/работы пользователь устанавливает периодичность замены (по пробегу, по времени или и то, и другое).
  4. Запись о выполненном обслуживании: После замены пользователь вносит запись в историю (дата, пробег, использованные запчасти, стоимость).
  5. Просмотр напоминаний: Пользователь видит на главном экране список предстоящих или просроченных замен.
  6. Просмотр истории обслуживания: Пользователь просматривает полную историю всех выполненных работ по автомобилю.
  7. Редактирование/удаление записей: Возможность корректировать или удалять ошибочные данные.

Понимание этих аспектов ляжет в основу разработки требований и проектных решений, обеспечивая, что «Расходник» будет по-настоящему ориентирован на пользователя.

Анализ конкурентных решений и формирование требований

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

Анализ существующих решений:

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

1. Мобильные приложения для учета авто: Многочисленные приложения для смартфонов (например, Drivvo, Car Expenses) предлагают учет топлива, расходов, сервисного обслуживания.
   • Сильные стороны: Мобильность, удобство ввода данных «на ходу».
   • Слабые стороны: Фокус на мобильных сценариях, часто избыточный функционал (топливо, штрафы), требующий подписки. Не всегда удобны для детального просмотра и планирования на большом экране.
2. Программы для СТО: Более сложные CRM-системы для автосервисов (например, АвтоДилер, АльфаАвто).
   • Сильные стороны: Детальный учет, возможность ведения складского учета, привязка к каталогам.
   • Слабые стороны: Слишком сложны для индивидуального пользователя, ориентированы на бизнес-процессы, а не на личный учет, дорогостоящие.
3. Таблицы Excel/Google Sheets: Многие автовладельцы ведут учет вручную в электронных таблицах.
   • Сильные стороны: Гибкость, бесплатность.
   • Слабые стороны: Отсутствие автоматических напоминаний, сложность в поддержании целостности данных, требует ручного расчета сроков, подверженность ошибкам.

Выявленные слабые места конкурентов и «слепые зоны»:

• Избыточная сложность: Многие решения перегружены функционалом, который не нужен обычному автовладельцу, и содержат специфическую терминологию.
• Ориентация на профессионалов: Программы для СТО совершенно не подходят для частного использования из-за своей комплексности.
• Отсутствие акцента на настольных приложениях: В тренде последних лет – мобильные приложения. Качественные, интуитивные настольные решения для личного учета встречаются реже.
• Недостаточная адаптация к не-IT пользователю: Часто интерфейсы требуют определенных навыков работы с компьютером, что снижает юзабилити.
• Разрыв между UX и инженерной проработкой: Во многих проектах по интерфейсам отсутствует детальная проработка архитектуры данных, что критично для стабильности и масштабируемости.

Уникальные требования к ПП «Расходник» на основе анализа:

1. Максимальная простота и интуитивность: Интерфейс должен быть понятен «с первого взгляда», без необходимости изучать сложные инструкции.
2. Фокус на базовом функционале: Учет расходников, история обслуживания, напоминания – ничего лишнего.
3. Акцент на настольное приложение: Использование преимуществ большого экрана для наглядного представления информации и удобства ввода.
4. Визуальная ясность и обратная связь: Четкие индикаторы состояния, понятные сообщения об ошибках.
5. Надежная и продуманная архитектура данных: Гарантия целостности и сохранности информации, возможность легкого доступа и анализа.
6. Эргономика для не-IT пользователя: Использование знакомых метафор, минимизация когнитивной нагрузки, отсутствие специализированного жаргона.
7. Детальное руководство пользователя: Полная документация, написанная простым и доступным языком.

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

Глава 3. Проектирование архитектуры и интерфейса настольного приложения «Расходник» (Закрытие слепых зон)

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

Проектирование информационной архитектуры и реляционной модели данных

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

Для реализации функционала учета регламентов замены и истории обслуживания необходимо спроектировать связи между следующими основными сущностями (таблицами):

1. Автомобиль (Car): Основная сущность, представляющая конкретный автомобиль.
   • ID_Автомобиля (PRIMARY KEY, INTEGER)
   • Марка (TEXT)
   • Модель (TEXT)
   • VIN (TEXT, UNIQUE) – Уникальный идентификатор автомобиля.
   • Текущий_Пробег (INTEGER)
   • Дата_Покупки (DATE)
   • ID_Владельца (FOREIGN KEY к сущности Владелец)
2. Владелец (Owner): Сущность, описывающая владельца автомобиля. В контексте локального приложения может быть один владелец, но наличие этой сущности позволяет в будущем расширить функционал для нескольких автомобилей одного пользователя.
   • ID_Владельца (PRIMARY KEY, INTEGER)
   • ФИО (TEXT)
   • Контактный_Телефон (TEXT)
   • Email (TEXT)
3. Расходный_Материал_Запчасть (Consumable_Part): Детальная информация о каждом расходнике или запчасти.
   • ID_Расходника (PRIMARY KEY, INTEGER)
   • Название (TEXT)
   • Номер_По_Каталогу (TEXT, UNIQUE)
   • Единица_Измерения (TEXT, например, «шт.», «л»)
   • Примерная_Стоимость (REAL)
4. Регламент_Замены_Обслуживания (Maintenance_Regulation): Сущность, определяющая правила и периодичность обслуживания.
   • ID_Регламента (PRIMARY KEY, INTEGER)
   • Вид_Работы (TEXT, например, «Замена масла», «Замена воздушного фильтра»)
   • ID_Расходника (FOREIGN KEY к сущности Расходный_Материал_Запчасть, может быть NULL, если работа не связана с конкретным расходником, например, «Диагностика»)
   • Периодичность_Пробег (INTEGER, в км)
   • Периодичность_Время (INTEGER, в месяцах)
   • Критичность (TEXT, например, «Высокая», «Средняя»)
5. Запись_Обслуживания_История (Service_Record): Фиксация каждого выполненного сервисного действия.
   • ID_Записи (PRIMARY KEY, INTEGER)
   • ID_Автомобиля (FOREIGN KEY к сущности Автомобиль)
   • Дата_Обслуживания (DATE)
   • Пробег_На_Момент_Обслуживания (INTEGER)
   • ID_Регламента (FOREIGN KEY к сущности Регламент_Замены_Обслуживания)
   • Использованный_Расходник_ID (FOREIGN KEY к сущности Расходный_Материал_Запчасть, если использовался конкретный расходник)
   • Стоимость_Работы (REAL)
   • Примечания (TEXT)

ER-диаграмма (Сущность-Связь):

erDiagram
    OWNER {
        INTEGER ID_Владельца PK
        TEXT ФИО
        TEXT Контактный_Телефон
        TEXT Email
    }

    CAR {
        INTEGER ID_Автомобиля PK
        TEXT Марка
        TEXT Модель
        TEXT VIN UK
        INTEGER Текущий_Пробег
        DATE Дата_Покупки
        INTEGER ID_Владельца FK
    }

    CONSUMABLE_PART {
        INTEGER ID_Расходника PK
        TEXT Название
        TEXT Номер_По_Каталогу UK
        TEXT Единица_Измерения
        REAL Примерная_Стоимость
    }

    MAINTENANCE_REGULATION {
        INTEGER ID_Регламента PK
        TEXT Вид_Работы
        INTEGER ID_Расходника FK NULL
        INTEGER Периодичность_Пробег
        INTEGER Периодичность_Время
        TEXT Критичность
    }

    SERVICE_RECORD {
        INTEGER ID_Записи PK
        INTEGER ID_Автомобиля FK
        DATE Дата_Обслуживания
        INTEGER Пробег_На_Момент_Обслуживания
        INTEGER ID_Регламента FK
        INTEGER Использованный_Расходник_ID FK NULL
        REAL Стоимость_Работы
        TEXT Примечания
    }

    OWNER ||--o{ CAR : "владеет"
    CAR ||--o{ SERVICE_RECORD : "имеет_историю"
    MAINTENANCE_REGULATION ||--o{ SERVICE_RECORD : "применяется_в"
    CONSUMABLE_PART ||--o{ MAINTENANCE_REGULATION : "используется_для"
    CONSUMABLE_PART ||--o{ SERVICE_RECORD : "использован_в"

Эта реляционная модель данных лежит в основе логики приложения. Она позволяет эффективно:

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

Продуманная структура БД не только обеспечивает функциональность, но и позволяет представить информацию в интерфейсе логично и интуитивно, что напрямую влияет на юзабилити.

Разработка логики взаимодействия и прототипов интерфейса

После того как фундамент данных заложен, можно перейти к «строительству» самого интерфейса. Этот процесс начинается с концептуального проектирования, где проверяется логика пользовательских сценариев (User Flow) и информационная архитектура.

Процесс концептуального проектирования:

1. Определение User Flow: На основе анализа целевой аудитории и контекста использования (Глава 2) были определены ключевые сценарии. Например, «Добавление новой записи об обслуживании» будет включать:
   • Нажатие кнопки «Добавить запись».
   • Выбор автомобиля (если их несколько).
   • Выбор вида работы/расходника.
   • Ввод даты и пробега.
   • Ввод стоимости и примечаний.
   • Сохранение.

   Каждый такой поток должен быть максимально простым и линейным, следуя закону Хика (минимизация выбора) и принципу «Распознавание важнее запоминания» Нильсена.

2. Создание информационной архитектуры: Это организация и структурирование информации таким образом, чтобы пользователи могли легко её найти и понять. Для «Расходника» это означает логичное группирование разделов: «Мои автомобили», «Напоминания», «История обслуживания», «Справочники расходников».
3. Разработка «проволочных диаграмм» (Wireframes): Это низкодетализированные, схематичные изображения основных экранов интерфейса, фокусирующиеся на расположении элементов, структуре информации и логике взаимодействия, а не на визуальном оформлении. Wireframes позволяют быстро обсудить итерационные решения по юзабилити и дизайну, не отвлекаясь на цвета и шрифты.

Примеры Wireframes ключевых экранов:

• Главный экран с напоминаниями:
  • В верхней части – навигация (Мои автомобили, Напоминания, История, Справочники).
  • Центральная часть – список предстоящих/просроченных напоминаний.
    • Каждое напоминание: Иконка (масло, фильтр), Название работы, Автомобиль, Дата следующей замены / Пробег, Статус (СКОРО, ПРОСРОЧЕНО).
  • В нижней части – кнопки быстрых действий: «Добавить запись», «Просмотреть все напоминания».
  • Соответствие Эвристике №1 Нильсена (Видимость статуса системы): Пользователь сразу видит текущее состояние дел.
• Экран «Добавление записи об обслуживании»:
  • Заголовок: «Новая запись обслуживания для [Имя Автомобиля]».
  • Поля ввода: Дата (с календарём), Пробег (числовой ввод), Вид работы (выпадающий список или поиск), Расходник (опционально, с поиском), Стоимость, Примечания.
  • Кнопки: «Сохранить», «Отмена».
  • Соответствие Эвристике №6 Нильсена (Распознавание важнее запоминания): Все поля четко обозначены, используются визуальные подсказки (календарь).
• Экран «История обслуживания»:
  • Фильтры: по дате, по виду работ, по расходнику.
  • Таблица с записями: Дата, Пробег, Вид работы, Расходник, Стоимость, Примечания.
  • Кнопки: «Редактировать», «Удалить» для каждой записи.
  • Соответствие Эвристике №3 Нильсена (Контроль и свобода пользователя): Пользователь может фильтровать, редактировать или удалять записи.

Ключевым результатом этого этапа является спецификация требований пользователя (User Requirements Specification), которая описывает функциональные и нефункциональные требования к си��теме с точки зрения пользователя, а также структура интерфейса, отраженная в Wireframes.

Обоснование UI-решений с точки зрения минимизации когнитивной нагрузки

Проектирование интуитивного интерфейса для не-IT пользователя требует особого внимания к деталям, направленным на минимизацию когнитивной нагрузки. Каждый элемент интерфейса должен быть осмыслен и обоснован, чтобы пользователь мог сосредоточиться на своих задачах, а не на понимании работы программы. Здесь мы опираемся на ГОСТ Р ИСО 9241-161—2016, который предоставляет руководство по элементам графического пользовательского интерфейса, а также на эвристики Нильсена.

Выбор конкретных UI-паттернов и визуальных решений:

1. Четкая обратная связь (Nielsen’s Heuristic №1: Visibility of system status):
   • Решение: Использование всплывающих уведомлений (Toast messages) для подтверждения сохранения данных («Запись успешно сохранена») или предупреждений. Индикаторы загрузки (Spinners) при выполнении длительных операций (например, при первой загрузке всех данных).
   • Обоснование: Пользователь всегда должен понимать, что его действие было принято системой и что происходит в данный момент. Это снижает тревожность и дает чувство контроля.
2. Иконки-метафоры и «язык реального мира» (Nielsen’s Heuristic №2: Match between system and the real world):
   • Решение: Использование понятных иконок: гаечный ключ для обслуживания, канистра для масла, календарь для даты. Текстовые подписи к кнопкам и элементам управления должны быть максимально простыми и понятными (например, «Добавить авто», а не «Создать сущность Автомобиль»).
   • Обоснование: Соответствие реальному миру позволяет пользователю использовать свои повседневные знания, снижая необходимость в обучении и запоминании. ГОСТ Р ИСО 9241-161—2016 также акцентирует внимание на выборе понятных иконок и пиктограмм, избегающих двусмысленности.
3. Упрощенная навигация (Nielsen’s Heuristic №8: Aesthetic and minimalist design; Hick’s Law):
   • Решение: Использование горизонтального или вертикального меню с ограниченным числом основных разделов (Мои автомобили, Напоминания, История, Справочники, Настройки). Избегание глубоких вложенностей.
   • Обоснование: Минималистичный дизайн и сокращение числа вариантов выбора на каждом уровне навигации (Закон Хика) уменьшают когнитивную нагрузку и делают приложение более «читаемым». Ненужная информация не отвлекает пользователя.
4. Контроль и свобода пользователя (Nielsen’s Heuristic №3: User control and freedom):
   • Решение: Реализация функций «Отмена» (Undo) и «Повтор» (Redo) для ключевых операций. Подтверждение необратимых действий (удаление). Возможность легко редактировать уже введенные данные.
   • Обоснование: Чувство контроля над системой дает пользователю уверенность и снижает страх совершить ошибку, что особенно важно для не-IT аудитории.
5. Предотвращение ошибок и помощь в их исправлении (Nielsen’s Heuristic №9: Help users recognize, diagnose, and recover from errors):
   • Решение: Маски ввода для полей (VIN, дата). Валидация данных в реальном времени (например, красная рамка вокруг поля с некорректным значением). Ясные сообщения об ошибках, указывающие на проблему и предлагающие решение.
   • Обоснование: Предотвращение ошибок лучше, чем их исправление. Если ошибка все же произошла, понятное объяснение помогает пользователю быстро её устранить, не прибегая к справке.
6. Доступность и читаемость:
   • Решение: Использование контрастных цветов для текста и фона. Достаточно крупный размер шрифта. Четкая иерархия заголовков и текстовых блоков.
   • Обоснование: Соответствие ГОСТ Р ИСО 9241-161—2016 в части требований к визуальному отображению элементов. Улучшает восприятие информации, особенно для пользователей с возможными ограничениями зрения.
7. Единообразие (Nielsen’s Heuristic №4: Consistency and standards):
   • Решение: Все интерактивные элементы (кнопки, поля ввода, ссылки) должны иметь единый стиль и поведение на протяжении всего приложения. Единая цветовая палитра и типографика.
   • Обоснование: Предсказуемость интерфейса снижает когнитивную нагрузку, так как пользователю не нужно каждый раз перестраивать свою ментальную модель взаимодействия.

Применение этих тщательно подобранных UI-решений, обоснованных как классическими принципами HCI, так и национальными стандартами, позволит создать интерфейс приложения «Расходник», который будет не только функционален, но и максимально интуитивен, снижая барьер входа для не-IT пользователя и обеспечивая положительный пользовательский опыт.

Заключительные положения и документация

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

Техническое задание (ТЗ) на реализацию ПП «Расходник»

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

Краткое описание функциональных требований:

• Управление автомобилями: Добавление, редактирование, удаление информации об автомобилях (марка, модель, VIN, текущий пробег, дата покупки).
• Управление расходными материалами/работами: Ведение справочника расходников (название, номер по каталогу, стоимость) и видов работ (например, «Замена масла», «Замена колодок»).
• Установка регламентов обслуживания: Настройка периодичности замены/обслуживания для каждого расходника/работы по пробегу (км) и/или по времени (месяцы).
• Ведение истории обслуживания: Запись о выполненных работах (дата, пробег, вид работы, использованные расходники, стоимость, примечания).
• Система напоминаний: Автоматическое формирование списка предстоящих и просроченных регламентных работ на основе текущего пробега и даты последнего обслуживания.
• Поиск и фильтрация: Возможность поиска и фильтрации записей в истории обслуживания и справочниках.

Краткое описание нефункциональных требований:

• Требования к юзабилити: Приложение должно соответствовать принципам, изложенным в ГОСТ Р ИСО 9241-11-2010 (Результативность, Эффективность, Удовлетворенность), а также эвристикам Нильсена (например, простота освоения, предотвращение ошибок, четкая обратная связь). Интерфейс должен быть интуитивно понятным для не-IT пользователя.
• Требования к производительности: Быстрый отклик на действия пользователя, оперативная загрузка данных.
• Требования к надежности: Обеспечение целостности и сохранности данных (например, механизм резервного копирования), устойчивость к ошибкам ввода.
• Требования к безопасности: Защита данных пользователя от несанкционированного доступа (в случае локального приложения это может быть пароль на вход).
• Требования к совместимости: Поддержка актуальных версий операционных систем Windows и/или macOS.
• Требования к эргономике: Соответствие ГОСТ Р ИСО 9241-161—2016 в части оформления элементов графического пользовательского интерфейса.

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

Структура и содержание «Руководства пользователя»

Руководство пользователя — это не просто дополнительный документ, а критически важная составляющая программного продукта, особенно когда целевая аудитория не обладает специальными IT-знаниями. Соответствуя Эвристике №10 Нильсена («Справка и документация»), руководство должно быть легкодоступным, сосредоточенным на задачах пользователя, содержать конкретные шаги и быть не слишком объемным. Для «Расходника» оно должно быть написано максимально простым и понятным языком, снимая возможную тревогу пользователя перед новой программой.

Предлагаемая структура Руководства пользователя:

1. Введение:
   • Приветствие и краткое описание назначения приложения «Расходник».
   • Кому предназначено это руководство.
   • Основные преимущества использования программы.
2. Системные требования:
   • Минимальные требования к операционной системе и оборудованию.
3. Установка и первый запуск:
   • Пошаговая инструкция по установке программы.
   • Действия при первом запуске (например, создание первого автомобиля).
4. Обзор интерфейса:
   • Краткое описание основных элементов главного окна (меню, панель навигации, рабочая область).
   • Объяснение назначения каждого раздела (Мои автомобили, Напоминания, История, Справочники).
   • Общие принципы работы с элементами управления (кнопки, поля ввода, выпадающие списки).
5. Работа с приложением (Ключевые сценарии):
   • Раздел 5.1. Мои автомобили:
     • Как добавить новый автомобиль (пошаговая инструкция со скриншотами).
     • Как редактировать/удалять данные автомобиля.
   • Раздел 5.2. Справочники:
     • Как добавить/редактировать расходные материалы.
     • Как добавить/редактировать виды работ.
     • Как установить регламент замены для конкретного расходника/работы.
   • Раздел 5.3. История обслуживания:
     • Как добавить новую запись об обслуживании (пошагово, с примерами).
     • Как просмотреть и отфильтровать историю.
     • Как редактировать/удалять записи.
   • Раздел 5.4. Напоминания:
     • Как работает система напоминаний.
     • Как настроить оповещения.
     • Как отметить напоминание как выполненное.
6. Часто задаваемые вопросы (FAQ):
   • Ответы на типовые вопросы и проблемы, которые могут возникнуть у пользователя.
7. Устранение типовых ошибок:
   • Как действовать, если программа не запускается, данные не сохраняются и т.д. (без использования технических терминов).
8. Контакты службы поддержки (если применимо).

Особенности содержания для не-IT пользователя:

• Визуализация: Максимальное использование скриншотов с выделением ключевых элементов.
• Простой язык: Избегание жаргона, использование повседневных слов и фраз.
• Ориентация на действие: Каждая инструкция должна быть представлена как пошаговое руководство («Нажмите здесь», «Введите это»).
• Снятие тревоги: Подчеркивание того, что ошибки можно исправить, и программа создана для удобства пользователя.
• Контекст: Объяснение, почему та или иная функция нужна и как она помогает автовладельцу.

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

Заключение

Настоящий курсовой проект успешно продемонстрировал комплексный, академически и инженерно обоснованный подход к проектированию Человеко-Машинного Интерфейса (ЧМИ) настольного приложения «Расходник». Цель работы – разработка проекта интуитивно-понятного ЧМИ для не-IT пользователя – была полностью достигнута за счет систематического применения теоретических принципов HCI, законов UX, эвристик юзабилити Якоба Нильсена и, что критически важно, строгого следования национальным стандартам серии ГОСТ Р ИСО 9241.

В ходе работы были выполнены все поставленные задачи:

1. Исследованы и систематизированы теоретические основы HCI, включая формальные определения ЧМИ, юзабилити, эргономичности согласно ГОСТ Р ИСО 9241-11-2010, а также принципы Дона Нормана и законы UX (Фикса, Хика).
2. Проведена детальная проработка методологии проектирования на основе итеративного процесса человеко-ориентированного проектирования, закрепленного в ГОСТ Р ИСО 9241-210-2016, что позволило структурировать весь ход работы от анализа контекста до оценки решений.
3. Осуществлен глубокий анализ целевой аудитории – автовладельцев без специфических IT-навыков – и контекста использования, что стало основой для формирования требований к интуитивности и простоте интерфейса.
4. Разработана исчерпывающая реляционная модель данных (ER-диаграмма) для приложения «Расходник», что стало ключевым аспектом закрытия «слепой зоны» конкурентов и обеспечило прочную инженерную основу для логики отображения данных в интерфейсе.
5. Спроектированы ключевые экраны интерфейса в виде Wireframes, а также обоснованы конкретные UI-решения с точки зрения минимизации когнитивной нагрузки. При этом особое внимание было уделено эвристикам Нильсена (№1, №2, №3, №6, №8) и рекомендациям ГОСТ Р ИСО 9241-161—2016 для элементов графического интерфейса.
6. Сформирована детальная структура и содержание «Руководства пользователя», адаптированного для не-IT аудитории, что является прямым выполнением Эвристики №10 Нильсена и способствует легкому освоению программы.

Таким образом, разработанный проект ЧМИ полностью соответствует поставленным целям, стандартам ГОСТ Р ИСО 9241 и принципам интуитивного проектирования. Он представляет собой не просто набор рекомендаций, а целостное, технически обоснованное и методологически выверенное решение, готовое стать основой для дальнейшей реализации настольного приложения «Расходник».

Перспективы дальнейшего развития:

• Реализация прототипа: Создание интерактивного прототипа для проведения пользовательского тестирования и сбора обратной связи, что является следующим итеративным шагом HCD.
• Расширение функционала: Интеграция с онлайн-каталогами запчастей для автоматического заполнения информации о расходниках.
• Мобильная версия: Разработка мобильного приложения-компаньона для быстрого ввода данных и просмотра напоминаний «на ходу».
• Облачное хранение данных: Реализация синхронизации данных между устройствами пользователя.
• Поддержка нескольких автомобилей: Расширение функционала для удобного управления несколькими транспортными средствами.

Данный проект подтверждает, что тщательное планирование, основанное на проверенных методологиях и стандартах, является залогом создания успешных и по-настоящему человеко-ориентированных программных продуктов.

Список использованной литературы

1. М.П. Силич Учебное методическое пособие «ИНТЕРФЕЙСЫ АСОИУ(интерактивные системы)». Томск, 2000. 37 с.
2. М.П. Силич Учебное пособие «ИНТЕРФЕЙСЫ АСОИУ(интерактивные системы)». Томск, 2000. 96 с.
3. П.В. Агуров «C#. Сборник рецептов». Санкт-Петербург: БВХ-Петербург, 2007. 432 с.
4. Стандарты — Юзабилити и человеко-машинное взаимодействие — Рэдлайн. URL: https://lred.ru/ (дата обращения: 07.10.2025).
5. Законы UX-дизайна: что делает пользователей счастливее, а продукт лучше — Habr. URL: https://habr.com/ (дата обращения: 07.10.2025).
6. Законы дизайна интерфейсов — Оди. О дизайне. URL: https://awdee.ru/ (дата обращения: 07.10.2025).
7. Введение в проектирование пользовательских интерфейсов — GitHub. URL: https://githubusercontent.com/ (дата обращения: 07.10.2025).
8. 7 принципов UX-дизайна Нормана. Человекоориентированный дизайн. URL: https://mindrepublic.ru/ (дата обращения: 07.10.2025).
9. Проектирование интерфейсов: основные принципы, этапы и ошибки при разработке. URL: https://yandex.ru/ (дата обращения: 07.10.2025).
10. Разработка базы данных по учету работы СТО (на примере «Автотехцентр — ЛПИ — филиал СФУ. URL: https://sfu-kras.ru/ (дата обращения: 07.10.2025).
11. ОСНОВЫ ПРОЕКТИРОВАНИЯ ИНТЕРФЕЙСОВ ПРОГРАММНЫХ СИСТЕМ — Пензенский государственный университет. URL: https://pnzgu.ru/ (дата обращения: 07.10.2025).
12. Спицина И.А., Аксенов К.А. Применение системного анализа при разработке пользовательского интерфейса информационных систем: учеб. пособие. 2-е изд., доп. Екатеринбург: Изд-во Урал. ун-та, 2024. URL: https://urfu.ru/ (дата обращения: 07.10.2025).
13. ГОСТ Р ИСО 9241-161— ЭРГОНОМИКА ВЗАИМОДЕЙСТВИЯ ЧЕЛОВЕК-СИСТЕМА Элементы: Настоящий стандарт предназначен для использования ответственными за выбор и реализацию визуальных элементов интерфейса пользователя в интерактивных системах и их анализ. URL: https://meganorm.ru/ (дата обращения: 07.10.2025).
14. ПРОЕКТИРОВАНИЕ ЧЕЛОВЕКО-МАШИННОГО ИНТЕРФЕЙСА — Научно-образовательный портал ТУСУР. URL: https://tusur.ru/ (дата обращения: 07.10.2025).
15. Проектирование пользовательского интерфейса: учебник — ЭБС Лань. URL: https://lanbook.com/ (дата обращения: 07.10.2025).
16. Эвристики Нильсена: 10 принципов юзабилити для дизайна интерфейсов — Skillbox. URL: https://skillbox.ru/ (дата обращения: 07.10.2025).
17. Эвристики Нильсена на примере реальных приложений / Хабр — Habr. URL: https://habr.com/ (дата обращения: 07.10.2025).
18. Готовая база данных Магазин автозапчастей. Часть 1. Таблицы — YouTube. URL: https://youtube.com/ (дата обращения: 07.10.2025).
19. ГОСТ Р ИСО 9241-210-2016 Эргономика взаимодействия человек-система. Часть 210. Человеко-ориентированное проектирование интерактивных систем. URL: https://docs.cntd.ru/ (дата обращения: 07.10.2025).
20. 10 эвристик Якоба Нильсена — школа дизайна и АКАДЕМИЯ ПРЕЗЕНТАЦИЙ BONNIE&SLIDE. URL: https://bonnieandslide.com/ (дата обращения: 07.10.2025).
21. Эвристики Нильсена: принципы для улучшения интерфейсов — Яндекс Практикум. URL: https://yandex.ru/ (дата обращения: 07.10.2025).