Принципы проектирования пользовательского интерфейса

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

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

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

    3. Основные этапы разработки интерфейса

    В процессе разработки интерфейса можно выделить три основных этапа, а именно:

    * первоначальное проектирование,

    * создание прототипа

    *тестирование/модификация прототипа.

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

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

    Документация  есть часть интерфейса, причем в сложных  системах – большая  часть 

    3.1. Первоначальное проектирование

    Проектирование состоит из следующих этапов:

    1. Определение необходимой функциональности  системы.

    2. Создание пользовательских сценариев.

    3. Проектирование общей структуры.

    4. Конструирование отдельных блоков.

    5. Создание глоссария

    6. Сборка и начальная проверка  полной схемы системы.

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

    Определение необходимой функциональности системы

    Результат. В конце этого этапа должна получиться примерно такая схема (Рисунок 2). 

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

      3. Построение прототипа

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

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

      Итак, как быстрее и дешевле построить  прототип?

      Первая  версия. Бумажная

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

      Вторая  версия. Презентация

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

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

      Фактически  для большинства систем этой версии оказывается достаточно.

      Третья  версия

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

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

      Четвертая версия

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

      4. Тестирование и модификация прототипа

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

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

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

      Собственно  тестирование

      Технически  сеанс тестирования довольно прост. Нужно иметь несколько пользователей, которые ни разу не видели текущего состояния системы. За исключением  редких случаев, когда ваша система  рассчитана на продвинутых пользователей (power user), нужно подбирать не слишком опытных субъектов. Тестерам дается задание, они его выполняют, после чего результаты анализируются.