Как создать хороший интерфейс пользователя?

Laura Arlov

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

• Пользователи думают, что интерфейс - это и есть программа.
• Чтобы пользователи работали более продуктивно, программа должна быть простой в использовании.
• Достижения технологии значительно увеличили количество решений, которые необходимо принимать во время разработки интерфейса
• Общеплатформенные стандарты пользовательского интерфейса решают только 15% вопросов разработки в типичном проекте.
• Большинство программных проектов ограничены во времени.
• Пользователи становятся все более привередливыми.
• Хороший интерфейс может стать преимуществом против конкурентов, плохой - послужить причиной неудачи всего проекта.

Разработчики программ могут последовать простому прагматическому методу, кратко описанному в этой статье. Более подробно этот метод описан в моей книге "GUI Design for Dummies".

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

Рекомендую вам уделить одинаковое внимание следующим пунктам:

• Пользователи: их опыт работы с компьютером, мотивы, размер/важность групп пользователей, образцы (типовые ситуации) использования
• Задачи: что послужило причиной создания проекта, этапы создания проекта, какие результаты должны быть получены, какая информация необходима и когда
• Технология разработки и платформа, на которой будут работать пользователи
• Среда, в которой будет создаваться и использоваться проект (физическая, рыночная, организационная и культурная)

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

• Неожиданное или неконтролируемое повторение процесса разработки, когда некоторые важные факторы становится известны вам слишком поздно в процессе разработки. "Что? У пользователей будут экраны с разрешением 800х600? Окна нашей программы просто не поместятся на экране!"
• Много дискуссий без значительного прогресса
• Вы не оправдаете ожиданий спонсоров вашего проекта (людей у которых есть причины забоится о доходе)

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

• Множественные окна
• MDI (много-документный интерфейс)
• Множественные фреймы
• Неструктурированное взаимодействие: экраны  с гиперссылками

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И снова, если вы хотите знать, какие сигналы вы подаете, не спрашивайте "Что я сказал?" Вместо этого спросите свою аудиторию, как они восприняли это.

Половина процесса разработки - это анализ и создание; вторая половина - получение обратной связи, и применение полученной информации.

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

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

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

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

Вернуться к списку статей