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

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

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

Статья описывает некоторые общие проблемы оболочки менеджера программ в 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 года в статусе помощника для обеспечения сервисов юзабилити.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#дизайн