От анализа рынка до широкого распространения продукта: как развивается дизайн-система Microsoft

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

Вопросы задавал старший разработчик контента в Miscrosoft Дэвид Бетц.

Скоро будет день рождения Fluent.

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

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

То есть у вас SaaS-модель, а дизайн-система — услуга?

Да, дважды в год мы решаем, что для нас приоритетно и что будет в следующем релизе. У нас всегда много идей и обратной связи. Мы пользуемся такими сервисами, как Feedback Hub, Insider Program, разговариваем с потребителями, участвуем в мероприятиях вроде MVP Summit и Build, чтобы собрать информацию и обратную связь от покупателей — так мы приоритизируем свою работу.

Этот цикл позволяет нам осознавать возможности индустрии. В Microsoft есть много команд-партнёров вроде Office, Cloud and Enterprise (C&E) и Xbox, которые занимаются такой же работой, так что мы взаимодействуем и взаимодополняем друг друга. В конце концов мы создаём инструменты для разработчиков приложений, чтобы те могли создавать хороший опыт для своих потребителей, так что наша работа должна быть согласованной.

Мы также пользуемся обратной связью, чтобы сосредоточить свою работу на определённых компонентах нашей платформы, например основы UX, элементы управления или шаблоны. Иногда это выглядит так: «Этот вариант был не совсем хороший, нам надо его лучше настроить» или «Здесь должно открываться быстрее или медленнее», или «Управление, которое мы тут сделали, неудачное — его надо отрегулировать».

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

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

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

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

Инженеры и дизайнеры собираются вместе, чтобы понять объём идеи, сколько усилий потребуется, в чём выгода для покупателя. Некоторые проекты могут длиться только в течение одного релиза, другие растягиваются на несколько релизов — зависит от сложности идеи. Выражаясь терминами Agile, инкубационный период — это изучение журнала пожеланий (backlog).

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

Когда у нас сложился понятный объём работ, когда мы понимаем, как функциональность должна выглядеть, и готовы начать писать реальный программный код — мы переходим к этапу систематизации. Это этап создания готового к потреблению интерфейса прикладного программирования (API) эксклюзивными (first-party) разработчиками. Он нужен, чтобы убедиться что мы не сделали что-то, что не входило в первоначальный план.

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

Когда мы готовы провести релиз функциональности, мы переходим к этапу критической массы. Функциональность переходит в этот этап, когда есть хотя бы несколько примеров эксклюзивного опыта: можно получить их от команды Windows Shell, из эксклюзивных (созданных Microsoft) приложений, Xbox или Office.

После того как эксклюзивные покупатели смогли попробовать интерфейсы прикладного программирования и функциональность, можно презентовать их на таких мероприятиях, как Build: «Это элемент Fluent. Мы сделали следующие управление и функциональность. Это вот код. А вот — пара примеров этой функциональности или элемента на практике». И так далее.

К этому моменту продукт готов, чтобы дизайнеры третьей стороны могли его использовать и создавать опыт для своих потребителей?

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

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

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

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

Ваша аудитория состоит в основном из дизайнеров и разработчиков. Как вы с ними взаимодействуете?

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

Теперь мы всё больше пишем в Medium, Twitter и на сайте Microsoft Design (который будет перезапущен в этом мае), чтобы активизировать и вовлечь дизайн-сообщество. Есть такая идея, и эта работа сейчас проводится.

Должен ли я как дизайнер присоединиться к программе Insider?

Да, конечно. Fluent настолько же для дизайнеров, насколько для разработчиков. Мы хотим говорить о создателях приложений в целом. И прямо сейчас всё, о чём мы говорили, направлено на вовлечение в Центр разработки для Windows. И под вовлечением мы имеем в виду, что можно посмотреть на API, загрузить пробные приложения, посмотреть на код.

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

Мы работаем над этим сейчас.

Вы уже работаете с командами из Office, C&E, Xbox, HoloLens и Cortana (а также с участниками Insider и наиболее ценными специалистами). Все эти дизайнеры помогают команде Fluent отлаживать и улучшать продукт. Но самое важное, что Fluent открыт и для дизайнеров третьей стороны. Помимо того, что они становятся участниками Insider, как ещё вы вовлекаете их в совместное творчество?

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

И на других крупных мероприятиях, таких как Ignite и Dev Days, мы также представляем своих коллег дизайнеров и разработчиков. Они показывают и пошагово рассказывают о коде, кратко знакомя с ним наиболее ценных специалистов. Или спрашивают мнение о запущенном продукте. Наступил важный период, когда мы все объединяемся.

#дизайн #microsoft