От идеи к функции: взгляд с точки зрения дизайна

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

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

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

Основной мыслью, которую пользователи хотят донести до нас, является возможность настройки всего и вся . Конечно , создавая платформу, мы хотели сделать ее максимально расширяемой и настраиваемой за счет массы доступныхAPI . Но суровая инженерная действительность состоит в том, что и настройка и расширяемость не обходятся даром – сразу же приходят мысли о производительности , сложности и совместимости . Только представьте функцию, имеющую два режима ( один включает новую функцию, второй – старую ) в одном выпуске. В следующем релизе функция может измениться, тогда будет четыре режима ( старый + старый , старый + новый , новый + старый , новый + новый ), в следующем – восемь и т.д. Сложность разработки стабильной и согласованной платформы состоит в том, что далеко не всегда удается реализовать все, что хотят пользователи, поэтому приходится делать выбор, как должна работать функция . Разработка функции подразумевает выбор, и порой очень сложный выбор . В то же самое время мы хотим, чтобы удобство самых распространенных задач – запуск приложений , управлениеокнами , работа с файлами и использование различной периферии – было максимальным . Это все должно отвечать нуждам широких масс с разными уровнями знания компьютера , а также обеспечиватьмеханизм персонализации и настройки . В каждом изнаших выпусковсочетаются фиксированные и настраиваемые элементы , поддержка существующего оборудованияи новых тенденций .

Данная статья является плодом совместных усилий Самуэля Моро ( SamuelMoreau ), менеджера команды UXDesign , Брэда Вида ( BradWeed ) , директораUXDesignandResearchforWindowsandWindowsLive , и Джули Ларсон-Грин ( JulieLarson - Green ) , вице-президента по программному менеджментуWindowsExperience . Ввиду огромного количества комментариев, описывающих идеи конкретных функций , мы подумали, что было бы здорово рассказать о нашем подходе к дизайну и о том, как из конкретных идей рождаются функции . – Стивен.

РазработкаWindows – отидеик функции

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

С точки зрения дизайна сложность разработки Windows заключается в широте ее использования. В некотором смысле, одним из магических элементов составляющих понятие «software» является «soft» (мягкий, гибкий), подразумевающий что разработчики могут предложить широкому диапазону групп пользователей различные опции за небольшую дополнительную цену, зависящую от количества этих возможностей (во многих комментариях согласованно предлагалось чтобы мы сделали все опции доступными и одновременно предоставили возможность их выбора и мы обсудили минимизацию стоимости в случае, когда компоненты не используются, будучи доступными). В то же время преимущества есть и у разработчиков, когда они заранее знают, что конкретный компьютер обладает базовым набором функций, и могут воспользоваться набором конкретных API, о которых известно, что они присутствуют и ведут себя определенным образом – т.е. платформой . От этого выигрывают и рядовые пользователи, потому что могут включить любой компьютер и не только увидеть знакомый интерфейс, но и сделать за ним свою работу, воспользоваться каким-либо устройством или запустить программу. Широта функциональности – ключевое преимущество Windows PC. С другой стороны, в этом и заключается основная проблема дизайна. Изучение, осмысление и реализация в Windows идей на базе различных источников информации – удивительно интересная и увлекательная часть процесса разработки.

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

В нашей структуре предусмотрена группа дизайнеров, отвечающих за разработку схемы взаимодействия пользователя с Windows, последовательность и визуализацию Windows. Программные менеджеры сотрудничают с дизайнерами в тот момент, когда последние пишут спецификации. Наряду с дизайнерами у нас есть и исследователи интерфейса (UX-researcher), которые проводят тестирование и утверждение дизайна, о котором мы говорили выше. Тут важно то, что для разработки функции мы используем все навыки, чтобы быть уверенными в полном владении ею и в прозрачности последовательных шагов конструирования. Для нас неприемлемо, что за создание продукта может отвечать всего один человек. Кто-то скажет, что такой подход может привести к проблемам, кто-то подумает, что такой продукт, разработку которого ведет большое количество людей, с огромным количеством функций, ориентированных на широкие массы пользователей, не может отвечать единой концепции (неважно, в разработке, тестировании, дизайне или маркетинге). Мы стараемся сделать так, чтобы инженеры отвечали за процесс разработки, чтобы продукты имели четкие спецификации, и чтобы они соответствовали нуждам пользователей Windows по всему миру. И что самое важное, с Windows 7 мы возобновили усилия в направлении "непрерывного" конструирования.

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

Выбрать вопрос илипридумать идею

Из различных источников мы берем идею – она может подразумевать серьезные изменения (к примеру, разработать интерфейс, поддерживающий новый способ ввода информации), нетривиальный подход (пересмотр парадигмы интерфейса для организации поддержки 3D-режима) или изменения/улучшения существующей функции (поддержка нескольких мониторов). Недостатка в идеях нет, поскольку, если говорить честно, сгенерить идею – это самое простое. Поток идей брызжет отовсюду – со всех концов нашей экосистемы, включая нас самих. Мы уже неоднократно говорили о комментариях и отзывах, полученных через этот блог, а это, сами понимаете, лишь один из способов получения свежих идей. Различные обзоры, корпоративные пользователи, линии поддержки пользователей, сборщики компьютеров, разработчики программного и аппаратного обеспечения, блоги, новостные группы, MVP и другие источники вносят неоценимый вклад в планирование и разработку наших продуктов.

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

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

Собрать информацию и статистику

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

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

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

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

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

Отличным примером этому служит один из комментариев к статье о панели задач. По словам его автора, порядок иконок в панели задач имеет настолько серьезное значение, что пользователь порой закрывает все открытые окна, перезапуская их в очередности, обеспечивающей необходимую последовательность приложений в панели задач. То есть, согласно телеметрии получалась довольно-таки странная последовательность действий: запуск/выход/запуск/выход/запуск/запуск. И лишь другие способы сбора информации помогли понять, в чем причина такого поведения. Поэтому если вы вне какого-либо контекста заявляете, что нужно сделать Windows проще, то вряд ли эта просьба окажется наверху списка запланированных на следующий выпуск дел. В этом маленьком примере объединены несколько интересных случаев – данные, собранные с помощью телеметрии, не отражают намерений пользователя; некорректно сформулированная просьба пользователя не позволяет нам поставить ее на верх списка важных дел; решение может принимать совершенно разные формы, но если проблема пользователя будет грамотно решена, итог может оказаться крайне полезным. Судя по нашему опыту, это лишь одна из «проблем», которая, по мнению пользователей, решается очень просто. Но мы хорошо выучили урок о том, что неважно, какую информацию или статистику нам удалось собрать, поскольку каждый раз кто-то из пользователей упоминает или предлагает это.

Построить гипотезу

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

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

Также важно понимать принятое в обществе мнение относительно построенной гипотезы, особенно в сегменте пользователей (конечных пользователей, энтузиастов, производителей компьютеров и т.д.). Это позволяет понять предпосылки для появления функции, а также узнать идеи пользователей по поводу ее решения. Существует масса примеров в истории, когда общественное мнение было настолько сильным, что приходилось вносить изменения в дизайн – тут следует вспомнить роль горячих клавиш для меню, столь необходимых в мире «DOS» (поскольку далеко не каждый компьютер оснащался компьютерной мышью), но абсолютно ненужных в мире Mac ввиду того, что они-то как раз мышами и оснащались. По общепринятому в мире DOS мнению, компьютерная мышь являлась дополнительным аксессуаром.

Провести эксперимент

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

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

Интерпретировать и обосновать

Итак, по получении вариантов решения проблемы мы приступаем к следующему шагу – интерпретации наших собственных мнений, результатов экспериментов и исследований, а также внешних (по отношению к команде разработчиков) отзывов. На этом этапе всегда есть место для подобных дискуссий: «Вариант ‘А’ лучше, поскольку он значительно упрощает обнаружение новой опции, но вариант ‘Б’ создает впечатление более глубокой интеграции в систему».

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

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

Выбрать

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

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

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

Для Windows 7, как и для любого другого выпуска, у нас предусмотрены «принципы дизайна». Эти принципы представляют поставленные нами цели – мы привыкли рассматривать принципы дизайна ОС как признаки антропоморфизма (или очеловечивания) продукта. Это было темой выступления Сэма на конференции PDC.

И как указано во введении к статье, невозможно дважды войти в одну реку. Мы должны решить. Мы могли бы написать массу статей по вопросам настройки, режимов совместимости и т.д. Мы прислушиваемся к мнению пользователей, поэтому прикладываем огромные усилия к тому, чтобы обеспечить возможность настройки ОС и одновременно ее стабильность и производительность. Некоторые из нас принимали участие в разработке Office 2007 и есть исследование Гарвардской бизнес-школы, о необходимости реализации «режима совместимости» в Office 2007. Для нас в тот момент это было трудным решением.

Реализовать и интегрировать

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

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

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

Сэм, Брэд и Джули