1. МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
2. Федеральное государственное автономное образовательное учреждение

value=3> высшего профессионального образования

УРАЛЬСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ

имени первого Президента России Б. Н. Ельцина

Математико-механический факультет

Кафедра информатики и процессов управления

РАЗРАБОТКА СРЕДСТВ ПОДДЕРЖКИ

ПРОЦЕССА ПРОЕКТИРОВАНИЯ ИНТЕРФЕЙСОВ

"Допущен к защите" ___________________ "__"____________2011 г.	Диссертация на степень магистра наук по направлению "Математика, компьютерные науки" студента гр. МГКН-2 Зуевой Анастасии Андреевны
	Научный руководитель Авербух Владимир Лазаревич к.т.н, доцент

Екатеринбург

2011

СОДЕРЖАНИЕ

ВВЕДЕНИЕ……………………………………………………………………

1. Подходы к описанию процесса проектирования
2. Определение схемы процесса……………………………………………
3. Решение поставленной задачи
1. Требования……………………………………………………...
2. Метафора………………………………………………..
3. Сценарии……………………………………………..
4. Реализация……………………………..

ЗАКЛЮЧЕНИЕ………………………………………………………………

ЛИТЕРАТУРА………………………………………………………………..

ПРИЛОЖЕНИЕ………………………………………………………………

ВВЕДЕНИЕ

Цифровые технологии прочно вошли в нашу жизнь и продолжают захватывать все больше различных областей. Число продуктов, содержащих в себе программный код, постоянно увеличивается. Программное обеспечение начинает играть ключевую роль в мировой экономике, все больше компаний зависят от программного обеспечения, используя его для самых разных задач. В повседневной жизни человек сталкивается с большим количеством цифровых продуктов, которые призваны улучшить и облегчить его деятельность. Множество необходимых операций уже переведено в цифровой вид и основано на программном коде. Программы определяют деятельность современного человека, со множеством вещей он взаимодействует посредством программ или при поддержке программ. Важность разработки программного обеспечения становится очевидной. Однако традиционные методы организации и управления в промышленности не подходят для процесса производства программного обеспечения, поскольку ориентированы на материальные вещи. Долгое время компании сталкивались с трудностями при создании программ, но постепенное накопление опыта привело к совершенствованию старых процессов и появлению новых, позволяющих эффективно организовать управление производством программного обеспечения. На начальных этапах развития области цифровые продукты задумывались и реализовывались исключительно программистами. Со временем в процесс включились профессиональные управленцы, помогавшие перевести благоприятные рыночные возможности на язык требований к продукту, тестирование программ оформилось в самостоятельную дисциплину, а с распространением графических пользовательских интерфейсов подключились графические дизайнеры, создававшие красивые визуальные элементы. Однако качество цифровых продуктов с точки зрения взаимодействия с пользователем оставляло желать лучшего. Причина кроется в том, что определением конечной формы и поведения программ занимались программисты, ориентированные на качественное и быстрое выполнение технической стороны. Естественно, что их представление о программе отличалось от мнений и ожиданий пользователей. Цели, мотивы и потребности конечного потребителя продукта — пользователей — не принимались в рассмотрение. Сложившаяся ситуация не могла не привлечь внимания, и постепенно стали формироваться различные дисциплины, связанные с проектированием и удобством использования продуктов, систем и услуг. Все эти дисциплины обычно объединяют под единым термином опыт взаимодействия (user experience, UX). Для цифровых продуктов в проектировании опыта взаимодействия сочетаются три пересекающиеся темы — форма, поведение и наполнение. Отличительной особенностью цифровых продуктов является именно сложное поведение, наличие большого количества вариантов использования. Поэтому принято выделять дисциплину проектирования взаимодействия (interaction design, IxD), под которой чаще всего понимают практику создания цифровых интерактивных решений, ориентированную именно на проектирование поведения. Помимо этого, однако, ставится вопрос о том, как поведение связано с формой и наполнением. Главная задача проектирования взаимодействия — спроектировать поведение и форму продукта таким образом, чтобы поддержать и упростить реализацию человеческого поведения. Ключевая роль во всем процессе отводится пользователям, их потребностям и ожиданиям, что позволяет достичь качественно нового уровня взаимодействия с программой. Хорошие результаты применения такого подхода привели к тому, что новая дисциплина заняла свое место в процессе создания программного обеспечения, предшествуя созданию кода и тестированию. Следует заметить, что кроме термина проектирование взаимодействия часто употребляется и термин проектирование пользовательских интерфейсов. Некоторые авторы склонны к тому, чтобы разделять эти понятия, понимая под проектированием интерфейсов исключительно разработку внешней формы, однако в рамках данной работы подобное разделение представляется несущественным, и они будут использоваться в качестве синонимов.

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

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

Рассмотрим некоторые из подходов первого уровня.

1. Дизайн, ориентированный на пользователей

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

2. Дизайн, ориентированный на задачи пользователей

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

3. Дизайн, ориентированный на деятельность пользователей

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

4. Дизайн, ориентированный на цели (мотивы) пользователей

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

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

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

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

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

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

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

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

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

1. Диаграммы процесса проектирования интерфейсов

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

2. Системы управления проектами

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

3. Бумага и ручка, доска с маркером, электронные таблицы и другие средства фиксации информации

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

Таким образом, предложенная нами концепция программного средства для поддержки процесса проектирования интерфейсов не имеет прямых аналогов.

ПОДХОДЫ К ОПИСАНИЮ ПРОЦЕССА ПРОЕКТИРОВАНИЯ

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

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

1) Процесс, ориентированный на задачи, Клейтон Льюис и Джон Риман

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

• Понять, кто будет использовать продукт и для чего

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

• Выбрать характерные задачи

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

• Скопировать идеи

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

• Сделать наброски дизайна

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

• Подумать о дизайне

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

• Разработать концепцию или прототип

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

• Протестировать на пользователях

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

• Повторить

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

• Создать продукт
• Осуществить сопровождение продукта

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

• Изменить продукт

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

2) Целеориентированный процесс проектирования Алана Купера

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

• Исследования

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

• Моделирование

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

• Выработка требований

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

• Определение общей инфраструктуры

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

• Детализация

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

• Сопровождение разработки

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

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

3) Процесс проектирования в гибкой разработке

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

• Определение концепции: создание структурных схем и макетов интерфейса низкой точности
• Прототипирование: разработка прототипа высокой точности
• Тестирование с клиентами (осуществление обратной связи)
• Тестирование с пользователями (юзабилити-тестирование)
• Возврат к началу цикла

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

4) Стандарт ISO 13407

Дизайн, ориентированный на пользователей — это подход к дизайну, который базируется на информации о людях, которые будут использовать продукт. Ориентация на пользователей сохраняется во время планирования, проектирования и разработки продукта. Существует международный стандарт, который является основой для многих методик дизайна, ориентированного на пользователей. Этот стандарт (ISO 13407: Human-centred design process) определяет общий процесс включения ориентированной на человека деятельности в жизненный цикл разработки, но не определяет точные методы. Процесс включает в себя следующие стадии:

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

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

• Оценить дизайн

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

Процесс повторяется до тех пор, пока не будут удовлетворены все поставленные требования.

ОПРЕДЕЛЕНИЕ СХЕМЫ ПРОЦЕССА

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

• Подготовка

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

• Разработка интерфейса

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

• Контроль

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

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

РЕШЕНИЕ ПОСТАВЛЕННОЙ ЗАДАЧИ

Требования

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

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

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

Метафора

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

1. Процесс проектирования в целом
2. Этапы процесса проектирования
3. Ключевые моменты этапа проектирования
4. Сопроводительные документы и результаты
5. Участники разработки интерфейса

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

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

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

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

Сценарии

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

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

1. Создание нового процесса

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

2. Работа с созданным процессом

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

3. Просмотр результатов работы

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

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

Сценарий 1. Создание нового процесса.

1. При входе пользователя в систему, ему предоставляется выбор — создать новый процесс или выбрать из уже имеющихся. Пользователь выбирает создание нового процесса.
2. Пользователь вводит название нового процесса. Создается пустой процесс с требуемым названием.
3. Пользователь производит наполнение процесса, добавляя к нему различные этапы.
4. Пользователь принимает решение сконструировать новый этап для текущего процесса.
5. Он выбирает тип этапа — подготовка, разработка или контроль. В зависимости от выбранного типа, происходит дальнейшая настройка этапа.
1. Пользователь выбирает тип «подготовка».
1. Ему предлагается выбрать желаемый результат гонки - показать лучшее время, приехать первым, набрать наибольшее количество очков, уложиться в определенное время, набрать необходимое число очков. Пользователь выбирает какой-либо вариант.
• Если выбран один из первых четырех вариантов, пользователю предлагается ввести оценку для количества кругов — итераций.
• В случае последнего варианта вводится число очков, которое необходимо набрать. Количество итераций не важно.
• Если ставится задача уложиться в определенное время, вводится оценка для времени.
2. После того, как тип гонки выбран, пользователь может разбить трассу на отдельные участки.
3. Пользователь выделяет несколько участков, указывая для каждого протяженность относительно этапа.
4. У пользователя есть возможность создать контрольные точки для этапа. Контрольная точка может либо представлять какое-то временное значение, либо контрольный список.
5. Пользователь создает контрольные точки.
• Если необходим отсчет времени, пользователь вводит временное значение.
• Если необходима проверка выполнения каких-то задач, пользователь создает и редактирует контрольный список.
6. Пользователь может выбрать типы транспортных средств — различные методики исследований и анализа — и назначить их либо на целый этап, либо на его участки.
• Пользователь выбирает методики из уже существующих или вводит свои.
• Пользователь определяет, в каком месте будет использована методика: где-то на протяжении всего этапа или на конкретном участке.
7. Пользователь может выбрать одного или нескольких соперников — участников данного этапа, например, инженерных психологов или менеджеров.
2. Пользователь выбирает тип «разработка».
1. Он выбирает желаемый результат аналогично пункту 5.1. a)
2. Пользователь может создать контрольные точки — временное значение, контрольный список или тип прототипа.
3. Пользователь создает контрольные точки.
• Временное значение и контрольный список — аналогично пункту 5.1. e)
• Если задается тип прототипа, можно выбрать из уже существующих или добавить новый.
4. Пользователь может выбрать типы транспортных средств — средства разработки, которые будет использоваться на этапе, и назначить их на этап.
• Пользователь выбирает средства из уже существующих или вводит свое значение.
5. Пользователь может выбрать соперников — участников процесса создания прототипа.
3. Пользователь выбирает тип «контроль».
1. Он выбирает желаемый результат аналогично пункту 5.1. a)
2. Пользователь создает контрольные точки аналогично пункту 5.1. e) или контрольную точку с указанием результата, который подлежит проверке.
3. Пользователь может назначить одного или нескольких соперников —участников разработки, реализующих интерфейс или его интеграцию с функционалом.
4. Пользователь может разбить трассу на участки, указав для каждого протяженность относительно всего этапа.
5. Пользователь может выбрать одно или несколько транспортных средств — различные методы тестирования.
6. Пользователь конструирует необходимое количество этапов.
7. Создание нового процесса проектирования завершается.

Сценарий 2. Работа с созданным процессом.

1. При входе пользователя в систему, ему предоставляется выбор — создать новый процесс или выбрать из уже имеющихся. Пользователь выбирает существующий процесс.
2. Система отображает этапы, из которых состоит процесс.
3. Пользователь выбирает один из этапов.
4. Система отображает текущее состояние процесса.
1. Система иллюстрирует метафору гонок, отражающую текущее состояние процесса.
2. Пользователь может просмотреть содержимое контрольных точек.
3. Пользователь видит список транспортных средств, задействованных в данный момент, и при желании — список всех средств на этап.
4. Система отображает прогресс каждого из участников на данном этапе, измерение прогресса задается пользователем (процент пройденного пути, прошедшее время или количество очков).
5. Пользователю доступен список документов, используемых на данном этапе, и степень их готовности.
5. Пользователь принимает решение отредактировать имеющиеся данные.
1. Пользователь изменяет состояние текущего этапа с использованием визуального представления метафоры.
1. Пользователь меняет положение участников на этапе.
2. Пользователь изменяет наполнение контрольных точек.
3. Пользователь изменяет временные значения или количество очков для участников этапа.
4. Пользователь также может изменить желаемый результат гонки.
5. Пользователь редактирует список транспортных средств и их задействованность на текущий момент.
2. Пользователь редактирует список имеющихся документов и их готовность.
6. Система запрашивает подтверждение и сохраняет изменения.

Сценарий 3. Просмотр результатов работы.

5. Войдя в систему, пользователь может выбрать существующий конкретный процесс для просмотра статистики по нему, или выбрать просмотр статистики по всем имеющимся процессам.
6. Пользователь выбирает выбирает интересующий его процесс.
1. Пользователю предлагается просмотреть статистику по процессу.
2. Пользователь выбирает тип статистики.
1. Например, подробная статистика для одного участника или сводная информация по всем.
2. Например, статистика использования ресурсов — документов или транспортных средств.
3. Статистика может зависеть от того, завершился данный процесс или нет.
7. Пользователь выбирает просмотр статистики по всем процессам.
1. Он может отредактировать, информация по каким процессам будет анализироваться.
2. Пользователь настраивает те характеристики, которые он хочет сравнить.
8. Система отображает необходимые данные.
1. Данные представляются в виде таблиц.

РЕАЛИЗАЦИЯ

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

При разработке прототипа мы обратили внимание на возможности новой версии языка разметки HTML – HTML5. HTML5 вводит несколько новых элементов и атрибутов. Нас в первую очередь заинтересовал элемент canvas, который предназначен для создания и обработки изображений при помощи JavaScript. Элемент состоит из области, заданной в HTML-коде, с определенной высотой и шириной. Из JavaScript-кода возможно обращение к этой области с помощью набора различных функций, что позволяет динамически создавать изображения. Элемент canvas позволяет работать как с bitmap-изображениями, так и с 2D-фигурами. Имеется набор функций для отрисовки графических примитивов — прямоугольников, дуг, прямых, кривых Безье.

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

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

ЗАКЛЮЧЕНИЕ

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

Из настоящей работы можно сделать следующие выводы:

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

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

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

ЛИТЕРАТУРА

1. Купер А., Рейман Р., Кронин Д. Алан Купер об интерфейсе. Основы проектирования взаимодействия. - Пер. с англ. - СПб.: Символ-Плюс, 2010. - 688с.
2. Норман, Дональд А. Дизайн привычных вещей. - Пер. с англ. - М: Вильямс, 2006. - 384с.
3. Lewis C., Rieman J. Task-centered user interface design. A Practical Introduction. 1993-1994, http://hcibib.org/tcuid/
4. Norman, Donald A. Human-centered design considered harmful//interactions, Volume 12, Issue 4, July + August 2005, стр. 14-19.
5. What is User-Centered Design?, Usability Professionals' Association, http://www.upassoc.org/usability_resources/about_usability/what_is_ucd.html
6. Головач В.В. Дизайн пользовательского интерфейса 2. Искусство мыть слона, http://uibook2.usethics.ru/
7. Авербух В.Л. К теории компьютерной визуализации//Вычислительные технологии, Том 10, № 4, 2005, стр. 21-51
8. Toriello E. What You Need to Know About Agile UX, 2011 http://www.instantshift.com/2011/04/08/what-you-need-to-know-about-agile-ux/
9. Saffer D. A Definition of Interaction Design, 2004, http://www.odannyboy.com/blog/archives/001000.html
10. Maier A. 8 Must-see UX Diagrams, 2010, http://www.uxbooth.com/blog/8-must-see-ux-diagrams/
11. Сценарии взаимодействия, краткие и подробные, http://www.uimodeling.ru/process/docs/use-cases.html
12. HTML Living Standard, http://www.whatwg.org/specs/web-apps/current-work/

ПРИЛОЖЕНИЕ 1

Пример реализации с помощью элемента canvas

var canvas = document.getElementById("track_canvas");

var context = canvas.getContext("2d");

context.fillStyle = "#336633";

context.fillRect(0, 0, 640, 480);

context.shadowOffsetX = 6;

context.shadowOffsetY = 3;

context.shadowBlur = 5;

context.shadowColor = "#000000";

context.strokeStyle = "#3399CC";

context.lineWidth = 15;

context.beginPath();

context.moveTo(30, 190);

context.bezierCurveTo(20, 140, 70, 100, 100, 100);

context.bezierCurveTo(130, 100, 140, 100, 170, 70);

context.bezierCurveTo(200, 40, 270, 50, 290, 60);

context.bezierCurveTo(320, 80, 370, 100, 420, 80);

context.stroke();

context.beginPath();

context.strokeStyle = "#FFFF00";

context.moveTo(450, 320);

context.bezierCurveTo(420, 310, 400, 310, 370, 330);

context.bezierCurveTo(340, 350, 270, 390, 220, 320);

context.bezierCurveTo(180, 260, 150, 290, 120, 290);

context.bezierCurveTo(100, 290, 50, 270, 30, 190);

context.stroke();

context.beginPath();

context.strokeStyle = "#CC0066";

context.moveTo(420, 80);

context.bezierCurveTo(490, 50, 520, 70, 550, 90);

context.bezierCurveTo(610, 120, 640, 130, 590, 190);

context.bezierCurveTo(570, 220, 580, 230, 600, 250);

context.bezierCurveTo(630, 270, 570, 370, 450, 320);

context.stroke();

ПРИЛОЖЕНИЕ 2

Пример экрана прототипа