Как создавался интерфейс Windows 95

Материал сотрудника Microsoft Кента Салливана о процессе и результатах проектирования нового пользовательского интерфейса для версии Windows 1995 года.

Перевод опубликован в издании «Хабрахабр».

Как создавался интерфейс 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). Публикуем её, чтобы документ никогда не потерялся.

Как создавался интерфейс Windows 95

Резюме

В разработке пользовательского интерфейса для большого коммерческого программного продукта вроде 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 месяцев) мы знали, что разработка по традиционной каскадной модели («Водопад») не предоставит нам достаточной гибкости для достижения наилучшего решения. Нас беспокоило, что традиционный подход может привести к созданию непригодной системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Начинающих и многих средних пользователей путал двухпанельный интерфейс менеджера файлов. Они были не уверены в связи между панелями и в том, как переходить в другие папки. Новичков часто поражала визуальная сложность менеджера файлов — и они испытывали базовые проблемы, например, непонимание возможности существования одних папок внутри других папок. Многих пользователей смущала иконка Parent Folder. Она появлялась в каждой папке и выглядела как файл, хотя на самом деле это элемент навигации для выхода на предыдущий уровень иерархии.
File Cabinet, ранняя версия менеджера файловой системы
File Cabinet, ранняя версия менеджера файловой системы
  • Пользователей всех уровней квалификации смущала папка Programs. Мы думали, что наличие на рабочем столе такой папки с другими папками и ссылками на программы внутри станет естественным для пользователей Windows 3.1, привыкших к менеджеру программ, и в то же время её будет относительно просто освоить новичкам. Мы ошибались. Новички быстро заблудились во всех папках (в отличие от File Cabinet, здесь каждая папка открывалась в новом окне), а у других пользователей возникло много проблем с попытками понять, видят они реальную файловую систему и её файлы или просто ссылки на настоящие файлы.
  • У пользователей возникли значительные сложности с определением, для чего нужна каждая из трёх кнопок в трее, а позже возникли трудности с запоминанием, куда идти для выполнения конкретной команды, поскольку в определённых контекстах их функции пересекались (например, для поиска чего-то в разделе помощи Help нажать Find или Help?).

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

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

Затем провели несколько лабораторных исследований, сравнивая Windows 3.1 и Windows 95 с учётом этих двадцати задач. Мы также провели собеседования с профессиональными преподавателями 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, но определённо должно быть привлекательным для пользователей любого уровня, потенциально по разным причинам.

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

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

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

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

Эволюция процесса спецификаций интерфейса пользователя

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

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

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

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

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

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

Отдельный интерфейс пользователя для новичков

Первым важным изменением дизайна, которое мы рассмотрели, стал отдельный интерфейс («оболочка») для начинающих пользователей. Дизайн быстро набросали в Visual Basic и протестировали в лаборатории юзабилити.

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

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

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

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

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

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

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

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

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

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

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

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

Мы надеялись, что проблему можно решить, если свёрнутые окна будут отличаться на вид и иметь больший размер. Мы ошиблись. Пользователи испытывали практически такие же затруднения, как в случае с Windows 3.1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отслеживание открытых тикетов

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

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

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

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

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

Отчёт

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

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

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

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

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

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

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

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

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

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

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

Выводы

Для многих сотрудников отдела проект Windows 95 стал первым опытом итеративной разработки, тестирования юзабилити и отслеживания проблем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3535
60 комментариев

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

10
Ответить

А где она в iOS и андроидах? Чем она лучше рабочего стола/домашнего экрана?

1
Ответить

Классная статья, спасибо, вернулся в воспоминания с интересом.

Только мало, приносите ещё такого, пожалуйста! :)

10
Ответить
Комментарий удалён модератором

Метро - это не погоня за трендами, это сам тренд и есть. Уже после него к флэту подтянулся весь веб, и даже ios. Единственное что осталось - OSX, оно до сих пор выглядит как говно динозавра со своим сквевоморфизмом.

Ответить

Ура, статья не про биткойн наконец)

9
Ответить

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

2
Ответить