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

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

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

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

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

Данная статья является плодом совместных усилий Самуэля Моро (Samuel Moreau), менеджера команды UX Design, Брэда Вида (Brad Weed), директора UX Design and Research for Windows and Windows Live, и Джули Ларсон-Грин (Julie Larson-Green), вице-президента по программному менеджменту Windows Experience. Ввиду огромного количества комментариев, описывающих идеи конкретных функций, мы подумали, что было бы здорово рассказать о нашем подходе к процессу дизайна и о том, как из конкретных идей рождаются функции.


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

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

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

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


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

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

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


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

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

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

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

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


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

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

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


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

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


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

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


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

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

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

Для Windows 7, как и для любого другого релиза, у нас предусмотрены "принципы дизайна". Это принципы представляют поставленные нами цели — мы привыкли рассматривать принципы дизайна ОС как признаки антропоморфизма (или очеловечивания) продукта. Это было темой выступления Сэма на конференции PDC.
И как указано во введении к статье, невозможно дважды войти в одну воду. Мы должны решить. Мы могли бы написать массу статей по вопросам настройки, режимов совместимости и т.д. Мы прислушиваемся к мнению пользователей, поэтому мы прикладываем огромные усилия к тому, чтобы обеспечить возможность настройки ОС и одновременно ее стабильность и производительность. Некоторые из нас принимали участие в разработке Office 2007 и есть исследование Гарвардской бизнес-школы о необходимости реализации "режима совместимости" в Office 2007. Для нас в тот момент это было трудным решением.


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

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

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

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


Источник: http://blogs.msdn.com/e7ru
Перевод: deeper2k