Разработка пользовательского интерфейса: как сделать так, чтобы UI не лишил вас прибыли — Дизайн на vc.ru

Содержание

как сделать так, чтобы UI не лишил вас прибыли — Дизайн на vc.ru

В ноябре 2018 года студия «Лайв Тайпинг» рассказывала читателям vc.ru, из чего складывается стоимость мобильного приложения. Эта статья посвящена одному из слагаемых: пользовательскому интерфейсу.

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

Пользовательский интерфейс, или UI (User Interface) — это внешний вид продукта, способ общения между пользователем и программой. А ещё интерфейс влияет на то, будет ли продукт приносить деньги и пользоваться уважением и любовью аудитории.

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

Когда плиточный дизайн — не лучшая идея

Источник: tjournal.ru

Новый дизайн фокусировал внимание пользователей на возможности смотреть фильмы платно через партнёров «Яндекса», и это решало только задачи площадки и

Проектирование пользовательского интерфейса Windows 95 / Хабр

Три года назад мне попалась интересная научная статья сотрудника Microsoft Кента Салливана о процессе и результатах проектирования нового пользовательского интерфейса для Windows 95. С тех пор веб-страница исчезла — одна из причин, почему я такой цифровой Плюшкин.

Статья описывает некоторые общие проблемы оболочки Менеджера программ в Windows 3.1 и рассматривает варианты разработки отдельной оболочки для «новичков». Я склоняюсь к мнению, что она предположительно создавалась в духе программы At Ease от Apple, довольно популярной во времена System 7. Я хорошо помню, как мы запускали At Ease в начальной школе, так что детишкам не приходилось возиться с жёстким диском в Finder.

Итак, вот что Кент дословно написал в своей статье под названием «Пользовательский интерфейс Windows 95: конкретный пример проектирования функциональности» (The Windows 95 User Interface: A Case Study in Usability Engineering). Публикуем её, чтобы документ никогда не потерялся.


В разработке пользовательского интерфейса для большого коммерческого программного продукта вроде Microsoft Windows 95 участвует много людей. У этого проекта обширные задачи и агрессивный график выполнения работ. Краткое изложение проекта здесь описывает опыт успешного применения принципов проектирования юзабилити, итеративной разработки и отслеживания проблем, чтобы повысить управляемость процессом разработки UI. Также обсуждаются конкретные проблемы дизайна и их решения.
Windows 95 — это обширное обновление продуктов Windows 3.1 и Windows for Workgroups 3.11. Почти во всех частях Windows произошли многие изменения. Не стал исключением и пользовательский интерфейс. В этой статье обсуждается дизайнерская группа, её задачи и процесс работы. Затем объясняется, как в проекте применялись принципы проектирования юзабилити, такие как итеративная разработка и отслеживание проблем. В качестве примеров приведены конкретные проблемы дизайна и их решения.

Дизайнерский отдел

Группу разработки пользовательского интерфейса Windows 95 сформировали в октябре 1992 года на ранней стадии проекта. Я подключился к группе в декабре 1992 года в статусе помощника для обеспечения сервисов юзабилити. Команда была по-настоящему междисциплинарной, со специалистами в области проектирования, графического дизайна, тестирования юзабилити и компьютерных наук. Количество сотрудников колебалось в ходе проекта, но в среднем нас было двенадцать. Ещё столько же программистов для реализации пользовательского интерфейса.

Цели дизайна

Дизайнерская группа работала над двумя очень широкими задачами:

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

С более чем 50 млн установок Windows 3.1 и 3.11 плюс практически нетронутым рынком домашних ПК с самого начала стало понятно, что задача выпуска лучшего продукта станет нетривиальным упражнением. Без тщательного дизайна и тестирования мы скорее всего сделаем продукт, который улучшит юзабилити только для определённой категории пользователей, но ухудшит его для миллионов остальных (существующих или потенциальных). Мы хорошо понимали проблемы средних и продвинутых пользователей, но мало знали о проблемах, которые испытывают новички.

Процесс дизайна

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

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

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

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

Рис. 1: Процесс итеративной разработки Windows 95

Этап изучения

На этом первом этапе мы экспериментировали с разными направлениями дизайна и собирали первые отзывы пользователей. Мы начали с прочного фундамента визуального дизайна UI, используя работу, проделанную группой Cairo. Мы унаследовали от них значительную часть фундаментального UI и интерфейсов взаимодействия: рабочий стол, трей (область уведомлений), контекстные меню, трёхмерный вид и проч.). Мы также получили данные из службы поддержки о 20-ти главных проблемах пользователей Windows 3.1.

На рис. 2 показан прототип дизайна рабочего стола Windows 95, юзабилити которого мы тестировали в январе 1993 года. Дизайн основан на Cairo и включает в себя первый проход исправления некоторых известных проблем Windows 3.1 (в частности, управления окнами).

Рис. 2: Ранняя версия рабочего стола Windows 95 (с выносками для ясности)

Верхняя иконка File Cabinet открывала вид в стиле менеджера файлов Windows 3.1 (слева иерархия, справа контент). Вторая иконка World показывала элементы в сети. Третья иконка Programs — это папка с другими папками, полными ссылок на программы, установленные в системе. Вдоль нижей части экрана располагается системный трей с тремя кнопками (System, Find и Help) и областью хранения файлов. Другая иконка Wastebasket представляет собой контейнер удалённых файлов.

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

Первые результаты

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

Сравнение с Windows 3.1

С первых лабораторных экспериментов стало понятно, что нам требуется база Windows 3.1 для лучшего понимания, какие проблемы существовали до Windows 95, а какие проблемы уникальны для нового дизайна. Сначала мы собрали данные рыночных исследований о 20-ти самых частых задачах, которые выполняют пользователи Windows 3.1. Затем провели несколько лабораторных исследований, сравнивая Windows 3.1 и Windows 95 с учётом этих 20-ти задач. Мы также провели собеседования с профессиональными преподавателями Windows 3.1 (и Macintosh, для сравнения), чтобы понять, какие аспекты операционной системы они считают простыми и сложными в обучении юзеров.

Ключевые результаты:

  • В Windows 3.1 новичкам требовалось в среднем 9,5 минут для поиска и открытия программы, которая не видна сразу на экране. В нашем прототипе Windows 95 результаты оказались ненамного лучше. Такие результаты явно неприемлемы с учётом того, что данные рыночных исследований (и здравый смысл) говорили о том, что запуск программ у пользователей является задачей номер один.
  • Новые и некоторые средние пользователи испытывали большие проблемы при использовании мыши, особенно двойного щелчка. В результате они часто не могли найти элементы в контейнерах, доступ в которые открывался только по двойному щелчку.
  • Начинающие и многие средние пользователи для поиска команд полагались почти исключительно на визуальную информацию. Они полагались на строки меню и панели инструментов, но не использовали всплывающие (контекстные) меню даже после обучения.
  • Все, кроме самых продвинутых пользователей, не понимали, как эффективно управлять множеством перекрывающихся окон. Больше всего проблем возникло у новичков — при сворачивании окна они думали, что оно «ушло», если оно было закрыто другим окном. От преподавателей мы слышали много историй (и наблюдали это в лаборатории), как пользователи исчерпывали всю оперативную память на компьютере, запуская многочисленные копии программы вместо переключения на первую запущенную копию. Средние пользователи проявили больший опыт, но тоже испытывали проблемы, особенно с приложениями Multiple-Document-Interface (MDI), такими как Менеджер программ и Microsoft Word. Данные рыночных исследований подтвердили проблему: оказалось, что 40% средних пользователей Windows не запускали больше одной программы одновременно, потому что испытывали какие-то трудности с этим.
  • Начинающих пользователей сбивала с толку иерархическая файловая система. Средние пользователи обычно справлялись с иерархией, но зачастую делали это с трудом и сохраняли все свои документы в директорию по умолчанию для той программы, которую использовали. Эта проблема (особенно у новичков) наблюдалась и у пользователей Macintosh.

Смена направления

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

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

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

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

Этап быстрых итераций

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

Эволюция процесса спецификаций UI

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

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

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

  1. Регулярные собрания сотрудников дизайнерского отдела. На еженедельных (иногда чаще) собраниях каждый сверял свою работу с общим проектом и все обсуждали, как работа каждого сотрудника может повлиять на других.
  2. Рассылка графиков и результатов тестирования юзабилити по электронной почте. Сотрудники дизайнерской группы получали регулярные уведомления о предстоящих тестах юзабилити и результатах завершённых тестов, чтобы быть в курсе, как продвигается дизайн.
  3. Формальное отслеживание проблем юзабилити. С проектом масштаба Windows 95 мы понимали, что требуется стандартный способ записи выявленных проблем юзабилити, когда и как они должны быть исправлены — а затем закрывать тикеты после исправления проблемы и успешной проверки на пользователях. Этот процесс более детально описывается в главе «Отслеживание открытых тикетов».
  4. Регулярные презентации дизайна для внешних групп. По мере продвижения проекта всё больше и больше групп (внутри и за пределами Microsoft) хотели посмотреть, что мы делаем, так что мы проводили такие презентации. Они эффективнее, чем рассылка документов, потому что презентации проще поддерживать в актуальном состоянии и они позволяют своевременно обсуждать дизайн.

Отдельный UI для новичков

Первым важным изменением дизайна, которое мы рассмотрели, стал отдельный UI («оболочка») для начинающих пользователей. Дизайн быстро набросали в Visual Basic и протестировали в лаборатории юзабилити (рис. 4). Тестирование показало неплохой результат, поскольку дизайн успешно ограничивал возможный выбор действий пользователя очень маленьким набором действий, но чем больше пользователей участвовали в тестировании, тем отчётливее проявлялись ограничения:

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

Рис. 4. Частичный вид отдельной оболочки для новичков

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

Примеры быстрой итерации

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

1. Запуск программ: меню «Старт». Хотя мы отказались от идеи отдельной оболочки для новичков, мы сохранили её самые полезные функции: доступ по однократному щелчку, хорошая различимость, взаимодействие через меню. Мы набросали много вариантов в Visual Basic и проверили их на пользователях всех уровней, не только на новичках, потому что это дизайнерское решение должно было хорошо восприниматься пользователями любого уровня. Рис. 5 показывает окончательный вариант меню «Старт» и подменю «Программы». Это меню служит не только для запуска программ, но сочетает в себе и другие функции. Все они открываются нажатием одной кнопки.

Рис. 5. Меню «Старт» и подменю «Программы»

2. Управление окнами: панель задач. Наша первая идея по улучшению управлением окнами была не очень амбициозной, но мы не знали, сколько работы понадобится для решения проблемы. Первой идеей было изменить внешний вид свёрнутых окон из иконок на «плитки». (рис. 6).

Рис. 6. Свёрнутые окна в виде «плиток»

Мы надеялись, что проблему можно решить, если свёрнутые окна будут отличаться на вид и иметь больший размер. Мы ошиблись! Пользователи испытывали практически такие же затруднения, как в случае с Windows 3.1. Результаты тестирования показали, что основная проблема в том, что окна не отображаются постоянно, так что пользователи не видят, какие окна открыты, и не могут быстро получить к ним доступ. Поняв это, мы быстро пришли к идее панели задач, показанной на рис. 7. У каждой задачи есть собственное место на панели, которая отображается поверх всех окон. Тестирование на пользователях показало, что это приемлемое решение проблемы.

Рис. 7. Панель задач с кнопкой «Старт», программами и часами

3. Работа с файлами: диалоги «Открыть» и «Сохранить как…». Информация из службы поддержки и результаты лабораторных тестов показали, что новички и средние пользователи испытывают много проблем с системными диалогами открытия и сохранения файлов (рис. 8).

Рис. 8. Диалоговое окно открытия файла в Windows 3.1

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

Рис. 9. Диалоговое окно открытия файла в Windows 95

4. Печать: мастер установки. Информация из службы поддержки говорила о том, что установка и конфигурация принтера является главной причиной звонков от пользователей Windows 3.1. Многие проблемы проистекают из интерфейса установки принтера (рис. 10).

Рис. 10. Основное диалоговое окно установки принтера в Windows 3.1

Найти нужный принтер сложно, потому что все они находятся в одном длинном списке. Для выбора порта, особенно в сетевом окружении, требовалось спуститься на 4-5 уровней с нестандартными и сложными вариантами выбора. Примерно в то время, когда мы начали решать эту проблему, сотрудники дизайнерского отдела начали рассматривать мастер (визард) как решение для многоэтапных нечасто выполняемых задач. Установка принтера отлично вписался в это определение, и созданный визард показал хорошие результаты в тестировании на пользователях. На рис. 11 показан экран выбора принтера из окончательного варианта визарда.

Рис. 11. Экран мастера добавления принтера в Windows 95

5. Помощь: диалог поиска и вкладка с индексом. Лабораторное тестирование Windows 3.1 показало, что пользователи испытывают проблемы с поисковом диалогом в справочном разделе (рис. 12).

Рис. 12. Диалог поиска по справочной информации в Windows 3.1

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

Рис. 13. Вкладка индекса в справочном разделе Windows 95

Этап тонкой настройки

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

  • Итоговые лабораторные тесты. Используя 20 основных задач из рыночного исследования мы провели комплексное тестирование всего UI. Пользователям разного уровня подготовки предлагали изоморфные наборы задач для измерения скорости обучения и уровня использования после освоения. Мы сравнивали эффективность работы с базовым уровнем Windows 3.1. После проведения собственного пилотного теста для выяснения возможных проблем с процедурой окончательное тестирование осуществил посторонний подрядчик, так что эти результаты можно использовать в официальных документах [3]. Результаты оказались весьма обнадёживающими — пользователи завершали выполнение задач примерно вдвое быстрее, чем в Windows 3.1 и в 20 из 21 категорий показали большее удовлетворение работой Windows 95.
  • Длительное полевое исследование. Двадцать человек приняли участие в полевом исследовании на бета-версии Windows 95. Сначала мы изучали, как они работают в Windows 3.1, а затем наблюдали за установкой Windows 95. Дополнительные тесты проводились через неделю и через месяц для проверки уровня обучения и произошедших изменений. Мы не нашли никаких серьёзных пробелов в юзабилити продукта, но подкорректировали формулировки в UI и темах справочного раздела. Некоторые из собранных данных впоследствии использовались при планировании следующей версии Windows, а также сотрудниками службы поддержки, в том числе краткий перечень тем, которые можно ожидать с началом звонков в службу поддержки.

В ходе разработки и тестирования пользовательского интерфейса Windows 95 мы применили различные принципы и практики разработки юзабилити [2] [4]. С проектом масштаба Windows 95 мы понимали, что требуется стандартный способ записи выявленных проблем юзабилити, когда и как они должны быть исправлены — а затем закрывать тикеты после исправления проблемы и успешной проверки на пользователях.

Для этого мы разработали реляционную базу данных (рис. 14).

Рис. 14. Образец записи в базе данных с тикетами

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

Рис. 15. Образец отчёта в базе данных с тикетами

Отчёт

Как и в любом проекте, практика — критерий истины, так что приведу некоторые сводные статистические данные.

Лабораторные тесты

Мы провели 64 этапа лабораторного тестирования с 560 пользователями. 50% из них имели средний опыт работы с Windows 3.1; остальные — это новички, продвинутые пользователи и пользователи других операционных систем. Эти цифры не включают тестирование компонентов, поступивших от других команд (почтовый клиент Exchange, программа для отправки факсов и проч.). Тестирование этих компонентов прошло примерно в 25 этапов с участием 175 человек.

Выявление проблем

Для ключевых компонентов оболочки в ходе проекта в базу данных были внесены 699 «отчётов юзабилити». Из них 148 положительных результатов и 551 проблема. Проблемам присваивался один из трёх уровней серьёзности:

  • Уровень 1: Пользователи не могут продолжать выполнение задачи или серии задач.
  • Уровень 2: Пользователи испытывают значительные сложности с выполнением задачи или серии задач, но всё-таки способны продолжить её выполнение.
  • Уровень 3: Пользователи испытывают незначительные сложности с выполнением задачи или серии задач.

Из 551 выявленной проблемы 15% получили уровень 1, 43% — уровень 2 и 42% — уровень 3.

Резолюции по проблемам

В ходе проекта использовалось пять резолюций по проблем:

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

К завершению проекта все проблемы с резолюциями «запланировано» или «под вопросом» перешли в одну из других категорий. 81% проблем завершились успешным решением, 8% остались с резолюцией «частично», а 11% остались нерешёнными. В большинстве случаев причиной отсутствия решения стали технические ограничения, а иногда — ограничения рабочего графика.
Для многих сотрудников отдела проект Windows 95 стал первым опытом итеративной разработки, тестирования юзабилити и отслеживания проблем.

Итеративная разработка

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

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

Процесс спецификации

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

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

Тестирование юзабилити

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

Отслеживание проблем

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

Все тикеты с пометками «частично» и «не решено» перенесли в новую базу. Они стали начальной точкой для проектирования следующей версии Windows. Специалисты по планированию и дизайнеры ежедневно работали с этой информацией, а также анализировали отчёты из службы поддержки.

1. Dumas, J. S., Redish, J. C. (1993). A Practical Guide to Usability Testing (стр. 324-325). Norwood, NJ: Ablex Publishing Company.

2. Nielsen, J. (1993). Usability Engineering. San Diego, CA: Academic Press, Inc.

3. Usability Sciences Corporation. (1994). Windows 3.1 and Windows 95 Quantification of Learning Time & Productivity.

4. Whiteside, J. L., Bennett, J, & Holtzblatt, K. (1988). Usability Engineering: Our Experience and Evolution. In M. Helander (Ed.), Handbook of Human-Computer Interaction (стр. 791-817). Amsterdam: Elsevier Science Publishers, B. V.

5. Wiklund, M. E. (1994). Usability in Practice: How Companies Develop User-Friendly Products. Cambridge, MA: Academic Press, Inc.

8 Характеристик удачного пользовательского интерфейса / Хабр

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

  1. Доступность
  2. Минимализм
  3. Уверенность
  4. Отзывчивость
  5. Соответствие контексту
  6. Привлекательность
  7. Эффективность
  8. Снисходительность

Доступность

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

Что делает эта кнопка? Наведем курсор и прочитаем.

Минимализм

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

Панель регулировки уровня звука в OS X. Коротко и доступно, ничего лишнего.

Уверенность

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

Интуитивно понятный интерфейс GoPlan. Надписи на вкладках дают понять пользователю содержимое раздела.

Отзывчивость

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

Во время загрузки Gmail отображается прогресс-бар.

Соответствие контексту

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

Элементы управления MS Office, различные для каждого типа контента.

Привлекательность

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

Интерфейс Google Chrome.

Эффективность

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

Три самых часто выполняемых действий над фотографиями в Apple Iphone объединены в общий список с моментальным доступом.

Снисходительность

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

Случайно удалено важная информация в Gmail. Не проблема, можем отменить действие!

Заключение

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

Оригинал перевода: 8 Характеристик удачного пользовательского интерфейса.

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

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

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

Графический интерфейс пользователя – тип интерфейсов, который прочно закрепился наряду с постоянно увеличивающейся производительностью ПК. В ближайшем будущем могут появиться пользовательские аудио-интерфейсы (VUI или voice user interface), которые позволят людям взаимодействовать с компьютером с помощью речи.

В различных компьютерных играх применяется натуральный пользовательский интерфейс (NUI или natural user interface). Его система анализирует движения человека, и преобразует их в движения в игре. На данный момент в стадии разработки находится перцептивный пользовательский интерфейс (PUI), а также интерфейс мозг-компьютер (BCI или brain-computer interface). Последняя разработка направлена на то, чтобы обеспечить людям возможность управлять компьютерами силой мысли.

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

Этот тип интерфейса пользователя предназначен для работы с символами. Исполнение происходит в режиме аппаратного текста, однако часто используется и дисплей. В данном случае на каждый источник у программиста имеется 256 символов. Навигация производится клавиатурой, а не мышью. В качестве примера можно привести Norton Commander или Turbo Pascal. Этот интерфейс также используется в загрузчиках ОС и BIOS-программах. Данный тип интерфейса также используется для установки операционных систем.

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

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

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

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

При разработке GUI применяются определенные своды правил, которые помогают сделать программы удобнее в использовании. В качестве примера можно привести 8 золотых правил от Бена Шнайдермана. Ниже приведем несколько сносок из этих правил:

  • Согласованность: взаимодействие должно происходить всегда похожим образом. То есть, следует избегать использования панелей управления с опциями типа “скопировать выделенную область”, “удалить выделенную область”, “добавить выделенную область”. Данный пример показывает отсутствие согласованности в GUI, чего следует избегать;
  • Информативная обратная связь: все действия, производимые пользователем, должны быть подкреплены обратной связью. Например, если двойной клик открывает программу, то человеку приходится подождать пару секунд, прежде чем он сможет пользоваться этой программой. Чтобы пользователь знал, что его действия принесли результат, нужно проинформировать его об этом. Это можно реализовать сменой курсора. Один из старейших и привычных примеров – это курсор с песочными часами в Windows;
  • Не перегружайте память пользователей: пользователи не в силах запомнить все и сразу. В длинных сегментах взаимодействия, где пользователь вынужден переходить по нескольким окнам, информация всегда должна отображаться в одной и той же области. Менее востребованная информация, которая отображалась в самом начале, должна быть скрыта.

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

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

Среди примеров можно отметить голосового помощника Apple, Siri, S-Voice у Samsung или голосовой поиск Google. Одна из главных задач при проектировании этого интерфейса пользователя (аудио-интерфейсов) заключается в том, чтобы предоставить аудитории комфортные условия для взаимодействия. То есть, при использовании голосовых синтезаторов в техподдержке, важно не обременять клиентов длинными сообщениями.

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

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

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

Данный тип интерфейса пользователя также можно комбинировать с VUI. Благодаря прямому отклику устройства взаимодействие происходит естественней, нежели при вводе мышью или клавиатуры. Кроме сенсорных устройств NUI также можно использовать в игровых приставках.

К примеру, Nintendo Wii позволяет воспроизводить действия на экране за счет перемещения контроллера рукой. Среди других примеров – дополнение Kinect к Xbox, которое позволяет управлять игровым персонажем на экране движениями собственного тела. Что делает взаимодействие более натуральным.

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

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

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

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

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

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

Руководство по разработке пользовательского интерфейса для телевизионных приложений


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


Для того, чтобы управлять новыми телевизорами, не требуются антенны и кабельные приёмники. Мы используем технологии Smart или стриминговые приставки (такие как Roku или Apple TV), а также игровые консоли вроде Xbox и PlayStation. Каждое из этих устройств имеет гораздо более продвинутый пользовательский интерфейс, чем «старое доброе» экранное меню.


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


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

Экран


Чем телевизоры отличаются от компьютеров, телефонов и планшетов


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


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


По каким-то
неведомым нам причинам переразвёртка до сих пор используется в HD телевизорах. Сегодня рекомендуемые границы безопасной области для пользовательского интерфейса составляют по крайней мере 5% от размеров экрана. Однако эти цифры могут меняться. Например, у Google безопасная область несколько уже, а у Apple — шире. Обычно мы устанавливаем границы этой области при построении сетки макета.


Для начала давайте ограничим экран стандартными размерами HDTV: 1920×1080 пикселей. При этом поля сверху и снизу равны 60 пикселям, а по бокам экрана — 90 пикселям.

Навигация


Влияние направленного входа на телевизионный интерфейс


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


Ещё одна традиция — управление телевизионными интерфейсами с помощью D-pad — четырёхкнопочной крестовины со стрелками (исключением является только невероятно красивый и настолько же неудобный
LG Bean Bird). Установленная на пульте или на джойстике система D-pad ограничивает навигацию четырьмя направлениями: вверх, вниз, влево и вправо. Поэтому сетка является наиболее естественной структурой для телевизионного интерфейса.



Apple TV (верхнее фото) для того, чтобы выделить элемент, на котором стоит курсор, делает его более объёмным, а HBO GO (нижнее фото) отмечает его с помощью голубой рамки


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


Давайте воссоздадим обычный макет телевизионного пользовательского интерфейса с одной горизонтальной строкой контента. Поставим курсор на первый элемент.

Вход


Как пульт помогает людям общаться с телевизором


8 этапов процесса разработки интерфейса мобильного приложения

От переводчика: Роман Гапонов — сооснователь компании Django Stars, которая занимается разработкой веб- и мобильных приложений. Основываясь на личном опыте и опыте своей компании, Роман написал статью о процессе разработки пользовательского интерфейса. Изначально она была размещена на Medium, на английском языке. Перевод этой статьи публикуется нами на Хабре.

Немного приятного: в этой статье (а это уже второй материал о мобильной разработке, первый здесь) есть своеобразная пасхалка, которая позволяет получить скидку на курс Skillbox и агентства Agima по мобильной разработке. Это ребус, который при расшифровке даст слово или название решения из сферы разработки мобильных интерфейсов. Скидка за угаданный ребус — 10%. Ребусы есть и в других наших статьях из этой серии. Скидки суммируются, и если собрать их все, можно получить курс за смешную цену.

Создание концепции

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

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

Финтех-приложение. Много иконок, они не слишком крупные, но работать с ними удобно. Обилие разнообразных функций

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

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

Брейнсторминг и эскизы

Как только концепция проекта ясна, двигаемся к следующему этапу — брейнстормингу. Он нужен, чтобы превратить идею интерфейса в реальность. Мы в Django Stars берем ручку и лист бумаги — это быстрее, чем использование таких продвинутых инструментов, как Balsamiq Mockups, Sketch, Photoshop и InVision.

Диаграмма переходов

Создание эскиза дает нам структуру интерфейса. Но как пользователь должен взаимодействовать с ним? Здесь поможет User Flow Diagram. Она проиллюстрирует логику продукта, показав всевозможные способы взаимодействия с интерфейсом, дорожную карту этих взаимодействий и состояние интерфейса на каждом этапе.

Утверждение структуры и диаграммы переходов

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

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

Выбор стиля интерфейса

Когда клиент все утверждает — можно двигаться дальше. Что будем делать? Выберем стиль интерфейса. Есть множество вариантов: от минимализма и Metro до material design и скевоморфизма. На этом этапе мы просим клиентов прислать несколько ссылок на примеры стиля интерфейса, который им нравится, а также спрашиваем об их планах на ближайшее будущее продукта. Мы уделяем внимание текущим трендам, масштабированию интерфейса, определяем время, которое необходимо на разработку и внедрение дизайна.

Подтверждение стиля

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

Курсы по теме: Fullstack мобильный разработчик.

Курс создан силами Skillbox и Agima. 4-месячная программа обо всех инструментах, без которых невозможна разработка мобильных продуктов.

Прототипирование, дизайн и их демонстрация

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

Wireframe

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

Макет

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

Кликабельный прототип

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

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

Анимированные flow

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

Утверждение дизайна

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

В качестве вывода

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

Skillbox рекомендует

20 заповедей дизайна пользовательского интерфейса / Хабр

Это перевод оригинальной статьи Principles of User Interface Design

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

— Пол Рэнд (Paul Rand)

1. Обязанность интерфейса — обеспечение взаимодействия

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

2. Ясность прежде всего

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

3. Внимание любой ценой

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

4. Под контролем пользователей

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

5. Лучшее управление — прямое управление

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

6. Один экран — одна основная задача

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

7. Второстепенная задача, знай свое место

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

8. Место для шага вперед

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

9. Поведение определяет внешний вид (или «функция определяет форму»)

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

10. Как важно быть последовательным

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

11. Четкая иерархия — всему голова

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

12. Грамотная организация снижает когнитивную нагрузку

Джон Маэда (John Maeda) в своей книге Simplicity пишет, что грамотная организация элементов интерфейса позволяет придать экрану менее загруженный вид. С помощью продуманной организации элементов вы сможете продемонстрировать связи между ними, и освоить такой интерфейс пользователям будет куда проще. Группируйте схожие элементы, располагайте их на экране таким образом, чтобы пользователям стало понятно, как они связаны между собой. Благодаря грамотной организации контента можно значительно снизить когнитивную нагрузку пользователей. Если в самом дизайне будут наглядно продемонстрированы связи между элементами, пользователям уже не придется мучительно в них разбираться! Не заставляйте пользователей лишний раз напрягаться — лучше просто покажите им все эти связи между элементами интерфейса с помощью вашего дизайна.

13. Подсказывай, а не указывай: роль цвета

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

14. Не все сразу

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

15. Подсказывай с умом

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

16. Момент истины: нулевое состояние

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

17. Текущие проблемы — главные проблемы

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

18. Лучший дизайн — невидимый дизайн

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

19. Расширяем кругозор

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

20. Неиспользуемый интерфейс — плохой интерфейс

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

Автор: Joshua Porter

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

Обзор разработки пользовательского интерфейса — приложения Win32

  • 2 минуты на чтение

В этой статье

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

Пользовательский интерфейс приложения и взаимодействие с пользователем

Для начала необходимо пояснить термины «пользовательский интерфейс» и «взаимодействие с пользователем».

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

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

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

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

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

Ниже описаны типичные этапы процесса разработки пользовательского интерфейса:

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

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

Реализация

  • Prototype — Разработка макетов бумажных или интерактивных экранов, ориентированных на интерфейс и не содержащих отвлекающих элементов визуального дизайна.
  • Construct — создайте приложение и подготовьтесь к запросам на изменение дизайна.

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

  • Юзабилити-тестирование — протестируйте приложение с различными пользователями и сценариями.
  • Тестирование доступности — протестируйте приложение с помощью доступных технологий и автоматизированных средств тестирования.

.

Домашняя страница разработки пользовательского интерфейса — Финансы и операции | Динамика 365

  • 3 минуты на чтение

В этой статье

Важно

Dynamics 365 for Finance and Operations превратился в специализированные приложения, которые помогут вам управлять конкретными бизнес-функциями.Дополнительные сведения об этих изменениях см. В Руководстве по лицензированию Dynamics 365.

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

Пользовательский интерфейс для приложений Finance and Operation значительно отличается от интерфейса для Microsoft Dynamics AX 2012. Клиент в Dynamics AX 2012 — это приложение Microsoft Win32, которое имеет расширения, использующие элементы управления ActiveX, WinForm или WPF. Логика приложения X ++ выполняется на клиенте для методов формы и таблицы, а некоторая логика выполняется на сервере.Что касается элементов управления, то интерфейс прикладного программирования логики X ++ (API) и физический элемент управления Win32 тесно связаны с клиентом. Клиент — это веб-клиент HTML, работающий во всех основных браузерах. Эти браузеры включают Microsoft Edge, Internet Explorer 11, Chrome и Safari (см. Системные требования). Переход на веб-клиент привел к следующим изменениям клиентских форм и элементов управления:

  • Физическое представление форм и элементов управления теперь в браузере — это HTML, JavaScript и CSS.
  • Элементы управления формой разделены на логическую и физическую части. Логический API X ++ и связанное с ним состояние выполняются на сервере.
  • Логическая и физическая части синхронизируются посредством сервисных вызовов, сообщающих об изменениях с каждой стороны. Например, действие пользователя на клиенте создает вызов службы к серверу, который либо отправляется немедленно, либо ставится в очередь, чтобы его можно было отправить позже.
  • Уровень сервера сохраняет состояние формы в памяти, пока форма открыта.

Метамодель формы продолжает использоваться для определения элементов управления и логики приложения.Этот подход поддерживает почти все существующие метамодели Form, Form DataSource и Form Control, а также методы переопределения X ++. Однако некоторые типы элементов управления, свойства и методы переопределения были удалены либо из-за несовместимости с новой платформой, либо из соображений производительности. Например, элементы управления ActiveX и ManagedHost больше нельзя использовать для добавления настраиваемых элементов управления, поскольку они несовместимы с платформой HTML. Вместо этого была добавлена ​​новая расширяемая структура управления, которая позволяет добавлять дополнительные элементы управления.

Учебники

Формы

Органы управления

Сообщения

Рекомендации по шаблонам формы

Расширяемость управления

.

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

  • 6 минут на чтение

В этой статье

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описание проблем

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

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

Ниже приведены дополнительные примеры постановок задач:

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

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

Приоритеты

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

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

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

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

Концептуальный проект

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

Логический дизайн

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

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

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

Физическая конструкция

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

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

.

Следуя руководству по интерфейсу пользователя — приложения Win32

  • 2 минуты на чтение

В этой статье

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

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

Руководства по пользовательскому интерфейсу

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

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

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

  • Стандарты.

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

  • Местные правила или руководство по стилю.

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

Не полагайтесь исключительно на инструкции

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

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

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

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

.

Отправить ответ

avatar
  Подписаться  
Уведомление о