автор Jeff Gothelf перевод

Куркина Д. А.

Lean UX
ПРИМЕНЯЕМ ПРОСТЫЕ
ПРИНЦИПЫ ДЛЯ УЛУЧШЕНИЯ
ПОЛЬЗОВАТЕЛЬСКОГО ОПЫТА
Слово “lean” переводится на русский как
«тощий», «худой», «постный». Если переводить
этот термин более специальным образом, то —
«бережливый», «экономный»,
«минималистический». Например, уже есть
термин «бережливое производство» — перевод
английского “lean production”. Бережливое
производство подразумевает постоянное
устранение всех видов потерь — это
достигается, в том числе, максимальной
ориентацией на потребителя. То же самое
верно и для подхода бережливого (тощего)
UX-дизайна.
Оглавление

ПРЕДИСЛОВИЕ

РАЗДЕЛ I ПРЕДСТАВЛЕНИЕ И ПРИНЦИПЫ

Почему Lean UX

Принципы

РАЗДЕЛ II ПРОЦЕСС

Видение, Прототипирование и Результаты

Командный дизайн (Collaborative Design)

MVP и Исследования

Обратная связь и исследования

РАЗДЕЛ III РЕАЛИЗАЦИЯ

Интеграция Lean UX и Agile

Проведение организационных изменений

ПРЕДИСЛОВИЕ

Читая Lean UX, вы отправитесь в путешествие по новому пути

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

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

чтобы заглянуть внутрь. Что бы вы увидели? Так как это
современная компания, вы бы увидели, что каждый блок
разработан для максимальной эффективности. Чтобы достичь этой
эффективности, вы, вероятно, нашли бы очень итеративный,
ориентированный на клиента подход к решению проблемы.В
производстве вы встретите традиционное мышление. В Разработке
или IT, возможно, некоторые вариации гибкой разработки. В
Маркетинге - развитие клиентов. В операциях - DevOps. И конечно
в Дизайне, новейшие методики дизайн мышления, интерактивного
дизайна и пользовательских исследований.

Вернувшись обратно к нашей высокой точке обзора, нам

простительно было бы подумать: «Эта компания использует
множество строгих, основанных на гипотезах, ориентированных на
клиента и итеративных методологий. Конечно, должно быть, это
чрезвычайно гибкая компания, способная быстро реагировать на
изменения рыночной конъюнктуры и постоянно обновляться!» Но
те из нас, кто работает в современных компаниях знают, как далеко
это от правды.
 Как это возможно, что наши дисциплинарные блоки работают с
ловкостью, но наши компании безнадежно жестки и медлительны?
С нашей далекой позиции дело в том, что мы упустили нечто
существенное. Хотя наши отделы может ценить аджайл технологии,
взаимосвязи между ними все еще погрязли в устаревшем
промышленном прошлом.

Рассмотрим только один пример, который, я надеюсь, покажется

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

И что происходит в конце этого процесса? Дизайнеры с

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

Однажды я разговаривал с компанией, которая заказала — за

ужасные деньги — многолетнее изучение их отрасли. Результатом
стало впечатляющее “видение будущего”, представленное в их штаб-
квартире. В этой комнате вы можете увидеть, как будет развиваться
их отрасль следующие 10 лет, в комплекте с рабочими демо
футуристических концепция продукта. Вы можете догадаться, что
произошло в течение последующих 10 лет: абсолютно ничего.
Компания сменила сотни или тысячи руководителей, менеджеров и
рабочих через этот проблеск будущего. И на самом деле, 10 лет
спустя, эта комната больше не выглядит футуристично. Вопреки
всему, ее прогнозы оказались в значительной степени точными. И
все же компании не удалось коммерциализировать даже одну из
рекомендаций в сопроводительном документе со спецификациями.
Поэтому я спросил компанию, что они планируют делать затем; они
сказали мне, что возвращаются к тем дизайнерам что предложили
концепт развития и спрашивают их прогноз на ближайшие 10 лет!
Компания обвинила своих разработчиков и руководителей в их
неспособности коммерциализировать проекты, а не дизайнеров.

Когда я рассказываю эту историю не дизайнерам, они в ужасе и

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

Но вина не в дизайнерах, или разработчиках, или даже в

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

Прошло около четырех лет с тех пор, как я начал писать и

говорить о новой концепции под названием Lean Startup, и всего год
с тех пор, как я опубликовал “Бережливый стартап: как
современные предприниматели используют непрерывные
инновации чтобы добиться радикально успешного бизнеса (Crown
Business)”. За это время, я видел, как идеи растут и
распространяются — от промышленности к промышленности, от
сектора к сектору и функции. Каждый раз, когда мы сталкивались с
новыми территориями, мы полагались на дальновидных лидеров,
чтобы помочь объяснить принципы, лежащие в основе и
разработать новые процессы их реализации.

Lean UX является важным шагом в этой эволюции. Впервые у

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

Lean Startup-это большая палатка. Он опирается на устоявшиеся

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

Я надеюсь, что все мы откликнемся на призыв Джефф Гофелфа

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

Пришло время разрушить бункеры, объединить кланы и

приступить к работе.

Eric Ries January 30, 2013 San Francisco, CA

РАЗДЕЛ I

ПРЕДСТАВЛЕНИЕ
И ПРИНЦИПЫ

В первом разделе я расскажу о Lean UX и его основных

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

Глава 1, « Почему Lean UX?» предоставляет краткую историю

проектирования UX и объясняет почему настало время для
эволюции этого процесса.

В главе 2 «Принципы» я подробно рассматриваю ключевые

принципы, которые управляют процессом Lean UX. Эти принципы
предлагают основу для более бережливого процесса
проектирования продукта, а также дают направления для команды
разработчиков продукта. Они имеют решающее значение для успеха
Lean UX и, если их инкорпорировать в вашу организацию, будет
иметь глубокое влияние на вашу культур, продуктивность и успех
ваших команд.
ГЛАВА 1

Почему Lean UX

Когда в 1980-х и 1990-х годах дизайнеры начали работать с

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

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

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

Сегодня мы сталкиваемся с новой реальностью. Интернет

радикально изменил распространение ПО. Большинство программ
теперь распространяется в интернете. Мы больше не ограничены
физическим производственным процессом и свободны работать
гораздо более короткими циклами выпуска.

Но слово “свободный « в действительности не описывает эту

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

В этой новой реальности традиционный подход “сначала

разберись во всем» не выполним. Так что же делать дизайнерам?

Пришло время перемен. Lean UX (UX = пользовательский опыт)

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

Lean UX коллаборативный и кросс-функциональный

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

Lean UX также позволяет нам изменить то, как мы говорим о

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

Lean UX - это три вещи. Дизайнерам его проще всего понять

как изменение процесса. Но дело не только в этом. Это мышление,
которое позволяет нам работать по-новому. Это также способ
думать об управлении программным обеспечением. Я буду
углубляться в каждую из этих концепций на протяжении всей
книги. В дальнейшем мы рассмотрим принципы, лежащие в
основе Lean UX.
ГЛАВА 2

Принципы

В основе Lean UX вы найдете набор принципов. Эти принципы

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

В конечном счете, если вы сможете заставить эти принципы

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

Lean UX стоит на трех основаниях. Первое основание - это

дизайн мышление.

Тим Браун, генеральный директор и президент легендарной

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

Дизайн-мышление важно для Lean UX, потому что оно

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

Вторым основанием Lean UX является гибкая разработка

программного обеспечения. Разработчики используют методы Ag-
ile в течение многих лет, чтобы сократить циклы разработки и и
непрерывно предоставлять потребительскую ценность. Хотя Agile
методы могут создавать процессуальные сложности для
проектировщиков (решения предлагаются в Разделе III), основные
ценности Agile находятся в основе бережливого UX. Lean UX
применяет четыре основных принципа гибкой разработки к
дизайну продукта:
1. Индивидуумы и взаимодействия над процессами и
инструментами. Для быстрого создания лучшего решения,
вы должны привлечь всю команду. Идеями надо
обменивается свободно и часто. Ограничения текущих
процессов и производственных инструментов избегаются в
пользу разговора с коллеги по работе.

2. Работающее ПО над комплексной документацией.

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

3. Сотрудничество с клиентами в ходе переговоров по

контракту. Сотрудничество с командой и клиентами строит
общее понимание пространства задач и предлагаемых
решений. Это создает консенсус между решениями.
Результат? Более быстрые итерации, реальное участие в
создании продукта и командная вовлеченность в изучение
продукта. Он также уменьшает зависимость от тяжелой
документации, так как все в команде уже участвовали в
принятии решений, которые были использованы для
письменного общения и защиты.

4. Реагировать на изменения помимо следования

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

му цель в том чтобы как можно скорее выяснить, что с ними

не так. Как только мы узнаем, что работает, а что нет, мы
корректируем наши предложения и снова тестируем. Этот
вход с рынка делает нас гибкими, постоянно подталкивая нас
в правильном направлении.
 Третьим основанием Lean UX является метод Lean Startup,
разработанный Эриком Райсом. Lean Startup использует цикл
обратной связи под названием “build-measurelearn « для
минимизации риска проекта и позволяет быстро создавать команды
и быстро учиться. Команды создают минимально жизнеспособные
продукты
(MVPs) и отправляют их

быстро чтобы получить обратную связь как можно быстрее. По

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

Каждый проект это предлагаемое бизнес-решение - гипотеза.

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

Lean UX является практикой, открывающей истинную природу

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

В остальной части этой главы я изложу принципы Lean UX.

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

КРОСС-ФУНКЦИОНАЛЬНЫЕ ГРУППЫ
Что это? Кросс-функциональные команды состоят из
различных дисциплин, участвующих в создании продукта.
Разработка программного обеспечения, управление продуктами,
дизайн взаимодействия, визуальный дизайн, контентная стратегия,
маркетинг и обеспечение качества (QA) должно быть включено в
команду Lean UX. Lean UX требует высокого уровня сотрудничества
между этими дисциплинами. Их участие должно быть
непрерывным, с первого дня проекта до конца.

Зачем это делать? Создание этих разнообразных команд

разрушает закрытый хэндофф процесс, известный как водопад.
Понимание каждой идеи приходит из всех соответствующих
дисциплин в начале процесса. Поощряется разговор между
функциональными нишами, что повышает эффективность работы
команды.
МАЛЕНЬКИЙ, СПЕЦИАЛИЗИРОВАННЫЙ,
СОВМЕСТНО РАЗМЕЩЕННЫЙ
Что это? Держите свои команды маленькими—не более 10
человек. Посвятите их одному проекту и наберите персонал из
одного и того же места.

Зачем это делать? Преимущество небольших команд сводится

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

ПРОГРЕСС = КОНЕЧНЫЙ РЕЗУЛЬТАТ,

А НЕ ПРОИЗВОДИТЕЛЬНОСТЬ
Что это? Функции и услуги - это то что производится. Бизнес-
цели означают для достижение результатов. Lean UX измеряет
прогресс с точки зрения четко определенных бизнес-результатов.

Зачем это делать? Когда мы пытаемся предсказать, какие

функции достигнут конкретных результатов, мы в основном
занимаемся спекуляциями. Хотя проще управлять запуском
определенных наборов функций, мы не знаем с достаточной
степенью уверенности, является ли функция эффективной, пока она
не появится на рынке. Управляя результатами (и прогрессом,
достигнутым в их направлении), мы получаем понимание
эффективности функций, которые мы создаем. Если функция не
хороша, мы можем принять объективное решение относительно
нее: следует оставить, поменять или заменить на другую.
КОМАНДА, СФОКУСИРОВАННАЯ
НА ПРОБЛЕМЕ
Что это? Проблемно-ориентированная команда - это команда,
которой дана бизнес-задача для решения, в отличие от набора
функций для реализации. Это логическое расширение фокуса на
конечные результаты.

Зачем это делать? Назначение команд для решения проблем

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

УМЕНЬШЕНИЕ ПОТЕРЬ
Что это? Одним из основных принципов бережливого
производства является удаление всего, что не ведет к конечной
цели. В Lean UX конечная цель - улучшение результатов;
следовательно, все, что не способствует этому считается отходами и
должно быть удалено из процесса команды.

Зачем это делать? Ресурсы команды ограничены. Чем больше

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

МАЛЕНЬКИЕ “ПАРТИИ”
Что это? Еще одним основополагающим принципом
бережливого производства является использование небольших
размеров партий. Бережливое производство использует этот
принцип для сохранения высокого качества производства при
ограниченных ресурсах. В переводе на Lean UX эта концепция
означает создание только дизайна, который необходим, чтобы
переместить команду вперед и избежать большой «свалки»
непроверенных и не реализованных дизайнерских идей.

Зачем это делать? Создание больших блоков изменений

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

НЕПРЕРЫВНЫЕ ИССЛЕДОВАНИЯ
Что это? Непрерывные исследования - продолжающийся
процесс, вовлекающий заказчика в процесс проектирования и
разработки. Такое взаимодействие осуществляется посредством
регулярных исследований с использованием как количественных,
так и качественный методик. Цель состоит в том, чтобы понять, что
пользователи делают с вашими продуктами и почему они это
делают. Исследования проводятся часто и на регулярной основе. В
исследовании участвует вся команда.

Зачем это делать? Регулярные разговоры с клиентами

предоставляют возможности для проверки новых идей продукта.
Собранная в исследовательский цикл, команда будет развивать
эмпатию к пользователям и проблемам, с которыми они
сталкиваются. Наконец, по мере того как команда учится вместе,
уменьшается потребность в последующей передаче опыта и
документации.
GOOB*: НОВАЯ ОРИЕНТИРОВАННОСТЬ НА
ПОЛЬЗОВАТЕЛЯ
Что это? Это может звучать как первое слово ребенка, но GOOB
на самом деле акроним того, что стэнфордский профессор,
предприниматель и автор Стив Бланк зовет: «выходим из здания
(getting out of the building)”. Это признание того, что дебаты в
конференц-зале о потребностях пользователей не будут
окончательно урегулированы в вашем офисе. Вместо этого ответы
лежат на рынке, за пределами вашего здания. После многих лет
пропаганды исследования пользователей, у UX сообщества
появился чемпион из мира бизнеса в лице Стива Бланка. Его
рецепт: дайте потенциальным клиентам возможность дать
обратную связь по вашим идеям быстрее, чем в прошлом. Гораздо
быстрее. Проверьте свои идеи с помощью сильной дозы реальности,
пока они еще молоды. Лучше узнать, что твоя идея попала мимо
цели, прежде чем потратишь время и ресурсы на создание продукта,
который никому не нужен.

Зачем это делать? В конечном счете, успех или неудача

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

РАЗДЕЛЯЕМОЕ ПОНИМАНИЕ
Что это? Разделяемое понимание - это коллективные знания
команды, которые накапливается со временем, когда команда
работает вместе. Это полное понимание пространства, продукта и
клиентов.

Зачем это делать? Разделяемое понимание - это валюта lean

UX. Чем больше команда коллективно понимает, что она делает и
почему, тем меньше у нее зависимость от докладов и детальных
документов для продолжения работы.

АНТИ-ШАБЛОН: РОК-ЗВЕЗДЫ, ГУРУ И НИНДЗЯ

Что это? Lean UX выступает за командную работу. Рок-звезды,
гуру, ниндзя и другие элитные специалисты своего ремесла
разрушают сплоченность команды и избегают сотрудничества.

Зачем это делать? Рок-звезды не делятся ни своими идеями,

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

МАТЕРИАЛИЗУЙТЕ СВОЮ РАБОТУ

Что это? Материализация означает выкинуть работу из головы
и из компьютера на всеобщее обозрение. Команды используют
доски, стены артефактов, распечатки и стикеры, чтобы показать
свою работу в процессе своим партнерам, коллегам и клиентам.

Зачем это делать? Материализация помещает идеи из голов

товарищей по команде на стену, позволяя всем видеть, где стоит
команда. Это создает пассивный, окружающий поток информации
по команде. Он вдохновляет на новые идеи,основанные на тех,
которые уже были разделены. Это позволяет всем членам команды -
даже тихим - участвовать в обмене информацией. Их заметки на
стикерах или эскизы на доске такие же громкие, как самые
вывыделяющиеся люди в команде.
ДЕЛАТЬ ВАЖНЕЕ ЧЕМ АНАЛИЗИРОВАТЬ
Что это? Lean UX значит - делать важнее, чем анализировать.
Полезнее создать первую версию идеи, чем тратить полдня на
обсуждение ее значимости в конференц-зале.

Зачем это делать? Ответ на самые сложные вопросы

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

ИЗУЧАТЬ ВАЖНЕЕ ЧЕМ РАСТИ

Что это? Трудно понять, что следует создать и одновременно
масштабировать свой бизнес вокруг этой штуки. Это
противоречивые действия. Lean UX предпочитает сначала
сосредоточиться на изучении и затем масштабировать.

Зачем это делать? Масштабирование недоказанной идеи -это

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

РАЗРЕШЕНИЕ НА ОШИБКУ
Что это? Для того, чтобы найти лучшее решение бизнес-
проблем, команда Lean UX должны экспериментировать с идеями.
Большинство из этих идей потерпят неудачу. Команда не должна
бояться потерпеть неудачу, если они хотят быть успешными.
Разрешение на ошибку значит, у команды есть безопасная среда для
экспериментов. Эта философия применима как к технической среде
(они могут предлагать идеи безопасным способом) и культурной
среды (они не будут наказаны за тестирование идей, которые не
увенчались успехом).

Зачем это делать? Разрешение потерпеть неудачу порождает

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

В видео под названием «Почему вам нужно потерпеть

неудачу» (http://www.youtube.com/watch?v=HhxcFGuKOys),
основатель CD Baby Дерек Сиверс описывает удивительные
результаты класса керамики. В первый день, инструктор объявил
своему классу, что ученики будут разделены на две группы.
Половина студентов должны были бы сделать только один
глиняный горшок за семестр. Их оценки будут зависеть от
совершенства этого одинокого горшка. Другая половина класса
будет оцениваться просто по весу Горшков, которые они сделали в
течение семестра. Если они сделали 50 фунтов горшков или больше,
сорок фунтов дадут четверку, тридцать фунтов-тройку и так далее.
То, что они на самом деле сделали, не имело значения. Инструктор
сказал, что не будет даже смотреть на их горшки. Он принесет свои
весы в последний день из класса и взвесит работы студентов.

В конце семестра произошла интересная вещь. Внешние

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

Напротив, группа, которая сделала один объект, не имела

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

ВЫБРАВШИСЬ ИЗ БЮРОКРАТИЗАЦИИ
БИЗНЕСА
Что это? Lean UX переориентирует процесс проектирования от
документов, которые команда создает, на результаты, которых
команда достигает. С увеличенным кросс-функционального
сотрудничества, диалог заинтересованных сторон становится
меньше о том, какой артефакт создается и больше о том, какой
результат достигается.

Зачем это делать? Документы не решают проблем клиентов—

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

Подведение Итогов: Принципы

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

В разделе II я приведу эти принципы в действие, подробно

описывая весь процесс Lean UX.
РАЗДЕЛ II
ПРОЦЕСС

Сегодня вторник, и Рик, Марк, Ольга и Арти стоят у белой

доски, смотря на вайрфрейм, который они нарисовали. У Арти в
руке маркер, но она не рисует.

“Рик, я не понимаю к чему ты клонишь. Ты можешь объяснить

проблему?”

Рик берет маркер, вытирает часть доски и снова объясняет

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

Через некоторое время команда кивает, и Арти снова берет

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

Арти, дизайнер, возвращается к своему столу, чтобы начать

детализировать дизайн, который они набросали. Марк,
разработчик front-end, начинает строить страницу—он
использует готовые компоненты из руководства living style,
которое утвердила команда, поэтому ему не нужно ждать
 Арти, чтобы разместить основные элементы. Рик открывает
wiki (энциклопедию) проекта и начинает документировать
решения, принятые командой о поведении приложения. Он
рассмотрит эти варианты с владельцем продукта позже в тот
же день. И Ольга, тестер QA, начинает процесс написания
тестов для нового раздела приложения.

Это повседневный ритм Lean UX: команда, работающая

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

В предыдущем разделе я показал вам идеи Lean UX —

принципы, которые управляют работой. В этом разделе я перейду к
практике и подробно опишу процесс внедрения Lean UX.

Глава 3, «Видение, Прототипирование и Результаты»,

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

В главе 4 «Совместный дизайн» описаны изменения в

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

Глава 5 «MVP и Тестирование» посвящена тестированию

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

Глава 6 «Обратная связь и исследования» посвящена

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

Видение,
Прототипирование и
Результаты

Если что-то не согласуется с

экспериментом, то это “что-то”
неправильно.
Д-р Ричард Фейнман

Традиционно UX-дизайн проекты формируются с учетом

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

В этой главе рассматривается основной инструмент

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

Формулирование гипотезы - это способ выражения

предположений в проверяемой форме. Он состоит из следующих
элементов:

Предположение
Верхнеуровневая формулировка того, что мы считаем правдой.

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

Цели
Сигналы, который мы ищем на рынке, чтобы подтвердить или
опровергнуть наши гипотезы. Они часто количественные, но также
могут быть качественные.

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

Особенности (возможности)
Изменения или улучшения продукта, как мы предполагаем, будут
управлять результатами, которые мы ищем.
Давайте рассмотрим каждый из этих элементов более подробно.
ПРЕДПОЛОЖЕНИЯ

Первым шагом в процессе Lean UX является формирование

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

Формирование ваших предположений позволит вашей

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

Формирование предположений является первым шагом в

процессе бережливого производства UX; см. рис. 3-1.:
МЕТОД: ФОРМУЛИРОВАНИЕ
ПРЕДПОЛОЖЕНИЙ

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

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

1. Аналитические отчеты, показывающие, как используется

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

2. Отчеты юзабилити, которые иллюстрируют, почему клиенты

принимают определенные действия в вашем продукте

3. Сведения о прошлых попытках устранить эту проблему и их

успехах и неудачах
 4. Анализ со стороны заинтересованной стороны бизнеса, как
решение этой проблемы повлияет на производительность
компании

5. Конкурентный анализ, который показывает, как конкуренты

решают такие же проблемы

МЕТОД: ПОСТАНОВКА ЗАДАЧИ

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

Шаблон постановки задачи

Постановка задачи состоит из трех элементов:

1. Текущие цели продукта или системы

2. Проблема, которую хочет решить заинтересованная сторона

бизнеса (т. е. ели, которые не достигаются)

3. Явный запрос на улучшение, который не диктует конкретного

решения

Шаблон
[Наш сервис/ продукт] был разработан для достижения [этих
целей]. Мы заметили, что продукт/услуга не соответствует
[этим целям], что является причиной [этого неблагоприятного
эффекта] для нашего бизнеса. Как мы можем улучшить
 [обслуживание/продукт] так, чтоб наши клиенты более
успешно решали задачи на основе [этих измеримых критериев]?

Например, вот заявление о проблеме, которое мы использовали

для начала проекта в The Ladders, интернет-рекрутинговой фирме,
где я работал. (В этой книге вы увидите еще много примеров из The
Ladders)

Наш сервис предлагает канал между соискателями и

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

Постановки задач наполнены предположениями. Работа

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

Рабочий Лист Бизнес-Предположений

Мне нравится использовать этот лист (созданный моим

партнером Giff Constable), чтобы облегчить обсуждение
предположений. Есть много способов заполнить этот лист. Вы
можете отвечать на вопросы всей командой, просто обсуждая
каждый ответ. Или вы можете запускать структурированный
мозговой штурм/сравнивать ответы участников для каждого
вопроса. Главное, помните, что важно дать каждому шанс внести
свой вклад. Кроме того, не переживайте, если вы концу заполнения
рабочего листа у вас нет согласия по всем ответам. Цель состоит в
том, чтобы собрать утверждения, которые по мнению вашей
команды могут быть верными. Если у вас есть сильное несогласие
по какому-либо вопросу, учтите различные мнения.

Вы можете обнаружить, что некоторые из этих вопросов не

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

Когда вы закончите рабочий лист, у вас будет список

предположений. Ваш следующий шаг - расставить приоритеты в
этих предположениях.
Лист Бизнес-Предположений

Приоритетность предположений

Причина, по которой мы объявляем предположения в начале

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

Lean UX-это упражнение в безжалостной приоритизации.

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

Бизнес-Предположения Предположения о пользователях

1. Я считаю, что у моим поль- 1. Кто является пользователем?

зователям нужен _______ .
2. Как наш продукт вписывается
2. Эти потребности могут в его работу или жизнь?
быть решены с помощью
_______ . 3. Какие проблемы решает наш
продукт?
3. Мои основные пользовате-
ли 4. Когда и как наш продукт ис-
(или будут) _______ . пользуют?

4. Главное, что пользователь 5. Какие функции важны?

хочет получить от моего
продукта _______ . 6. Как должен выглядеть и вести
себя наш продукт?
5. Пользователь может также
получить дополнительные
преимущества в виде _______
.

6. Я приобрету большинство
моих пользователей через
_______ .

7. Я буду получать прибыль

через _______ .

8. Мой главный конкурент на

рынке _______.

9. Мы превзойдем их благо-
даря _____.

10. Мой самый большой про-

дуктовый риск _______ .

11. Мы снимем риск при по-

мощи
_______ .
1. Какие еще предположения
могут негативно повлиять на
бизнес, если окажутся оши-
бочными _______.

Цель состоит в том, чтобы определить приоритетность набора

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

Это не означает, что предположения, которые не попадают в

“первую десятку” будут отсеяны насовсем. Сохраните бэклог других
предположений, которые вы определили, чтобы вернуться к ним и
проверить их, когда это будет иметь смысл сделать.
ГИПОТЕЗЫ

С вашим списком предположений в руках, вы готовы перейти к

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

Как правило, гипотезы используют формат:

Мы верим [в это утверждение].

Мы знаем, что мы [правильно/неправильно] когда мы видим

следующую обратную связь от рынка: [качественная обратная
связь] и/или [количественная обратная связь] и/или [изменение
ключевого индикатора производительности].

Вы можете видеть, что этот формат состоит из двух частей.

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

Выражение ваших предположений таким образом оказывается

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

СУБГИПОТЕЗЫ: РАЗДЕЛЕНИЕ ГИПОТЕЗЫ НА

МЕЛКИЕ ЧАСТИ
Иногда — если не большую часть времени — вы обнаружите, что
ваша гипотеза слишком большая, чтобы проверить ее за один тест.
Он будет содержать слишком много подвижных элементов,
слишком много субгипотез. Когда такое происходит, я нахожу
полезным разделить гипотезу на более мелкие и специфические
части. Хотя есть много способов сделать это, для работы с
продуктом, мне кажется полезным формат:

Мы считаем, что [выполнение этого/создание этой функции/

создание этого опыта] для [этих людей/персонажей]
позволит достигнуть [этого результата].

Мы узнаем, верно ли это, когда увидим [эта обратная связь с

рынком, количественная мера или качественное понимание].

Первое поле заполняется функцией или улучшением, которое

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

Это не только числа!

Стоит отметить, что в дизайнерской среде было много негатива

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

На самом деле я согласен с этой точкой зрения, поэтому считаю,

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

Давайте рассмотрим пример того, как это работает, вернувшись

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

Одно из предположений, которые мы делаем в этой постановке

проблемы, заключается в том, что рекрутеры будут использовать
новый канал (The Ladders) для взаимодействия с кандидатами. Это
утверждение - не доказанный факт и нуждается в проверке. Как бы
мы написали гипотезу для этого заявления? Давайте возьмем наш
шаблон и заполним его:
Мы считаем, что

создание эффективной коммуникации в приложении The

Ladders для рекрутеров и соискателей

повысит количество успешных контактов пользователей и

удовлетворенность от продукта.

Мы узнаем, что это правда, когда увидим увеличение числа

ответов от соискателей рекрутерам и увеличение количества
вакансий, отправленных рекрутерами в нашей системе.
ЗАВЕРШЕНИЕ ФОРМУЛИРОВАНИЯ
ГИПОТЕЗЫ
Чтобы сформулировать свою гипотезу, начните собирать
строительные блоки. Составьте список целей которые хотите
достигнуть, определите персоны для которых вы это делаете, и
набор функций, которые по вашему мнению может сработать в этой
ситуации. Когда у вас собран весь этот сырой материал, их можно
собирать в список утверждений. Давайте посмотрим поближе на
каждый из этих элементов.

Важность контрольных показателей

Помните, что ни одна из ваших метрик не будет иметь смысла, если

у вы не определили ориентир перед написанием гипотез. Этот

ориентир — текущее состояние метрики, которую вы используете

для определения успеха вашей идеи должен быть определен зара-

.
нее, чтобы, что команда знала, на что она нацелена
ЦЕЛИ

Когда вы создаете гипотезы для проверки, вы стараетесь очень

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

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

пытаетесь решить. Вероятно, у вас есть несколько верхнеуровневых
целей, которые вы надеетесь достичь (например, увеличение
регистраций, частота использования продукта и т. д.). Подумайте,
как вы можете разбить эти верхнеуровневые цели на более мелкие
части. Изменение какого показателя даст большую пользу: больше
посетителей сайта? Больше кликов на email-рассылку? Увеличение
количества товаров в корзине? Иногда полезно запустить
коллективный мозговой штурм, чтобы создать список отдельных
небольших целей, которые, по вашему мнению, вместе помогут
достигнуть искомой большой цели.

На рис. 3-3 показан пример, приведенный, Гиффом Констеблем,

в котором команда исполнительных руководителей провела
мозговой штурм, а затем проголосовала за ключевые показатели
(KPIs), которых должна достигнуть компания. После консолидации
списка, показанного на фото, каждому руководителю было дано по
четыре M&Ms. Те кто сумел не съесть свои голоса, проголосовали
рис. 3-3 приоритизация KPI с помощью конфет соответствующими
конфетами за метрики которые считали наиболее важными. Путы
были разорваны CEO.
ПЕРСОНАЖИ (ПЕРСОНЫ)

Дизайнеры часто создают модели под названием “персонаж”

для представления пользователей своей системы. Если у вашей
команды уже есть четко определенный набор персонажей,
единственное на данный момент что вам нужно решить, каких из
них использовать в постановке гипотез. Если у вас еще нет
персонажей, этот раздел объясняет, как создавать персонажей для
процесса Lean UX.
ПРОТО-ПЕРСОНЫ
Дизайнеры давно выступают за конечного пользователя. Lean
UX ничем не отличается. Когда мы делаем предположения о нашем
бизнесе и целях, которых мы хотим достигнуть, нам все равно
нужно держать пользователя в центре нашего внимания.

Большинство из нас привыкли думать о персонах как о

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

В Lean UX мы меняем порядок операций в процессе

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

Команда, с которой мы работали в Нью-Йорке, создавала

приложение, которое улучшало опыт Сельского хозяйства
при поддержке общин (CSA) для жителей Нью-Йорка. CSA-это
программа, которая позволяет жителям города объединить
свои деньги и приобрести продукцию всего сезона у
местного фермера. Затем фермер еженедельно доставляет
продукты членам CSA. Многие подписчики CSA - мужчины и
женщины в возрасте от двадцати до тридцати, которым
приходится искать баланс между трудовой и активной
общественной жизнью, желающие участвовать в CSA.
Команда предположила, что большинство потребителей CSA-
женщины, которые любят готовить. Они потратил около часа,
создавая личность по имени Сьюзан. Но когда они перешли к
проведению исследований, они быстро узнали, что
подавляющее большинство поваров, а следовательно, и
потенциальные пользователи их приложения - молодые
люди. Они вернулись в офис и пересмотрели свою персону,
создав Тимоти (рис. 3-4).

Тимоти оказался гораздо более точным портретом целевого

пользователя. Команда не потеряла время на оттачивание
идей не для той аудитории. Теперь они были нацелены на
аудиторию, которая, хоть и не была идеальной, была гораздо
более реальной, чем их первоначальные предположения.
рис. 3-4 пример прото-персоны
ФОРМАТ ПЕРСОНЫ
Мы любим рисовать прото-персон на бумаге, используя
нарисованные от руки сектора, как на рисунках 3-5 и 3-4 (сложить
лист бумаги в четыре раза). Верхний левый сектор содержит
портрет личности и его или ее имя и роль. В правом верхнем углу
находится основная демографическая информация. Попробуйте
сосредоточиться на демографической информации, которая
предсказывает определенный тип поведения. Например, могут быть
случаи, когда возраст человека совершенно неважен, но доступ
через определенный девайс, например iPhone, полностью изменит
их взаимодействие с вашим продуктом.

рис. 3-5. Пустая схема персоны

Нижняя половина формы прото-персоны - это то, куда мы

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

ПРОЦЕСС СОЗДАНИЯ ПЕРСОНЫ

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

Если у вас есть список целей, и группа пользователей, пора

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

ПРОЦЕСС МОЗГОВОГО ШТУРМА

ПО СОЗДАНИЮ ФИЧИ
Используя методы, которые были описаны ранее, мы создаем
списки функций, проводя коллективный мозговой штурм. Мы
ищем функции, которые, по нашему мнению, повлияют на
поведение клиентов в нужном направлении. Пусть каждый член
команды напишет идею жирным маркером на стикере. Когда время
истечет, попросите всех наклеить свои стикеры на стену и вместе
распределите их по темам.

СБОРКА ВАШИХ ГИПОТЕЗ

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

Рис. 3-7. Таблица гипотез

Когда ваш список гипотез завершен, вы можете (наконец-то!)

перейти к следующему шагу: разработке. Если вы работали до этого
момента всей своей командой (и я настоятельно рекомендую это
сделать), у вас будет прекрасная возможность двигаться вперед
вместе. Этот процесс очень эффективен для создания общего
понимания и общей миссии всей вашей команды.
ЗАКЛЮЧЕНИЕ
В этой главе мы обсудили, как мы можем переосмыслить нашу
работу с точки зрения достижения целей, что является жизненно
важной техникой Lean UX: нацеленность нашей работы на
достижение целей освобождает нас (и наши команды) для поиска
лучших решений проблемы. Мы также посмотрели на процесс
постановки целей. Для этого, мы начинаем с постановки проблем
проекта, затем формируем наши предположения, а затем
преобразуем эти предположения в гипотезы. Мы также показали,
как писать гипотезы, которые отражают предполагаемые
особенности, аудиторию и цели и являются достаточно
конкретными для тестирования. В итоге вы получите инсайты,
которые послужат дорожной картой для следующего шага процесса
Lean UX: совместного проектирования.

В следующей главе мы определим совместный дизайн и как он

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

Командный дизайн
(Collaborative Design)

Проживая оставшуюся жизнь будьте

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

Lean UX - это совместный процесс. Он объединяет дизайнеров и

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

Почему все занимаются дизайном

 • Как артефакты низкой проработкой увеличивают
сотрудничество

• Построение общего понимания в вашей команде

Мы также рассмотрим ряд методов, которые обеспечивают более

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

• Дизайн студия - упражнение по совместному скетчингу для

всей команды

• Руководства по стилю и библиотеки шаблонов - живые

репозитории всех элементов вашего продукта,
ориентированных на клиента

• Методы совместной работы для географически

распределенных команд

В предыдущей главе мы обсуждали гипотезы о свойствах

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

Самый эффективный способ сплотить команду вокруг

направления дизайна - это сотрудничество. В долгосрочной
перспективе сотрудничество дает лучшие результаты, чем дизайн,
основанный на героях (практика вызова дизайнера или команды
дизайнеров, чтобы придумать что-то красивое и уйти, чтобы спасти
следующий проект). Команды редко учатся или становятся лучше от
работы с героями. Вместо этого совместное проектирование
повышает дизайн-IQ всей команды. Это позволяет каждому члену
команды сформулировать свои идеи. Это дает дизайнерам гораздо
более широкий набор идей, на которые они могут опираться при
улучшении пользовательского опыта. Это сотрудничество, в свою
очередь, порождает повышенное чувство ответственности за работу,
выполняемую всей командой. Наконец, совместный дизайн создает
общее понимание для всей команды. Именно это общее понимание
является валютой Lean UX. Чем больше в команде коллективное
понимание, тем меньше она должна документировать, чтобы
двигаться вперед.

Совместное проектирование - это подход, который позволяет

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

Совместное проектирование - все еще работа дизайнера.

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

В типичном сеансе совместного проектирования команды

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

Выходные данные этих сессий обычно состоят из скетчей низкой

проработки и прототипов. Этот уровень точности имеет решающее
значение для поддержания гибкости работы, что позволяет команде
быстро менять направление, если их тесты показывают, что этот
подход не работает. Намного проще отказаться от неудачного
подхода, если вы не потратили слишком много времени на
кропотливое документирование и детализацию этого подхода.
СОВМЕСТНОЕ
ПРОЕКТИРОВАНИЕ НА
ПРАКТИКЕ

Разговор: ваш самый мощный инструмент

Lean UX продвигает разговор как основное средство

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

Имея такие разговоры рано и часто, команда осознает идеи

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

Поначалу эти разговоры могут показаться неловкими; в конце

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

В 2010 году я проектировал информационную панель для веб-

приложения, ориентированного на аудиторию рекрутеров и
работодателей The Ladders. Было много информации, которую
требовалось уместить н аодин экран, и я изо всех сил пытался
заставить все это работать. Вместо того, чтобы тратить время за
столом, налегая на пиксели, я схватил доску и позвал ведущего
разработчика. Я набросал свою первоначальную идею о том, как
уместить весь контент и функции на этой панели. Мы обсудили это,
а затем я передал ему маркер. Он набросал свои идеи на той же
доске. Мы ходили взад и вперед, в конечном счете сходясь к макету
и схеме взаимодействия, которые были не только применимы, но и
выполнимы, учитывая наши двухнедельные временные рамки
спринта (см. Рис. 4-2). В конце этой двухчасовой сессии мы
вернулись к своим рабочим столам и начали работать. Я
переработал наш скетч в более детальный прототип и описание
взаимодействия, и он начал писать код инфраструктуры,
необходимой для реализации этого прототипа.

Мы создали общее понимание через нашу совместную сессию

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

Рисунок 4-2. Эскиз на доске, к которому мы вместе пришли.

ДИЗАЙН СТУДИЯ
Когда вашей команде удобно сотрудничать, неформальные
сессии, подобные той, что я только что описал, проводятся
постоянно. Но иногда вам нужно будет собрать всех на официальное
рабочее заседание. Дизайн студия - популярный способ сделать это.
Дизайн студия (иногда ее называют дизайн телега) - это способ
объединить многофункциональную команду для визуализации
потенциальных решений проблемы дизайна. Этот метод разрушает
организационные блоки и создает форум для точек зрения ваших
товарищей по команде. Объединив дизайнеров, разработчиков,
экспертов в данной области, менеджеров по продуктам, бизнес-
аналитиков и других специалистов в одном пространстве и
сосредоточив их всех на одной задаче, вы получите результат,
намного превосходящий работу в отдельных блоках. У дизайн-
студии есть еще одно преимущество: она начинает завоевывать
доверие вашей команды, чтобы перейти от этих официальных
сессий к более частым и неформальным совместным действиям.
Проведение Дизайн студии

Хотя описанная ниже методика очень специфична, вы должны

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

Процесс

Дизайн студия идет по такому пути:

1. Определение проблемы и ограничений

2. Генерация идеи (расхождение)

3. Презентация и критика

4. Итерируйте и уточняйте (появляйтесь)

5. Генерация идеи команды (схождение)

Материалы:

• карандаши

• ручки

• маркеры для доски (несколько цветов / толщины)

• маркеры (несколько цветов)

• скетчбук (вы можете использовать предварительно

напечатанные шаблоны на 1 и 6 листов или использовать
чистые листы бумаги размером 11 × 17 дюймов, разделенные
на шесть секторов)
 • 25-дюймовые 30,5-дюймовые доски

• блоки стикеров (или любого вида маленьких наклеек)

Процесс работает лучше всего для команды из пяти-восьми

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

Постановка проблемы и ограничения (15–45 минут)

Первый шаг в Design Studio - убедиться, что все осведомлены о

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

Индивидуальная генерация идей (10 минут)

На этом этапе вы будете работать индивидуально. Раздайте

каждому члену команды лист бумаги с шестью пустыми секторами
на нем (рис. 4-3). Вы можете сделать это, сложив чистый лист
бумаги размером 11 × 17 дюймов (или вы можете использовать
предварительно напечатанный шаблон).
Рис. 4-3

Необязательно: иногда люди сталкиваются с трудностями, глядя

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

Затем, с вашими пустыми (или опционально помеченными)

листами из 6 листов перед вами, дайте каждому пять минут на то,
чтобы сгенерировать шесть набросков с низкой точностью для
каждой пары персонаж/болевая точка на их 6 секторах. Это должны
быть визуальные выражения (наброски пользовательского
интерфейса, рабочие процессы, диаграммы и т. Д.), а не текст.
Поощряйте свою команду, раскрывая грязный секрет дизайна
взаимодействия (the dirty secret), чтобы сравнять шансы: если вы
можете нарисовать круг, квадрат и треугольник, вы можете
нарисовать любой интерфейс. Я уверен, что любой в вашей команде
может нарисовать эти фигуры.

Презентация и критика (3 минуты на человека)

Когда время истекло, делитесь и критикуйте то, что вы уже

сделали (см. Рисунок 4-4). Обойдя стол, дайте каждому участнику по
три минуты, чтобы он поднял свои эскизы и представил их команде.
Докладчики должны четко указать, для кого они решают проблему
(персона), к какой болевой точке они обращаются (гипотеза), а
затем объяснить эскиз. Каждый член команды должен предоставить
докладчику критику и обратную связь. Критика должна
сосредоточиться на разъяснении намерений докладчика. Такие
вопросы, как «Как эта функция решает конкретную проблему
персоны?», очень полезны. Такие комментарии, как «Мне не
нравится эта идея», имеют малую ценность и не дают ведущему
конкретные идеи для повторной работы.

Убедитесь, что каждый член команды дает и получает критику.

 Рис. 4-4. Пример результата дизайн студии

Повторение и уточнение (5–10 минут)

Теперь попросите всех поработать индивидуально еще раз.

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

Как только время истечет, попросите команду снова пройти

процесс оперативного и критического анализа.
Командная генерация идей (45 минут)

Теперь, когда у каждого в команде есть отзывы о его или ее

индивидуальной идее, команда должна сходиться к одной идее. На
этом этапе команда пытается прийти к согласию относительно
идеи, которая, по их мнению, имеет наибольшие шансы на успех.
Эта идея послужит основой для следующего шага процесса Lean
UX: создания MVP и проведения экспериментов (оба
рассматриваются в следующей главе).

Попросите команду использовать большую доску, чтобы

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

Если у вас есть несколько команд в дизайн студии, попросите

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

Артефакты, созданные в дизайн студии, теперь можно

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

РУКОВОДСТВО ПО СТИЛЮ (STYLE GUIDES)

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

Некоторые компании используют вики для своих руководств по

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

Руководства по стилю создают эффективность. Они

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

Сводя к минимуму споры по поводу стандартных элементов,

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

Взаимодействие и визуальные дизайнеры также выигрывают.

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

Создание руководства по стилю

Существует два основных подхода к созданию руководства по

стилю:

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

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

Ведение руководства по стилю

При планировании вашего руководства по стилю важно

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

Изучим на примере

В этом примере мы рассмотрим, как команда UX в General

Electric (GE) создала руководство по стилю корпоративного уровня.

Когда Грег Петрофф возглавил глобальную практику GE по UX в

конце 2011 года, он унаследовал глобально распределенную
команду, изо всех сил пытающуюся донести огромный опыт по
продуктам до одной из крупнейших в мире организаций.
Оказывается, GE является четырнадцатым по величине
производителем программного обеспечения в мире, создавая
системы для мониторинга, управления и понимания производимого
ими промышленного оборудования. С 500 разработчиками на
каждого дизайнера команда нашла, что трудно достичь желаемых
результатов проектирования, удовлетворяющих огромные
требования организации. Найм большего количества дизайнеров не
был вариантом, и широкая корпоративная защита методов
проектирования UX изменила бы культурные основы - включая
процессы, ценности, коммуникационные практики, отношения и
предположения - слишком медленно. Кроме того, недавно
созданный UX Center of Excellence быстро оказался перегружен
запросами на работу. Рассмотрение каждого UX-проекта, который
прошел через компанию, превратил их в то самое узкое горлышко,
которое они пытались устранить.
 Должен был существовать лучший способ. Первоначально
команда пыталась создать UX-сообщество в масштабах всей
компании с помощью централизованной платформы социальных
сетей. Несмотря на то, что этот подход начал создавать дух
товарищества, он не сделал достаточно, чтобы создать
согласованную эстетику дизайна или позволить командам
разработчиков без UX-возможностей делать хорошую работу.

Проведя несколько пилотных проектов в нескольких бизнес-

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

В течение недели команда проводила мозговой штурм и

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

С этой инициативой родилась Система промышленного

интернет-дизайна (IIDS). “Соломенный человечек” был одобрен
руководством и был внедрен летом 2012 года. IIDS основана на
современных платформах HTML5, таких как Bootstrap, jQuery и
другие, но не похожа на них (см. Рисунки 4-5 и 4-6). Это фирменная
библиотека шаблонов дизайна пользовательского интерфейса. Она
предоставляет графические ресурсы, фрагменты кода и правила
использования для каждого из шаблонных продуктов GE. Команда
также создала примеры приложений, чтобы помочь другим
командам в составлении приложений. IIDS также включает в себя
типичных клиентов, чтобы проектные команды могли получить
четкое представление о своих целевых клиентах и о том, как
предполагаемый клиент влияет на выбор шаблонов дизайна,
который они делают.

Команда Петроффа выбрала две разные аудитории для IIDS.

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

IIDS расширяет возможности команд, стремящихся стать более

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

Самое главное, что все команды GE теперь имеют возможность

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

Рисунок 4-5. Пример страницы шаблона IIDS.

Рисунок 4-6. Макет таблицы в IIDS
Рисунок 4-7. Пример руководства по стилю от TheLadders.

Что входит в руководство по стилю

Если элемент сделан из пикселей, он входит в руководство по

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

Как выглядит элемент

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

Где он обычно размещается на экране

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

Когда элемент используется

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

Когда элемент используется

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

Далее включите все элементы визуального дизайна. Начните с

общей цветовой палитры вашего продукта. Убедитесь, что каждый
основной цвет доступен с шестнадцатеричными значениями, а
также с дополнительными и комплиментарными вариантами цвета.
Если определенные элементы, такие как кнопки, имеют разные
цвета в зависимости от состояния, убедитесь, что эта информация
включена. Другими элементами, которые следует здесь включить,
Рисунок 4-8. Еще один пример страницы руководства по стилю от
TheLadders.

являются логотипы, верхние и нижние колонтитулы, структура

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

Наконец, убедитесь, что стили копирайтинга также

кодифицированы. Запишите тон вашего бренда, конкретные слова,
которые вы будете и не будете использовать, грамматический
выбор, допустимые (и недопустимые) разговорные выражения, а
также язык кнопок (ОК? Да? Перейти? и т.д.) И другой язык
навигации (предыдущий/далее, больше/меньше и т. д.).
Характеристики успешного руководства по стилю

У успешного руководства по стилю есть три важные

характеристики: оно доступно, постоянно обновляется (например,
живой документ), и его можно использовать.

Доступность

Доступность означает, что руководство по стилю доступно

каждому в вашей организации. Доступные руководства по стилю:

Легко найти
Используйте запоминающийся URL и убедитесь, что все знают об
этом.

Легко распространяется
Убедитесь, что ваши команды могут легко получить доступ к
руководствам по стилю в любой момент (в офисе, вне офиса, на
мобильном телефоне и т. Д.).

Легко искать
Комплексная и точная функция поиска в руководстве по стилю
значительно увеличивает его использование.

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

Постоянно улучшается

Руководство по стилю должно рассматриваться как живой

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

Я рекомендую использовать вики*. Вот почему:

• Вики - это знакомое средство для разработчиков. Это

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

• Вики хранят историю изменений (хорошие, во всяком

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

• Вики отслеживают, кто что изменил, и предоставляют

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

*Ви
́ ки (англ. wiki) — веб-сайт, содержимое которого пользо-

ватели могут самостоятельно изменять с помощью инструментов,

предоставляемых самим сайтом. Форматирование текста и вставка
различных объектов в текст производится с использованием вики-
разметки.
Реализуемый

Ваш гид по стилю - это не просто библиотека или музей для

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

КАК СОЗДАТЬ РУКОВОДСТВО ПО СТИЛЮ?

Создание руководства по стилю состоит из двух частей:

1. Создайте оглавление (TOC) - оглавление определяет, как

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

2. Заполните контент. Как упоминалось ранее, есть два способа

сделать это: подход большого взрыва и капля по капле.

Подход большого взрыва (в котором ваша команда создает

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

Ваш гид по стилю должен оставаться актуальным, если он

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

Назначьте владельца руководства по стилю. Этот человек не

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

Не только для дизайнеров

Ваш гид по стилю не должен содержать информацию,

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

Слово о живых руководствах по стилю

Команды, работающие в Интернете, недавно начали применять

новый подход к руководствам по стилю - живое руководство по
стилю (Live Style guides). По сути, они идентичны руководствам по
стилю вики, но есть одно принципиальное отличие: код в
руководстве по стилю - это тот же код, который используется
приложением. Команды получают преимущества от этого подхода,
но берут на себя дополнительную инфраструктуру и нагрузку на
процесс.

Живые руководства по стилю - это, по сути, часть вашего

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

Когда вы вносите изменения в базовый HTML и CSS вашего

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

СОТРУДНИЧЕСТВО С ГЕОГРАФИЧЕСКИ
РАСПРЕДЕЛЕННЫМИ КОМАНДАМИ
Физическая дистанция является одной из самых серьезных
проблем для тесного сотрудничества. Некоторые из методов,
которые я обсуждал в этой главе, особенно «дизайн студия»,
становятся сложнее, когда команда находится не в одном месте. Но
вы все равно можете найти способы сотрудничества.

Вот некоторые методы, которые могут помочь сократить

расстояние для географически распределенных команд. Такие
инструменты, как Skype, Google Docs (включая Google Draw), вики и
телефон с камерой, делают взаимодействие между часовыми
поясами эффективным и позволяют командам чувствовать себя
практически подключенными в течение длительного времени в
течение дня.
Всемирная совместная сессия дизайна

Географически распределенные команды делают совместное

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

Эта команда была разделена на две группы в двух городах:

команда по продукту и опыту пользователей находилась в Нью-
Йорке, а команда разработчиков в Ванкувере. Моя цель состояла в
том, чтобы запустить Студию дизайна и сеанс создания диаграммы
сходства со всей командой.

Подготовка

Мы попросили две группы собраться в своих отдельных

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

Мы подготовили очень короткую вводную презентацию (около

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

Мы начали с упражнения по составлению карт. Обычно это

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

Мы попросили команду придумать как можно больше идей для

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

Чтобы убедиться, что все были осведомлены обо всех

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

Чтобы смоделировать группировку сходства в общей электрон-

ной таблице, ведущий (в данном случае я) начал второй лист в

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

Затем я попросил команду взять каждую идею и скопировать ее

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

Дизайн студия с удаленными командами

Чтобы настроить следующий шаг, сеанс Дизайн студии, мы

постарались максимально имитировать совмещенную версию
упражнения. Мы раздавали бумагу и ручки для каждого офиса. Мы
создали установку с двумя мониторами в каждой конференц-
комнате, чтобы в каждой комнате можно было видеть эскизы на
одном мониторе, а также видеть своих товарищей по команде через
Skype на втором мониторе (как показано на рисунке 4-10). Мы
попросили каждую команду использовать iPhone, чтобы
сфотографировать их эскизы и отправить их всем остальным. Эта
настройка помогла соединить диалог и артефакты с беседой.

После этой первоначальной настройки мы смогли продолжить

процесс Дизайн студии как обычно. Каждый член команды смог
представить свои идеи в обеих комнатах и получить трансконти-
Рисунок 4-9. Вывод сеанса удаленного отображения соответствия.

нентальную критику. Обе команды смогли усовершенствовать свои

идеи вместе и в конечном итоге смогли объединить их в одну идею
для продвижения вперед.

Рисунок 4-10. Настройка двух мониторов во время удаленной Design

Studio.
Заключение: совместный
дизайн
Совместный дизайн - это эволюция UX. В этой главе я рассказал о
том, как «открытый исходный код» процесса проектирования
вовлекает всю команду глубже в проект. Я говорил о том, как
прототипы с низкой детализацией, созданные на сеансах Дизайн
студии, могут помочь командам генерировать много идей, а затем
сходиться в наборе, который может использовать вся команда. Я
показал вам практические приемы, которые вы можете использовать
для создания общего понимания, основной валюты Lean UX.
Используя такие инструменты, как руководства по стилю, Дизайн
студия и простой разговор, члены вашей команды могут
сформировать общее понимание, которое позволяет им двигаться
вперед гораздо быстрее, чем в традиционных средах.

Теперь, когда все наши предположения сформулированы и наши

гипотезы о дизайне созданы, вы действительно можете приступить к
процессу исследований. В следующей главе я расскажу о
минимально жизнеспособном продукте (MVP) и о том, как
использовать его для планирования экспериментов. Мы будем
использовать эти эксперименты, чтобы проверить правильность
наших предположений и решить, как двигаться дальше в нашем
проекте.
ГЛАВА 5

MVP и Исследования

Вся жизнь - эксперимент. Чем

больше экспериментов вы
проводите, тем лучше. Ralph Waldo
Emerson

Теперь, когда части вашей гипотезы определены, вы готовы

определить, какие идеи работают, а от каких следует отказаться.
В этой главе мы обсудим минимально жизнеспособный продукт
(MVP) и его значение в Lean UX. Кроме того, мы рассмотрим:

• Определение ориентации на продукт (обеспечение ценности

или увеличение исследований?) с использованием MVP

• Использование прототипов и инструментов для

прототипирования

• Проведение экспериментов без прототипов

О MVP И ЭКСПЕРИМЕНТАХ
Lean UX интенсивно использует понятие MVP. MVP помогают
проверить наши предположения - достигнет ли эта тактика
желаемого результата? - минимизируя работу, которую мы
вкладываем в недоказанные идеи. Чем раньше мы сможем найти, в
какие функции стоит вкладывать усилия, тем быстрее мы сможем
сосредоточить наши ограниченные ресурсы на лучших решениях
наших бизнес-задач. Эта концепция является важной частью того,
как Lean UX минимизирует отходы.

Ваш приоритетный список гипотез дал вам несколько путей для

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

ФОКУС MVP
Формулировка «MVP» вызвала много путаницы в своей
короткой жизни. Проблема в том, что он используется двумя
разными способами. Иногда команды создают MVP в первую
очередь, чтобы что-то изучить. Они не заинтересованы в выходе на
рынок с тем, что у них есть; они просто пытаются понять, чего хочет
рынок. В других случаях команды создают небольшую версию
продукта или функции, потому что они хотят как можно быстрее
начать получать прибыль на рынке. Во втором случае, если вы
правильно спроектируете и развернете MVP, вы также сможете
извлечь из него уроки, даже если это не основная задача. Смотрите
рисунок 5-1.
 Рисунок 5-1. Вы создадите MVP после того, как определили и
расставили приоритеты для ряда гипотез.

Давайте возьмем в качестве примера компанию среднего

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

Первый вопрос, на который они должны были ответить, будет

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

Они потратили полдня на разработку и кодирование формы и

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

На данный момент команда не приложила усилий для

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

СОЗДАНИЕ MVP
Когда вы начинаете планировать свой MVP, первое, что вам
нужно сделать, это рассмотреть то, что вы пытаетесь узнать.
Полезно подумать об этих трех основных вопросах:

1. Есть ли необходимость в решении, которое я разрабатываю?

2. Есть ли ценность в предложении и возможностях, которые я

предлагаю?

3. Можно ли использовать мое решение?

Хотя вы можете создать MVP, чтобы помочь вам ответить на

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

Если вы пытаетесь ответить на второй вопрос, вы, скорее всего,

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

Вот несколько рекомендаций, которым нужно следовать, если

вы пытаетесь максимально улучшить свое исследование:

Быть ясным и лаконичным

Потратьте время на то, чтобы донести свою идею до ее

основного ценностного предложения и представить ее своим
клиентам.

Безжалостно расставлять приоритеты

Идеи, как и артефакты, преходящи. Пусть лучшие проявят себя.

Будьте гибкими

Информация поступит быстро, поэтому убедитесь, что вы

работаете в среде, которая позволяет быстро обновляться.

Изучайте поведение

Создавайте MVP, которые позволяют вам наблюдать и измерять,

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

Вы узнаете, что люди ценят ваше решение, когда они

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

Вот несколько советов, которым нужно следовать, если вы

пытаетесь повысить ценность своего продукта для пользователя:

Быть функциональным

Нужна интеграция MVP с остальной частью вашего приложения

для создания реалистичного сценария использования.

Интеграция с существующей аналитикой

Измерение производительности вашего MVP должно быть

сделано в контексте существующих рабочих процессов продукта.

Соответствовать с остальной части приложения

Чтобы свести к минимуму любые отклонения в сторону новой

функциональности, разработайте MVP, чтобы соответствовать
вашему текущему стилю руководства и бренда.

Конечно, вы обнаружите, что вы пытаетесь одновременно

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

Независимо от желаемого результата, постройте наименьший

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

И помните одно: во многих случаях ваш MVP не будет включать

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

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

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

прототипа, зависит от:

• Кто будет взаимодействовать с ним

• Что вы надеетесь узнать

• Сколько времени у вас есть на его создание

Очень важно указать целевую аудиторию для вашего прототипа.

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

Стейкхолдеры зачастую менее знакомы с собственным

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

Низко детализированниые прототипы: бумага

Изготовлен из самых доступных компонентов - бумаги, ручек и
скотча - бумажные прототипы (рис. 5-2) позволяют вам
моделировать опыт быстро, хитро, и с юмором. Цифровых
инвестиций не требуется. Использование клапанов, чтобы показать
и скрыть различные состояния на странице или даже создание
«окна» для слайд-шоу изображений для перемещения, дает
команде ощущение того, как продукт должен функционировать. Вы
сможете сразу понять, что доступно и чего не хватает. Бумажное
прототипироРисунок 5-2. Пример бумажного прототипа

вание может дать вам ощущение, как рабочий процесс начинает

объединяться между элементы интерфейса, которые вы собрали.
Бумажное прототипирование особенно полезно с сенсорными
интерфейсами, которые требуют от пользователя манипулирования
элементами на экране.

За

• Может быть создан в течение часа

• Легко создать и изменить

• Дешевый

• Можно собрать из материалов, имеющихся в офисе

• Забавное занятие, которое нравится многим людям

Против

• Быстрые итерации и дублирование прототипа могут стать

времязатратными и утомительными

• Симуляция очень искусственна, потому что вы не используете

фактические механизмы ввода (мышь, трекпад, клавиатура,
сенсорный экран и т. д.)

• Обратная связь ограничена верхнеуровневой структурой и

подачей продукта
Низко детализированниые прототипы: кликабельные
вайрфреймы

Передача опыта при помощи интерактивных каркасов (рисунок

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

Рисунок 5-3. Пример прототипа с интерактивным каркасом

За

• Обеспечивает хорошее представление о продолжительном

рабочего процесса

• Выявляет основные препятствия на пути выполнения задачи

• Позволяет оценить находимость основных элементов

• Может быть использован для быстрого создания «чего-то

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

Против

• Большинство людей, которые будут взаимодействовать с

этими прототипами, достаточно опытны, чтобы распознать
незаконченный продукт

• Больше внимания, чем обычно, уделяется маркировке и

копированию

Инструменты для создания кликабельных вайрфреймов с

низким качеством воспроизведения

Вот некоторые из инструментов, которые хорошо работают для

этого типа прототипирования:

Balsamiq
Недорогой инструмент для создания прототипов, который
обеспечивает "схематичный" вид результата. Это самая близкая
вещь к цифровым наброскам интерфейсов и имеет надежное
сообщество. Его ограничения - то, что делает его мощным
инструментом; вы не можете тратить время на настройку тонкостей
интерфейса, так что вы тратите больше времени на проверку
гипотез. Способность легко связать страницы вместе делает его
отличным инструментом для раннего создания прототипов.

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

Figma
Современный инструмент для простого создания как прототипов
любой степени сложности. Простой интерфейс и широкий
функционал. До 10 проектов бесплатно. Есть веб версия и
десктопное приложение.

Miro (Realtimebord)
Онлайн. Сервис позволяющий сразу несколькими пользователям
работать с документом в режиме реального времени. Удобен для
распределенных команд. Интерфейс представляет собой чистый
холст с инструментами.

Новые ресурсы для прототипирования и тестирования

продуктов появляются постоянно, вы можете выбрать любой
подходящий вам для конкретной ситуации.

Прототипы средней и высокой точности

Прототипы средней и высокой точности (см. Рис. 5-4) содержат

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

формы, поля, раскрывающиеся меню, которые работают, и кнопки

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

• Производит качественные и реалистичные прототипы

• Можно проверить визуальный дизайн и элементы бренда

• Можно оценить взаимодействие рабочего процесса и

пользовательского интерфейса

Против

• Интерактивность все еще более ограничена, чем у полностью

нативных прототипов

• Пользователи обычно не могут взаимодействовать с

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

• В зависимости от инструмента создание и поддержка этих

прототипов может занять много времени; поддержание
высокоточного прототипа и синхронизация его с реальным
продуктом часто требует дублирования усилий

Инструменты для создания кликабельных каркасов

средней и высокой точности

Вот некоторые из инструментов, которые хорошо работают для

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

Figma

Sketch

Прототипы с кодом

Прототипы, написанные кодом, обеспечивают высочайший

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

Для кодовых прототипов существует два уровня точности: ручной

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

За

• Возможность повторного использования кода для

производства

• Самый реалистичный симулятор

• Может генерироваться из существующих активов кода

Против

• Команда может увязнуть в обсуждении тонкостей прототипа

• Трудоемкий процесс создания рабочего кода, который

обеспечивает желаемый опыт

• Соблазн совершенствовать код перед показом клиентам

• Обновление и итерации могут занять много времени

ЧТО ДОЛЖНО ВОЙТИ В МОЙ ПРОТОТИП?
Вы выбрали инструмент для создания MVP и готовы приступить
к работе. Нет необходимости прототипировать весь опыт продукта.
Вместо этого смоделируйте наиболее важную часть опыта для
вашего клиента и вашего бизнеса. Сосредоточьтесь на основных
рабочих процессах, которые иллюстрирует ваш MVP.

Сосредоточение внимания на основных рабочих процессах

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

Рисунок 5-5. Где прототипирование вписывается в цикл Lean UX.

Демо версии и превью

Протестируйте свой прототип MVP с вашими товарищами по

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

Прототипы помогают показать заинтересованным сторонам

проекта, что прогресс достигнут. Если у вашей команды есть
демонстрационный день (а если нет, то должен), принесите
прототип туда, чтобы показать прогресс в проекте. Чем больше
внимания получает MVP, тем больше у вас будет представление о
его достоверности. Далее, передайте свой прототип клиентам и
потенциальным клиентам. Позвольте им потестировать его и
соберите отзывы.

Обобщим: использование прототипа MVP

Вот как одна команда, с которой я недавно работал,

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

У этого успешного стартапа были сложности с текущим

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

• Примут ли нынешние пользователи это изменение, учиты

вая, что оно изменит исключительный характер сообщества?

• Будет ли новый сегмент рынка заинтересован в этом типе

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

Я работал с командой, чтобы сформулировать наш план как

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

Мы потратили неделю на создание прототипов с

использованием Balsamiq, чтобы наши разработчики, маркетологи
и руководители были в курсе нового направления. В течение этих
пяти дней мы показывали прототипы текущим клиентам (дважды!)
И получили прототип с интерактивной системой управления - наш
MVP.

Срок нашего эксперимента был выбран случайно: на следующей

неделе в Техасе была запланирована конференция с
потенциальными клиентами. Команда прилетела на конференцию
и обошла залы конференц-центра с прототипом на наших iPad.

Макеты отлично работали на iPad: клиенты тапали, свайпали и

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

Мы собрали заметки в группы, и появились некоторые четкие

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

В общей сложности мы потратили восемь рабочих дней на

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

Непрототипный MVP

Для многих команд подходом по умолчанию к созданию MVP

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

Иногда имеет смысл создать MVP, который не моделирует ваш

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

Мантра, которую следует иметь в виду при создании

непрототипных MVP, такова: вы всегда можете сделать меньше.

Чтобы спланировать свой MVP, задайте себе следующие

вопросы:

1. Что я пытаюсь понять?

2. Какие основные сигналы мне нужны от рынка для проверки

моей гипотезы?

3. Есть ли какие-либо другие сигналы, которые я могу

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

В качестве примера, давайте ответим на эти вопросы для

решения, которое хочет проверить компания электронной
коммерции:

1. Что я пытаюсь понять? Мы пытаемся узнать, увеличит ли это

новое решение для электронной коммерции количество
продаж.

2. Какие основные сигналы мне нужны от рынка для проверки

моей гипотезы? Основным сигналом, который мы ищем на
рынке, является увеличение количества совершенных
покупок.

3. Есть ли какие-либо сигналы, которые я могу проверить,

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

4 . Какой самый быстрый способ для меня найти эту

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

Типы непрототипных MVP

Давайте кратко рассмотрим некоторые методы создания MVP

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

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

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

Гибриды и Творчество

Когда я общаюсь с командами и владельцами бизнеса, меня

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

Вот пример того, как Шерил Йео запустила CityPockets,

используя гибридный подход, называемый Concierge MVP, чтобы
выяснить, решила ли ее идея реальную проблему и было ли
достаточно спроса, чтобы оправдать ее реальное создание.

Шерил Йео основала CityPockets на основе гипотезы о том, что у

людей возникают проблемы с управлением, отслеживанием и
погашением всех ежедневных сделок и купонов, которые они
приобрели в Интернете. Она взяла интервью у клиентов, чтобы
подтвердить, что это действительно необходимо, но она не была
уверена, что ее решение - онлайн-кошелек для всех этих купонов -
принесет такую ценность, которая нужна этим клиентам. Чтобы
подтвердить свою гипотезу, она запустила версию CityPockets.com
для MVP, в которой был только внешний интерфейс. Построение
необходимой серверной обработки и интеграции, было бы
дорогостоящим; она не хотела тратить свои деньги, пока не была
уверена, что ее клиенты сочтут ее продукт ценным.

Вместо создания серверной части, Шерил назначала

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

Этот подход, хотя и включал в себя некоторый дизайн и

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

Заключение

В этой главе мы определили минимальный жизнеспособный

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

В главе 6 мы рассмотрим различные виды исследований,

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

Обратная связь и
исследования

Исследование это формализованное

любопытство. Оно пробует и любопытствует с
определенной целью.
Zora Neale Hurston

Настало время проверить наш MVP. Вся наша работа до этого

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

Исследование пользователей лежит в основе большинства

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

В этой главе мы рассмотрим:

• Методы совместных исследований, которые позволяют вам

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

• Какие артефакты для тестирования и какие результаты вы

можете ожидать от каждого из этих тестов

• Как включить голос клиента в цикл Lean UX

• Как использовать A/B-тестирование (описано далее в этой

главе) в ваших исследованиях

• Как примирить противоречивые отзывы из разных

источников

Непрерывный и совместный

Lean UX использует основные методы исследования UX и

накладывает на них две важные идеи.

Во-первых, исследования Lean UX непрерывны; это означает,

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

Во-вторых, исследования Lean UX являются совместными: вы не

полагаетесь на работу специализированных исследователей, чтобы
донести знания до своей команды. Вместо этого исследовательская
деятельность и обязанности распределяются по всей команде.
Устраняя разрыв между исследователями и членами команды, мы
повышаем качество нашего исследования. Наша цель во всем этом
заключается в создании взаимопонимания в команде.
Смотрите рисунок 6-1.
Рисунок 6-1. Сбор отзывов с помощью исследований является
последним этапом цикла Lean UX.

СОВМЕСТНОЕ ОТКРЫТИЕ
Совместное проектирование (рассматривается в главе 4) - это
один из двух основных способов объединения функций в команде
Lean UX. Совместное открытие - работа в команде для проверки
идей на рынке - другое. Совместное открытие - это подход к
исследованию, который выводит всю команду из здания - в прямом
и переносном смысле - чтобы встретиться и поучиться у заказчиков.
Это дает возможность каждому члену команды увидеть, как
проверяются гипотезы, и, что самое важное, умножает количество
входных данных, которые команда может использовать для сбора
информации о клиенте.

Важно, чтобы вы и ваша команда проводили совместные

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

Исследователи иногда возражают против такого подхода к

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

Совместное открытие в полевых условиях

Совместное открытие - это способ выйти на поле с вашей
командой. Вот как вы это делаете:

• Как команда, просмотрите ваши вопросы, предположения,

гипотезы и MVP. Решите, как команда, что вам нужно узнать.

• Работая в команде, решите, с кем вам нужно поговорить,

чтобы достичь целей исследования.

• Создайте руководство по интервью (см. Следующую боковую

панель), которое вы все сможете использовать для ведения
своих бесед.

• Разбейте свою команду на пары для интервью, смешивая

различные роли и дисциплины в каждой паре (т.е.
старайтесь не связывать дизайнеров с дизайнерами).

• Вооружите каждую пару версией MVP.

• Отправьте каждую команду на встречу с клиентами/

пользователями.
 • Пусть один член команды проводит интервью, а другой
делает записи.

• Начните с вопросов, разговоров и наблюдений.

• Продемонстрируйте MVP позже в сеансе и разрешите клиенту

взаимодействовать с ним.

• Соберите заметки, как клиент обеспечивает обратную связь.

• Когда ведущий интервьюер закончил, поменяйтесь ролями,

чтобы дать возможность записывавшим задавать
дополнительные вопросы.

• В конце интервью попросите клиента направить вас к другим

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

Руководство по интервью

Чтобы подготовиться к полевым работам, создайте небольшую

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

Планируя свои вопросы, подумайте о последовательности:

сначала попытайтесь определить, входит ли клиент в вашу
целевую аудиторию. Затем попробуйте подтвердить любые
проблемные гипотезы, которые у вас есть для этого сегмента.
Наконец, если у вас есть прототип или макет, покажите это
клиенту последним, чтобы не ограничивать разговор своим
видением решения.
Совместное открытие: пример
Команда, с которой я работал в PayPal, приступила к созданию
прототипа Axure для проведения сеанса совместного открытия.
Команда состояла из двух дизайнеров, исследователя UX, четырех
разработчиков и менеджера по продукту; они разделились на
команды по два и три. Каждый разработчик был в паре с не
разработчиком. Прежде чем приступить к работе, команда провела
мозговой штурм в том, что они хотели бы узнать из своего
прототипа, и использовала результаты этого сеанса для написания
кратких руководств для интервью. Их продукт был нацелен на
широкий потребительский рынок, поэтому они решили отправиться
в торговые центры возле своего офиса. Каждая пара
предназначалась для своего торгового центра. Они провели два часа
в поле, останавливая незнакомцев, задавая им вопросы и
демонстрируя свои прототипы. Чтобы создать свой набор навыков,
они поменялись ролями (от ведущего интервьюера до записчика) за
час до начала исследования.

Когда они собрались, каждая пара прочитала свои заметки для

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

Непрерывное открытие
Важнейшей передовой практикой в Lean UX является создание
регулярного ритма участия клиентов. Регулярно запланированные
разговоры с клиентами сводят к минимуму время между созданием
гипотез, подготовкой исследования и отзывами пользователей, что
позволяет быстро проверить свои гипотезы. В общем, знание, что от
обратной связи с клиентом вас отделяет пара дней, оказывает
мощное влияние на команды. Это снимает с вас давление при
принятии решений, потому что вы знаете, что вы не получите более
чем в нескольких днях от получения значимых данных с рынка.

Непрерывное открытие в лаборатории: три

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

Мне нравится использовать еженедельный ритм для

привлечения клиентов в офис для участия в исследованиях. Я
называю это «3-12-1», потому что оно основано на следующих
рекомендациях: три пользователя за 12 часов один раз в неделю
(рис. 6-2).

Рисунок 6-2. Календарь активности 3-12-1.

Вот как рушится деятельность команды:

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

Вторник: уточнение компонентов теста

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

Среда: продолжение уточнений, написание сценария и

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

Четверг: тестирование!
Проведите утреннее тестирование MVP с клиентами. Не трать более
часа с каждым клиентом. Все в команде должны делать заметки.
Команда должна планировать смотреть из отдельного места.
Просмотрите результаты со всей командой проекта сразу после того,
как последний участник завершит тест.

Пятница: планирование
Используйте свое новое понимание, чтобы решить, были ли ваши
гипотезы проверены и что вам нужно делать дальше.
Упростите свою тестовую среду
Многие фирмы создали собственные юзабилити-лаборатории;
Раньше было то, что вам нужно. В наши дни вам не нужна
лаборатория - все, что вам нужно, это тихое место в вашем офисе и
компьютер с сетевым подключением и веб-камерой. Одним из
специализированных инструментов, который я рекомендую,
является программное обеспечение для записи и вещания на
рабочем столе, такое как Morae, Silverback или GoToMeeting.

Вещательное программное обеспечение является ключевым

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

Кто должен смотреть?

Краткий ответ: вся ваша команда. Как и почти во всех других

аспектах Lean UX, юзабилити-тестирование должно быть
групповым занятием. Поскольку вся команда наблюдает за тестами,
получает обратную связь и реагирует в режиме реального времени,
вам потребуется меньше последующих дебрифингов. Команда
узнает из первых рук, где их усилия преуспевают и терпят неудачу.
Нет ничего более унизительного (и мотивирующего), чем видеть,
как пользователь борется с программным обеспечением, которое вы
только что создали.

Слово о наборе участников

Набор, планирование и подтверждение участников занимает
много времени. Предотвратите эти дополнительные издержки,
перенеся работу на стороннего вербовщика. Рекрутер выполняет
работу и получает оплату за каждого участника, которого он или она
приводит. Кроме того, рекрутер заботится о проверке,
планировании и замене неявок в день тестирования. Эти рекрутеры
могут стоить от 75 до 150 долларов за каждого привлеченного
участника.

ПРИМЕР ИЗ ПРАКТИКИ: ТРИ ПОЛЬЗОВАТЕЛЯ

КАЖДЫЙ ЧЕТВЕРГ ОТ MEETUP
Одна из компаний, которая подняла концепцию «трех
пользователей каждый четверг» на новый уровень, - Meetup.
Основанная в Нью-Йорке под руководством вице-президента по
продуктам, стратегии и сообществу Андрес Глусман, Meetup начала
с желания протестировать каждую из своих новых функций и
продуктов.

После того, как они оценили некоторые аутсорсинговые

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

Со временем они перешли к тестированию в одной комнате, к

которому присоединился только модератор. Остальная часть
команды смотрела видеопоток из отдельного конференц-зала
(Meetup изначально использовал Morae для обмена видео; сегодня
они используют GoToMeeting).

Meetup не пишет сценарии тестирования, потому что они не

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

Meetup набирается непосредственно из сообщества Meetup с

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

Команда расширилась с трех пользователей один раз в неделю

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

Практическая минимальная жизнеспособная ориентация

процесса Meetup также проявляется в их подходе к мобильному
тестированию. По мере роста числа пользователей мобильных
устройств, Meetup не хотел откладывать тестирование на
мобильных платформах, ожидая появления модного мобильного
оборудования для тестирования. Вместо этого они построили свои
собственные - за 28 долларов (см. Рис. 6-3).
Рисунок 6-3. Мобильная платформа тестирования юзабилити Meetup.
 Начиная с 2012 года, Meetup успешно масштабировала свой
минимальный жизнеспособный процесс тестирования юзабилити
до впечатляющей программы. Они проводят около 600 тестовых
сессий в год на общую сумму около 30 000 долларов США (не
включая расходы на персонал). В эту стоимость входит 100-
процентное покрытие видео и заметок для каждой сессии. Если
учесть, что это примерно эквивалентно затратам на проведение
одного крупного исследования юзабилити на аутсорсинге, это
достижение действительно поразительно.

ОСМЫСЛЕНИЕ ИССЛЕДОВАНИЯ -
КОМАНДНАЯ ДЕЯТЕЛЬНОСТЬ
Независимо от того, выполняет ли ваша команда полевую или
лабораторную работу, исследования генерируют много
необработанных данных. Осмысление этих данных может занять
много времени и разочаровать, поэтому этот процесс часто
передается специалистам, которых просят обобщить результаты
исследований. Вы не должны так поступать. Вместо этого старайтесь
изо всех сил, чтобы разобраться в данных всей командой.

Как можно скорее после окончания исследовательских сессий -

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

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

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

Проверить с другими источниками

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

Например, наши регулярные тестовые сессии в TheLadders

показали интересное изменение отношения наших клиентов с
течением времени. В 2008 году, когда мы впервые начали
регулярно встречаться с соискателями, мы обсуждали различные
способы общения с работодателями. Одним из предложенных нами
вариантов было SMS. Поскольку наша аудитория, как правило,
состояла из соискателей и нанимателей с высоким доходом,
которым было около сорока и ранних пятидесяти, их ранние ответы
показали сильное презрение к SMS как к законному способу
общения. Для них это было то, что делали их дети (и, возможно, они
делали это со своими детьми), но это, конечно, не был
«правильный» способ поиска работы.

К 2011 году, однако, SMS-сообщения взлетели в Соединенных

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

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

Скетчи
Отзывы, собранные по скетчам (рис. 6-4), помогут вам
подтвердить ценность вашей концепции. На этом уровне вы не
получите тактическую, пошаговую обратную связь с процессом,
понимание элементов дизайна или даже значимые отзывы о выборе
копий. Вы Рисунок 6-4. Пример эскиза, который можно
использовать с покупателями.

не сможете много узнать (если вообще что-нибудь) о юзабилити

вашей концепции.
Статические вайрфреймы
Отображение вайрфремов участников теста (рис. 6-5) позволяет
оценить иерархию информации и структуру вашего опыта. Кроме
того, вы получите обратную связь по таксономии, навигации и
информационной архитектуре.

Вы получите первые отзывы о рабочем процессе, но на этом

этапе участники вашего теста сфокусированы в основном на словах
на странице и выбранных ими вариантах. Каркасы предоставляют
Рисунок 6-5. Пример каркаса.

хорошую возможность начать тестирование вариантов

копирования.

Визуальные макеты высокого качества (не

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

Некликабельные макеты по-прежнему не позволяют вашим

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

Макеты (кликабельные)
Набор интерактивных макетов - по сути, прототип, созданный в
Axure, Sketch, Figma, invision, или любом другом жизнеспособном
инструменте для создания прототипов (см. Рис. 6-6) - позволяет
избежать ошибок при отображении экранов, которые не связаны
друг с другом. Пользователи видят фактические результаты своих
кликов. Этот тип макета не позволит вам оценить взаимодействие с
данными (например, вы не сможете проверить эффективность
поиска), но вы все равно сможете многое узнать о структуре вашего
продукта.
Рисунок 6-6. Пример кликабельного макета из Skype в классе.
Прототипы с кодом
Живой код - это лучший опыт, который вы можете поставить
перед своими участниками тестирования. Он копирует дизайн,
поведение и рабочий процесс вашего продукта. Обратная связь
реальна, и вы можете применить ее непосредственно к опыту. Вы
можете смоделировать соединение с живыми данными или
фактически подключиться к действующим данным; если вы хорошо
подготовите тестирование, пользователи не смогут отличить, но их
реакция предоставит вам прямое представление о том, как
реальные данные влияют на восприятие (Рисунок 6-7).

Рисунок 6-7. Клиенты могут предоставить обратную связь по

многим каналам.
МЕТОДЫ МОНИТОРИНГА ДЛЯ
НЕПРЕРЫВНОГО, СОВМЕСТНОГО ОТКРЫТИЯ
В предыдущих обсуждениях в этой главе я рассмотрел способы
регулярного использования качественных исследований для оценки
ваших гипотез. Но как только вы запустите свой продукт или
функцию, ваши клиенты начнут давать вам постоянные отзывы - и
не только о вашем продукте. Они расскажут вам о себе, о рынке, о
конкуренции. Это понимание неоценимо и проникает в вашу
организацию со всех сторон. Ищите эти сокровища клиентской
разведки в вашей организации и используйте их для управления
вашим текущим дизайном продукта и исследованиями.

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

• Обратитесь к ним и спросите, что они слышат от клиентов о

разделах продукта, над которым вы работаете.

• Проводите регулярные ежемесячные встречи с ними, чтобы

понять тенденции. Что клиенты любят в этом месяце? Что
они ненавидят?

• Используйте их глубокие знания продукта, чтобы узнать, как

они решат проблемы, над которыми работает ваша команда.
Включите их в сессии дизайна и обзоры дизайна.

• Включите ваши гипотезы в свои сценарии вызовов - один из

самых дешевых способов проверить ваши идеи - предложить
их в качестве исправления клиентам, звонящим с похожей
жалобой.
 В середине 2000-х я руководил командой UX в средней
технологической компании в Портленде, штат Орегон. Одним из
способов, которым мы расставили приоритеты в работе, была
регулярная проверка пульса клиентской базы. Мы сделали это с
постоянной ежемесячной встречей с нашими представителями
обслуживания клиентов. Каждый месяц они предоставляли нам
лучшие 10 вещей, на которые жаловались клиенты. Мы
использовали эту информацию, чтобы сосредоточить наши усилия
и впоследствии измерить эффективность нашей работы. Если мы
пытались решить одну из этих болевых точек, ежемесячный
разговор давал нам четкое представление о том, приносили ли
наши усилия плоды; если проблема не попадала в список 10
лучших, наше решение не сработало.

Дополнительным преимуществом этих усилий было то, что

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

Обзоры обратной связи на месте

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

• Простые формы электронной почты

• Форумы поддержки клиентов

• Сторонние сайты сообщества

Вы можете использовать эти инструменты для исследования,

выполняя такие действия, как:
 • Подсчет количества входящих сообщений электронной
почты, которые вы получаете от определенного раздела
сайта

• Участие в онлайн-дискуссиях и предложение некоторых

ваших гипотез

• Поиск сайтов сообщества для труднодоступных участников

теста

Эти входящие каналы обратной связи с клиентами

обеспечивают обратную связь с точки зрения ваших самых
активных клиентов.

Вот несколько тактик для получения других точек зрения:

Журналы поиска

Условия поиска - это четкие индикаторы того, что клиенты ищут

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

Одним из способов использования журналов поиска для

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

Аналитика использования сайта

Журналы использования сайта и аналитические пакеты,

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

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

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

A / B тестирование

A/B-тестирование - это методика, изначально разработанная

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

Вот как это работает: возьмите предложенный опыт (вашу

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

Есть несколько компаний, которые предлагают наборы A/B-

тестирования, но все они в основном работают одинаково. Название
предполагает, что вы можете протестировать только два варианта,
но на самом деле вы можете протестировать столько вариантов,
сколько захотите (это называется A / B / n-тестированием).
Хитрость заключается в том, чтобы убедиться, что изменения,
которые вы делаете, достаточно малы, чтобы любое изменение в
поведении можно было связать с ними напрямую. Если вы меняете
слишком много вещей, любое изменение поведения не может быть
напрямую связано с вашей единственной гипотезой.

Компании, которые предлагают инструменты A / B-

тестирования, включают Unbounce для тестирования целевой
страницы, Эксперименты с контентом Google (ранее Site Optimizer),
Adobe Test & Target (ранее Omniture) и Webtrends Optimize.
Заключение

В этой главе я рассказал о многих способах начала проверки

MVP и экспериментов, которые вы построили на основе своих
гипотез. Я посмотрел на методы непрерывного открытия и
совместного обнаружения. Я рассказал, как построить простой
процесс юзабилити-тестирования каждую неделю, и рассказал о
том, что вы должны тестировать и чего ожидать от этих тестов. Я
также рассмотрел способы мониторинга вашего взаимодействия с
клиентами в контексте Lean UX и затронул возможности A/B-
тестирования.

Эти методы, используемые в сочетании с процессами,

описанными в главах с 3 по 5, составляют полный цикл процесса
Lean UX. Ваша цель - циклически проходить этот цикл как можно
чаще, совершенствуя свое мышление с каждой итерацией.

В следующем разделе я отойду от процесса и рассмотрю, как

Lean UX интегрируется в вашу организацию. Независимо от того,
являетесь ли вы стартапом, крупной компанией или цифровым
агентством, я расскажу обо всех организационных изменениях,
которые вам необходимо будет сделать для поддержки подхода Lean
UX. Эти идеи будут работать в большинстве существующих
процессов, но в главе 7 я конкретно расскажу, как сделать
совместную разработку Lean UX и Agile.
РАЗДЕЛ III
РЕАЛИЗАЦИЯ

С 2007 по 2011 год я возглавлял команду UX в TheLadders,

онлайн-доске вакансий в Нью-Йорке. За время моей работы
компания начала переход от Waterfall к Agile. Это была инициатива
разработчика, но компания признала, что если не включить UX,
переход будет неудачным. Я должен был выяснить, как мы
интегрируем Lean UX с этим новым стилем работы. В 2007 году,
если вы гуглили«Agile UX», страница результатов была завалена
сообщениями в блогах, статьями и тематическими исследованиями,
в которых задокументированы неудачи и разочарования.
Основными темами, казалось, были крики «Agile sucks!» И статьи,
утверждающие, что «UX не работает таким образом».

Не останавливаясь, я продолжал искать идеи сотрудничества и

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

Мы были убеждены, что есть лучший путь, поэтому, подобно

хорошим Agilistas, мы продолжали настраивать наш процесс. Через
несколько месяцев я почувствовал, что мы добились успеха. Мы
расширили сотрудничество, начали выпускать меньше документов
и усилили усилия по проверке клиентов. Внутренние крики
«Проворный отстой» и «Я ненавижу это» также стихли. Я
чувствовал себя довольно хорошо о нашей маленькой команде.

Однажды утром в понедельник я вошел в офис, готовый начать

неделю, и обнаружил, что диаграмма на рисунке III-1 распечатана и
аккуратно положена на мой стол.

Рисунок III-1. Команда UX в TheLadders выразила свои чувства по

поводу наших усилий по интеграции Agile / UX.

Оказывается, все было не так радужно, как я думал. Моя

команда ушла и провела свою собственную ретроспективу (читай:
разгрузочное занятие) и подготовила эту диаграмму как
«удобочитаемую» для меня. Это застало меня врасплох, но когда я
углубился в детали документа и обсудил ключевые болевые точки с
командой, дыры в нашем процессе стали очевидными.
 Посмотрите на диаграмму: если вы пытались интегрировать Ag-
ile и UX, возможно, вы узнаете некоторые из этих проблем. Команда
чувствовала, что не было достаточно времени, чтобы выполнить
работу с «золотой медалью». Они чувствовали, что их работа не
была критической. Они чувствовали, что у них не было времени для
повторения. Список можно продолжить. Когда я показываю эту
диаграмму другим командам, пытающимся интегрировать Agile и
UX, всегда есть много печальных улыбок признания.

Присутствие этой диаграммы на моем столе было унизительным

опытом, но оно затронуло диалог и включило процесс обучения,
который лежит в основе Agile-подходов. Диалог позволил нам
начать процесс открытия, который в конечном итоге привел к
межфункциональному сотрудничеству, которое сделало наш Agile-
процесс успешным, как описано в Разделе II.

О разделе III

Как вы можете интегрировать процесс Lean UX в вашу

организацию? На этот вопрос я отвечу в разделе III.

В главе 7 «Интеграция Lean UX и Agile» я рассмотрю тактику,

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

В главе 8 «Внесение организационных изменений» я расскажу

о конкретных организационных изменениях, которые необходимо

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

Интеграция Lean UX
и Agile

Гибкие методы в настоящее время широко распространены. Так

же, как и дизайн пользовательского опыта, благодаря огромному
успеху таких продуктов, как Kindle и iPhone. Но заставить Agile
работать с UX долго было проблемой. В этой главе я рассмотрю, как
методы Lean UX могут вписаться в самый популярный вариант Agile
- процесс Scrum, - и расскажу о том, как сочетание Lean UX и Agile
может создать более продуктивную команду и более совместный
процесс. Я освещу:

Определение терминов
Просто чтобы убедиться, что мы все на одной странице о некоторых
словах, таких как «спринт» и «история».

Ступенчатые спринты
Единовременный спасатель интеграции с Agile/UX - это всего лишь
ступенька к настоящему сплочению команды.

Прослушивание ритмов Scrum

Места проведения собраний Scrum являются четкими ориентирами
для интеграции Lean UX.
Участие
Действительно кросс-функциональный процесс требует, чтобы
каждый был его частью.

Дизайн как командный вид спорта

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

Курс вверх и наружу

Устраните препятствия на пути прогресса вашей команды, проявив
инициативу в общении.

Некоторые определения

Agile процессы, в том числе Scrum, используют множество

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

Scrum
Гибкая методология, продвигающая циклы, ограниченные по
времени, самоорганизацию команды и высокую ответственность
команды. Скрам - самая популярная форма Agile.

Пользовательская история
Наименьшая единица работы выражается в пользе для конечного
пользователя. Типичные пользовательские истории пишутся с
использованием следующего синтаксиса:
Как [тип пользователя]
Я хочу [достичь чего-то], чтобы [что-то получилось]
Беклог
Приоритетный список пользовательских историй. Беклог - самый
мощный инструмент управления проектами в Agile. Именно
благодаря активном уочищению беклога команда управляет своей
ежедневной рабочей нагрузкой и переориентирует свои усилия на
основе поступающих знаний. Это то, как команда остается гибкой.

Sprint
Единый командный цикл. Целью каждого спринта является
предоставление рабочего программного обеспечения. Большинство
команд Scrum работают в двухнедельных спринтах.

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

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

Встреча по планированию итерации

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

В мае 2007 года Дезире Си и Линн Миллер опубликовали

«Адаптационные исследования юзабилити для гибкого,
ориентированного на пользователя дизайна» в Журнале
исследований юзабилити (http://www.upassoc.org/upa_publications/
jus/2007may/ agile-ucd. Pdf). , Си и Миллер были одними из первых,
кто попытался объединить Agile и UX, и многие из нас были рады
решениям, которые они предлагали. В статье Си и Миллер
подробно описывают свою идею продуктивной интеграции гибкого
и ориентированного на пользователя дизайна. Они используют
технику, называемую «Цикл 0» (возможно, вы слышали, что она
называется «Спринт ноль» или «Смещенные спринты»).

Короче говоря, Си и Миллер описывают процесс, в котором

деятельность по дизайну происходит на один шаг впереди
разработки (рис. 7-1). Работа проектируется и проверяется во время
«спринта проекта», а затем передается в поток разработки, который
будет реализован во время спринта разработки.

Рисунок 7-1. Модель «спонтанных спринтов» Си и Миллера.

Многие команды неверно истолковали эту модель. Си и Миллер

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

Пошаговые спринты могут хорошо работать для некоторых

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

Для этих команд ступенчатые спринты могут обеспечить

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

Тем не менее, эта модель лучше всего работает в качестве

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

Есть еще одна причина, по которой этот процесс далеко не

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

СОЗДАНИЕ LEAN UX В РИТМЕ SCRUM

Как я уже говорил в начале этой главы, мы попытались
использовать «Ступенчатые спринты» в TheLadders. И когда у нас
были проблемы, мы продолжали улучшать наш процесс, в
конечном итоге заканчивая совместной работой, которая
разыгрывалась в ритмах Scrum. Давайте посмотрим, как вы можете
использовать структуру собраний Scrum и Lean UX для построения
эффективного процесса.

Темы
Скрам предполагает много встреч. Многие люди недовольны
встречами, но если вы используете их в качестве верстовых столбов
во время спринта, вы можете создать интегрированный процесс
Lean UX и Agile, в котором вся команда работает над одним и тем же
одновременно.

Давайте возьмем двухнедельную модель спринта и

предположим, что мы можем связать серию этих спринтов вместе
под одним зонтиком, который мы назовем темой (рисунок 7-2).
Рисунок 7-2. Спринты связаны вместе с темой.

Встречи для зарисовок и идей

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

После того, как вы начали свои спринты, эти идеи будут

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

Встреча по планированию итерации

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

График тестирования пользователей

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

Участие
Один из больших уроков, которые я извлек из диаграммы,
которую я показал в начале раздела III, заключался в том, что
дизайнерам нужно время для творчества. Двухнедельные циклы
параллельной разработки и дизайна предлагают мало
возможностей для творческого времени. Некоторые Agile методы
используют более гибкий подход ко времени, чем Scrum.
(Например, Канбан покончил с понятием двухнедельной партии
работ и делает упор на цельном потоке.) Но вы все равно можете
найти время в спринте Scrum, в котором могут происходить
творческие действия.

Причина, по которой моя команда UX в TheLadders не нашла

того времени, заключалась в том, что мы не принимали полного
участия в процессе Scrum. Это была не наша вина: содержание
многих встреч Scrum мало что дало разработчикам UX. Однако без
нашего участия наши проблемы и потребности не были учтены в
планах проекта. В результате мы не выделяли время в спринтах для
творческой работы - остальная часть команды не понимала, что это
время было необходимо.
 Чтобы Lean UX мог работать в Agile, вся команда должна
участвовать во всех мероприятиях - в анализе беклога,
ретроспективе, IPM, мозговом штурме - все они требуют успеха от
участия каждого. Помимо согласования сложности определенных
функций, межфункциональное участие позволяет дизайнерам и
разработчикам создавать эффективные расстановки приоритетов.

Например, представьте в начале спринта, что первая история, в

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

Другой жертвой редкого участия является общее понимание.

Команды принимают решения на собраниях. Эти решения
основаны на обсуждениях. Даже если 90 процентов собрания не
имеют отношения к вашей насущной потребности, 10 процентов,
которые имеют отношение к делу, сэкономят часы времени в
потоке, объясняя, что произошло на собрании и почему были
приняты определенные решения.

Участие позволяет договориться о времени, необходимом для

выполнения вашей работы. Это верно как для дизайнеров UX, так
и для всех остальных в команде.
ДИЗАЙН - ЭТО КОМАНДНЫЙ ВИД СПОРТА:
ТЕМАТИЧЕСКОЕ ИССЛЕДОВАНИЕ KNOWSY
В этом тематическом исследовании дизайнер и тренер Лейн
Халли подробно рассказывает, как она собрала за столом всех
игроков - разработчиков, дизайнеров, маркетологов и
заинтересованные стороны - чтобы создать игру для планшета.

В своей работе в качестве дизайнера продуктов я использую

методы Lean UX на различных проектах. Недавно я работал в сфере
развлечений, электронной коммерции и социальных сетей,
мультимедийных продуктов для различных платформ, включая
iPad, iPhone и Web. Команды были небольшими, от трех до семи
человек. Большинство из моих проектов также имели следующие
характеристики:

• Проект выполняется в рамках Agile (фокус на клиента,

• непрерывная доставка, команда сидит вместе, легкая

документация,

• групповое владение решениями, общими ритуалами, такими

как пятиминутки, ретроспективы и т. д.).

• Команда состоит из людей с различными навыками (фронт и

бэкэнд

• разработка, пользовательский опыт и информационная

архитектура, продукт менеджмент и маркетинг, графический
дизайн, копирайтинг).

Люди в команде обычно выступали в своей области знаний /

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

В подобных проектах «зеленых полей» мы одновременно

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

Компания инновационных игр

Компания Innovation Games (TIGC) выпускает серьезные игры
для исследования рынка. TIGC помогает организациям получить
действенное представление о потребностях и предпочтениях
клиентов для повышения производительности через совместную
игру. В 2010 году меня пригласили помочь TIGC создать новую игру
для потребительского рынка.

Я был частью команды, которая создала Knowsy для iPad, pas-

sand-play игру о том, что вы узнаете о своих друзьях, семье и
коллегах, одновременно проверяя, насколько хорошо они вас знают.
Человек, который лучше всех знает других игроков, выигрывает
игру. Это быстрая, веселая и по-настоящему «социальная» игра для
шести игроков.

Это было наше первое приложение для iPad, и у нас был

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

Работая над Knowsy, я искал способы, которыми я мог бы

привнести в свою UX практику больше сотрудничества,
визуального, легкого и итеративного. Я искал возможность работать
в режиме реального времени с другими людьми в команде
(например, разработчики и менеджер по продукту) и грубые вещи
так быстро, как возможно на самом низком уровне ответственности.

Когда мы нашли правильные решения, и команда поняла и

приобрела концепция дизайна, я смог повысить точность
проектирования артефактов, будучи уверенным, что у нас общее
видение продукта (Рисунок 7-6).

Рисунок 7-6. Команда Knowsy со стеной артефактов позади них.

Ломая узкое место в дизайне

В начале проекта я сел с разработчиком внешнего интерфейса,
чтобы поговорить про игровой дизайн. Мы создали общий игровой
поток на бумаге, передавая друг другу, пока мы говорили. Это была
моя возможность слушать и узнать, о чем он думал. Когда мы
набросали, я смог указать несоответствия, задавая такие вопросы,
как: «Что мы делаем, когда это случается?» Этот подход имел
преимущество, меняя диалог с «Я прав, а вы не правы» на «Как мы
решаем эту проблему?».
 После того, как у нас сформировалось это базовое соглашение, я
смог создать бумажный прототип (Рисунок 7-7) игры,
основанРисунок 7-7. Бумажный прототип начинает обретать форму.

ной на потоке, и сыграть в нее с командой. Эффект на команду был

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

Как только мы все оказались на одной странице, мне было легче

потратить некоторое время вдали от команды и зафиксировать то, о
чем мы договорились, в интерактивном прототипе. Смотрите
рисунок 7-8.

Рисунок 7-8. Лейн обновляет прототип и стену артефакта в

реальном времени

Результат
Вступление Knowsy в Lean UX оказалось успешным. Мы
получили приложение для Apple в срок. Позже меня позвали снова,
чтобы помочь команде с еще одним вариантом продукта. Для этого
раунда я использовал похожий процесс. Из-за того, что я работал
удаленно, и команда разработчиков была не так готова к
сотрудничеству, я должен был проделать более сложную работу.
Тем не менее, основной принцип повторения нашего пути к более
высокой точности продолжался.

Помимо Скрам Команды

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

Самое большее, эти команды планируют итерацию или две

вперед. Эта кажущаяся «близорукость» не удовлетворяет
большинство руководителей высокого уровня. Как тогда пройти
проверки, сохраняя темп вашего Lean UX и скрам процессы?

Два слова: проактивная коммуникация.

Однажды я руководил командой, которая радикально изменила

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

Оказывается, что когда у людей возникают проблемы с

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

Этот здоровый кусок скромного пирога послужил ценным

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

Вот несколько советов:

1. Активно обращайтесь к владельцам и руководителям ваших

продуктов.
 Пусть знают:

• Как продвигается проект

• Что вы уже опробовали и узнали

• Что ты будешь делать дальше

2. Сосредотачивайте обсуждения на результатах (как вы близки

к вашей цели), а не наборе функций.

3. Убедитесь, что зависимые отделы (служба поддержки

клиентов, маркетинг, ОПС, и т.д.) знают о предстоящих
изменениях, влияющих на их работу.

4. Предоставьте им достаточно времени для обновления

рабочих процессов, если это необходимо.

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

В следующей и заключительной главе мы рассмотрим

организационные изменения. Это нужно сделать, чтобы поддержать
Lean UX. Эта глава может служить в качестве руководства для
менеджеров о том, что им нужно сделать, чтобы создать команды
для достижения успеха.
ГЛАВА 8

Проведение
организационных
изменений

Ранее в этой книге мы обсуждали принципы, лежащие в основе

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

Когда я тренирую команды, они иногда спрашивают меня “Rак я

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

Чтобы подготовить вас к этой работе, я расскажу в этой главе о

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

В этой главе мы обсудим следующие изменения, которые

возможно понадобится произвести в вашей организации в этих
областях:

1. Переход от результатов (output) к целям (outcomes)

2. Переход от ограниченных ролей к возможностям совместной

работы

3. Освоение новых навыков

4. Создание кросс-функциональных команд

5. Создание малых групп

6. Создание открытых, совместных рабочих пространств

7. Не полагаться на героев

8. Устранение «Big Design Up Front, BUFD” (детальное

проектирование до начала разработки)

9. Скорость в первую очередь, эстетика во вторую

10.Ранжирование решаемых проблем

11. Принятие долга UX

12.Изменение культуры компании

13.Работа со сторонними поставщиками

14.Стандарты навигационной документации

15.Быть реалистами по отношению к вашей среде

16.Управление вверх и наружу

Сдвиг: результаты

В главе 3 я обсуждал роль результатов в бережливом

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

Команды, пытающиеся использовать Lean UX, должны быть

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

Руководство должно задать это направление, а команды должны

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

В большинстве компаний работа, которую вы делаете,

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

Неутешительный кросс-функциональный вклад укрепляет

разделение департаментов компании. Чем более дискретна работа
человека, тем легче ему отступить в безопасное место в пределах
своей дисциплины. В результате: слабый и недоверительный диалог
между дисциплинами, указывание пальцем и “прикрывание своей
задницы». Строгое разделение на департаменты и блоки - это
смерть совместных команд.

Чтобы Lean UX заработал, ваша организация должна принять

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

Позвольте вашим коллегам внести свой вклад в любые

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

Многие компании нанимают дизайнеров для создания

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

Дизайнеры должны открыть процесс проектирования.

Дизайн продукта должен принадлежать команде, а не

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

Дизайнеры должны взять на себя ведущую роль в своей команде.

Ваши коллеги привыкли критиковать вашу дизайнерскую

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

Для многих команд сотрудничество - это деятельность,

основанная на одной дисциплине. Разработчики решают проблемы
с другими разработчиками, в то время как дизайнеры сидят на
бобовых мешках, зажгите лава-лампы и “генерировать идеи» с
братсвом черных водолазок. (Я шучу...Я люблю дизайнеров!).

Идеи, рожденные в результате сотрудничества в рамках одной

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

Бережливый UX требует межфункционального сотрудничества.

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

Мы уже давно знаем, насколько важно межфункциональное

сотрудничество. Исследование Роберта Дейли, проведенное в конце
1970-х годов, “Роль команды и характеристики задачи в R & D team
совместном решении проблем и производительности, « обнаружило
связь между продуктивностью решения проблем в команде и тем,
что он назвал «четырьмя предикторами»: определенность задачи,
взаимозависимость задачи, размер команды и сплоченность
команды. Держите свою команду сплоченной, ломая
дисциплинарные границы.
Сдвиг: небольшие команды

Большие группы людей менее эффективны, чем малые. Это

интуитивно понятно. Но менее очевидно следующее: меньшая
команда должна работать над небольшой проблемой. Такой
небольшой размер облегчает поддержание дисциплины
необходимой для создания минимально жизнеспособных
продуктов. Разбейте свои большие команды на то, что основатель
Amazon.com Джефф Безос лихо назвал «команды на две
пиццы” (http://www.fastcompany. com/50106/inside-mind-jeff-bezos)
если команде нужно больше двух пицц, то она слишком большая.

Сдвиг: рабочее пространство

Разрушьте физические барьеры, препятствующие

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

При совместном размещении людей создавайте

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

Если совместное размещение - не вариант, предоставьте

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

Сдвиг: больше никаких героев

В командах, с которыми я работал до сих пор, не было

разработчиков, которые противились бы Lean UX. Именно
дизайнеры сопротивлялись больше всего. В чем причина? Многие
дизайнеры хотят быть героями.

В среде, в которой дизайнеры создают прекрасные результаты,

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

Я не утверждаю, что все эти проекты поверхностны. Обучение,

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

Создатели этих документов провозглашаются лидерами мысли

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

Если коротко, нет!

Для того чтобы Lean UX преуспел в вашей организации, все

типы участников - дизайнеры и недизайнеры - должны активно

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

У Lean UX буквально нет времени на героев. Вся концепция

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

Больше никаких BDUF, детка.

В сообществе Agile вы иногда слышите, как люди говорят о Big

Design Up Front, или BDUF. Я уже давно выступаю за то, чтобы
отойти от BDUF. Но так было не всегда.

В начале 2000-х я был дизайнером пользовательского

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

Один разработчик устал ждать меня и начал реализовывать

некоторые из идей еще до того, как документы были закончены.
Боже, как же я расстроился! Как мог он идти вперед без меня?
Откуда ему знать, что именно делать? Что, если это было бы
неправильно или не работало бы? Ему пришлось бы переписать
весь код!

Оказалось, что проделанная им работа позволила нам увидеть

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

Ирония зависимости команды от документов и «вдохновения»,

которое они дают, в том, что разработчик не был потерян для нас.
Фактически, в конце проекта, мне дали шуточную награду за
вдохновление товарища по команде на «недокументированное
творчество».

Сдвиг: сначала скорость, потом - эстетика

Джейсон Фрид, генеральный директор 37Signals, однажды

сказал “сначала скорость, потом - эстетика” (https://twitter.com/ ja-
sonfried/status/23923974217). Он говорил не о том, что качество не
важно. Он говорил о том чтобы изменить идеи и процесс в корне. В
Lean UX быстрая работа означает создание множества артефактов.
Не тратьте время на споры о том, какой тип артефакта создать, и не
тратьте время, шлифуя их до совершенства. Вместо этого
используйте тото, чтобыстрее создать и обсудить с командой.
Помните, что эти артефакты являются преходящей частью проекта -
как разговор. Создайте. Покажите. Обсудите. Двигайтесь дальше.

Эстетика - в смысле визуального дизайна - это неотъемлемая

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

визуальную часть до идеала. Однако, прилагать такие же усилия по

визуализации на ранней стадии проектирования и создания
прототипов —это пустая трата времени.

Жертвуя совершенством промежуточных артефактов дизайна,

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

Сдвиг: Ранжирование решаемых проблем

Lean UX заставляет нас задавать сложные вопросы о том, как мы

оцениваем дизайн.

Если вы дизайнер, читая это, вы, вероятно, задались вопросом,

как это часто происходит, когда скорость превосходит эстетическое
совершенство:
Если моя работа теперь состоит в том, чтобы создавать
концепции вместо готовых идей, каждый идея, которую я
произвожу, кажется бестолковой. На самом деле, я чувствую,
что я « Иду на бронзу». Ничто из того, что я создаю, никогда не
заканчивается. Ничто не демонстрирует, что я способен
проектировать. Я создаю работы “на бронзовую медаль”
нарочно! Как я могу чувствовать гордость собственника за
дизайн, который просто не сделан?

Некоторым дизайнерам кажется, что Lean UX угрожает тому,

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

Хотя ваша организация должна продолжать ценить эстетику,

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

Сдвиг: UX долг

Часто бывает так, что команды, работающие в agile процессах,

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

Джеймс О’Брайен, UX дизайнер, работающий в Лондоне,

описывает, что случилось это, когда его команда начала
отслеживать долг UX таким же образом, как команда отслеживала
технический долг: «эффект был драматическим. Однажды мы
представили [переделку] как долг, всякое противодействие отпало.
Не только не было вопроса о том, чтобы долг не был выплачен, но
он был распределен по приоритетам.»

Чтобы использовать концепцию долга UX, напишите истории,

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

Сдвиг: агентства находятся в бизнесе конечных

результатов

Применение Lean UX в интерактивном агентстве - непростая

задача. Большинство агентств создаются таким образом, чтобы
затруднить внедрение Lean UX, который основан на меж
функциональном сотрудничестве и ориентирован на конечную цель.
Основная бизнес- модель агентства проста: клиенты платят за
результаты, а не за достигнутые цели. Но культура агентства - это
так же огромное препятствие. Культура героев сильна в местах,
которые возвышают людей на такие должности, как
исполнительный креативный директор. Междисциплинарное
сотрудничество также может быть затруднено в крупных агентствах,
где процессы и « проектные стадии « поощряют результаты и
разделение на отделы по дисциплинам. Возможно, самым сложным
препятствием является ожидание клиента « бросить через стену «
агентству, а затем увидеть результаты, когда они будут готовы.
Сотрудничество между клиентом и Агентством в этом случае может
быть ограничено неадекватной и непродуктивной критикой,
основанной на личных предубеждениях, политике и CYA.

Чтобы заставить Lean UX работать в агентстве, все вовлеченные

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

Некоторые агентства пытаются сосредоточиться на достижении

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

Это непростые преобразования — ни для агентства, ни для

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

Краткое замечание о партнерах по развитию

Во внутриагентских отношениях команды разработчиков

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

Сдвиг: работа с субподрядчиками

Сторонние поставщики программного обеспечения представ-

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

При работе c субподрядчиками старайтесь создавать проекты на

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

Сдвиг: стандарты документации

Многие организации имеют строгие стандарты документации,

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

Как выразилась дизайнер и преподаватель Лейн Галлей, «вы

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

Сдвиг: будьте реалистичны в отношении вашего

окружения

Перемены пугают. Подход Lean UX приносит с собой много

изменений.

Изменения могут быть особенно неприятными для менеджеров,

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

Сдвиг: управление вверх и наружу

Lean UX дает командам большую свободу для поиска

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

Два ценных урока для обеспечения более плавных циклов

проверки:

1. Всегда есть другие отделы, на которые влияет ваша работа.

Игнорируйте их на свой страх и риск.

2. Убедитесь, что клиенты знают о любых существенных

предстоящих изменениях и позвольте отказаться от них (по
крайней мере временно).

Последнее слово

Как раз в тот момент, когда мы вносили последние штрихи в эту

главу, мы получили электронное письмо от коллеги. Иногда может
показаться невозможным изменить укоренившееся привычки
организации. Поэтому я был рад получить это письмо, отрывок из
которого я тут приведу. В нем Эмили Холмс, директор K12 UX в
Hobsons, описывает изменения, которые она внесла в своей
организации:
Я думаю, что многие крупные компании изо всех сил пытаются
найти лучший способ реализации этих приемов. Мы изначально
встретили очень высокое сопротивление к тому чтобы перейти
на Lean UX, потому что мы “не стартап», но, конечно, это не
совсем так.
Мы пригласили тренера, чтобы помочь укрепить в команде
наше намерение перейти к методологии Lean UX (внешний голос
может помочь подкрепить то, что предлагается внутри
компании), и с тех пор мы добились хорошего прогресса. Меньше
чем через год, наша структура команды поменялась с этого:

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

Это требует постоянного коучинга с моей стороны, и мы еще

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

Я верю, что многое из того, что работает на нас, может быть

применено к другим организациям вполне успешно.

Я тоже в это верю, и надеюсь что изменения и принципы,

которые я осветил в этой главе помогут вам.
ВЫВОД
Lean UX - это эволюция дизайна продукта. Он сочетает в себе
лучшие методы проектирования взаимодействия с научным
методом для создания продуктов, простых в использовании,
красивых и вполне успешных. Путем смешивания идей стоящих за
Lean Startup, гибкой разработкой программного обеспечения и
дизайн-мышлением, этот подход устраняет раздувание и
неопределенность из процесса дизайна продукта и подталкивает его
к объективно обоснованному результату. Надеюсь, тактика,
стратегия, и реальные примеры в этой книге были полезны для вас.
Я горю желанием продолжить разговор за пределами книги и хотел
бы услышать от вас, как вы решили построить свои команды Lean
UX. Как вы преуспеете и как вы потерпите неудачу, я хочу знать. Я
хочу рассматривать эту книгу как моментальный снимок и
использовать все ваши понимание, чтобы продолжать двигаться к
улучшению дизайна, командной динамики и успеху. Напишите мне
на jeff@ jeffgothelf.com или напишите Джошу по адресу
josh@joshuaseiden. com ирасскажите ваши истории. Мы с
нетерпением ждем вашего ответа.