Май 2016

Том 31 номер 5

Visual Studio - Развиваем методики Lean UX

Карл Мелдер | Май 2016

Продукты и технологии:

Visual Studio, диагностика, отладка, PerfTips, условные точки прерывания

В статье рассматриваются:

  • бережливая разработка;
  • Lean UX;
  • обратная связь с пользователями;
  • дизайн продуктов;
  • дизайн функций.

В Visual Studio 2015 Microsoft предложила несколько новых средств отладки и диагностирования, которые подробно описаны в статье Эндрю Холла (Andrew Hall) в номере «MSDN Magazine» за март 2016 года «Debugging Improvements in Visual Studio 2015» (msdn.com/magazine/mt683794). Для средств, в которых произошли существенные изменения UX, Microsoft взяла на вооружение подход Lean UX, где для получения информации, на основе которой ведется разработка, используются итеративные эксперименты и прямые отклики от пользователей.

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

Lean UX

Lean UX дополняет методики бережливой разработки (lean development), завоевывающие популярность в нашей отрасли. Эрик Рис (Eric Ries) определил бережливую разработку как методику «Разработка, измерение и обучение» в своей вышедшей в 2011 году книге «The Lean Startup» (Crown Business), в которой он описывает подход с использованием «экспериментов, основанных на бизнес-гипотезах». Аналогично Lean UX — это набор принципов и процессов, где центральное место занимает непрерывная начинающаяся на очень ранней стадии проверка пользователями, когда вы проводите эксперименты по проверке своих гипотез о пользователях и дизайне продукта в чрезвычайно коротких циклах. Итерации по разработке дизайна выполняются очень быстро, и их основная цель — решение конкретных задач пользователей. Хорошим справочником по методике является вышедшая в 2013 году книга Джеффа Готелфа (Jeff Gothelf) «Lean UX» (O’Reilly Media), в которой он приводит инструкции и диаграммы, помогающие группам внести ясность в то, чего они надеются достичь.

Для групп, разрабатывающих отладочные среды в Visual Studio, Lean UX — подход с активным коллективным взаимодействием, в котором вся группа, включая менеджеров программ, исследователей UX, разработчиков и дизайнеров UX, участвует в генерации идей, генерации гипотез и интерпретации показанного и рассказанного пользователями.

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

Проблемы дизайна

Технологии Microsoft — богатый источник данных, благодаря которым разработчики могли бы использовать удобные способы диагностирования проблем. Однако в UX-лабораториях пользователи раз за разом прибегают к ручному «прохождению» выполняемого кода, несмотря на преимущества, которые обеспечивают такие инструменты, как Profiler. Данные мониторинга, трассировки и ведения журналов остаются невостребованными из-за неактивного использования Visual Studio Profiler, несмотря на уверенность, что он способен сделать поиск проблем с производительностью гораздо эффективнее. Для таких инструментов, как Visual Studio, с которыми пользователь работает восемь или более часов в день, может оказаться непросто убедить его сменить свой стиль работы. Поэтому группы предпочитают следовать естественному стилю работы пользователя при анализе проблем производительности с помощью отладки и создании пользовательской среды.

Технологии Microsoft — богатый источник данных, благодаря которым разработчики могли бы использовать удобные способы диагностирования проблем.

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

Процесс исследования

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

Исследование UX часто делят на количественную и качественную категории, когда развитие бизнеса и продукта определяется сочетанием мониторинга/анализа и отзывов от пользователей. На раннем этапе количественных исследований получение отзывов пользователей означает получение их реакции на идеи. Группа принимает во внимание не только то, что они говорят, но и их физические реакции, выражения лиц и интонации голоса. Кроме того, пользователям дают практические задания, например исправить «баг», связанный с производительностью, без помощи со стороны исследовательской группы, которая наблюдает за ними, как показано на фотографии на рис. 1. Это значит, что пользователям дают побороться. Сотрудники группы снимают их на видео для последующего анализа и делают заметки о том, что они увидели и услышали. Наблюдения за пользователями помогают группе понять их стиль работы и идентифицировать невысказанные потребности — усовершенствования, о которых пользователи могут не просить, но способные существенно улучшить продукт.

A Research Session with a User
Рис. 1. Исследовательский сеанс, проводимый с пользователем

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

Каждую неделю к непрерывному исследованию новых перспектив привлекались различные участники. Пользователи, которые выделялись для исследований, участвовали в них и за которыми мы наблюдали, могли работать как во внутренних группах, так и у поставщиков. Группа не искала пользователей, имеющих опыт именно в диагностике. Вместо этого привлекались просто активные пользователи Visual Studio. Значит, каждую неделю у нас были пользователи с разными навыками, опытом и рабочим контекстом. Это дало группе возможность каждую неделю узнавать что-то новое и позволило систематизировать информацию. Кроме того, группа могла развивать свои идеи так, чтобы они имели успех у более широкой аудитории.

Не менее важным было обеспечить баланс во взаимодействии группы с пользователями. То, как задавались вопросы, могло существенно повлиять на результаты и сделать обсуждение пристрастным. Группа вырабатывала привычку всегда задавать вопросы, допускающие различные ответы: вопросы исследования определялись тем, что сказал или не сказал пользователь. Например, если пользователь утверждал, что ему что-то не нравится, мы просто просили: «Расскажи об этом подробнее». Группа не пыталась что-либо предположить и при каждой возможности выдвигать предположения и гипотезы. Эти навыки относятся к области UX и использовались каждым членом группы. Если вы хотите подробнее познакомиться с этими методиками интервьюирования, рекомендую книгу Синди Альварес (Cindy Alvarez) «Lean Customer Development» (O’Reilly Media, 2014).

Ранние сеансы «с учащенным пульсом» и непоколебимый подход к работе

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

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

Группа сначала визуализировала идеи в Photoshop, причем крайне опытному дизайнеру требовалось более дня на то, чтобы сгенерировать макет для получения отзывов. Photoshop в большей мере помогает создавать высококачественный UI. Затем группа начала использовать вместо Photoshop Microsoft PowerPoint и надстройку для создания эскизов (aka.ms/jz35cp), что позволило каждому члену группы быстро создавать представления своих идей в среднем качестве. Такие эскизы давали пользователям представление о том, как может выглядеть реализация, но в то же время были достаточно грубыми для того, чтобы можно было сказать пользователям, что это рабочий вариант дизайна и полученная от них информация напрямую повлияет на него. Конечным результатом было то, что стало гораздо проще отбросить итоги 30-минутной работы, если эксперимент терпел неудачу. Кроме того, можно было проверять идеи — даже если группа знала, что они не заработают на практике, отзывы помогали генерировать новые идеи.

Чтобы получить отзывы на модель взаимодействия с пользователем, каждый слайд презентации PowerPoint представлял либо действие пользователя, либо ответ системы на это действие. При создании набросков взаимодействия мы показывали с помощью значка курсора, где пользователь сделает щелчок. Это было полезно при обмене идеями и проработке деталей. Однако мы удаляли значок курсора перед показом наброска пользователям. Это позволяло группе спросить пользователей, что они собираются делать далее, и, таким образом, с минимальными издержками выявить возможные проблемы обнаружения функций. В случае каждого слайда с ответом системы мы также спрашивали пользователей, добились ли мы успеха, что позволяло знать, получили ли мы устраивающий нас отзыв. Такой подход к получению отзывов в исследовании UX называют «процессом когнитивного прохождения» (cognitive walkthrough process), и он может помочь идентифицировать кое-какие проблемы на самых ранних этапах проектирования взаимодействия. При этом он позволяет заранее выявить области, о которых надо позаботиться и в которых для доведения решения до ума потребуются дальнейшие итерации и эксперименты.

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

«О, это потрясающе!»

Группе нужно было найти способ показать в коде информацию о производительности, не снижая читаемость кода, и дать пользователям возможность вести отладку, «охватывая» код. Code Lens — средство Visual Studio, позволяющее видеть информацию о хронологии редактирования, «багах», тестировании модулей и ссылках, — послужило источником идей для создания потенциальной модели взаимодействия и визуального дизайна. Группа экспериментировала с макетами нескольких идей, показывая пользователям, как можно было бы выводить показатели производительности в миллисекундах, когда разработчик выполняет код в пошаговом режиме (рис. 2).

An Early Mockup Showing Performance Data in a Debugging Session
Рис. 2. Ранний макет, где во время сеанса отладки показываются данные о производительности

Самым первым признаком того, что мы что-то нащупали, оказалось то, что участник (это был менеджер по разработке) оживился во время ознакомления со средой. Должен подчеркнуть, что ему просто показали предлагаемую среду без какой-либо базовой информации. Когда он осознал, что видит, он начал задавать вопросы о подробностях и был весьма увлеченным, когда говорил. Он сказал, что это могло бы быть решением проблемы, заключающееся в том, что его начинающие разработчики выбирают неправильные подходы при кодировании и в результате у приложений оказывается низкая производительность. В его текущем процессе проблемы с производительностью разрешались в ходе трудоемкого процесса анализа кода, который был тяжелым бременем для него и его группы. Он почувствовал, что эта идея могла бы помочь его начинающим разработчикам усвоить, как писать производительный код, когда они только начинали этим заниматься. Он дал такой комментарий: «Может ли это [PerfTip] быть политикой [в Visual Studio]?». Другой пользователь после осознания ценности этой возможности, заметил: «Вот что выделяет Visual Studio — возможности, доступные, когда вы «стоите» на строке кода!».

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

Проработка деталей

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

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

Группа реализовала минимальную версию средства, работающую только в определенных условиях. Затем создала приложение с проблемами в логике и производительности, чтобы пользователи могли заниматься диагностикой. Пользователей просили идентифицировать конкретную причину проблемы. Если им не удавалось это сделать, группа могла определить, почему они не добились успеха, исходя из того, что она видела и слышала. Затем можно было изменить дизайн и повторить попытку на следующей неделе. Кроме того, в это время была подготовлена доступная для внешних пользователей CTP-версия и осуществлялся ее мониторинг. В ней PerfTips связывались с окном свойств, чтобы пользователи при желании могли без труда изменить пороговые значения. Группа пришла к следующим выводам.

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

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

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

Заметки

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

Microsoft OneNote оказалось очень удобным приложением для того, чтобы планировать тесты, сохранять необработанные заметки и быстро набрасывать выводы. У нас всегда был специальный «ответственный за заметки», который записывал все, что видит и слышит. Это давало другим членам группы возможность взять передышку и полностью сосредоточиться на пользователе. Для тех, кто не мог присутствовать физически, мы организовывали «прямые линии» по Skype; каждый член группы получал приглашение понаблюдать и поучиться. Кроме того, эти сеансы записывались для членов группы, которые пропустили их из-за конфликтов во встречах и хотели бы посмотреть их позже. Еще видеозаписи позволяли заново посмотреть моменты, требующие дополнительного внимания. На совещаниях группы по результатам каждой недели давалась информация о том, что следует сделать на следующей неделе. Писать формальные отчеты не было необходимости, и это только замедлило бы всю работу.

Заключение

Проектирование и разработка PerfTips были лишь небольшой долей того, что мы делали, проводя еженедельные эксперименты. Мы исследовали множество идей, проводя до четырех экспериментов на пользователя каждую неделю. Переработка Breakpoint Settings — еще один пример экспериментов, которые проводились неделю за неделей, чтобы получить в результате итерации более удобную и эффективную среду. Применяя Lean UX, группа имела возможность снижать риски и в то же время черпать идеи из увиденного и услышанного на экспериментах. Эти эксперименты вывели работу наугад из формулы проектирования функциональности. Идеи поступали из многих источников, а источником вдохновения было наблюдение за естественным трудом разработчиков.

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

Поучаствуйте в программе

Группа исследования Microsoft UX ищет разработчиков всех типов, которые готовы напрямую поддерживать обратную связь и принять участие в нашем непрерывном эксперименте. Чтобы подписаться, оставьте на aka.ms/VSUxResearch немного информации о ваших технических знаниях и о том, как лучше с вами связаться.

Хотел бы особо поблагодарить всех, кто тем или иным способом участвовал в проекте. Вы только представьте себе «пятницы учащенного пульса», на которых толпа людей изо всех сил следит, учится и размышляет о том, как добавить в Visual Studio продуманную и полезную функциональность. Особую благодарность хотел бы выразить Дэну Тейлору (Dan Taylor), который возглавлял группу разработки и с высоко поднятой головой решал технические проблемы. Благодаря глубоким техническим знаниям и прагматичному подходу Эндрю Холла (Andrew Hall) группа все время двигалась вперед. Фрэнк Ву (Frank Wu) постоянно генерировал идеи в области дизайна и обладал сверхъестественной способностью ухватить суть идеи и найти способ выразить ее простыми словами.


Карл Мелдер (Karl Melder) — старший исследователь UX, постоянно применяющий при разработке UX свои знания и опыт в исследовании UX, в информатике, понимании человеческих и UI-факторов. Последние 15 лет занимается совершенствованием взаимодействия Visual Studio с разработчиками, ориентируясь на широкий круг пользователей.

Выражаю благодарность за рецензирование статьи экспертам Microsoft Эндрю Холлу (Andrew Hall), Дэну Тейлору (Dan Taylor) и Фрэнку Ву (Frank Wu).


Discuss this article in the MSDN Magazine forum