Поделиться через

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

  • Статья

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

Введение

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

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

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

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

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

Функциональные требования

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

  • Следуйте рекомендациям по проектированию пользовательского интерфейса.

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

  • Убедитесь, что пользовательский интерфейс доступен.

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

  • Поддержка международного рынка.

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

Анализ пользователей

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

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

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

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

Постановка задач

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

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

Ниже приведены дополнительные примеры операторов проблем:

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

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

Приоритеты

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

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

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

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

Концептуальное проектирование

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

Логическое проектирование

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

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

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

Физический дизайн

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

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