Страх чистого листа при проектировании интерфейсов. Этапы проектирования пользовательского интерфейса Этапы проектирования интерфейса user needs

2.2. ЭТАПЫ ПРОЕКТИРОВАНИЯ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

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

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

во-вторых, они не должны говорить одновременно;

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

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

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

Теперь давайте вспомним, чего не любят наши собеседники.

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

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

Таким образом, при проектировании пользовательского интерфейса необходи­мо определить:

Структуру диалога;

Возможный сценарий развития диалога;

Визуальные атрибуты отображаемой информации (синтаксис сообщений).

2.2.1. ВЫБОР СТРУКТУРЫ ДИАЛОГА

Выбор структуры диалога - это первый из этапов, который должен быть выпол­нен при разработке интерфейса.

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

ДИАЛОГ ТИПА «ВОПРОС - ОТВЕТ»

Структура диалога типа «вопрос-ответ» (Q&A) основана на аналогии с обыч­ным интервью. Система берет на себя роль интервьюера и получает информа­цию от пользователя в виде ответов на вопросы. Это наиболее известная струк­тура диалога; все диалоги, управляемые компьютером, в той или иной степени состоят из вопросов, на которые пользователь отвечает. Однако в структуре Q&A этот процесс выражен явно. В каждой точке диалога система выводит в качестве подсказки один вопрос, на который пользователь дает один ответ. В зависимости от полученного ответа система может решить, какой следующий вопрос задавать. Структура Q&A предоставляет естественный механизм ввода как управляющих сообщений (команд), так и данных. Никаких ограничений на диапазон или тип входных данных, которые могут обрабатываться, не на­кладывается. Существуют системы, ответы в которых даются на естественном языке, но чаще используются предложения из одного слова с ограниченной грамматикой.

Диалог в виде вопросов и ответов в достаточной степени обеспечивает поддер­жку пользователя, так как даже краткий наводящий вопрос при разумном построе­нии может быть самопоясняющим. Структура Q&A не гарантирует минимального объема ввода, оцениваемого по количеству нажатий клавиш, однако при подходя­щем подборе сокращений можно уменьшить любую избыточность. Вместе с тем, структура Q&A обладает одним существенным недостатком. Даже если ввод проис­ходит достаточно быстро, для человека, который уже знает, какие вопросы задает система и какие ответы нужно на них давать, отвечать на всю серию вопросов до­вольно утомительно.

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

ДИАЛОГ НА ОСНОВЕ МЕНЮ

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

Существует несколько основных форматов представления менюна экране:

Список объектов, выбираемых прямым указанием, либо указаниемномера (или мнемонического кода);

Меню в виде блока данных;

Меню в виде строки данных;

Меню в виде пиктограмм.

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

Меню в виде пиктограмм представляет собой множество объектов выбора, раз­бросанных по всему экрану; часто объекты выбора содержат графическое представ­ление вариантов работы.

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

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

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

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

ДИАЛОГ НА ОСНОВЕ ЭКРАННЫХ ФОРМ

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

Если встретилась какая-либо ошибка, приложение не должно заново выво­дить пустую форму; выводится форма с предыдущими ответами и допущенны­ми ошибками. Новый «бланк» выдается лишь в случае соответствующего зап­роса пользователя.

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

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

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

Структура диалога на основе экранной формы обеспечивает высокий уровень поддержки пользователя: для каждого вопроса формы могут быть предусмотрены сообщения об ошибках и справочная информация. Пользователю можно также ока­зать помощь, включив некоторые элементы формата ответа в вопрос или в поле ответа. Эта структура позволяет повысить скорость ввода данных по сравнению со структурой типа «вопрос - ответ» и манипулировать более широким диапазоном входных данных, нежели меню; кроме того, с ней могут работать пользователи лю­бой квалификации. Поскольку эта структура имеет последовательную, а не древо­видную организацию, она в меньшей степени подходит для работы в режиме выбо­ра вариантов. Еще одной областью применения экранных форм является задание параметров запросов в базах данных. Этот механизм иногда называют запросом по образцу ( Query by Example ).

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

ДИАЛОГ НА ОСНОВЕ КОМАНДНОГО ЯЗЫКА

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

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

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

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

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

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

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

Ключевые параметры уменьшают нагрузку на память пользователя в том отноше­нии, что отпадает необходимость в запоминании порядка их следования; кроме того, Можно опускать необязательные параметры. С другой стороны, в этом случае пользова­телю необходимо запомнить множество ключевых слов, а разработчику - подобрать для них «осмысленные» имена. Этот подход также требует большего времени работы системы, чтобы распознать ключевые слова, заданные в произвольном порядке.

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

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

Изложенное можно представить в форме так называемой «таблицы выбо­ра» (рис. 2.1).

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

* - использование этого типа диалога данной категорией пользователей требует нали­чия системы помощи;

** - использование средств системы возможно только в ограниченном объеме.

Рис. 2.1. Вариант таблицы выбора

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

Выбор наиболее подходящей структуры диалога на основе таблицы выполняет­ся следующим образом.

1. Закрыть графы «Тип диалога».

2. В графе «Выбор пользователя» пометить критерии, относящиеся к рассмат­риваемому применению.

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

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

2.2.2. РАЗРАБОТКА СЦЕНАРИЯ ДИАЛОГА

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

Целями разработки сценария диалога являются:

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

Выбор рациональных путей перехода из одного состояния диалога в другое (из текущего в требуемое);

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

Сложность разработки сценария определяется в основном двумя факторами:

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

В свою очередь, степень неопределенности действий пользователя зависит от выб­ранной структуры диалога. Наибольшей детерминированностью обладает диалог на основе меню, наименьшей - диалог типа «вопрос-ответ», управляемый пользователем.

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

использование смешанной структуры диалога (применение меню с целью «огра­ничения свободы» пользователя там, где это возможно);

применение входного контроля вводимой информации (команд и данных).

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

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

Способ описания сценария диалога зависит от степени его сложности. Суще­ствующие методы описания сценариев можно разделить на две большие группы:

неформальные и формальные методы.

Главное достоинство формальных методов состоит в том, что они позволяют автоматизировать как проектирование диалога, так и его модификацию (адапта­цию) в соответствии с характеристиками пользователя.

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

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

Рис. 2.2. Шаг диалога

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

ТЕМП ВЕДЕНИЯ ДИАЛОГА

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

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

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

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

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

Требования к времени ответа зависят от того, что ожидает пользователь от рабо­ты системы, и от того, как взаимодействие с системой влияет на выполнение его заданий. Исследования показали [З], что если время ответа меньше ожидаемого, точность выбора операции из меню увеличивается с увеличением времени ответа системы. Это связано с тем, что излишне быстрый ответ системы как бы «подгоня­ет» пользователя, заставляет его суетиться в стремлении «не отставать» от более расторопного партнера по общению. Замечено, что начинающий пользователь боит­ся работать с системой, если, потратив несколько минут на ввод, он моментально получает от нее ответ с сообщением об ошибке.

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

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

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

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

0,1... 0,2 с - для подтверждения физических действий (нажатие клавиши, рабо­та со световым пером, «мышью»);

0,5... 1,0 с - для ответа на простые команды (например, от момента ввода команды, выбора альтернативы из меню до появления нового изображения на экране);

1... 2 с - при ведении связного диалога (когда пользователь воспринимает се­рию взаимосвязанных вопросов как одну порцию информации для формирования одного или нескольких ответов, задержка между следующими друг за другом воп­росами не должна превышать указанную длительность);

2... 4 с - для ответа на сложный запрос, состоящий в заполнении некоторой формы. Если задержка не влияет на другую работу пользователя, связанную с пер­вой, могут быть приемлемы задержки до 10 с;

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

МЕТОДЫ РАЗРАБОТКИ ГИБКОГО ИНТЕРФЕЙСА

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

Существуют три вида адаптации: фиксированная, полная и косметическая.

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

подробный (для начинающего пользователя);

краткий (для подготовленного пользователя).

Правило двух уровней может быть расширено до правила N уровней диалога. Однако такой подход имеет несколько недостатков:

1) не учитывается тот факт, что навыки накапливаются постепенно;

2) пользователь может хорошо знать одну часть системы и совсем не знать другую;

3) пользователь сам определяет уровень своей подготовки, что снижает объек­тивность оценки.

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

В настоящее время полная (автоматическая) адаптация практически ни водной диалоговой системе не реализована.

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

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

Использование умолчаний;

Использование сокращений;

Опережающий ввод ответов;

Многоуровневая помощь;

Многоязычность.

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

во-первых, начинающий пользователь имеет возможность использовать боль­шинство параметров системы по умолчанию,

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

Для удобства начинающих пользователей значения, используемые по умолча­нию, могут выводиться на экран вместе с соответствующим вопросом системы, например: «Дата регистрации документа? [текущая]».

Самый распространенный способ принятия значений по умолчанию - это нуле­вой ввод, т.е. простое нажатие клавиши «Ввод» в качестве ответа на вопрос систе­мы. Если используется командный язык, то пользователь просто пропускает пара­метр, используемый по умолчанию.

Использование сокращений предполагает, что пользователь вместо полного имени команды может вводить ее любое допустимое сокращенное обозначе­ние. На первый взгляд может показаться, что сокращенный ввод более удобен для начинающего пользователя. Но это не совсем так. Чтобы пользователь мог, не задумываясь, заменить команду корректным сокращением, он должен доста­точно хорошо представлять имеющийся набор команд, усвоить «лексику» си­стемы. Например, если в системе имеются команды Copy и Compare , то начи­нающему проще набрать полное имя, чем выбрать корректный вариант сокращения.

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

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

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

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

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

2.2.3. ВИЗУАЛЬНЫЕ АТРИБУТЫ ОТОБРАЖАЕМОЙ ИНФОРМАЦИИ

К визуальным атрибутам отображаемой информации относятся:

Взаимное расположение и размер отображаемых объектов;

Цветовая палитра;

Средства привлечения внимания пользователя. Проектирование размещения данных на экране предполагает выполнение следу­ющих действий:

1) Определение состава информации, которая должна появляться на экране;

2) Выбор формата представления этой информации;

3) Определение взаимного расположения данных (или объектов) на экране;

4) Выбор средств привлечения внимания пользователя;

5) Разработка макета размещения данныхна экране;

6) Оценка эффективности размещения информации.

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

Общие принципы расположения информации на экране должны обеспечивать для пользователя:

возможность просмотра экрана в логической последовательности;

простоту выбора нужной информации;

возможность идентификации связанных групп информации;

различимость исключительных ситуаций (сообщений об ошибках или предуп­реждений);

возможность определить, какое действие со стороны пользователя требуется (и требуется ли вообще) для продолжения выполнения задания.

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

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

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

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

оставлять пустым приблизительно половину экрана (окна);

оставлять пустую строку после каждой пятой строки таблицы;

оставлять четыре-пять пробелов между столбцами таблицы. Фрагменты текста должны располагаться на экране так, чтобы взгляд пользова­теля сам перемещался в нужном направлении. Содержимое полей должно не «при­жиматься» к краю экрана, а располагаться около его горизонтальных или верти­кальных осей. Меню, содержащее относительно небольшой объем информации, должно смещаться в левую верхнюю часть экрана. Чтобы подчеркнуть симметрию, содержимое и наименования полей, относящихся к одной группе, должны вырав­ниваться по вертикали. По возможности необходимо выравнивать все логически связанные группы данных.

Другой набор рекомендаций определяется факторами, связанными с право-ле­вой асимметрией головного мозга человека. Известно, что левое и правое полуша­рия по-разному участвуют в восприятии и переработке информации. В частности, при запоминании слов ведущую роль играет левое полушарие, а при запоминании образов более активно правое. Информация с правой части экрана поступает непос­редственно в левое полушарие, а с левой части - в правое (естественно, при бинокулярном зрении оператора). В связи с этим можно рекомендовать текстовые сообщения группировать справа, а изображения - слева. У некоторых людей это распределение функций полушарий противоположно, у женщин асимметрия выражена слабее, чем у мужчин. Этот факт еще раз подтверждает необходимость индиви­дуализации характера отображения информации. Учет право-левой асимметрии памяти имеет существенное значение, если интервалы следования сообщений не превышают 10с. Поэтому приведенные рекомендации следует в первую очередь учитывать в интерфейсах программ, работающих в режиме реального времени.

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

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

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

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

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

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

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

Я хотел бы дать вам простой, но парадоксальный совет: не верьте всему, что говорят про проектирование.

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

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

Миф № 1. Проектирование - это дополнительная услуга

Проектировщик, занятый важным общественно-полезным делом

Многие считают, что этап проектирования - это дополнительная услуга, которой можно пренебречь. Это не так.

Ради чего мы создаем IT-продукты? Если мы находимся в своём уме и доброй памяти, мы создаем их ради решения бизнес-задач (своих собственных или своих клиентов - не так важно); решение этих бизнес-задач, в свою очередь, опирается на выполнение создаваемым продуктом задач пользователей с учётом условий рынка, технологических ограничений и всего прочего.

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

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

Можно ли сделать сколь-нибудь сложный и полезный продукт, миновав все эти этапы? Согласитесь: вряд ли. А между тем все описанные процессы и составляют то, что принято называть проектированием - анализ (разбор условий задачи), синтез (формирование продукта) и фиксация (составление правильной проектной документации).

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

Миф № 2. Проектирование стоит дорого

Менеджер проекта выколачивает бюджет из заказчика

Бытует мнение, что этап проектирования только удорожает продукт.

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

Карл Вигерс как-то провел исследование американского рынка IT-разработки и подсчитал, что в среднем 40% бюджетов разработки тратится впустую , причём эти деньги теряются не по вине криворуких разработчиков или плохих заказчиков, а всего лишь потому, что две стороны - заказчик и разработчик - просто не смогли договориться между собой .

Сорок процентов - и это для Америки, где царят совершенно иные отношения между заказчиком и разработчиком! Для России, мне кажется, эта цифра ещё выше - раза эдак в полтора.

При этом правильное системное проектирование, по подсчётам того же Вигерса, отнимает 15-20% бюджетов на разработку (и эта цифра полностью подтверждается нашим опытом).

Получается интересный эффект: мы тратим фиксированные 15-20% на проектирование, но при этом сводим к минимуму «пустые» траты (те самые 40% бюджета), которые потенциально могут похоронить проект и, к тому же, чрезвычайно затягивают сроки получения работоспособного продукта.

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

Миф № 3. Проектирование - это написание ТЗ

Слон, сделанный по ТЗ

Часто приходится слышать, что проектирование - это процесс написания ТЗ, который можно приложить к договору. Это не так.

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

• проектирование позволяет учесть интересы пользователей (и тем самым минимизировать риски разработки);
• проектирование позволяет учесть интересы заказчика (и тем самым минимизировать риски разработки);
• проектирование позволяет учесть все значимые внешние факторы (и тем самым минимизировать риски разработки);
• проектирование позволяет сторонам получить единое видение продукта (и тем самым минимизировать риски разработки);
• проектирование позволяет точно спрогнозировать сроки и стоимость разработки (и тем самым… ну, вы поняли).

Написание ТЗ - это всего лишь один из инструментов, который позволяет однозначно, достаточно, системно и отчуждаемо зафиксировать требования к продукту в формате, понятном для разработчика. Да, этот инструмент можно назвать важнейшим, но этап проектирования несёт куда более важную задачу - и это нужно помнить.

Миф № 4. Проектирование - это про пользовательские интерфейсы

Продукт с продуманным дружественным интерфейсом

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

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

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

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

Миф № 5. Проектировать может и менеджер

Менеджер, занятый профильной активностью

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

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

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

И так будет на всем протяжении разработки. Если к этому ценностному аспекту прибавить аспект профессиональный (всё-таки проектировщик должен уметь многое из того, что не обязан знать менеджер), то легко понять, почему проектированием должен заниматься отдельный, специально обученный человек со своей системой ценностей.

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

Миф № 6. Проектированием должны заниматься психологи

Техническое содержание продукта по версии психолога

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

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

Миф № 7. Проектирование должны заниматься инженеры

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

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

Кто же такой проектировщик?

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

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

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

Но такие люди есть - и именно для их поиска и формирования я создал в свое время Гильдию вольных проектировщиков, и это тоже отдельная тема для разговора.

Единого подхода к проектированию не существует

Проектировщик не выдерживает накала страстей на проекте

Подходов к проектированию много, и неискушенный читатель может запросто сойти с ума от обилия приемов, подходов и аббревиатур, щедро сдобренных терминологическим бардаком (всеми этими UX, UI, CX, HCD и прочими IDDQD с кривыми русскоязычными аналогами).

Некоторые, впрочем, пытаются вывести универсальные модели проектирования, но в итоге получается так, что в попытке объединить существующие 20 (условно) подходов к проектированию мы получаем в итоге 21 подход - и методологии, как кажется, начинают плодить самих себя.

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

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

Вместо заключения

Итак, что мы с вами сегодня выяснили?

• Проектирование стоит своих денег и позволяет уменьшить бюджет на разработку.
• Проектирование минимизирует риски разработки.
• Проектирование отстаивает интересы продукта в целом.
• Проектированием должны заниматься проектировщики (вот так истина, а?).
• Проектирование - это большой и сложный процесс, у которого есть свои закономерности и единые подходы.
• Не верьте тому, что пишут про проектирование - не бойтесь думать сами, предлагать свои взгляды и отстаивать своё ви́дение.

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

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

Формализация контекста использования

Формализация объективных критериев успеха

Анализ целей

Формализация бизнес-ролей пользователей

Формализация функциональности

Формализация сценариев действий пользователей

Обзор интерфейса конкурирующих систем

Формализация привычек и ожиданий пользователей

Формализация контекста использования

На этом этапе собирается большинство сведений о пользователях. Описываются следующие свойства аудитории системы:

Характеристики пользователей: их опыт работы с компьютером, знание предметной области, мотивы, размер/важность групп пользователей, образцы (типовые ситуации) использования;

Цели и задачи пользователей;

Задачи проекта: что послужило причиной создания проекта, этапы создания проекта, какие результаты должны быть получены, какая информация необходима и когда;

Технология разработки и платформа, на которой будут работать пользователи;

Среда, в которой будет создаваться и использоваться проект (физическая, рыночная, организационная и культурная).

На входе: доступ к имеющимся и потенциальным пользователям системы, экспертам и проектной документации.

На выходе: описание контекста использования системы, возможно более детальное описание свойств пользователей.

наверх к оглавлению

Формализация объективных критериев успеха.

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

Соответственно, на данном этапе создается реальное задание на проектирование интерфейса. Например:

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

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

на 20% снизить количество человеческих ошибок.

На входе: доступ к пользователям, экспертам и проектной документации.

На выходе: список объективных критериев успеха.

наверх к оглавлению

Анализ целей

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

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

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

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

На входе: доступ к пользователям, экспертам и проектной документации

На выходе: перечень целей внедрения нового интерфейса с весовыми характеристиками каждой.

наверх к оглавлению

Формализация бизнес-ролей пользователей

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

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

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

На выходе: описание бизнес-ролей пользователей.

наверх к оглавлению

Формализация функциональности

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

На входе: доступ к пользователям, экспертам и проектной документации, знание основных аспектов предметной области.

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

наверх к оглавлению

Формализация сценариев действий пользователей

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

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

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

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

Андрей Фёдорович делает активным окно уже открытой почтовой программы и включает процесс скачивания новой почты. Получив почту, он ее читает. Одно сообщение он пересылает другому адресату, после чего удаляет его, а еще одно печатает. После чего переключается на другую задачу.

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

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

На входе: доступ к пользователям, экспертам и проектной документации, знание основных аспектов предметной области.

На выходе: сценарии работы пользователей (разработанные сценарии, как правило, представляются в виде блок-схем, описывающих весь процесс использования системы для выполнения той или иной задачи).

наверх к оглавлению

Обзор интерфейса конкурирующих систем

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

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

На входе: доступ к конкурирующим системам.

На выходе: обзор преимуществ и недостатков интерфейса конкурирующих систем.

наверх к оглавлению

Формализация привычек и ожиданий пользователей

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

На входе: доступ к пользователям.

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

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

1. Постановка задачи.

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

Формализация контекста использования

Описываются следующие свойства аудитории системы:

Характеристики пользователей: их опыт работы с компьютером, знание предметной области, мотивы, размер/важность групп пользователей, образцы (типовые ситуации) использования;

Цели и задачи пользователей;

Задачи проекта: что послужило причиной создания проекта, этапы создания проекта, какие результаты должны быть получены, какая информация необходима и когда;

Технология разработки и платформа, на которой будут работать пользователи;

Среда, в которой будет создаваться, и использоваться проект (физическая, рыночная, организационная и культурная).

Формализация объективных критериев успеха.

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

Анализ целей

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

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

Формализация бизнес-ролей пользователей

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

Формализация сценариев действий пользователей

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

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

Обзор интерфейса конкурирующих систем

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

2. Высокоуровневое проектирование

На этой стадии начинается непосредственное проектирование интерфейса; предыдущие этапы посвящены исключительно сбору данных и постановке задачи.

Проектирование структуры экранов системы

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

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

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

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

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

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

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

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

Установление качественной процессуальной связи обычно довольно трудная задача, поскольку единственным источником информации является наблюдение за пользователем. В то же время установление такой связи дело исключительно полезное. Зачем, например, рисовать на экране сложную систему навигации, если точно известно, к какому блоку пользователь перейдет дальше? В этом смысле зачастую оправдано навязывать пользователю какую-либо процессуальную связь, жертвуя удобством, зато выигрывая в скорости обучения (поскольку пользователю приходится думать меньше). Жестко заданная связь позволяет также уменьшить количество ошибок. Классическим примером жестко заданной процессуальной связи является устройство мастеров, при котором пользователя заставляют нажимать кнопку Далее.

Проектирование навигационной системы

На основе разработанной ранее структуры экранов на этом этапе выбирается наиболее адекватная навигационная система и разрабатывается её детальный интерфейс.

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

Проектирование структуры справочной системы

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

3. Низкоуровневое проектирование

Разрабатываются интерфейсы конкретных экранов системы (состав, взаимное расположение и поддерживающие текст интерфейсных элементов).

Проектирование основных экранов

На данном этапе разрабатываются интерфейсы основных экранов системы.

Тестирование

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

Проектирование второстепенных экранов

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

Финальное тестирование

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

Наиболее известные языки проектирования на 2010 год:

VHDL (англ. VHSIC (Very high speed integrated circuits) Hardware Description Language) - язык описания аппаратуры высокоскоростных интегральных схем. Язык проектирования VHDL является базовым языком при разработке аппаратуры современных вычислительных систем.

Был разработан в 1983 г. по заказу Министерства обороны США с целью формального описания логических схем для всех этапов разработки электронных систем, начиная модулями микросхем и заканчивая крупными вычислительными системами.

Verilog - это язык описания аппаратуры, используемый для описания и моделирования электронных систем. Этот язык (также известный как Verilog HDL) позволяет осуществить проектирование, верификацию и реализацию (например, в виде СБИС) аналоговых, цифровых и смешанных электронных систем на различных уровнях абстракции SystemC - язык проектирования и верификации моделей системного уровня, реализованный в виде C+ библиотеки с открытым исходным кодом. Библиотека включает в себя ядро событийного моделирования, что позволяет получить исполняемую модель устройства. Язык применяется для построения транзакционных и поведенческих моделей, а также для высокоуровневого синтеза. ДРАКОН (Дружелюбный Русский Алгоритмический язык, Который

Обеспечивает Наглядность) - визуальный алгоритмический язык, созданный в рамках космической программы Буран. Разработка данного языка была начата в 1986 г. под руководством Владимира Паронджанова. В разработке языка принимали участие Российское космическое агентство (НПЦ автоматики и приборостроения им. акад. Н.А. Пилюгина, г. Москва) и

Российская академия наук (Институт прикладной математики им. акад. М.В. Келдыша).

Одно из задач, ставившихся перед разработчиками, было создание единого универсального языка, который должен был заменить специализированные языки ПРОЛ2 (для разработки бортовых комплексных программ Бурана), ДИПОЛЬ (для создания наземных программ Бурана) и ЛАКС (для моделирования) .

Работы по разработке языка были закончены в 1996г. (спустя 3 года после закрытия программы Буран), когда была создана автоматизированная технология проектирования программных систем (CASE-технология)

Язык ДРАКОН может удачно применяться для специфицирования протоколов взаимодействия (например, клиент-серверных). UML (сокр. от англ. Unified Modeling Language - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.

Заключение

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

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

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

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

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

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

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

Международная организация по стандартам (International Standard Organization, ISO) и другие организации (МСЭ, МЭК и др.). Обычно разработанные ими стандарты носят рекомендательный характер.

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

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

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

3. Низкоуровневое проектирование, где разрабатываются интерфейсы конкретных экранов системы (состав, взаимное расположение и поддерживающие текст интерфейсных элементов).

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

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

2. Возможный сценарий развития диалога.

4. Визуальные атрибуты отображаемой информации (синтаксис сообщений)

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

1. Баканов А.С., Обознов А.А. Проектирование пользовательского интерфейса: эргономический подход - М.: Изд-во «Институт психологии РАН», 2009. - 184 с.

2. Благодатских В.А. Стандартизация разработки программных средств: Учеб. пособие. - М.: Финансы и статистика, 2003. - 288 с.

3. Бурцева Е.В., Селезнёв А.В., Терехов А.В. Информационные системы: Учеб. пособие. - Тамбов: Изд-во Тамб. гос. техн. ун-та, 2009. - 128 с.

4. Волков А.К. Информационные технологии (для экономиста): Учебное пособие. - М.: ИНФРА-М, 2001. - 310с.

5. Гаврилов М.В. Информатика и информационные технологии: Учебник для вузов. - М.: Гардарики, 2006.

6. http://www.km.ru/referats/6893BB3095D64A08BC33DCF5ADB20A88

7. http://www.km.ru/referats/6893BB3095D64A08BC33DCF5ADB20A88

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

Предложенное деление не является универсальным. Каждый из этапов можно поделить на подэтапы. И на под подэтапы - так процесс выглядит еще сложнее, а значит дороже в глазах клиентов:-)

1. Сбор данных

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

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

2. Проектирование

На этом этапе разработки интерфейса программы дизайнер:

• определяет сетку, цвета, шрифты и фон;
• а также часто создает нестандартные элементы управления, такие как выпадающие меню.

Естественно, на каждом из этапов идет обсуждение и, при необходимости, бесплатная доработка. Ваш заказ вы получите либо в качестве графических файлов в формате Photoshop , либо в виде HTML- или XAML-кода .

4. Имплементация

Когда с интерфейсом все понятно, дело остается за немногим:) Как правило, наши клиенты держат штатных программистов, а нас привлекают для различных работ, связанных с пользовательским интерфейсом, от проектирования до создания иконок . Однако, тем клиентам, у которых нет собственных разработчиков, мы предлагаем разработку и тестирование веб-приложений и мобильных приложений под iOS . У нас есть постоянный отдел разработчиков и тестировщиков. Мы гарантируем: никакого фриланса.

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

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

5. Юзабилити-тестирование

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

• естественно нужно стараться привлечь к работе над проектом лучших дизайнеров интерфейса (например, VisualPharm:) Но, к сожалению, это не всегда возможно. Порой в вашем проекте принимают участие те люди, которых вы можете к нему привлечь , а не те, о работе с которыми вы мечтаете;
• дизайн не является точной наукой ; даже если ваш дизайнер гений, не все его идеи одинаково хороши. Потому для уменьшения риска логичным будет подвергнуть все эти идеи проверке в реальных условиях с реальными пользователями. (напоминаем, новые идеи можно проверить с минимальными затратами с помощью таких техник, как бумажный прототип);
• каким образом дизайнеры интерфейсов вообще становятся хорошими дизайнерами? Очень просто: учась на опыте тому, какие идеи работают, а какие нет. Но для получения этого опыта необходимы тесты , которые и проводят специалисты по юзабилити;
• даже самые лучшие дизайнеры могут создать успешный продукт только в том случае, если они решают правильно поставленную задачу. Замечательный интерфейс не поможет, если безграмотно выстроен функционал. Акаким образом дизайнеры интерфейсов узнают, что необходимо пользователям ? Ответ прост: с помощью юзабилити-исследований;
• никто не идеален. Даже очень хороший дизайн может быть улучшен, если его пропустить через процесс поэтапного улучшения качества. На каждом этапе вы проводите тесты с пользователями и на основе результатов, шаг за шагом, улучшаете качество пользовательского интерфейса.

• быстро : 2-7 дней на тест;
• дешево - на один-два порядка дешевле, чем большие исследования;
• в рамках вашей целевой аудитории . Мы ее найдем. Вам нужны американцы со среднего запада 30-55 лет, заинтересованные в русских невестах? Пожалуйста.

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

Сроки

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

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

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

Стоимость

Проектирование и дизайн одного экрана также стоят одинаково:

• проектирование/дизайн первого экрана стоит 48 800 р . Первый экран стоит дороже, поскольку является определяющим для всего приложения. При его разработке мы должны учитывать структуру всего приложения;
• проектирование/дизайн остальных экранов – 18 350 р . за каждый.

Таким образом, разработка прототипа (или дизайна) пяти экранов будет стоить 48 800р.+18 350р. х 4 = 122 200р.

Ориентировочная стоимость юзабилити-тестирования 52 500р. – 126 000р.

Большие проекты

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

• интерфейс голосового общения;
• интерфейс общения с видео;
• управление списком контактов;
• и так далее.

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